Decision map

Find the decisions that make a large effort specifiable. Keep a small map as an index and put each question and resolution in one separate document. Work sequentially; this workflow has no claim, lease, assignment, or parallel-agent protocol.

Authority and boundaries

• Treat the destination as the scope boundary, not as permission to implement it. The map is complete when the route to a spec is clear.
• Keep each decision's detailed question, evidence, resolution, and consequences in its decision document. map.md contains only links, status, and one-line gists.
• Use documenting-work to resolve persistence, identity, paths, metadata, index, and lifecycle. Under its fallback, use docs/decision-maps/<name>/map.md and decisions/DNNN-<slug>.md.
• Use domain-modeling when a question actively changes domain terms, invariants, states, relationships, or boundaries. Use codebase-design for a module interface or architectural seam. Record their established outcome in the decision document; do not duplicate their full analysis.
• Use to-spec only after the open decisions and material fog no longer prevent one coherent specification.
• Do not create or mutate tracker issues, implement destination code, claim work, commit, push, publish, or delete documents.

A request to inspect, explain, or draft a possible map is read-only and returns conversation output. A request to create, chart, update, resolve, or continue a named decision map authorizes that repository document set and its required index entry, but not code, prototype files, external writes, or publication. A prototype or prerequisite that changes another artifact requires separate authorization for that artifact.

Chart a map