runner-issue-authority

name	runner-issue-authority
description	When dispatched with an issue number, the runner's authoritative source for what to do is `gh issue view <N>`, NOT the dispatcher's paraphrase. The dispatcher's invocation provides the issue number and any explicit overrides; the runner self-fetches. This keeps state in GitHub (where it belongs) and avoids paraphrase drift.

Authority for task content (runner)

When dispatched with an issue number, gh issue view <N> is your authoritative source for what the task is. This is non-negotiable.

When to apply

Whenever the runner is dispatched with an issue number -- apply immediately, before composing the prompt.

Rules

• Always fetch first. Your first action when dispatched with an issue number is gh issue view <N>. Do it before composing the prompt, even if the dispatcher's invocation includes a paraphrase or summary of the issue body.
• The dispatcher does NOT paste the issue body. That's an anti-pattern -- it duplicates state that lives in GitHub, risks paraphrase drift, and violates the state-externalization corollary (the issue is the durable source; conversation is transient).
• The dispatcher's invocation provides three things:
  • (a) the issue number (and optionally repo path / owner)
  • (b) explicit constraints / overrides / scope-narrowers that don't appear in the issue
  • (c) sometimes a pointer like "focus on X" or "skip Y."
• Synthesize: issue body (authoritative) + dispatcher's constraints (local overrides). If they conflict, the dispatcher's explicit override wins -- the issue is the spec; the dispatcher is the local interpreter for this particular dispatch.

Dispatch shape you'll see

The dispatcher sends a minimal structured directive (per the dispatcher's dispatch-format discipline):

implement #<N> in <repo-path>

constraints:
- <override or scope-narrower>
- <override or scope-narrower>

• First line is the directive (implement #N, fix CI in PR #N, etc.).
• <repo-path> is optional when the issue is in the current cwd's project.
• constraints: is optional. The dispatcher includes it only when they have explicit overrides; if the directive is bare, the issue body is the spec.

Why this matters

If the dispatcher paraphrases the issue into the dispatch prompt:

• The dispatch prompt bloats (dispatcher context burns tokens to write the paraphrase)
• Drift risk: dispatcher's summary diverges from the actual issue
• State duplication: same content in GitHub AND in the dispatch prompt
• Violates the state-externalization corollary: state should live in durable stores (GitHub issues), not transit through the conversation

The cleanest contract: the issue body is in GitHub; the dispatcher gives you a pointer; you fetch.

Related

• draft-pr-first -- the lifecycle the runner follows after fetching the issue.
• orchestration-prompt-template -- the prompt-composition template the runner uses.