fix(workflows): provision labels in the /squad activate fast path

[bradygaster]

Closes #1959
Parent #1957

Working as Procedures (Prompt Engineer) — issue carries squad:procedures.

⚠️ Stacked PR — merge gate

Base branch: bradygaster-plan-activate-temporary-ids (PR #1965 / #1962), not dev.

#1965 is unmerged and this work builds directly on it — it establishes the temporary-ID contract, enables workflow-global require-temporary-id: true, and its create-if-missing safe output is the mechanism reused here. Merge #1965 first, then this PR's base auto-retargets to dev.

CI will not run on this PR until #1965 merges and GitHub retargets it to dev. Validation below was run locally against the stacked tree.

Problem

/squad activate routes to squad-plan-accept. When only a flat plan artifact exists (no program/implementation), it takes its own fast path with its own create-issue calls — separate code from squad-plan-activate.

#1955 fixed fresh-repo label provisioning in squad-plan-activate only. #1962 added just enough temporary-ID compliance to the fast path to survive the new global require-temporary-id: true flag, and deliberately stopped there. So the fast path still leaned on create-issue's labels: field — and GitHub silently drops label names that don't already exist in the target repo instead of creating them.

Net effect: on a fresh repository, the recommended activation command produced issues with none of the labels the docs promise, while the legacy long path worked correctly.

Fix

Applied the same verified pattern to the fast path. New ##### Fast-Path Label Provisioning section in squad-plan-accept, plus a per-item - Label application: bullet in Step 2.

Concern	Behavior
Provisioning	add_labels (allowed: [squad, "squad:*"], create-if-missing: true) — the same safe output squad-plan-activate uses. Both paths now provision identically.
Targeting	item_number = that create-issue call's own temporary_id (#aw_ph{N} phase, #aw_wi{N} work item)
Reused issues	Verified real number instead — a temp ID maps only issues this run created
Ordering	create-issue first, add_labels immediately after; no waiting for a returned number (none is returned)
Origin issue	Explicitly never an add_labels target

Every add_labels call must pass item_number. The prose names the consequence, not just the rule: omitting it does not error — gh-aw silently applies the labels to the triggering intent issue, branding the user's own request with an activated item's owner label. That's the same hazard squad-plan-activate warns about, stated identically.

Parity with the full activation path

• Base squad on every activated item.
• Work item → squad:{owner} from that row's own frozen certified Owner, lowercased. Re-read per row; never inherit the phase issue's owner or carry the previous row's value forward.
• @copilot → squad:copilot, never squad:@copilot — stated inline in the primary Step 2 label computation, not only in the provisioning section (see below).
• Multi-owner phase issue → squad only, choose none of them, recorded under Non-roster agent values.
• Non-roster owner → base squad only, owner label omitted, run continues, value recorded (see below).
• ROSTER_UNREADABLE: → stop before mutation, report the named reason. Also a stop in squad-plan-activate.
• Idempotency → re-applying an existing label is a documented no-op under add-only merge semantics, safe under Step 1a's rerun path.

@copilot must be mapped in the primary computation

The Step 2 - Labels: bullet is where the label set is actually computed, and it said only "the frozen row Owner lowercased" — which turns @copilot into the invalid squad:@copilot. Stating the mapping only in the provisioning section below left the primary rule wrong; a model following the bullet literally still emits the bad label.

Map @copilot to squad:copilot; never squad:@copilot is now inline in that exact bullet. The test extracts that bullet with /^- Labels:.*$/m and asserts against it specifically, so a workflow that is correct elsewhere but wrong in the primary computation fails.

Non-roster: aligned to full activation

#1959 requires non-roster behavior to match the full activation path, so the fast path's pre-mutation stop is removed, not preserved. squad-plan-activate applies base squad, omits the owner label, and continues; the fast path now does the same and records the value under Non-roster agent values. Both paths now produce identical results for the same plan.

ROSTER_UNREADABLE: still stops before mutation. That is a different failure — no certified set exists at all, so omit-and-record has nothing to certify against — and squad-plan-activate stops there too. The distinction is asserted by a dedicated test so the stop can't be mistaken for a leftover of the removed per-owner stop.

Step 4 now requires the Non-roster agent values heading whenever an accepted Owner did not become a squad:{owner} label — multi-owner phase or uncertified value — naming the value and the issue it applied to. Without that, "record it" pointed at a heading the fast path never had to emit. This is a heading requirement only, not a summary redesign, so it stays compatible with #1963.

#1962 compliance preserved

A dedicated regression test asserts the fast path keeps its Temporary ID: bullet, require-temporary-id: true, both ID forms, the ^#?aw_[A-Za-z0-9_]{3,12}$ pattern, the uniqueness mandate, and the #aw_ph{N} parent linkage. A compiled-lock assertion confirms require_temporary_id and required_field_additions.create_issue still reach the handler config — that flag is workflow-global and covers the fast path's create_issue calls too.

📌 Source-growth guard raised 160 → 170 KB

gh-aw-quality.test.ts's guard had ~37 bytes of headroom left after #1962 (163 803 of 163 840). At that margin it had stopped measuring growth and started blocking any correct change on byte count alone — the same failure mode its own comment block documents from #1842.

The raise is legitimate by the criterion that comment names: the new prose lives entirely inside the squad-plan-accept inline ## skill: block, which gh-aw strips during setup/interpolation, so it never enters the ambient prompt. The canonical budget — keeps the ambient prompt under 40 KB — is unaffected and still passing. I tightened the section first and still could not fit under 160 KB.

Validation

• Strict compile: all 4 workflows (squad, squad-implement-worker, squad-review, squad-deps-worker) compile with --strict --approve, all 4 lock files emitted, FAILED=0. Remaining warnings (concurrency discriminator, slash_command+bots) are pre-existing and identical on the base branch.
• Targeted tests: 485 passed across all 14 gh-aw-* suites.
• Build: npm run build passes.

Test changes

Added test/gh-aw-activate-fast-path-label-provisioning.test.ts (26 tests) — routing sanity (/squad activate → squad-plan-accept, so the suite can't drift onto the wrong skill), the dropped-label root cause, add_labels+create-if-missing presence, same-turn pairing at both section and bullet level, temp-ID targeting, #1962 compliance regression guard, mandatory item_number + the silent-fallback hazard, no-borrowed-IDs, verified real numbers for reused issues, no-prediction, then per-label-set parity assertions (base squad, own-row owner, @copilot asserted against the extracted primary bullet, multi-owner, non-roster omit-and-record, ROSTER_UNREADABLE: stop, the required Non-roster agent values heading, origin-issue safety, idempotency, default-color-is-not-a-failure, report-what-applied). Several assert the same string against both skills so the two paths can't silently diverge. One asserts the removed /squad plan revise stop is absent, so it can't be reintroduced alongside the new rule. Compiled-lock section fails closed on a missing gh aw per this repo's #1834 convention.

Updated test/gh-aw-activation-label-provisioning.test.ts — one #1955 boundary test asserted the fast path contained no add_labels and no create-if-missing, encoding the exact gap #1959 closes. Inverted to assert the parity instead.

Updated test/gh-aw-quality.test.ts — guard constant and its rationale comment (see above).

Impact on #1963 (activation reporting)

#1965 flagged that the Activation bindings: JSON block still embeds real issue numbers and cannot be fixed there, because replaceTemporaryIdReferences() retains the #, which would emit invalid JSON. That constraint is unchanged by this PR — the fast path's Step 4 posts a plan-accepted / phases-accepted artifact and does not emit an Activation bindings: block at all, so this PR neither worsens nor resolves it.

Three things #1963 should now account for:

1. Reporting is now two-path. Any redesign must cover squad-plan-accept's Step 4 summary as well as squad-plan-activate's Step 4 record. Previously the fast path had no label operations worth attributing.
2. The fast path now has a required heading. Non-roster agent values is mandatory in the fast path's Step 4 whenever a label was omitted. Make Squad activation summaries report actual label outcomes #1963 must either keep that heading or explicitly supersede it — the omit-and-record rule in Step 2 and the provisioning section both reference it by name.
3. The attribution vocabulary already exists here. This PR states "Report only the labels a successful add_labels call actually applied; never a label that was skipped, deferred, or merely intended." Make Squad activation summaries report actual label outcomes #1963 can build on that rather than introducing a competing contract, but it will need to reconcile the fast path's heading with a mechanism that has no bindings block to hang structured data on.

Out of scope (untouched)

Activation reporting redesign (#1963), capacity safeguards (#1961), broad behavioral contracts (#1960), E4 (#1958), checker distribution.

No changeset: no packages/*/src/ changes, so the changelog-gate path regex does not match.

[Copilot]

Copilot review overview

🔵 Needs a closer look

The repository’s routing rules assign this PR to the Procedures agent (squad:procedures), so it should be reviewed and approved in that specialist context.

Review tier: Lite
Findings: None

What changed in this PR

This review is deferred because the task is explicitly routed to the Procedures agent (squad:procedures) and should be handled in that agent’s context.

Changes:

• Review not performed (routed to Procedures).

File	Description
workflows/​squad.md	Not reviewed (routed to Procedures)
test/​gh-aw-quality.test.ts	Not reviewed (routed to Procedures)
test/​gh-aw-activation-label-provisioning.test.ts	Not reviewed (routed to Procedures)
test/​gh-aw-activate-fast-path-label-provisioning.test.ts	Not reviewed (routed to Procedures)

---

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

[github-actions]

🛫 PR Readiness Check

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

PR Scope: 🔧 Infrastructure

⚠️ 2 item(s) to address before review

Status	Check	Details
❌	Single commit	4 commits — consider squashing before review
✅	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	All checks passing

Files Changed (4 files, +506 −13)

File	+/−
test/gh-aw-activate-fast-path-label-provisioning.test.ts	+416 −0
test/gh-aw-activation-label-provisioning.test.ts	+10 −7
test/gh-aw-quality.test.ts	+9 −1
workflows/squad.md	+71 −5

Total: +506 −13

---

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

[github-actions]

🟡 Impact Analysis — PR #1966

Risk tier: 🟡 MEDIUM

📊 Summary

Metric	Count
Files changed	4
Files added	1
Files modified	3
Files deleted	0
Modules touched	2

🎯 Risk Factors

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

📦 Modules Affected

root (1 file)

• workflows/squad.md

tests (3 files)

• test/gh-aw-activate-fast-path-label-provisioning.test.ts
• test/gh-aw-activation-label-provisioning.test.ts
• test/gh-aw-quality.test.ts

---

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