Fix campaign orchestrator to add all discovered items to project board

[Copilot]

Campaign orchestrators were discovering worker-created items (issues/PRs/discussions with tracker-ids) but not adding them to the project board, only adding tracker-labeled items.

Root cause

The "Deterministic planner step" (4.5) in orchestrator instructions limited "planned actions" to 3, which AI agents misinterpreted as a hard cap on board synchronization operations rather than strategic commentary.

Changes

Updated pkg/campaign/prompts/orchestrator_instructions.md:

• Step 4.5: Reframed as "strategic observations" instead of "planned actions". Added explicit note that this does NOT limit board synchronization.

• Step 5: Added CRITICAL directive requiring ALL discovered items (tracker-labeled + worker-created) be added. Clarified prioritization when governance limits apply: tracker-labeled first, then worker-created.

• Step 8: Made explicit that execution adds ALL items from step 5, up to governance limit, with remainder deferred to next run.

• Step 11: Split reporting to distinguish tracker-labeled vs worker-created item counts.

Example of key change:

5. **Decide additions (with pacing)** - For each new item discovered:
   - **CRITICAL**: All discovered items (both tracker-labeled from step 1 AND worker-created from step 2) MUST be added to the board to maintain synchronization between the campaign state and the project board.
   - When applying the governance limit, prioritize in this order:
     1. Tracker-labeled items (campaign tasks) - add oldest first
     2. Worker-created items (worker outputs) - add oldest first

Impact

Campaign orchestrators will now add both tracker-labeled and worker-created items to project boards, with proper prioritization when governance limits apply.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/githubnext/gh-aw/actions/runs/20657950192
  • Triggering command: /usr/bin/curl curl -L -H Accept: application/vnd.github+json -H Authorization: Bearer -H X-GitHub-Api-Version: 2022-11-28 REDACTED (http block)
• https://api.github.com/user
  • Triggering command: /usr/bin/gh gh api user --jq .login -json GO111MODULE ux-amd64/bin/go GOINSECURE GOMOD GOMODCACHE go env -json GO111MODULE rg/toolchain@v0.-nilfunc GOINSECURE GOMOD GOMODCACHE go (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Campaign discovered 4 issue items and 25 other items: https://github.com/githubnext/gh-aw/actions/runs/20657950192
But project board only shows 4.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[mnkiefer]

@copilot: Why were some workers items missing the tracker label in the first place?

[Copilot]

@copilot: Why were some workers items missing the tracker label in the first place?

Worker items don't have the tracker label by design. Workers are intentionally campaign-agnostic (Core Principle #2 in the orchestrator instructions) - they embed a tracker-id in the issue/PR/discussion body via XML comment (<!-- agentic-workflow: WorkflowName, tracker-id: WORKER_ID -->), but they don't apply campaign labels.

This separation allows the same worker workflow to be reused across multiple campaigns or run independently without any knowledge of campaign coordination. The orchestrator discovers worker outputs by searching for tracker-ids in bodies and comments, not by labels (the "explicit correlation" mechanism).

The two discovery methods are:

1. Tracker-labeled items: Human-labeled campaign tasks (label:campaign:project-64)
2. Worker-created items: Discovered via tracker-id search ("tracker-id: worker-name" in:body)