fix(squad.md): stop seeding Owner/Agent binding with the tokens it forbids

[bradygaster]

Working as Procedures (Prompt Engineer).

Closes #1784.

The finding

E3 ran the full long planning path against fixture bradygaster/aspiregregator-squad-e2e #16. Activate minted squad:lead x3 and squad:devrel x1.

We ruled out the innocent explanations. The fixture's .github/workflows/squad.md is 55,954 chars — byte-identical in length to dev — and contains every #1778 marker. The fixture has a valid .squad/team.md with a populated ## Members table (Keaton, McManus, Fenster, Hockney, Kint).

There is no DevRel role anywhere in that roster. The model could not have derived devrel from team.md. It lifted both tokens verbatim out of the parenthetical that forbids them:

never a Role string (Lead, DevRel) or lowercased role (lead, reviewer)

squad.md:730 had the same shape — it spelled out `squad:lead` as the bad example, and squad:lead is exactly what shipped.

Naming the forbidden value concretely made it more likely to be emitted. The concrete token is salient; the negation is not.

What changed

Six binding sites in workflows/squad.md, each rewritten as a positive requirement only — what the value MUST be, plus the @copilot fallback, with no enumerated counter-examples. Prohibition is now abstract ("no other column of .squad/team.md supplies a valid owner, in any casing").

Site	Before	After
squad-plan Step 1	Name verbatim (e.g. `Flight`, `Procedures`, `EECOM`) — never a Role string (`Lead`, `Prompt Engineer`, `DevRel`) and never a lowercased role (`lead`, `devrel`, `reviewer`)	4-step procedure: build the allowed-owner set from the Name column, write it out, bind every value to it character-for-character, resolve via routing.md. No tokens named.
squad-plan Step 3	"never a Role string"	"a verbatim value from the Name column … or @copilot. Re-check each cell before posting."
squad-plan-accept labels	never mint a role-derived label such as `squad:lead` or `squad:reviewer`	"confirm the Owner value appears verbatim in the Name column … if not present, do not mint the label"
squad-plan-implementation Step 2	never a Role string (`Lead`, `DevRel`) or lowercased role (`lead`, `reviewer`)	"list the Name column values verbatim in your working notes … that list, plus @copilot, is the complete set of permitted values"
squad-plan-implementation Step 3	"never a Role string"	"appears verbatim in the Name column … or is @copilot"
squad-plan-implementation Step 4	"never a Role string"	"a verbatim value from the Name column … Re-check each cell before posting."

Positive examples were genericized too. (e.g. `Flight`, `Procedures`, `EECOM`) and Owner `Flight` → `squad:flight` were this repo's names appearing in a prompt that runs against other repos' rosters — the same copy-the-salient-token mechanism, pointed at a different target.

Grounding. The plan and implementation rules now instruct the model to write out the roster it read before assigning, so the binding rests on data it just retrieved rather than on recall.

/squad plan validate — Check 10. The validator returned RESULT: PASS, 0 critical / 0 warnings, and explicitly attested that lead/devrel were "valid roster names." It now has a mechanical roster check with the Name column as sole source of truth: build the roster set, quote it in the output, flag every non-matching value as ❌ Critical (which forces RESULT: FAIL), and "never report a value as a valid roster name unless you found it in the Name column." A missing or empty roster is itself Critical.

Activate pre-flight. The skill that actually applies labels now gates on the roster set: a value that fails the check must not become a squad:{agent} label. That issue gets the bare squad label and the value is reported under a Non-roster agent values heading.

Testing — read this part

#1778 shipped a "role-string-leak detector" that passed while the system was broken. It asserted the prompt text contained the rule. A prompt-text-presence test can never verify LLM compliance — the rule was present at 7 sites and was disobeyed at all of them. That is the #1766 failure mode.

Those assertions are deleted, not added to. In their place is the falsifiable inverse: the binding blocks must contain no backticked code span that names a Role. Backticked spans are the most copyable form a token takes in a prompt, and that is precisely the regression being fixed. The forbidden set is derived from team.md's Role column rather than hardcoded, so it stays honest as the roster changes.

The detector is itself tested against the real pre-fix strings from lines 913 and 730, so a broken detector cannot silently pass.

Falsifiability check — I restored the pre-fix workflows/squad.md and re-ran:

× squad-plan-accept mints squad:{owner} from the cast Name, not a role
× squad-plan-implementation binds the Agent column to the cast Name
× squad-plan states the binding positively, without naming a Role token
× squad-plan-accept states the binding positively, without naming a Role token
× squad-plan-implementation states the binding positively, without naming a Role token
× declares a roster-binding check in the checks table
× scores a non-roster value as Critical, not a warning
× binds the check to the Name column and forbids attesting validity otherwise
  Tests  8 failed | 23 passed (31)

Post-fix: 31/31 pass.

⚠️ What I did NOT verify

This fix is not live-verified. No fixture run was performed. Everything above is static analysis of prompt text plus a compile check.

Concretely:

• I have not confirmed the model now emits cast Names. Only a fixture run through /squad plan activate and an inspection of the labels actually applied can show that. That is a post-merge step and it is the only evidence that closes this issue's success criteria.
• Check 10 and the activate gate are still instructions to a model, not code. They are strictly stronger than what was there — the validator previously had no roster check at all — but they can be disobeyed exactly as the binding rule was.
• Success criteria 1 and 2 in Owner/Agent binding fix (#1759) is ineffective live — model copies the forbidden tokens out of the prohibition #1784 ("validated programmatically, not by prompt instruction") are not met by this PR and are deliberately out of scope. This is the low-risk half, shipped ahead of tomorrow's E2E series. The deterministic-enforcement rewrite is follow-up work.

Verification performed

• npx vitest run test/gh-aw-plan-lifecycle.test.ts — 31/31 pass
• gh aw compile --strict gate (gh-aw-quality.test.ts > strict-compiles and preserves prompt/config behavior) — passes against the modified workflow
• npm run build — exit 0
• npm test — 9 files fail, all pre-existing. Confirmed by stashing both changed files and re-running the same 9 on a clean tree: identical failures (Windows path separators, CLI packaging smoke, scheduler timing, ESM patching).
• Staged diffstat: 2 files, +176/−25. Deletion check empty.
• No changeset — no packages/*/src changes.

[github-actions]

🟡 Impact Analysis — PR #1789

Risk tier: 🟡 MEDIUM

📊 Summary

Metric	Count
Files changed	2
Files added	0
Files modified	2
Files deleted	0
Modules touched	2

🎯 Risk Factors

• 2 files changed (≤5 → LOW)
• 2 modules touched (2-4 → MEDIUM)

📦 Modules Affected

root (1 file)

• workflows/squad.md

tests (1 file)

• test/gh-aw-plan-lifecycle.test.ts

---

This report is generated automatically for every PR. See #733 for details.

[github-actions]

🛫 PR Readiness Check

ℹ️ This comment updates on each push. Last checked: commit 153730f

PR Scope: 🔧 Infrastructure

⚠️ 2 item(s) to address before review

Status	Check	Details
✅	Single commit	1 commit — clean history
✅	Not in draft	Ready for review
✅	Branch up to date	Up to date with dev
❌	Copilot review	No Copilot review yet — it may still be processing
✅	Changeset present	No source files changed — changeset not required
✅	Scope clean	No .squad/ or docs/proposals/ files
✅	No merge conflicts	No merge conflicts
✅	Copilot threads resolved	No Copilot review threads
❌	CI passing	9 check(s) still running

Files Changed (2 files, +176 −25)

File	+/−
test/gh-aw-plan-lifecycle.test.ts	+106 −8
workflows/squad.md	+70 −17

Total: +176 −25

---

This check runs automatically on every push. Fix any ❌ items and push again.
See CONTRIBUTING.md and PR Requirements for details.

[Copilot]

Pull request overview

This PR updates the Squad workflow prompt and its contract tests to reduce “role token leakage” into Owner/Agent bindings by rewriting several binding instructions as positive-only constraints (no enumerated counter-examples), and by adding stronger validator/activation roster-binding guidance checks.

Changes:

• Rewrites multiple Owner/Agent binding instruction sites in workflows/squad.md to avoid naming forbidden role tokens and to ground bindings in the .squad/team.md ## Members → Name column.
• Adds a new “Check 10” roster-binding procedure to /squad plan validate and a corresponding roster pre-flight gate in /squad plan activate.
• Replaces the prior “prompt-text presence” assertions with a detector that fails when binding blocks contain backticked role tokens derived from the Role column.

Show a summary per file

File	Description
workflows/squad.md	Reworks plan/accept/implementation/validate/activate instructions to bind Owner/Agent to the roster Name column using positive-only phrasing; adds Check 10 and an activation roster gate.
test/gh-aw-plan-lifecycle.test.ts	Updates lifecycle contract tests with a role-token leak detector for binding blocks and adds assertions for the new validation roster check/severity rules.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Suppressed comments (1)

workflows/squad.md:1134

• The roster gate allows @copilot as a valid Agent (step 3), but step 4 only blocks values that fail step 3 from becoming squad:{agent} labels. That leaves the @copilot case ambiguous (and it also conflicts with the later rule that {agent} must be a roster-set value).

It would be clearer to explicitly say that @copilot must never be turned into a squad:{agent} label, and that only roster names get a squad:{agent} label.

3. For every `Agent` value in the implementation plan, confirm it matches a
   roster-set entry ignoring case, or is exactly `@copilot`. The `Name` column is
   the only permitted source; a value taken from any other column of
   `.squad/team.md`, such as the `Role` column, does not qualify.
4. A value that fails step 3 MUST NOT be turned into a `squad:{agent}` label.

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite