fix(design): take recommendations only when told #166
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/design-recommended-decisions"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
The policy never said whether an instruction to go without approval
covers
design's open decisions. A user who leaves a session alonecould not predict the run: one session stops at the first open decision
and waits, another takes its own recommendations. On 2026-10-28 a
session given "fix the open issues, I'll review the PRs tomorrow"
stopped at three issues for exactly this reason. Fixes #140.
Two alternatives were weighed and set aside. Letting every instruction
to go without approval cover the decisions would let a generic phrase
settle product and architecture choices. Never letting any instruction
cover them would stall every session left alone at its first open
decision.
What changed
Before,
designasked every open decision with no exception. Now ittakes its recommendation only when you have explicitly said to take the
recommended decisions. It records each one in the work file's Decisions
as its own choice under your instruction, with the instruction's date.
Even then it still asks three kinds of decision: one it has no
recommendation for, one that adds a production dependency, and one that
would invent a security rule. That keeps the explicit approval
AGENTS.mdasks for a dependency, and its stop before a new securityrule.
Going without approval, or approving through a pull request, still
leaves the decisions to you.
get-approvalstep 2 now says so for bothinstructions and points to
designstep 3. Thedesignandinternal-skills workflow pages say the same, and the design flowchart
branches on the instruction.
The eval preambles, in English and Italian, simulate a user who is away
and cannot answer. They now also say to take the recommended decisions,
so a case that reaches an open decision does not wait for an answer that
never comes.
How to verify
On a fresh checkout of the branch, read
designstep 3 andget-approvalstep 2 as an agent would in two scenarios.agent to pass the gates and still ask each open decision.
should lead the agent to take each recommendation and record it as
its own choice under that instruction, except for a production
dependency, a new security rule, or a decision with no
recommendation.
On
main, scenario 1 has no answer about the decisions.The README's Maintenance checks pass on
3d7e07e, including 299agent-configuration tests and 46 work-folder tests. Over two rounds the
change, security and document reviewers closed every medium finding, and
the D2 and D3 decisions came from you. The behavioral evals did not run,
because each run is billed. This change touches two skills and the eval
preambles, so the Maintenance section asks for them before merge.
Considerations
The page's "Stops for you" bullet mentions only the instruction, not the
three decisions that are still asked. The paragraph right below it lists
them, so the change reviewer's low finding on this was set aside as a
later round's low finding.