Research

Resolve technical uncertainty for one identified proposed backlog record before readiness. Research covers both the technologies the delta touches and the concepts, standards, and guidelines it implicates. Findings live with the desired change in docs/backlog. Stay on the current branch.

Preconditions

1. Resolve the project root and read applicable repository instructions.
2. Require the $setup-project scaffold: docs/wiki/index.md, docs/wiki/maintenance.md, docs/backlog/index.md, docs/backlog/maintenance.md, all four backlog type templates, and scripts/validate-project.mjs. If any is missing, stop and direct the user to $setup-project.
3. Run node scripts/validate-project.mjs; on an invalid baseline, report and stop unless the user explicitly asks to repair that state.
4. Require one named EPIC-NNN or WORK-NNN with status: proposed. Without one, offer $backlog intake first. Reject research on a ready, in-progress, or terminal record; never silently reopen it.
5. Read backlog maintenance, the matching type template, the complete named record (delta, parent and child scope, relationships) and directly related records; the wiki root, maintenance rules, nearest indexes, and accepted architecture concepts. Guidance pages are read per subject at step 3, once the inventory exists.

1. Inspect the repository

Inspect evidence bearing on the proposed delta: manifests, lockfiles, runtime and engine files, build and deployment configuration, source imports, tests. Record exact installed or constrained versions with the paths that establish them. Never infer a version from familiarity.

2. Build the subject inventory

A subject is one technology, or one concept, standard, or guideline, that the proposed delta affects or implicates. Inventory subjects only — never survey the whole stack. The project's language, toolchain, and runtime are always subjects when the delta introduces or builds on them.