These are repository-owned public workflow instructions invoked by the user, not hidden platform instructions. Source revision: c284c767fa9b38d908773f968d214b145d16bac9. Later user overrides appear in campaign-user-prompt-history.json. This is provenance for the original campaign; it is not a claim that every file below was replayed unchanged in every later request.
Immutable source · SHA-256 8381be0ebda7f5d68307f42b27ec3db2c68112a8d70cf0c8fad05211e9bc9a63.
---
name: triage-fix-all-bugs
description: Use when asked to coordinate triage and remediation of all currently open native GitHub Bug issues in this repository. Does not apply to fixing one issue or authoring this skill.
---
# Triage and fix all Bugs
Run a repository-wide Bug campaign in two sequential phases: **triage, then
remediation**. The root coordinates; dedicated workers investigate, implement,
and review. Apply each role's instructions only to the agent assigned that role.
An invocation authorizes the requested campaign, subject to the user's scope and
the repository's rules. Reading, editing, or testing this skill does not launch
the campaign or authorize its issue mutations, workers, or LCM replacement.
## Read by phase
The references contain the full procedure, including mandatory gates and event
payloads. Do not treat this entrypoint as a replacement for the applicable phase.
1. The root reads [inventory and triage](references/triage.md) and
[coordination and completion](references/coordination.md) before starting.
2. Before dispatching triage, give each worker the shared contract here and the
relevant triage instructions, its issue, the frozen inventory, and evidence.
3. After the complete triage barrier passes, the root and each owner read
[remediation](references/remediation.md). Give implementers and reviewers the
applicable sections and a self-contained role brief.
4. The root uses the final audit in the coordination reference before reporting
completion. On resume, load the existing run record and reconcile live state;
preserve S0, candidate history, and spent review rounds.
## Shared contract
- **Native types and relationships:** `Bug` and `Epic` mean native GitHub issue
types with those exact names. Labels, title matching, Projects fields, and
checklists cannot substitute for types or native sub-issue relationships.
- **Immutable scope:** establish S0 only after two consecutive, fully paginated
native-Bug enumerations agree. Record T0, TF, parents, and the exact default
branch HEAD. Later Bugs, including deferred P2s, never enter S0.
- **Existing ownership:** an S0 Bug already parented outside the run is
`delegated-existing-parent`. Record it without mutation, reparenting, triage,
or remediation. Keep it in the S0 inventory and denominator.
- **Triage barrier:** every S0 member must have a valid disposition, every
individual triage worker must finish, and every suspected S0 duplicate group
must finish centralized adjudication before remediation starts.
- **Seven productive owners:** at most seven Bugs actively undergo remediation.
Park externally blocked work and promptly refill slots with actionable Bugs.
Parking alone is not terminal. Avoid obvious overlap where practical; do not
acquire exclusive source-file locks or delay ready merges for convenience.
- **Exact candidate:** commit and freeze each candidate SHA. GLM and Grok review
independently; Opus reviews second using both reports; the owner adjudicates.
Freeze implementation while reports are being gathered. Every head change
requires this complete process again, including CI-only or conflict commits.
- **Severity and budget:** accepted P0/P1 always block. Accepted P2 blocks during
the initial three reviewed candidate rounds; after round three, defer remaining
P2s into linked native Bugs outside S0. P2 alone never triggers escalation.
Escalation does not reset the P2 budget. P3 needs adjudication, not remediation.
- **Root boundary:** the root does not implement fixes, edit owner worktrees,
perform implementation review, or replace a reviewer. Only the root communicates
with the user and manages the main LCM installation and daemon.
## Execution integration
Read the repository's `AGENTS.md`, `WORKFLOW.md`, and applicable `AGENTS.local.md`
before work. For a non-primary worktree, identify the primary with
`git worktree list --porcelain` and read its local instructions too. Use the
available `lcm-memory` skill for project context.
Preserve repository delivery rules: signed commits when required, DCO signoff,
the PR template and assignment convention, relevant local tests, fresh exact-head
CI and full coverage gates, review-thread handling, documentation, and the
Changeset decision. Use a merge commit as required by `WORKFLOW.md`. Do not bypass
admission, force-push, or weaken checks to finish a campaign.
In this repository, the root/coordinator executes pushes, PR creation, and merges.
Bug owners remain accountable for their PRs through merge: they send the root the
branch, exact clean SHA, PR content, and the evidence applicable to that action.
The root verifies orchestration and admission evidence without reviewing the
implementation. References saying an owner publishes or merges describe that
owner's responsibility; the root executes those operations under `WORKFLOW.md`.
Owners emit `publication-requested` with branch, clean SHA, review/adjudication
record, local validation, and PR text. CI that requires a published branch is not
a prerequisite for this request. The root returns `pr-published` with URL and
head SHA. Owners emit `merge-requested` with that PR, clean SHA, and complete
exact-head CI, review, and follow-up evidence. Immediately before merging, the
root rechecks the live PR head against the declared clean SHA and required gates,
using an expected-head merge guard when supported. On a mismatch, return to the
owner for review of the new candidate; do not merge. Return `pr-merged` with the
verified merge SHA after confirming GitHub reports `MERGED`.
Publication requests include the originating Bug and a closing reference when
the fix fully resolves it. After merge, verify the source Bug is closed and the
fix is present on the default branch. If GitHub did not close it automatically,
the owner supplies the resolution evidence and the root closes it explicitly,
then reads back the state before recording `merged-resolved`. A merged PR with
an unresolved or still-open source Bug is not terminal; return incomplete fixes
to the owner instead of closing them for accounting purposes.
For P2 deferrals made before a PR exists, create the native Bug with the originating
Bug, candidate SHA, review context, evidence, and reproduction details first.
Record its PR link as pending; creating the follow-up satisfies the pre-publication
deferral gate. Add the PR link immediately after publication. A missing PR link
blocks merge and the final audit, so this ordering never loses the required link.
Use issue-body links or cross-references for these follow-ups, not native parenting
under the current campaign. Describe the distinct remaining finding so it is not
mistaken for the already-fixed originating Bug. If a follow-up is later fixed,
record the fixing SHA and verified resolution instead of leaving stale work open.
Establish the run's root as the Environment Coordinator before any global LCM
mutation. If another coordinator holds that responsibility, arrange an explicit
handoff; do not seize its lock or let subagents replace the global installation.
The root follows the repository's exact artifact installation and health workflow.
Use supported subagent mechanisms, within the runtime's depth and capacity limits.
The logical hierarchy is root → bug owner → implementers/reviewers. If the surface
cannot dispatch grandchildren, the root may dispatch those workers on the owner's
behalf and route their reports to that owner; ownership and independent reviews
stay unchanged. Do not create user-owned tasks merely to bypass subagent limits.
## Required worker routing
Resolve these model names against the **live** dispatch catalog; record the exact
model ID and effective settings in the run record. Do not invent a model ID or
claim a service tier that was not selected or confirmed by the runtime.
Use the active tool schema and supported explicit model overrides as authoritative
evidence; a default list is not necessarily exhaustive when the runtime permits
user-selected routes. Reuse a verified route recorded for the run. When several
routes provide the requested model/settings, select an available authorized route
and record the choice; ask only if the choice changes a user constraint or cannot
be resolved from runtime evidence. Reviewer unfamiliarity with the harness is not
evidence that a supported route is unavailable.
| Role | Model | Reasoning | Service tier |
| --- | --- | --- | --- |
| Triage, centralized duplicate adjudication | Luna | high | priority |
| Dedicated Bug owner | Astra | medium | priority |
| Default initial implementer | Luna | high | priority |
| Security-related initial implementer | Daybreak Blue | high | priority |
| Escalated implementer | Astra | high | priority |
| Independent first-pass reviewer | GLM-5.3 | Max | unspecified |
| Independent first-pass reviewer | Grok 4.6 | medium | unspecified |
| Second-pass reviewer | Opus 5 | medium | unspecified |
Both planning and every frozen candidate use the same GLM → Opus and Grok → Opus
review structure. GLM and Grok do not see each other's first-pass reports. Use
minimal, self-contained dispatch context; follow runtime fork restrictions.
Before launching the run, verify that required models, reasoning levels, service
tiers, and dispatch mechanisms are available. A runtime-confirmed fixed priority
tier is sufficient even when no per-call tier parameter exists. If a required
setting cannot be provided or verified, report the blocker before issue mutation
or worker launch and request an explicit substitution. Never silently substitute
models, lower reasoning, omit reviewers, or assume an unverified tier.
## Durable run record and recovery
Keep a run record in workflow-local scratch; keep the root Epic as the authoritative
high-level tracker. Record the repository, default branch, T0, TF, freeze SHA,
complete S0 inventory, hierarchy, all required counters, worker IDs and settings,
worktrees/branches, triage evidence, dispositions, candidate SHAs, completed review
rounds, adjudications, P2 follow-ups, PRs, current clean SHA, and LCM installed SHA
and health evidence. Keep tokens and credentials out of both locations.
Give the root Epic a stable run identifier and record the coordinator task/host,
scratch location, and a compact recovery checkpoint: S0 and freeze metadata,
owner/disposition map, current candidates, spent rounds, P2 state, review-evidence
links, PRs, and last verified LCM SHA. Update it at meaningful transitions. Avoid
publishing private host paths on a public Epic; use a shareable artifact location
or the host/task identity plus a relative scratch location. Preserve enough state
there for a successor to identify evidence without guessing paths or resetting
budgets. Inspect existing run Epics during preflight to distinguish a requested
resume from a new campaign. Reuse the same run on resume; an unrelated open Epic
alone does not block an authorized new run or authorize takeover of its members.
Reconcile issue state, native parents, existing Epics, worker status, and PR heads
before retrying interrupted mutations. Read back uncertain writes before retrying
so recovery does not duplicate Epics, follow-ups, closures, owners, or merges.
Never restart the inventory or round budget merely because the session resumed.
Recheck parent ownership immediately before attaching or dispatching an issue; if
it was claimed externally, preserve that hierarchy and record delegation.
Live external closures do not change S0. Read the closure reason and evidence,
then have the assigned worker validate the underlying disposition: an established
duplicate is `closed-duplicate`, an obsolete/fixed report verified against the
default branch is `closed-nonreproducible`, and a verified merged fix with resolved
issue is `merged-resolved` during remediation. Record who closed it and when; the
worker need not perform a second close. Unsupported automated closures are not
terminal evidence: investigate, correct the issue state when justified, or report
the specific external blocker. Do not invent a catch-all terminal state that
accepts an unverified closure. Delegated issues retain the no-mutation rule.
For every deferred follow-up, read back its native type and current resolution
at final audit. If automation has changed or closed it, inspect the evidence;
retain a valid resolution/canonical successor or correct an unsupported change.
Do not repeatedly reopen valid duplicates or resolved work to satisfy a counter.
If full enumeration keeps changing, cannot finish, or returns an error, leave S0
unfrozen and report the blocker. A partial response or fixed CLI result limit is
not an empty or complete Bug set. Do not mutate issues just to stabilize the set.
For a validated empty S0, create the requested empty tracking Epic, launch no
workers, and perform the normal final audit.
## Decision checks
| Situation | Required action |
| --- | --- |
| Two S0 workers each call the other a duplicate | Keep both open pending centralized adjudication |
| Reproduction is inconclusive | Keep open as `uncertain-needs-remediation` |
| Round three ends with only accepted P2s | File linked native Bug follow-ups; do not escalate |
| A clean head gains one CI-only commit | Invalidate cleanliness and review the new SHA fully |
| No active owners, but an S0 Bug is parked | Reconcile/resume or establish a genuine external blocker; not completion by itself |
| A worker finishes between watchdog checks | Handle the event immediately and refill available slots |
For example, if S0 contains four Bugs, one is delegated, one closes during triage,
and two merge, all four are terminal. Two deferred P2 follow-ups remain separate:
the denominator is still four. Completion also requires the final hierarchy,
default-branch, exact installed LCM, and daemon-health audit.
Immutable source · SHA-256 a10a6e51797a06b6a1d87c993f9dae59adb5168f56af1f385d657d28adbce313.
# Inventory and triage
Read the shared contract in [SKILL.md](../SKILL.md) before applying this phase.
**Contents:** Preflight → immutable S0 → existing parents → native Epic hierarchy → triage workers → duplicate adjudication → triage barrier.
## 0. Preflight
Before mutating any GitHub issue or launching any worker:
1. determine the repository's actual default branch;
2. determine its exact HEAD SHA;
3. verify that the repository or organization exposes a native GitHub issue type named exactly `Bug`;
4. verify that a native GitHub issue type named exactly `Epic` is available for the tracking hierarchy;
5. verify that native GitHub sub-issue relationships are available;
6. determine any native GitHub sub-issue capacity constraints that affect the tracking hierarchy;
7. verify that the root coordinator has enough access to:
- enumerate native issue types;
- create issues;
- assign native issue types;
- create native sub-issue relationships;
- comment on issues;
- close issues;
- create and merge pull requests as required;
8. verify the main LCM daemon is running and healthy.
Do not silently replace missing native issue types or native issue relationships with labels, Projects fields, Markdown checklists, or other approximations.
If a required native GitHub capability is unavailable, stop before destructive mutation and report the blocker to the user.
Do not assume the default branch is named `master` or `main`.
## 1. Establish the immutable Bug set
At task start, perform an exhaustive enumeration of all open GitHub issues whose **native GitHub issue type** is exactly:
`Bug`
Call the resulting immutable set **S0**.
### Critical classification rule
`Bug` means the repository or organization's native GitHub issue type named exactly `Bug`.
It does **not** mean:
- an issue carrying a `bug` or `Bug` label;
- an issue whose title contains "bug";
- a GitHub Projects custom field;
- an issue that merely appears bug-like.
**Do not use labels as a substitute for GitHub issue type.**
If the convenient GitHub CLI command being used cannot reliably expose or filter native issue types, use another GitHub API or GraphQL query that can.
Do not silently fall back to label-based enumeration.
### Snapshot semantics
GitHub issue enumeration is not assumed to provide an atomic transactional snapshot.
Use these operational semantics:
1. record an enumeration-start timestamp **T0**;
2. enumerate all open issues using complete pagination;
3. select only issues whose native issue type is exactly `Bug`;
4. perform a second exhaustive enumeration before freezing S0;
5. compare the resulting Bug sets;
6. if they differ, repeat the exhaustive enumeration until two consecutive complete enumerations agree;
7. freeze the agreed result as S0;
8. record an S0-freeze timestamp **TF**.
Do not mutate candidate S0 issues before S0 is frozen.
S0 is the validated stable enumeration result established by this procedure. Do not attempt to reconstruct a historical atomic snapshot at T0 from issue timelines.
### Enumeration requirements
For every issue in S0, record:
- issue number;
- title;
- URL;
- native issue type;
- native parent issue, if any;
- enumeration-start timestamp T0;
- S0-freeze timestamp TF.
Also record:
- the repository's actual default branch;
- the exact default-branch HEAD SHA observed when S0 is frozen.
Sanity-check the resulting count and complete issue list before declaring S0 established.
Only after this validation may triage workers be launched.
Once established, **S0 never changes during this run**.
Issues created later, including Bugs created from deferred P2 findings, are not added to S0.
## 2. Existing ownership and parent relationships
During S0 establishment, inspect the native parent relationship of every Bug in S0.
If an S0 Bug already belongs to a native parent hierarchy outside this remediation run:
1. do not reparent it;
2. do not otherwise mutate it as part of this run;
3. record its existing parent;
4. classify it as:
`delegated-existing-parent`
5. treat that classification as a terminal S0 state;
6. include it in the tracking Epic inventory as externally owned.
A `delegated-existing-parent` Bug does not receive a triage worker and does not enter remediation.
It remains part of S0 for accounting and final completeness checks.
Do not alter another remediation hierarchy solely to make this run's tracking hierarchy complete.
## 3. Create the tracking Epic hierarchy
Create one new GitHub issue using the native GitHub issue type:
`Epic`
This is the **root remediation Epic**.
The root Epic must describe the remediation run and contain the complete S0 inventory, including Bugs classified as `delegated-existing-parent`.
The root Epic is the authoritative high-level progress tracker for this run.
### Native relationship requirements
For S0 Bugs that do not already belong to another native parent hierarchy, make them native descendants of the root remediation Epic.
Prefer direct native sub-issue relationships where capacity permits.
If the complete S0 set cannot fit directly beneath one Epic because of GitHub native hierarchy capacity:
1. create additional tracking issues using the native `Epic` issue type;
2. make those tracking Epics native descendants of the root remediation Epic;
3. distribute eligible S0 Bugs beneath those child Epics;
4. preserve one native remediation hierarchy rooted at the root Epic.
Tracking child Epics are orchestration metadata and are **not** members of S0.
Do not silently omit an S0 Bug because of native hierarchy capacity.
Do not substitute labels or a Markdown checklist for native issue relationships.
Bugs classified as `delegated-existing-parent` remain in their existing hierarchy and are represented in the root Epic inventory without being reparented.
### Epic state tracking
Keep the root Epic updated as S0 Bugs move through:
- delegated to existing parent;
- triage;
- closed during triage;
- queued for remediation;
- active remediation;
- PR open;
- merged/resolved;
- blocked or parked.
The root Epic should also track aggregate counters for this run.
## Phase 1: Triage
For every Bug in S0 that is not already in the terminal state `delegated-existing-parent`, spawn one independent:
**Luna, high reasoning, priority service tier**
triage worker.
Launch triage workers in parallel where possible.
Each worker owns exactly one Bug for triage.
## Triage worker responsibilities
Each triage worker must independently determine:
1. whether the reported bug is still reproducible against the S0-freeze default-branch HEAD or a newer default-branch HEAD where appropriate;
2. whether the issue appears to duplicate another existing issue.
The worker must leave enough evidence on the issue for another engineer to understand and verify the conclusion.
### If no longer reproducible
Document:
- the attempted reproduction;
- environment or conditions used;
- relevant evidence;
- the conclusion.
Then close the Bug.
Record the triage disposition:
`closed-nonreproducible`
### If clearly duplicate of an issue outside S0
If the canonical issue is outside S0 and the duplicate relationship is unambiguous:
1. identify and link the canonical issue;
2. document the reasoning;
3. close the S0 Bug.
Record the triage disposition:
`closed-duplicate`
### If suspected duplicate of another S0 issue
If the suspected canonical or duplicate issue is also a member of S0:
1. document the suspected duplicate relationship;
2. provide evidence and reasoning;
3. do **not** close either S0 issue;
4. report the relationship to the root coordinator for centralized duplicate adjudication.
Independent S0 workers must not independently close each other as duplicates.
### If still reproducible
Record the reproduction result and supporting evidence.
Leave the Bug open for remediation.
Record the triage disposition:
`reproducible`
### If uncertain
Do not close the Bug merely because reproduction was inconclusive.
Document what was attempted and why the result remains uncertain.
Keep it open and treat it as needing remediation unless there is positive evidence that it is obsolete or duplicated.
Record the triage disposition:
`uncertain-needs-remediation`
## Triage worker completion event
When a triage worker reaches a terminal triage result, it must immediately notify the root coordinator of:
- Bug number;
- triage disposition;
- whether it was closed;
- whether S0 duplicate adjudication is required;
- any exceptional blocker.
This is a coordinator wake-up event.
It is not a user-facing notification.
Workers must not communicate directly with the user.
## S0 duplicate adjudication
After all individual triage workers have completed, but before releasing the triage barrier, inspect all suspected duplicate relationships involving two or more S0 issues.
If any exist, spawn one dedicated:
**Luna, high reasoning, priority service tier**
duplicate-adjudication worker.
Provide that worker:
- the complete S0 inventory;
- all suspected S0 duplicate relationships;
- all relevant triage evidence;
- current issue states.
The duplicate-adjudication worker must:
1. evaluate each connected duplicate group;
2. determine whether the issues are actually duplicates;
3. choose the canonical issue where duplication is established;
4. avoid duplicate cycles such as A → B and B → A;
5. preserve the issue containing the clearest or most complete canonical problem statement where practical;
6. document the reasoning;
7. close only the issues adjudicated as duplicates;
8. leave the canonical issue in its appropriate triage state.
For each closed duplicate, record:
`closed-duplicate`
For the canonical issue, preserve or establish the correct remaining triage disposition.
The duplicate-adjudication worker must notify the root coordinator when adjudication is complete.
## Triage barrier
The root coordinator must not begin remediation until every issue in S0 satisfies exactly one of these conditions:
- `delegated-existing-parent`;
- `closed-nonreproducible`;
- `closed-duplicate`;
- `reproducible`;
- `uncertain-needs-remediation`.
Additionally:
- every individual triage worker must have completed;
- every suspected S0 duplicate group must have completed centralized adjudication.
Only then may remediation begin.
Update the root Epic with final triage counts before entering remediation.
## Worker safety and replacement
Run reproductions and tests in the repository's isolated fixtures, with
worker-owned home/XDG state, temporary roots, sockets, databases, and any test
daemon. Do not point destructive or state-changing reproductions at the user's
main LCM state or another worker's publication lock. Ordinary read-only project
memory access is separate from reproduction. If authentic reproduction requires
shared state that cannot be isolated, report the boundary instead of experimenting
on it. Never infer nonreproducibility from a broken fixture or unavailable runtime.
A failed triage worker is not a completed disposition. Replace it for the same
Bug with a worker that inherits the recorded evidence and completes the required
triage. Record the failed instance as superseded and ensure it cannot continue
mutating that issue. The barrier requires a completed valid triage assignment for
each non-delegated Bug, with no unresolved or still-running triage assignment;
it does not require a failed process to return successfully.
Centralized duplicate adjudication preserves outside ownership. A delegated S0
member can be the canonical target of another Bug's duplicate finding, but this
run never comments on, closes, reparents, or otherwise mutates that delegated
member. Preserve its `delegated-existing-parent` disposition even if it would
otherwise be the less complete report.
Immutable source · SHA-256 2e894e58704c086e23cf9f91bc3f5c0e9ac1895af4dde2b77bdcd368e4dcf0a3.
# Root coordination and completion
Read the shared contract in [SKILL.md](../SKILL.md) before applying this phase.
**Contents:** Root responsibilities → LCM ownership and health → event handling → watchdog → counters → user communication → terminal states → final audit.
## Root coordinator responsibilities
The root coordinator is responsible for:
- preflight validation;
- establishing and validating S0;
- recording existing parent ownership;
- creating and maintaining the remediation Epic hierarchy;
- enforcing the triage barrier;
- launching centralized S0 duplicate adjudication where needed;
- maintaining up to 7 productive active Bug owners;
- replenishing remediation slots;
- best-effort conflict-aware scheduling;
- monitoring Bug-owner progress;
- maintaining overall counters;
- ensuring stalled or failed workers are noticed;
- handling truly necessary inter-agent deconfliction;
- maintaining the main LCM installation and daemon;
- communicating with the user.
The root coordinator is an orchestrator, not an implementation agent.
## Root coordinator prohibitions
The root coordinator must **not**:
- implement Bug fixes;
- edit bug-owner worktrees;
- perform implementation review;
- act as GLM, Grok, or Opus reviewer;
- take over implementation from an assigned implementer;
- hold exclusive source-file locks;
- serialize independent work unnecessarily;
- repeatedly interfere with healthy workers;
- micromanage bug owners.
The root coordinator should intervene in sub-agent work only when coordination genuinely requires it.
## LCM ownership
The root coordinator is the **only agent permitted to manage the main local LCM installation or main LCM daemon**.
No bug owner, reviewer, implementer, triage worker, duplicate adjudicator, or other sub-agent may:
- install LCM globally;
- replace the main LCM installation;
- restart the main daemon;
- stop the main daemon;
- upgrade the daemon;
- take ownership of its coordination lock.
Whenever a merge advances the default branch HEAD and therefore publishes a new LCM HEAD, the root coordinator must:
1. observe the current new default-branch HEAD;
2. install that exact version using the repository's prescribed installation procedure;
3. verify the main LCM daemon is running;
4. verify the daemon is healthy before returning to normal orchestration.
If multiple merges occur before the coordinator processes an LCM update, converge directly to the current default-branch HEAD rather than intentionally installing obsolete intermediate versions.
The root coordinator is the sole owner of any exclusive coordination primitive required specifically for the main LCM daemon.
It must hold **no other exclusive locks**.
## LCM health invariant
The main LCM daemon should remain up and healthy throughout the task.
The root coordinator must verify daemon health:
- at startup;
- before an LCM replacement or upgrade;
- after an LCM replacement or upgrade;
- during each periodic coordinator status check;
- whenever there is evidence that LCM may be unhealthy.
If the daemon is unhealthy, restoring it is a root-coordinator responsibility.
LCM recovery should not cause the root coordinator to begin editing Bug-owner worktrees or otherwise violate orchestration ownership.
## Event-driven coordinator behavior
The root coordinator should normally remain idle and allow sub-agents to work independently.
It should wake immediately for meaningful coordinator events, including:
- triage-worker completion;
- completion of duplicate adjudication;
- the triage barrier becoming satisfiable;
- a Bug owner parking work;
- a Bug owner becoming externally blocked;
- a PR opening;
- a PR becoming merge-ready;
- a PR merging;
- implementer escalation;
- worker failure;
- evidence of LCM failure.
Event-driven wake-ups should be used to keep work moving without continuously polling workers.
In particular:
- do not wait for the next 30-minute interval after all triage work has completed;
- do not leave remediation slots idle until the next periodic pass after a merge or park event.
## Periodic coordinator watchdog
Independently of event-driven wake-ups, every **30 minutes** proactively perform one coordination pass.
During that pass:
1. verify LCM daemon health;
2. inspect the state of every active Bug owner;
3. identify completed work;
4. identify failures;
5. identify stalled work;
6. identify parked or externally blocked Bugs;
7. replenish available remediation slots;
8. update the root Epic if appropriate;
9. emit a concise progress report.
The 30-minute pass is a watchdog and reconciliation mechanism.
It is **not** the primary mechanism for detecting normal state transitions.
Do not continuously poll workers between periodic checks unless an event requires immediate coordinator action.
## Progress counters
Maintain these counters explicitly:
- total Bugs in S0;
- delegated to existing parent;
- triage dispositions completed;
- closed during triage as non-reproducible;
- closed during triage as duplicate;
- eligible for remediation after triage;
- waiting for remediation;
- active remediation owners;
- PRs open;
- PRs merged;
- blocked or parked S0 Bugs;
- S0 Bugs escalated to Astra;
- S0 Bugs routed to Daybreak Blue;
- deferred P2 follow-up Bugs created;
- S0 Bugs remaining to terminal state.
`deferred P2 follow-up Bugs created` is a separate counter.
Deferred P2 Bugs are never included in:
`S0 Bugs remaining to terminal state`
Do not allow newly generated follow-up Bugs to change the immutable S0 denominator.
## Progress reports
Each 30-minute progress report should be brief and include at least:
- total Bugs in S0;
- delegated to existing parent;
- triaged;
- closed during triage;
- remaining after triage;
- waiting for remediation;
- active remediation owners;
- PRs open;
- PRs merged;
- blocked or parked S0 Bugs;
- Bugs escalated to Astra;
- Bugs routed to Daybreak Blue;
- deferred P2 follow-up Bugs created;
- S0 Bugs remaining to terminal state.
Include exceptional events only when useful.
Routine internal worker chatter should not be forwarded to the user.
## User communication
The root coordinator is the **only agent permitted to interact with the user**.
Sub-agents must never directly request decisions from the user.
If a sub-agent requires user input, it must send the root coordinator:
- the question or decision required;
- enough context to understand it;
- why the decision matters;
- available options;
- the safest reasonable default or reversible action, if one exists.
The root coordinator decides whether the user actually needs to be interrupted.
If user input is required for one Bug, continue all unrelated work rather than stopping the entire task.
Where a reversible or clearly safe default permits useful progress, prefer continued progress while the decision is unresolved.
Do not invent irreversible user decisions.
## Push notifications
Because this is expected to be a long-running task, the root coordinator may send push notifications to the user.
Use them only for meaningful events such as:
- a decision genuinely requiring user input;
- a major blocker;
- repeated worker failure;
- an orchestration failure that prevents useful progress;
- a significant completion milestone.
Do not send push notifications for normal sub-agent activity.
The regular 30-minute progress report is sufficient for routine progress.
Coordinator wake-up events and user push notifications are distinct concepts.
A worker waking the root does not imply that the user should be notified.
## Terminal S0 states
An S0 Bug is terminal only in one of these states:
1. `delegated-existing-parent`
2. `closed-nonreproducible`
3. `closed-duplicate`
4. `merged-resolved`
5. `blocked-genuine-external-condition`
`blocked-genuine-external-condition` may be used only when the Bug is genuinely blocked by a condition that the orchestration system cannot resolve autonomously and that condition has been explicitly reported to the user.
A temporarily parked Bug is **not** terminal merely because its active remediation slot was released.
## Completion condition
The task is complete only when **every issue in S0** has reached exactly one valid terminal state.
Before declaring completion:
1. verify every S0 issue has a terminal state;
2. verify every merged fix is reflected on the current default branch;
3. verify every deferred accepted P2 has a corresponding linked native `Bug` issue;
4. verify deferred P2 Bugs were not added to S0;
5. verify the root remediation Epic accurately reflects final status;
6. verify the complete tracking hierarchy is internally consistent;
7. verify the main LCM installation corresponds to the current default-branch HEAD;
8. verify the main LCM daemon is running and healthy;
9. verify no active Bug owner is still performing useful work on an S0 Bug declared terminal;
10. provide a concise final report.
The final report should include:
- total S0 Bugs;
- delegated-existing-parent;
- closed non-reproducible;
- closed duplicate;
- remediated and merged;
- genuinely externally blocked;
- escalated to Astra;
- routed to Daybreak Blue;
- deferred P2 follow-up Bugs created;
- final default-branch HEAD;
- LCM health status.
Do not declare completion merely because there are no active workers.
Completion is a property of the terminal state of **every member of S0**.
## Operational reliability
Apply these checks when wiring the run or recovering interrupted workers:
- **Deliver completion events.** At dispatch, establish a supported path that
actually wakes the root when a worker finishes or needs intervention. Include
Bug number, transition, worker ID, PR URL, candidate/merge SHA as applicable,
and run-record location. Verify the first event is received and handled. A
message saved in a worker transcript is not evidence that an idle root woke.
If the runtime only delivers events during an active wait, keep the root in
that supported wait while workers run; do not end the turn and assume it wakes.
- **Wire the watchdog separately.** Register a supported 30-minute wake-up for
reconciliation and progress reporting. Include the run/Epic identity and
record location so it resumes the same campaign. Reuse or update that run's
existing watchdog on recovery; stop it after the final audit. Do not create a
separate autonomous goal or replace event handling with periodic polling.
- **Verify the effective dispatch route.** A healthy model proxy alone does not
establish that the current agent runtime exposes GLM, Grok, or Opus. Check the
active dispatch catalog and effective settings. After a route failure, require
a successful result through that route before restoring broad parallel use;
an older worker's success does not prove fresh launches work. Unknown-model
errors, unavailable tools, and provider tool-count limits are worker failures,
not clean reviews. Reduce optional tool exposure when the supported surface
permits it, while preserving access needed for an independent review.
- **Recover at the interrupted gate.** Preserve the worktree, candidate SHA,
plan, completed reports, spent rounds, and P2 state. Retry only missing or
failed reviews when the candidate SHA is unchanged; every new SHA still needs
a complete review. Read worker reports after a purported recovery before
declaring the route healthy. Do not restart a Bug or replace required models
merely because the dispatch environment failed.
- **Respect shared services.** Authorization to manage the main LCM daemon does
not authorize reconfiguring or restarting the user's Codex app-server, model
proxy, or desktop connector. Diagnose the specific failing boundary, report
any broader repair needed, and preserve affected candidates while unrelated
work continues. Resume only after verifying that boundary works again.
- **Keep scope changes explicit.** A later user instruction may authorize a
successor inventory or a different concurrency limit. Record that as an
explicit run-contract revision with its own denominator and timestamp;
preserve the original S0 record. New follow-up Bugs, runtime recovery, and
idle workers never imply permission to expand S0 or exceed seven active owners.
- **Reconcile merge batches.** Record a fixed set of observed merge completions
and verify their ancestry against the chosen current default-branch SHA before
installing that artifact. If more merges arrive during refresh, preserve the
pending events and converge to the newest observed HEAD. Do not mark later
merges installed using an earlier artifact's evidence or lose their counters.
- **Preserve verification failures.** Keep the original failed environment-test
log and file newly discovered Bugs outside S0 as required by repository policy.
An unchanged reduced-concurrency retry can diagnose contention; it does not
establish that the original concurrent failure was fixed. Do not change
assertions, timeouts, skips, or required CI gates to manufacture a pass.
- **Recover watcher evidence.** Expired watchers or lost handles do not establish
completion. Reconcile the known process, durable logs, and exit status; attach
a fresh supported watcher where needed. Keep the environment handoff pending
until test completion and daemon health have fresh evidence.
- **Repair audit metadata carefully.** A missing detector field is an evidence
gap, not proof that a gate ran or failed. Reconcile canonical GitHub records and
owner review/CI artifacts against the exact SHAs. Correct bookkeeping without
repeating established gates; rerun only when evidence is absent or invalid.
A merged PR alone does not prove all required reviews and CI passed.
These checks concern orchestration evidence. They do not authorize the root to
review or edit implementations, claim a worker's successful result on its behalf,
or infer current health from an older status report.