agent-team: -f issue_number=... inputs not reliably propagated to implementer-agent on manual dispatch

[verkyyi]

Summary

During the verkyyi/agentfolio#105 dogfood, a manual re-dispatch of the implementer via gh workflow run implementer-agent.yml -f issue_number=105 -f iteration=1 did not propagate the inputs — the agent's first 19 tool calls were spent label-searching the repo to infer which issue to act on (run 24680708086), burning ~69s of wall clock before real work started. Only the second re-dispatch (also with -f) propagated correctly.

Unclear whether this is a gh-aw framework bug (how it wires workflow_dispatch inputs into the prompt), a catalog bug (how implementer-agent.md reads them), or a gh CLI quirk.

Proposal

• Add a catalog/agent-team/test/ harness that re-dispatches each of planner/implementer/reviewer with known inputs and asserts the agent received them (log-scrape check).
• If confirmed as catalog-side: make each agent fail-loud when a required input is empty instead of falling back to label search. Label-search fallback silently selecting the wrong issue is strictly worse than a crash.
• If confirmed as gh-aw-side: open a tracking issue there and link it.

Acceptance

• Reproduction test covering the failure mode (either CI-runnable or documented manual repro).
• Root cause identified and pinned to catalog or gh-aw.
• Fallback removed (on the catalog side) in favor of a loud failure with a precise error message.

[verkyyi]

v0.2 auto-rebase smoke reproduced this — with a clearer root cause

Today's smoke test of the v0.2 auto-rebase work (branch mcp/context7-planner-implementer, spec: docs/superpowers/specs/2026-04-23-agent-team-auto-rebase-design.md) hit this exact bug. Rebase-mode can't fall back to state:impl-needed label search, so it surfaced the gap cleanly instead of working by accident.

Repro

• Playground: verkyyi/agent-team-playground temporarily upgraded to v0.2 (implementer + sweep), OAuth tweak applied, committed to main.
• Dispatch: gh workflow run implementer-agent.lock.yml --ref main -f issue_number=4 -f pr_number=5 -f iteration=1 -f mode=rebase
• Run: https://github.com/verkyyi/agent-team-playground/actions/runs/24810592683 — conclusion: success, PR untouched.
• Agent's final self-report (from the run log): "The workflow inputs were not accessible. Specifically, issue_number, iteration, pr_number, and mode were passed as workflow_dispatch inputs but were not injected into the prompt."
• Agent's bash probes during the run all came up empty:
  • env | grep -iE 'INPUT_|ISSUE|ITERATION|PR_' — nothing
  • cat /tmp/gh-aw/agent/inputs.json — missing
  • find /tmp/gh-aw -type f — no inputs payload anywhere
• Agent then fell back to mcp__github__list_issues --labels state:impl-needed, found no matches (because rebase dispatch doesn't set that label), and exited cleanly.

Playground has since been reverted to pre-smoke state (d95ee21).

Root cause (more confident now)

1. gh-aw does not interpolate ${{ inputs.X }} into the prompt body. The "Interpolate variables and render templates" step in the run log says No expression variables found, skipping interpolation. All inputs.X references in the prompt are literal prose.
2. The pre-v0.2 implementer "worked" only because the dispatcher (planner/reviewer) sets state:impl-needed on the issue first. The implementer's real dispatch signal has always been that label, not the inputs.issue_number. The -f issue_number=... flag was never actually being read by the agent — it was being discovered via label search. When label and -f disagree, label wins silently.
3. v0.2 rebase mode has no equivalent label, which is why it fails loudly (empty result) instead of failing silently (wrong issue).

This matches both the original report here (19 wasted tool calls label-searching on manual dispatch) and issue-#57's "pre-flight checks" ask (a canary dispatch would catch this).

Fix options

Aligns with this issue's "Proposal" — narrowing the two branches:

A. Catalog-side fix via $GITHUB_EVENT_PATH (recommended)

• Every workflow_dispatch event writes inputs to $GITHUB_EVENT_PATH as .inputs.*.
• Add to each agent prompt (implementer, planner, reviewer): "Resolve inputs from $GITHUB_EVENT_PATH via jq '.inputs.<name>' \"$GITHUB_EVENT_PATH\". If any required input is empty, fail-loud: add state:blocked, comment, stop. Do not fall back to label search."
• Generic; removes the silent label-fallback footgun for all four agents.
• Needs a 30-second verification that the gh-aw sandbox allows reading that file. Happy to run that probe next.

B. Catalog-side fix via a dedicated state:rebase-needed label (narrower)

• Sweep sets the label before dispatch; rebase-mode reads via gh pr list --label state:rebase-needed.
• Consistent with the existing pattern, but widens the state machine and doesn't help planner/reviewer inputs.

Action items (v0.2.1 proposal)

• Verify $GITHUB_EVENT_PATH is readable from the gh-aw sandbox (30-second probe workflow).
• If yes: add fail-loud $GITHUB_EVENT_PATH input resolution to implementer (impl + rebase), planner, reviewer. Remove label-search fallback.
• Land the test harness from this issue's Proposal (dispatches each agent with known inputs, log-scrapes for them).
• Ship v0.2.1 — the v0.2 branch merges cleanly (install path + sweep registration + compile all work) but the rebase pipeline is latent until the input fix lands.