agent-completion/truth-gate is permanently unsatisfiable for any PR closing an `[aw]` issue

[groupthinking]

Summary

linear-code[bot] applies the agent-task label to [aw] issues that were not created from the Agent task template. That label is a contract marker, not a topic tag: agentTaskApplicable() in .github/workflows/pr-checks.yml trusts it transitively through the linked issue, so any PR closing a mislabelled issue is judged an agent completion and is then required to satisfy a contract the issue never declared. The gate cannot be satisfied by an agent or by a human, and the block is permanent.

Observed on PR #1123 (agent-completion/truth-gate → failure). It is the only substantive check failing on that PR, and it passes on every sibling PR (#1118, #1119, #1122, #1129) purely because their linked issues are not mislabelled.

Evidence

The verdict artifact (agent-completion-verdict-1123, run 30609194922):

{
  "verdict": "blocked",
  "reasons": ["invalid_payload"],
  "details": { "invalid_fields": ["policy.agent_login", "policy.run_id"] }
}

and its input:

"policy": { "applicable": true, "agent_login": null, "run_id": null },
"collection_errors": [
  "incomplete_linked_issue_contract",
  "missing_intent_snapshot",
  "missing_agent_run_id",
  "missing_agent_login"
]

.github/ISSUE_TEMPLATE/agent-task.yml establishes what the label means:

title: "[Agent] "
labels:
  - agent-task

Complete this contract before dispatch. The completion gate reads these headings from the issue, not from the pull request.

Its fields — Agent login, Agent run ID, Objective, Acceptance criteria, Declared file scope, Allowed extra files, Focused test paths — map 1:1 onto what the gate parses (pr-checks.yml:224-227, 2146-2151, 2162-2176). So agent-task asserts "this issue declares an agent contract." Applying it to an issue that declares none turns that assertion false.

Issue #1091's label provenance shows the mislabel is not from our harness:

+agentic-workflows  by github-actions[bot]     <- our harness
+agent-task         by linear-code[bot]        <- third-party triage bot
+needs-triage       by linear-code[bot]
...

The mislabel is systematic across the [aw] class — every one carries agent-task, none declares the contract:

Issue	agent-task	declares Agent Run ID	declares Agent Login
#1053	yes	no	no
#967	yes	no	no
#1091	yes	no	no
#1125	yes	no	no
#1089	yes	no	no

(#951 predates the bot and is correctly unlabelled.)

Applicability is decided by agentTaskApplicable(pull, selectedIssue) (pr-checks.yml:616), which unions PR labels with linked-issue labels. On #1123 every PR-side signal is negative — author groupthinking is not in knownAgents, branch fix/agentic-workflow-noop-terminal-state-1091 does not match /^(?:agent|claude|codex|copilot|jules)[/-]/i, PR labels are documentation, ci/cd, and there is no agent-lock-manifest in the body. The linked issue's agent-task label is the sole trigger.

Why this matters

[aw] issues are machine-filed reports, and most are spurious — 54 of 60 all-time [aw] issues were "produced no safe output" noise, which is what #1091 and PR #1123 exist to stop. Humans must be able to close them. Today, closing one with a correctly-linked PR guarantees a red check, which trains reviewers to ignore a gate whose entire value is that it is trustworthy when red.

There is no honest escape. Fabricating an Agent Run ID/Agent Login, or adding an agent-lock-manifest to a human PR, would defeat exactly what the gate protects. Dropping the closing reference would violate PR governance, which requires exactly one canonical closing issue.

Suggested fix

Decide applicability from PR provenance, not from the linked issue's labels. The PR-side signals already present in agentTaskApplicable() — agent bot author, agent branch prefix, agent label on the PR, agent-lock-manifest in the PR body — describe who produced the change, which is what the gate verifies. A human PR closing an agent-filed issue is not an agent completion.

Belt-and-braces alternative: keep the linked-issue signal, but treat agent-task as present-and-valid only when the issue body actually declares the contract headings, and surface mislabelled_agent_task rather than invalid_payload when it does not. That preserves fail-closed behaviour while making the diagnosis actionable instead of unresolvable.

Either way the linear-code[bot] labelling rule should stop applying agent-task to issues not created from the template, since the label is a contract assertion rather than a topic tag.

Scope note

Deliberately not fixed in PR #1123. That PR fixes the harness's terminal-state contract; silently relaxing a governance gate to green a PR of my own is the failure mode the gate exists to catch. The check is not merge-blocking today — main has no required status checks and all five open PRs sit at UNSTABLE — so this is a correctness and trust problem rather than a delivery blocker.

[linear-code]

GRV-196

[github-actions]

👋 Thanks for opening this issue! It has been automatically labeled for triage.

[coderabbitai]

🔗 Related PRs

#272 - feat(agents): add pr-shepherd agent for ready-for-review and needs-input PRs [merged]
#404 - fix(web): sync package-lock with @vercel/functions (unblocks #277 auto-merge) [merged]
#411 - ci: add agentic verification loop workflow and refactor state log [merged]
#593 - ci(phase-goal-tracker): goal tracker workflow with reviewer findings resolved (supersedes #531) [merged]
#872 - ci: enforce deterministic agent completion truth gate [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!