gh-aw: plan activate summary reports squad:{agent} labels it did not apply, and omits the required Non-roster agent values disclosure #1860

Summary

The /squad plan activate summary's Hierarchy section reports squad:{agent} labels on two epic issues that were never applied, and omits the Non-roster agent values disclosure that workflows/squad.md:1325 requires in exactly this situation.

The behaviour was correct — the labels were rightly withheld. Only the reporting is wrong. But a summary that claims labels it did not apply is a false provenance claim, which is the specific failure mode #1812 exists to prevent.

Evidence

Fixture: octodemo/aspiregregator-squad-e2e, seed issue #5, activation run 32778953402 (all six jobs success).

What the summary claimed:

- [Epic] Worker loop hardening (Epic 1.1) — squad:kint
- [Epic] Fetch retry, timeout, and failure persistence (Epic 1.2) — squad:kint / squad:mcmanus

What was actually applied:

#6 created=2026-08-24T21:28:57Z labels=[squad] [Epic] Worker loop hardening
#7 created=2026-08-24T21:28:59Z labels=[squad] [Epic] Fetch retry, timeout, and failure

Neither epic carries any squad:{agent} label. For contrast, the very next two issues created seconds later did get theirs, so this is not a transient failure or a label-does-not-exist-yet race:

#8 created=2026-08-24T21:29:01Z labels=[squad,squad:hockney]
#9 created=2026-08-24T21:29:03Z labels=[squad,squad:kint]

Root cause

The withholding is correct and intentional. Both epics have multi-valued owners in the program plan:

• Epic 1.1 — suggested owner: McManus / Hockney
• Epic 1.2 — suggested owner: McManus, but the summary itself renders the epic as squad:kint / squad:mcmanus (union of its tasks' agents)

A slash-joined pair is not a certified ROSTER_MEMBER: name, so per workflows/squad.md:1324-1325 only the squad label is applied. That is right.

What is missing is the second half of that same rule:

A value matching no certified name and not @copilot MUST NOT become a squad:{agent} label: apply only squad for that issue and record the value under a Non-roster agent values heading, naming the certified set it should come from.

The summary contains no Non-roster agent values heading. Instead it renders the uncertified multi-value string in the Hierarchy as though it had been applied.

This also conflicts with workflows/squad.md:1319-1320:

Reproduce the certified ROSTER_MEMBER: lines verbatim in the summary as the provenance of the labels applied — the summary may name only values TG-2 emitted.

squad:kint / squad:mcmanus is not a value TG-2 emitted; it is a synthesized pair.

Note on what worked

The provenance block itself was correct and verbatim, which is the #1812 requirement:

**Roster provenance (Team Guard TG-2, certified this run):**
ROSTER_MEMBER: keaton
ROSTER_MEMBER: mcmanus
ROSTER_MEMBER: fenster
ROSTER_MEMBER: hockney
ROSTER_MEMBER: kint

The defect is confined to the Hierarchy rendering and the missing disclosure heading.

Suggested fix

1. In the Hierarchy section, render only labels that were actually applied to that issue. Do not render a synthesized multi-agent string as if it were a label.
2. When an epic's owner is multi-valued or otherwise uncertified, emit the required Non-roster agent values heading naming the offending value and the certified set it should have come from.
3. Consider asserting the summary against reality before posting: every squad:{agent} named in the Hierarchy should be verifiable on the issue it is attributed to.

Impact

A reader trusting this summary would believe Epic 1.1 and Epic 1.2 are routed to agents. They are not — they carry only squad, so label-based routing will not pick them up, and the summary gives no signal that anything was withheld.