document-feature-technical

Document a feature — technical

Record the engineering view of a feature: how it actually works, the files that make it up, and the decisions a future maintainer needs. Companion to the document-feature-product rule (the user-facing view).

Where it goes

docs/features/<feature>/technical.md     ← this rule
docs/features/<feature>/product.md       ← document-feature-product rule
docs/features/README.md                  ← index (product rule owns it)

• <feature> is a kebab-case slug. Match it to how the codebase already names the feature (its module/package/directory) so the docs are easy to trace back.
• If this project pins the docs directory elsewhere (via .cursor/doc-everything.json or .claude/doc-everything.json docsPath, or the DOC_EVERYTHING_DOCS_PATH env var), use that path instead of docs/features/.
• One file per feature — update the existing technical.md in place, don't spawn technical-v2.md. Keep it current with the code, not a changelog.

How to write it

1. Read the code first. Describe what the code actually does today, never aspirational or planned behavior. If the project has architectural conventions (a data-access layer, a service pattern, a module boundary), describe the feature in those terms.
2. Fill the template below. Drop sections that genuinely don't apply — say so in one line rather than leaving an empty stub.
3. Link real files as clickable references (path/to/file:line), and cross-link the matching product.md.
4. When you change a feature, update the affected sections (data model, files, decisions) — stale technical docs are worse than none.

Template

# <Feature> — technical

> Product view: ./product.md

## Summary
One or two lines: what this feature does at the system level.

## Status
scaffolded | in progress | shipped — and a line on what's real vs stubbed.

## Architecture & data flow
How it fits the app's architecture. Trace one representative action end to end
(what the user/client triggers → each layer it passes through → where it lands).
Note where reads come from vs where writes go.

## Files & responsibilities
| File | Role |
|------|------|
| `path/to/entry` | request entry / route / handler |
| `path/to/logic` | core logic / use-case / service |
| `path/to/data`  | data access / persistence |
| `path/to/ui`    | UI / presentation |

## Data model
Tables/collections/columns or types touched, and the migration(s) or schema
changes that introduced them. Note any fields with special handling.

## Auth, validation & authorization
Where the request is authenticated, where input is validated, and how access is
authorized. Note the trust boundary (what the client is/ isn't allowed to send).

## External dependencies & integrations
Third-party services, APIs, queues, env vars, or feature flags this relies on.

## Key decisions & trade-offs
Why it's built this way; alternatives rejected; known limitations / TODOs.

## Testing
What's covered (unit / integration / e2e), where those tests live, and how to
run them.

## Extending / gotchas
What a future change most likely touches, and traps to avoid.