fix(design): take recommendations only when told #166

Merged
claudiomaradonna merged 2 commits from fix/design-recommended-decisions into main 2026-10-29 14:05:26 +01:00
Collaborator

Why

The policy never said whether an instruction to go without approval
covers design's open decisions. A user who leaves a session alone
could 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, design asked every open decision with no exception. Now it
takes 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.md asks for a dependency, and its stop before a new security
rule.

Going without approval, or approving through a pull request, still
leaves the decisions to you. get-approval step 2 now says so for both
instructions and points to design step 3. The design and
internal-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 design step 3 and
get-approval step 2 as an agent would in two scenarios.

  1. The user said "fix it, I'll review the PR". The text should lead the
    agent to pass the gates and still ask each open decision.
  2. The user said "fix it and take the recommended decisions". The text
    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 299
agent-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.

## Why The policy never said whether an instruction to go without approval covers `design`'s open decisions. A user who leaves a session alone could 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, `design` asked every open decision with no exception. Now it takes 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.md` asks for a dependency, and its stop before a new security rule. Going without approval, or approving through a pull request, still leaves the decisions to you. `get-approval` step 2 now says so for both instructions and points to `design` step 3. The `design` and internal-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 `design` step 3 and `get-approval` step 2 as an agent would in two scenarios. 1. The user said "fix it, I'll review the PR". The text should lead the agent to pass the gates and still ask each open decision. 2. The user said "fix it and take the recommended decisions". The text 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 299 agent-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.
An instruction to go without approval said nothing about design's
open decisions, so one run stopped at the first decision while another
took its own recommendations. Design now takes its recommendation for
each only when the user explicitly says to take the recommended
decisions, recording each as its own choice under that instruction; it
still asks a decision with no recommendation, one adding a production
dependency, or one that would invent a security rule. Going without
approval, or approving through a pull request, leaves the decisions to
the user. get-approval and the workflow pages match.

Fixes #140
The eval preambles tell the session to go without approval because
nobody can answer. Under design's new rule that leaves its decisions to
the user, so a case reaching an open decision would wait for an answer
that never comes. Both preambles now also say to take the recommended
decisions, as a user leaving a session alone would.
claudiomaradonna deleted branch fix/design-recommended-decisions 2026-10-29 14:05:31 +01:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
claudiomaradonna/agent-foundry!166
No description provided.