Approve a plan
A goal drafts a specification before any code is written. This is what it contains, what saying yes actually authorises, and how to push back.
What approving actually authorises#
Approving a specification is standing approval for the planning and consolidated-QA gates for that one bounded run. Everything those gates guard is local and reversible, which is why they can be cleared in advance.
It is not approval to ship. Opening a pull request is a separate gate that clears on evidence produced minutes earlier — a green suite and a running application from the exact tree about to be pushed.
What to read on the card#
- The decisions
- The choices the specification has made on your behalf. This is where a wrong assumption is cheapest to catch.
- The paths
- Which parts of the repository the work will touch. Anything surprising here is worth a rejection.
- The contracts
- Interfaces between services that the plan intends to rely on or change.
- What it cannot do
- Anything needing a credential, repository access or a passing environment check. A specification blocked on one of these is never auto-approved.
Rejecting well#
Reject, then re-run the goal with a corrective objective. Rejection is not a dead end and does not discard what was learned — the next specification starts from the memory the first one built.
Approval and rejection work identically from the command line, the dashboard and Telegram, so a specification can be cleared from a phone.
Common questions
Can I approve everything pending at once?
Yes — proposals can be approved individually or all together.
What if I approve something I should not have?
Work stays local until the ship gate. Nothing reaches your remote on the strength of a specification approval alone.