ddflow_decision_add
Capture architectural decisions with context, alternatives, and consequences, and link them to relevant code paths so future agents understand why the software is built this way.
Instructions
Record an architectural decision so the project stays consistent and the reasoning survives. Use when you or the operator settle a question about HOW the software is built — a data representation, a boundary, a library choice, an invariant.
ALWAYS set globs to the code it governs: that is what lets the decision be surfaced automatically to whoever works those files later, instead of only being findable by someone who already suspects it exists. Record alternatives too — without it the next agent re-proposes what was rejected.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | 'operator' or 'agent' or a name. | |
| id | No | Stable id, e.g. 'D1'. Choose one: `supersedes`, commit messages and docs all reference it, and a generated id cannot be cited in advance. | |
| item | No | The task it arose from. | |
| tags | No | Comma-separated tags. | |
| globs | No | Comma-separated paths this governs. | |
| title | Yes | The decision as a one-line statement. | |
| status | No | proposed | accepted (default) | superseded. 'proposed' records a decision the operator has not ratified, which is honest about its standing rather than presenting it as settled. | |
| context | No | The forces: why a decision was needed at all. | |
| decision | Yes | What was DECIDED (not what was discussed). | |
| supersedes | No | Comma-separated ids this replaces. | |
| alternatives | No | What was rejected, and why. | |
| consequences | No | What it costs, including what it makes harder. |