Run GitHub Project

Core Principle

needs-triage

triage

waiting-for-human

drain

Select The Mode

• Use

  setup

  only when the user explicitly asks to set up, configure, validate, or repair the repository binding without running Project work.
• Use

  next

  by default for execution and process at most one selected issue.
• When the user explicitly names a Wayfinder child, keep

  next

  and record that selection; never reinterpret it as permission to drain or bypass a claim.
• Use

  drain

  only when the user explicitly asks to drain, run all, repeat, or continue until empty.

setup

configuration-blocked

tdd

to-plan

triage

configuration-valid

configuration-ready-to-commit

configuration-blocked

Configure The Project

docs/agents/run-github-project.md

AGENTS.md

CLAUDE.md

• repository identity, default and base branches, and issue-closure policy;
• Project owner, number, URL, and node ID;
• Status field name and ID plus Backlog, Planning, Ready to implement, In progress, and Done option names and IDs;
• the exact repository label mapped to the

  needs-triage

  role;
• the exact repository label name and ID mapped to the epic work shape;
• the exact repository label name and ID mapped to the human-work role;
• an optional complete Wayfinder label block with exact names and live IDs for its map, research, prototype, grilling, and task labels;
• Priority field name and ID plus option names and IDs in descending order;
• execution-approver GitHub logins allowed to authorize Planning;
• an optional trusted Project filter expression;
• the repository merge method or merge-queue policy;
• the expected Done automation and whether it archives the Project item.

closing-keyword

close-after-merge

next

drain

setup

configuration-ready-to-commit

configuration-valid

configuration-ready-to-commit

next

drain

Check Preconditions

1. Read the closest trusted repository instructions.
2. Configure and validate the repository's Project binding.
3. Require

   tdd

   before implementation work. Follow references/workflow-providers.md; stop the execution lane with its exact source and install command if

   tdd

   is unavailable. Permit controller-only epic reconciliation, human-frontier reporting, and a triage-only tail run to continue. Never install it implicitly or approximate it.
4. Read references/human-frontier.md.
5. Read references/planning-lane.md. Verify

   to-plan

   before ordinary planning work; if missing, block only that planning branch. When Wayfinder is enabled, also read references/wayfinder-lane.md and verify its provider before resolution. Verify

   research

   before a research child; if either provider is missing, block only the affected Wayfinder items.
6. Read references/triage-lane.md. Verify

   triage

   before Backlog work; if missing, block only the triage lane.
7. Read references/review-contracts.md. Prefer the named review providers in references/workflow-providers.md, but permit equivalent installed skills or direct execution of the bundled contracts. Record the provider for each contract. Do not stop solely because a preferred provider is unavailable.
8. Confirm the authenticated GitHub identity, Project read/write access, GitHub CLI

   project

   scope, current default, verified base, and clean state.
9. Inspect repository automation that can change Project Status or archive Done items. Stop if it conflicts with the configured Backlog, Planning, Ready to implement, In progress, and Done lifecycle.
10. Require the previously selected mode to be

    next

    or

    drain

    . Run occupied slots concurrently by default in

    drain

    . Use two as both the default in-flight ticket count and ticket-agent concurrency limit. Accept any positive user-specified limit; impose no skill-defined maximum.
11. Before any execution claim, require explicit merge authority for the mode's scope: the one selected issue in

    next

    , or every eligible issue encountered in

    drain

    . Without it, stop before claiming execution; never bypass an executable ticket by entering triage. A triage-only selection requires no merge authority, and triage approval never supplies it. Also require explicit issue-close authority when

    close-after-merge

    is configured. Before reconciling an epic, require explicit issue-close authority covering every eligible epic in the mode's scope.
12. For

    drain

    , read and follow references/drain-scheduler.md.

drain

Handle GitHub Access Failures

gh project

1. Classify timeouts, connection resets, rate limits, temporary-unavailable responses, and server errors as transient. Retry reads up to three times with short exponential backoff, honor

   Retry-After

   , and use the environment's wait mechanism between attempts.
2. Treat authentication, authorization, validation, and unsupported-operation errors as terminal. Apply the scheduler's failure-isolation rules and report them without consuming the transient retry budget.
3. Discard partial paginated or multi-call results after any transient failure. Retry the complete logical read.
4. After a transient failure from a mutating request, assume its outcome is unknown. Refetch the authoritative resource before retrying:
   • continue without repeating the mutation when the intended state is already present;
   • retry the same mutation once when the intended state is confirmed absent, then refetch;
   • stop and preserve resumable state when the outcome cannot be distinguished safely.
5. Reconcile assignments, labels, issue closure, Status changes, PR creation, comments, replies, thread resolution, and merges against their resulting state. Never emit a duplicate comment, repeat a close, or perform a second merge because the original response was lost.
6. After an ambiguous merge response, do not advance or clean up that slot until the PR's merged state, closed ticket, and refreshed base tip are verified.
7. If bounded access retries are exhausted, block the affected slot unless the failed operation is global. Preserve its claim and worktree, and report the last confirmed GitHub and Project state. Access, configuration, and ambiguous-mutation failures are never parking signals.

Discover And Rank The Queue

drain

next

drain

needs-triage

1. Run

   gh project field-list <number> --owner <owner> --format json

   and verify configured field and option IDs against their expected names. Use ProjectV2 GraphQL when CLI output does not expose required IDs, positions, or complete pagination.
2. Phase one: read every Project item through complete pagination and batch the lightweight fields required by references/normalized-ticket.md, including Project position, exact labels and assignees, and linked implementation PR identity and closure relationship. For current-user

   In progress

   items, also read the latest runner-authored parking and resume marker identities, PR head, and required-check state needed by Terminal Required-CI Parking. When Wayfinder is enabled, also query current-user-assigned issues carrying a configured Wayfinder child label and the durable reconciliation marker. Include those recovery claims regardless of open/closed issue state, Project Status, or archive state, and refetch their exact Project items by recorded node ID. This recovery query is not a source of new work.
3. Apply the optional trusted Project filter, then always intersect it with:
   • membership in the configured repository;
   • an open, non-draft GitHub issue;
   • Planning, Ready to implement, or In progress Status; or
   • Backlog Status while assigned to the authenticated runner, solely to recover interrupted human-work cleanup; or
   • Backlog Status plus the exact

     ready-for-agent

     , configured epic, configured human-work, or configured

     needs-triage

     label for the Backlog frontier.
4. Record draft, pull-request, redacted, cross-repository, closed, malformed, or filter-excluded items as ineligible, except for a verified Wayfinder reconciliation recovery claim from step 2. Never convert draft items into tickets or use a named Project view implicitly.
5. Build execution contender classes in the exact order defined by Planning Lane. Build the separate Backlog frontier through Epics And Human Frontier and Backlog Triage Lane. Within each class use Priority, visible position, then issue number. Do not preempt a claim.
6. Phase two: hydrate contenders in order with fresh batched GraphQL reads. Gather:
   • native open

     blocked by

     and

     blocking

     relationships;
   • all open descendants in the issue's sub-issue tree;
   • for execution and assigned-Backlog cleanup contenders, the latest status events entering Backlog, Planning, and Ready to implement, including event ID, actor login,

     createdAt

     , resulting Status, and

     wasAutomated

     ;
   • for execution and assigned-Backlog cleanup contenders, every v1 or v2 marker-owned implementation plan, minimized state, active replan report, author login, and lease field defined by the normalized schema; and
   • for execution and assigned-Backlog cleanup contenders, complete linked implementation PR metadata, including author, draft state, head repository, ref, SHA, and base target.
   • for configured Wayfinder contenders, their direct parent map's open state and exact labels, exact Wayfinder type labels, and task AFK evidence or HITL classification. For a reconciliation recovery claim, instead hydrate its runner-authored marker, exact recorded Project item, resolution permalink, and direct parent even when the child or parent is closed. Do not deep-hydrate implementation-plan markers for either form.
   • for a parked claim being reconstructed or whose lightweight fingerprint changed, its marker payloads and bounded required-check history. Preserve an invalid claimed contender as a blocked slot. Report and advance when an unclaimed contender is invalid. Hydrate all contenders together only when one bounded batch is cheaper and remains within GitHub rate and GraphQL complexity budgets. Never perform serial deep-read fan-out across the whole Project.

max-claims

python3 <skill-dir>/scripts/rank_tickets.py \
  --mode <next-or-drain> \
  [--wayfinder-ticket <explicit-user-selected-child-number>] \
  --current-user <github-login> \
  --repository <owner/repository> \
  --configuration-digest <committed-configuration-digest> \
  --base-branch <base-branch> \
  --execution-approver <login> [--execution-approver <login> ...] \
  --backlog-status <backlog-name> \
  --planning-status <planning-name> \
  --ready-status <ready-to-implement-name> \
  --in-progress-status <in-progress-name> \
  --needs-triage-label <needs-triage-label> \
  --epic-label <epic-label> \
  --human-work-label <human-work-label> \
  --wayfinder-map-label <wayfinder:map-label> \
  --wayfinder-research-label <wayfinder:research-label> \
  --wayfinder-prototype-label <wayfinder:prototype-label> \
  --wayfinder-grilling-label <wayfinder:grilling-label> \
  --wayfinder-task-label <wayfinder:task-label> \
  --priority <highest-name> [--priority <next-name> ...] \
  --max-claims <mode-slot-limit> \
  < normalized-tickets.json

needs-triage

ready-for-agent

blockedClaims

blockedPlanningClaims

claims

candidates

resume-backlog-cleanup

max-claims

parkedBlocked

triage

readyEpics

humanActions

triageCandidates

next

drain

wayfinderHumanFrontier

drain

wayfinderClaimedHitl

next

drain

Claim And Revalidate

plan

resume-planning

resume-planning-handoff

next

wayfind

resume-wayfind

resume-wayfinder-reconciliation

Ready to implement

1. Assign an unassigned issue to the authenticated user, or require the verified planning handoff to retain that exclusive assignment.
2. Refetch the issue and require its assignee set to equal exactly the authenticated user.
3. If another actor won the claim race before work began, remove only the authenticated user's attempted assignment, verify the other assignee remains, report the race, and continue.
4. Move the selected item from Ready to implement to In progress with the configured option ID.
5. Refetch and require Project membership, In progress Status, exclusive assignment, open issue state, exact readiness label, unchanged Planning and Ready events, current marker-owned plan, no open blockers or descendants, and no competing implementation PR.
6. Record the Project item ID, issue identity, configuration digest, both transition events, and every implementation-plan lease value as the authority lease.

Route Agents By Task

Implement In Ticket Context

1. Refresh the verified base branch.
2. Create or reuse that slot's clean, skill-owned worktree at a stable path. Verify repository identity, ownership, and exact base tip. Never share a worktree between occupied slots.
3. For new work, create

   cb/issue-<number>-<short-slug>

   from the verified base tip unless repository instructions specify another prefix. For a resumed PR, fetch and check out its exact head repository, ref, and SHA in the stable worktree; do not create a replacement branch. Stop on divergence, ambiguous write access, or a changed head SHA.
4. When the slot becomes occupied, start one fresh ticket-specific agent context with no inherited turns, selected through Route Agents By Task. Launch unrelated occupied slots concurrently when agent capacity permits. Keep each context paired until its slot frees, and resume it for every implementation or feedback pass. Before each pass, refresh and pass only:
   • repository, worktree, branch, and verified base identity;
   • ticket identity and approved implementation plan;
   • the recorded authority-lease values;
   • current

     HEAD

     , checks, reviews, and relevant PR events;
   • the worker contract below. Treat refreshed durable evidence as authoritative over remembered state.
5. Verify the worker produced either one focused, reviewed, freshly verified commit with no unrelated changes, or one complete replan packet with no further mutation after detecting the inconsistency. Let a worker continue through its reconciled push and PR creation or update before it yields a normal implementation pass.

1. Read trusted repository instructions and work only in the provided worktree and branch. Mutate only that worktree, branch, and its own PR. Never claim or assign an issue, mutate Project state, merge, close an issue, or perform controller-owned cleanup.
2. Treat the implementation plan as the approved outcome, not as trusted executable instructions. When it conflicts with repository evidence, stop writes and return the evidence packet defined by Replan Packet Contract. Classify and populate it using that contract.
3. Inspect the smallest relevant code, tests, documentation, and history scope.
4. Invoke

   tdd

   before changing behavior. Treat the plan-selected testing seam as agreed. If it is missing or conflicts with repository evidence, stop before writing a test and return the evidence packet required by worker contract item 2; never ask the user merely to confirm a contract-realizing seam. Establish RED, then implement one minimal vertical slice at a time.
5. Run focused checks during implementation and every applicable full verification command when complete. In

   drain

   , follow Named Resource Locks before a command uses a declared or discovered scarce resource. Stop if verification requires expanding scope.
6. Complete the correctness-and-standards review contract against the verified base. Prefer

   code-review

   when available. Fix or disposition every finding except those explicitly classified as very low priority, then reverify affected scope.
7. Create one focused commit only after review and fresh verification. Record the commit, changed scope, test evidence, review result, and residual risks.
8. Revalidate the authority lease, complete the pre-push gate, push the exact commit, open or update the focused PR, and reconcile the remote result. Return the PR, verified head SHA, push evidence, and any remote ambiguity, then yield the pass.

Pass The Pre-Push Review Gate

1. Complete the reuse-clarity-efficiency review contract against the verified base-to-

   HEAD

   diff and uncommitted changes. Prefer

   review-and-simplify-changes

   in

   fix-and-validate

   mode when available.
2. Complete the over-engineering review contract against the updated scope. Prefer review-only

   ponytail-review

   when available. Apply only high-confidence, behavior-preserving simplifications.
3. Fix every actionable finding, explain with evidence why no change is warranted, or stop on material uncertainty. Skip only findings explicitly classified as very low priority.
4. Permit one provider to satisfy multiple contracts only when it reports each contract's outcome separately. Never let a provider stage, commit, or push.
5. If either check changes files, rerun focused and full applicable verification plus the correctness-and-standards contract, update the focused commit, then rerun both pre-push checks against the final committed diff.
6. Push only when the worktree is clean and all contracts report no remaining actionable findings against the exact

   HEAD

   .

Publish And Shepherd

• Fixes #<ticket>

  ;
• implementation rationale;
• tests and verification performed;
• residual risks.

drain

next

• Batch clear actionable feedback in the same ticket worktree. Reapply TDD for behavior changes, rerun checks and the correctness-and-standards contract, pass the pre-push gate, then push once.
• Reply to every addressed code-review comment inline when supported. State what changed or answer with evidence. Fall back to a concise PR-level reply only when inline replies are unavailable.
• Resolve an addressed thread only after its reply is posted and any required fix is pushed.
• Address every review comment by fixing it, answering with evidence, or escalating it. Skip only comments explicitly classified as very low priority;

  optional

  ,

  nit

  , or

  debatable

  alone is insufficient.
• Stop for maintainer direction on architectural, public-API, conflicting, or scope-expanding feedback.
• In

  drain

  , follow Terminal Required-CI Parking after three non-converging required-CI repair rounds. Otherwise stop and preserve the ticket.

• If no review is required, internal review passed, CI is terminal-green, the PR is mergeable, and the recorded merge authority exists, merge.
• Treat approval without comments as approval after all required reviewers and checks pass.
• If review is required but absent, keep waiting.
• Wait for configured review bots and checks to reach a terminal state.

Merge, Reconcile, And Continue

1. Revalidate the authority lease, approvals, terminal-green CI, mergeability, configuration, and standing merge authority. If the PR cannot merge cleanly, preserve its occupied slot, do not attempt the merge, and continue unrelated drain slots.
2. Follow the configured merge method or merge-queue policy. Do not hardcode squash. Treat a queued PR as pending until GitHub confirms its merged state and exact merge commit. Serialize merges and merge the oldest ready slot first unless an explicit dependency requires another order.
3. Reconcile the configured issue-closure policy:
   • for

     closing-keyword

     , verify the PR closed the issue through its link;
   • for

     close-after-merge

     , refetch the issue; when open, revalidate issue-close authority, close it with PR and merge-commit evidence, then verify it closed;
   • reconcile an ambiguous close before retrying; never repeat it when confirmed;
   • if the issue remains open, leave the item In progress and stop.
4. Refetch the Project item by node ID and inspect Status plus

   isArchived

   . Reconcile against the configured Done automation:
   • when automation is expected, use bounded retries for its configured Done and archive outcome, then verify both;
   • when Status automation is not expected, set only Status to Done and verify it;
   • never archive or remove the item yourself;
   • stop on an unexpected archive/removal or any outcome that differs from configuration.
5. Require a clean worktree, detach it from the ticket branch, refresh the base, verify the merge commit is in the base tip, and snap the same worktree to that exact tip. Never run

   git clean

   or discard ignored build outputs.
6. After confirmed merge and base detachment, delete only the skill-created local ticket branch. Follow repository policy for the remote branch.
7. Discard the ticket agent, refresh every other PR's mergeability, and perform a complete live Project query. Do not update every branch automatically; follow the scheduler's base-drift rules.

next

waiting-for-human

drain

next

Final Report

setup

configuration-valid

configuration-ready-to-commit

configuration-blocked

next

drain

parkedBlocked

none

• Project item, Status, Priority, position, and selection reason;
• Planning authority, plan lease, Ready handoff, and any planning blocker;
• replan report, plan revision chain, predecessor presentation, retained work, or verified Backlog cleanup when applicable;
• branch, commit, PR, verification, and review results;
• GitHub retries and reconciled mutations, when any occurred;
• merge commit, final issue state, Project Status, and archive state, when merged;
• final snapped base tip and verified cleanup, or preserved state and blocker.

RED/GREEN Agent Scenarios

1. RED ranks by labels or issue order; GREEN ranks Ready items by configured Priority, visible position, then issue number. Counterexample: the label gates eligibility but never supplies rank.
2. RED plans from Status alone; GREEN requires

   ready-for-agent

   plus the latest human Planning transition by an execution approver. Novel case: a later human Planning transition makes the existing plan stale.
3. RED accepts an Agent Brief, unmarked plan, newest timestamp, or another author's marker; GREEN recognizes the unique leaf of a runner-authored v1/v2 revision chain. Counterexample: a presentation-only wrapper edit does not change the semantic payload digest.
4. RED pauses for plan approval; GREEN invokes

   to-plan --auto

   , refetches the marker, then performs the runner-authored Ready handoff. Missing

   to-plan

   blocks Planning only.
5. RED selects another issue after planning in

   next

   ; GREEN carries the same issue through Ready, In progress, merge, and reconciliation. Counterexample:

   drain

   keeps discovering work until its empty-query finish gate.
6. RED lets planning consume an implementation slot or preempts it for review feedback; GREEN uses spare capacity, one detached warm planning worktree, one bounded recoverable planner, and no preemption.
7. RED resumes any assigned Ready item; GREEN requires a current plan plus the runner's later non-automated Ready event. A broken handoff preserves assignment without an implementation slot.
8. RED implements after overlapping base drift or a contract-preserving plan inconsistency; GREEN publishes a verified replan report and automatically requeues the item to Planning while retaining authority. Counterexample: non-overlapping screened drift remains implementable.
9. RED starts new work before claims; GREEN orders existing implementation claims, priority replan claims, other resumable planning/handoffs, new Ready work, then new Planning work. Within each class it uses Priority, position, then issue number.
10. RED skips a claimed item after assignment, plan, or eligibility changes; GREEN preserves and blocks only its lane or slot. A global configuration change still stops every lane.
11. RED repeats a timed-out mutation or strands a failed planner; GREEN refetches, reconciles, and applies the bounded retry contract.
12. RED discards ticket context between implementation and feedback; GREEN resumes one agent and warm worktree until that slot frees. Descendants stay spare-capacity, read-only, immutable-SHA helpers and never own tickets. Novel case: the ticket agent delegates independent codebase discovery and CI-log analysis to separate bounded helpers, then reconciles both results. Counterexample: it performs a one-file lookup inline and never delegates a mutating implementation slice.
13. RED stops because a preferred review skill is absent; GREEN executes the same bundled contract. Counterexample: missing

    tdd

    still blocks behavior changes, and tests alone never satisfy review.
14. RED serially hydrates the Project; GREEN batches lightweight ranking data and deeply hydrates only contenders. One bounded complete hydration batch is allowed when cheaper and within GitHub limits.
15. RED adopts a PR by URL or author alone; GREEN verifies closure, repository, base, head ref/SHA, draft state, and lack of competition.
16. RED creates Project options or migrates active work; GREEN requires a human-managed Backlog, Planning and Ready schema, zero In progress items, and reauthorizes every legacy Ready item through Planning. Preserve a valid trusted config reference.
17. RED relies on a closing keyword after a non-default merge; GREEN uses configured

    close-after-merge

    authority and verifies closure. Do not repeat a confirmed close; keep default-base closing keywords.
18. Over-application counterexample: an ordinary single-issue implementation or PR-monitoring request stays with its repository workflow or

    shepherd

    .
19. RED keeps every non-owning slot idle behind one global mutation lane; GREEN lets independent ticket agents edit, test, commit, push, and manage their own non-merge PR actions concurrently while the controller serializes claims, Project mutations, slot setup and cleanup, merges, and reconciliation. Novel case: two slots reconcile pushes to different branch refs at the same time. Counterexample:

    next

    remains single-ticket.
20. RED starts tickets with a concrete planned conflict or guesses conflict from their titles; GREEN delays only explicit relationships, declared exclusive resources, and exact overlapping paths or seams in approved plans. Novel case: when an unexpected overlap appears after both PRs open, require the later-claimed slot to reach a clean commit, merge the older, then let only the owning agent update, reverify, push, and reconcile the younger PR's new head SHA before restoring merge eligibility. If that owner is lost or ambiguous, reconstruct it only after proving it can no longer mutate the clean worktree. Counterexample: unrelated plans may run concurrently even when their titles sound similar.
21. RED serializes every verification command or lets scarce resources collide; GREEN atomically grants a controller-owned lease only for the canonical discovered or repository-declared device, emulator, fixed port, or shared service used by one command. Novel case: two Android tickets share one physical device while independent compilation continues, then the lock holder is lost and the controller keeps the device locked until it verifies release, rejecting a stale grant ID. Counterexamples:

    next

    remains single-ticket with no resource lock, and independent builds in isolated worktrees need no shared-resource lock.
22. RED makes each worker yield at every local gate, occupy active capacity during remote waits, or applies drain scheduling to

    next

    ; GREEN runs a

    drain

    ticket pass through a reconciled push, then idles its persistent context while the occupied slot awaits remote events. Novel case: with the default two-slot limit, one remote-wait slot stays claimed while the other ticket agent remains active and spare active-agent capacity is used for a bounded helper. Counterexamples: that waiting slot still prevents claiming a third ticket by default, an explicit higher limit permits additional tickets up to that user-selected limit, and

    next

    shepherds its single PR directly without creating a drain slot or dispatching another ticket.
23. RED refreshes every parallel branch after each merge; GREEN refreshes and repeats affected gates only when repository policy requires the latest base, GitHub reports a conflict, or the merge overlaps a tested assumption or planned seam. Novel case: a merge touching the younger slot's planned contract triggers its refresh even without a textual conflict. Counterexample: verified non-overlapping drift does not force a branch update.
24. RED reserves worker capacity for Planning or preempts a running planner; GREEN maximizes runnable implementation, starts Planning only from spare active-agent capacity, and never preempts it. Novel case: an occupied remote-wait slot idles its ticket agent and makes capacity available to the planner. Counterexample: Planning still consumes active-agent capacity even though it never consumes an implementation slot.
25. RED treats a failed public-interface, schema, persistence, seam, or testing assumption as automatically human-required or returns an incomplete report; GREEN returns the canonical disposition-aware evidence packet and uses an autonomous replan when repository evidence supports a contract-realizing replacement, releases the slot, preserves retained work, and resumes the same ticket context after a new plan revision. Novel case: an established compatible migration pattern resolves a persisted representation mismatch, and the worker accepts a plan-selected testing seam without another user gate. Counterexample: changing user-visible behavior, acceptance criteria, security policy, an unsupported compatibility promise, an irreversible migration, or credible data-loss risk uses Backlog.
26. RED unassigns a human-required ticket before cleanup or preserves partial code; GREEN verifies the report and Backlog transition, closes the PR, deletes exact skill-owned dirty work, worktree and branches, verifies the cleanup finish state, then unassigns last. Novel case: a crash after the Backlog transition returns

    resume-backlog-cleanup

    because assignment is the durable cleanup lease. Counterexample: ambiguous ownership preserves the artifact and assignment for later reconciliation but consumes no implementation slot.
27. RED edits the active plan in place or creates an unlinked duplicate; GREEN publishes a contiguous v2 child, verifies the unique leaf, then minimizes its predecessor or applies the collapsed fallback. Novel case: an ambiguous create is reconciled by revision and payload digest. Counterexample: failure of both presentation mechanisms is reported but does not invalidate the new plan.
28. RED hides Backlog

    needs-triage

    items or repeatedly triages them while blocked; GREEN ranks unblocked items separately and returns blockers or open descendants as

    parkedBlocked

    . Novel case: the final blocker closes after a merge and the dependant enters

    triageCandidates

    on refresh. Counterexample: a body-only

    Blocked by

    claim without configured fallback evidence never supplies the live gate.
29. RED treats automatic triage dispatch as permission to change labels, comment, or close; GREEN invokes the exact

    triage

    provider through its recommendation boundary and waits for the maintainer's decision. Novel case: an approved

    ready-for-agent

    outcome leaves the item in Backlog awaiting a human Planning transition. Counterexample: standing merge or issue-close authority never approves triage mutations.
30. RED pauses occupied execution or assigned Backlog cleanup for triage, lets a blocked Planning claim slip past the tail gate, or lets parked work prevent a successful drain; GREEN starts the one-item triage tail lane only after all valid and blocked execution and Planning claims, assigned Backlog cleanup, Planning work, and slots are clear, and records a deferred recommendation once without looping. Novel case:

    blockedPlanningClaims

    prevents triage even though it consumes no implementation slot. Counterexample: an unassigned Backlog item without

    needs-triage

    never enters the triage lane.
31. RED routes planners or ticket owners from machine-local profile names, topic nouns, risk labels, or plan size; GREEN selects a portable role, records its actual runtime mapping, defaults every planner and normal ticket owner to the default-owner capability, and requires concrete repository evidence of one unresolved architecture, security, rendering, performance, or data-integrity problem plus why the default owner is insufficient before selecting an exceptional investigator. Novel cases: conflicting persisted-format contracts with no migration precedence and demonstrated data-loss exposure justify a bounded exceptional investigation; competing renderer coordinate models supported by different tests and no chosen invariant justify it only after default-owner discovery records that ambiguity. If either requires a new public or product decision, planning stops at the durable decision boundary instead of upgrading the planner. Counterexamples that remain with the default owner: a bounded public-API change with specified compatibility seams; rendering work with an explicit algorithm, acceptance criteria, and visual validation; graphics tests or documentation with no production diff; and a decision-complete cross-language migration with explicit ownership, ordering, rollback, and validation. Discovery and evidence roles remain bounded read-only helpers. A runtime with only generic agents expresses every role in prompts and records that runtime mapping without stopping.
32. RED sends every Backlog parent through triage or implementation; GREEN returns a bare configured epic as

    readyEpics

    only after its native open blockers and descendants clear, then closes it in the controller lane with explicit authority and reconciles Done. Novel case: its closure exposes a downstream Planning-authorization action on the refreshed graph. Counterexample: an epic with configured human work is never auto-closed.
33. RED hides

    ready-for-agent

    Backlog work or treats conversation approval as Planning authority; GREEN returns

    move-to-planning

    in

    humanActions

    and waits for the approver's live Project transition. Novel case: several independent human actions appear in one ordered frontier packet while an unrelated implementation slot continues. Counterexample: an unchanged frontier packet is not repeated.
34. RED treats a human frontier as a failed partial drain or a successful empty drain; GREEN returns

    waiting-for-human

    only after controller, planning, implementation, monitoring, and triage work clear. Novel case: resumption reconstructs the graph after a long pause and obtains fresh merge and epic- close authority. Counterexample: a blocked claimed slot remains a partial drain.
35. RED parses issue prose as a dependency or permits conflicting role labels; GREEN schedules only from native relationships, reports prose drift, and rejects epic-plus-agent or multiple next-action roles. Novel case: an assigned human gate remains a human action rather than interrupted runner cleanup. Counterexample: an unassigned bare epic needs no next-action role label.
36. RED lets

    setup

    fall through execution preconditions, trust a partial live read, or skip bounded retries; GREEN applies read-only failure handling, discovers, writes, and live-validates only the complete configuration pair, then returns its configuration result without claims or remote mutations. Novel case: a partial paginated field read is discarded and the complete logical read is retried. Counterexamples: mutation reconciliation never applies in

    setup

    , and missing

    tdd

    or merge authority does not block a complete

    configuration-ready-to-commit

    result.
37. RED leaves a terminal ticket-local required-CI blocker occupying its slot, trusts local parking state after restart, selects from a stale queue, or finishes before a fresh query; GREEN verifies a durable parking record after three non-converging repair rounds, releases the slot and agent, refreshes the complete Project graph and verified base, then reranks before claiming or finishing. Novel case: after restart, an unchanged record stays parked; a changed PR head or required-check fingerprint produces a verified resume record, and an existing Ready item takes the released slot before a newly discovered Planning item uses spare agent capacity. Counterexamples: a transient remote wait still occupies its slot; access, review, base-repair, configuration, and ambiguous-mutation failures are not parkable; and the same failure in two slots or on the verified base is global. Configuration or merge-policy drift stops the drain and never resumes a parked claim.
38. RED leaves an authorized configuration commit without a terminal result when it is not on the verified base; GREEN returns

    configuration-valid

    only when the base contains both files and otherwise returns

    configuration-ready-to-commit

    with the exact commit and missing-base evidence. Novel case: a valid configuration commit on a feature branch remains ready to land while

    next

    and

    drain

    stay paused. Counterexample: a base that already contains the live-validated pair is valid, not ready to commit. Discovering missing configuration during

    next

    never silently switches modes or begins execution from uncommitted configuration.
39. RED accepts a labelled child, map membership, or an old Planning event; GREEN requires an open configured-Project child in Planning, exactly one configured type label, an open configured-map parent, native unblocked graph, and the latest non-automated approver-authored Planning transition. Novel case: a malformed unclaimed child is reported while ordinary planning proceeds; an assigned invalid child remains a blocked Planning claim. Counterexample: an enabled map label never turns an ordinary ticket into a Wayfinder child without all child eligibility evidence.
40. RED sends Wayfinder work through

    to-plan

    , Ready, or implementation; GREEN invokes the installed

    wayfinder

    provider in the single Planning lane, requires distinct Wayfinder mutation authority before a claim, and closes a successful child after resolution while reconciling the map. Novel case: completion closes a decision-ready map only after every child closes and fog clears. Counterexample: a created child enters Backlog and awaits a new human Planning transition.
41. RED lets

    drain

    pause for every Wayfinder ticket or lets an ambiguous task run AFK; GREEN runs only proved AFK research/tasks in spare Planning capacity, uses a fresh Wayfinder provider context for each non-research AFK child in

    drain

    , preserves

    next

    HITL as the current live exchange, and requires

    research

    subagents for research tickets. It reports unassigned prototype, grilling, HITL, and ambiguous-task work as a non-blocking Wayfinder human frontier. Counterexample: a generic read-only helper never substitutes for

    research

    , and

    next

    resolves only its selected, freshly approved HITL child before finishing.
42. RED leaves HITL tickets frontier-only in every mode; GREEN passes the mode to the ranker so

    next

    selects an authorized HITL ticket by normal Planning rank while

    drain

    keeps an unassigned ticket in the human frontier and an assigned ticket in separate HITL attention. Novel case: an explicitly named eligible child outranks Project order in

    next

    . Counterexamples: explicit selection never works in

    drain

    , bypasses another durable claim, or calls an assigned ticket frontier work.
43. RED closes a resolved child before map work and loses it after a crash; GREEN publishes a runner-authored reconciliation marker first, recovers it across closed issues and archived Project items, then preserves Wayfinder's child-close-before-map order while replaying its exact plan idempotently, reconciling configured Done/archive, and unassigning last. Novel case: an out-of-scope disposition writes its linked gist and reason only under

    Out of scope

    ; map completion requires no open child, empty fog, and current decision/scope indexes. Counterexample: a marker for another Project item or runner is a blocked claim, never recovery authority.
44. RED reports Wayfinder tickets as bare numbers; GREEN renders every human-facing map and ticket reference as

    [title](URL)

    while retaining numbers and node IDs in machine payloads. Novel case: both the assigned HITL attention packet and final report use linked names. Counterexample: ranker diagnostics may still use issue numbers.