Astra repeatedly hits `cyber_policy` after benign multi-agent bug triage

# Triage and remediate all currently open Bug issues

You are the **root coordinator** for this task.

Your role is orchestration only. Do not implement fixes or perform code review yourself.

The task has two sequential phases:

1. **Triage**
2. **Remediation**

Remediation must not begin until the complete initial Bug set has been enumerated and every Bug in that set has finished triage.

---

# 1. Establish the immutable Bug set

At task start, take a snapshot of **all open GitHub issues whose native GitHub issue type is ****`Bug`**.

Call this immutable set **S0**.

## Critical classification rule

`Bug` means the repository's **native GitHub issue type named ****`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.

## Enumeration requirements

Before spawning any triage workers:

1. Enumerate all open issues, following pagination until the result set is exhausted.
2. Select only issues whose native issue type is exactly `Bug`.
3. Record:
   - each issue number;
   - title;
   - URL;
   - native issue type;
   - the task-start timestamp.
4. Determine the repository's default branch and record its exact HEAD SHA.
5. Sanity-check the resulting count and 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. Create the tracking Epic

Create one new GitHub issue using the repository's native **`Epic`**** issue type**.

The Epic should describe this remediation run and contain the complete S0 inventory.

Make every issue in S0 a native GitHub **sub-issue** of this Epic.

Use native issue relationships. Do not substitute labels or a Markdown checklist for sub-issue relationships.

The Epic is the authoritative high-level progress tracker for this run.

Keep it updated as bugs move through:

- triage;
- closed during triage;
- queued for remediation;
- active remediation;
- PR open;
- merged/resolved;
- blocked or parked.

---

# Phase 1: Triage

For **every Bug in S0**, spawn one independent:

**Luna, high reasoning, priority service tier**

triage worker.

Launch triage workers in parallel where possible.

Each worker owns exactly one Bug.

## Triage worker responsibilities

The worker must independently determine:

1. whether the reported bug is still reproducible against the task-start default-branch HEAD or a newer default-branch HEAD where appropriate;
2. whether the issue duplicates 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 and evidence, then close the Bug.

### If duplicate

Identify and link the canonical issue, document the reasoning, and close the duplicate.

### If still reproducible

Record the reproduction result and leave the Bug open for remediation.

### If uncertain

Do not close it merely because reproduction was inconclusive.

Keep it open and treat it as needing remediation unless there is positive evidence that it is obsolete or duplicated.

---

# Triage barrier

The root coordinator must wait until **every issue in S0 has a recorded triage result**.

Only then may remediation begin.

Update the Epic with the final triage counts before entering remediation.

---

# Phase 2: Remediation

Maintain **up to 5 Bugs actively being remediated at once**.

Whenever fewer than 5 productive remediation owners are active and eligible Bugs remain, create additional owners until the active count reaches 5 or no immediately actionable Bugs remain.

A Bug occupies an active remediation slot while useful work on it is progressing.

If a Bug becomes blocked solely on external input or another dependency and no useful work can continue, it may be parked so that another Bug can use the slot.

The root coordinator should keep unrelated work moving even when one Bug is blocked.

---

# Bug owner

For every Bug entering remediation, spawn:

**Astra, medium reasoning, priority service tier**

as its dedicated **bug owner**.

The owner remains responsible for that Bug through planning, implementation coordination, review adjudication, PR publication, and merge.

The bug owner must:

1. create a dedicated worktree for the Bug;
2. create a dedicated branch;
3. investigate the problem;
4. develop the remediation plan;
5. coordinate all reviewers and implementers;
6. adjudicate review findings;
7. own the resulting PR until merge.

The bug owner should not delegate ownership of the Bug itself.

---

# Planning review

Before implementation begins, the bug owner must produce a concrete remediation plan.

The plan then receives two **independent first-pass adversarial reviews**:

- **GLM-5.3 Max**
- **Grok 4.6, medium reasoning**

The two first-pass reviewers must work independently and must not be given each other's review before completing their own.

They are reviewers only. They must not modify the plan or implementation.

After both reviews complete, spawn:

**Opus 5, medium reasoning**

for a second-pass adversarial review.

Give Opus:

- the original plan;
- relevant issue context;
- the GLM review;
- the Grok review.

Opus should independently:

- adjudicate disagreements;
- identify findings missed by both first-pass reviewers;
- challenge assumptions;
- identify edge cases;
- identify correctness, concurrency, security, compatibility, testing, or maintenance risks;
- produce a synthesized second-pass review.

The bug owner then reads and adjudicates all findings and updates the plan as necessary.

Only after this process may implementation begin.

---

# Initial implementation

Spawn:

**Luna, high reasoning, priority service tier**

as the implementation sub-agent.

The Luna implementer works in the bug owner's worktree and implements the approved plan.

The bug owner continues coordinating the Bug but should leave implementation to the assigned implementer.

---

# Frozen candidate review

When implementation reaches a candidate state, commit it and record the exact candidate commit SHA.

That SHA is a **frozen candidate head**.

All reviewers in that review round must review exactly the same candidate SHA.

Do not allow implementation changes while reviews of that candidate are still being gathered.

For every candidate, perform the same adversarial review structure:

### Independent first pass

- GLM-5.3 Max
- Grok 4.6, medium reasoning

### Second pass

- Opus 5, medium reasoning

Opus receives:

- the exact candidate SHA;
- relevant Bug context;
- the approved remediation plan;
- both first-pass implementation reviews.

The bug owner reads and adjudicates the combined findings.

---

# Finding handling

Classify actionable review findings as P0, P1, P2, or P3.

## P0 / P1

P0 and P1 findings block completion.

The implementer must address accepted P0 and P1 findings before another candidate is produced.

A candidate is not clean while any accepted P0 or P1 finding remains unresolved.

## P2

P2 findings do **not** block the current Bug remediation.

For every accepted P2 finding:

1. create a new GitHub issue;
2. assign its native GitHub issue type to **`Bug`**;
3. include enough context, evidence, and reproduction information to make it independently actionable;
4. link it to the current Bug and PR;
5. leave it for future remediation.

These newly created Bug issues are **not part of S0** and must not recursively expand this run.

## P3

P3 findings do not require remediation as part of this task.

They may be ignored after being read and adjudicated.

PR review conversations should still be resolved appropriately so the PR is not left with dangling review threads.

---

# Luna remediation loop

After a reviewed candidate produces blocking P0 or P1 findings:

1. the Luna implementer fixes those findings;
2. commits a new candidate;
3. freezes the new SHA;
4. the complete GLM + Grok + Opus implementation review process repeats.

Allow the Luna implementer **up to 3 complete remediation rounds**.

A remediation round consists of:

1. frozen candidate SHA;
2. independent GLM review;
3. independent Grok review;
4. Opus second-pass review;
5. bug-owner adjudication;
6. remediation of accepted P0/P1 findings;
7. production of the next candidate, if required.

Stop early if a review round finds no unresolved accepted P0 or P1 findings.

---

# Implementer escalation

If blocking P0 or P1 findings still remain after 3 Luna remediation rounds, replace the Luna implementer with:

**Astra, high reasoning, priority service tier**

The Astra implementer inherits:

- the existing worktree;
- existing branch;
- approved plan;
- implementation history;
- review history;
- outstanding findings.

Do not restart the Bug from scratch.

The Astra implementer continues remediation using the same frozen-candidate and GLM + Grok + Opus review process until the candidate has no unresolved accepted P0 or P1 findings or the bug owner determines that a genuine external blocker requires escalation.

---

# Pull request

Once there is a clean candidate, the bug owner publishes the PR.

The bug owner owns the PR until merge.

Before merging, the owner must ensure:

- required repository tests pass;
- required CI checks pass;
- the implementation matches the intended fix;
- every PR review and automated review has been read;
- every finding has been adjudicated;
- every accepted blocking finding has been addressed;
- every accepted P2 has a corresponding new Bug issue;
- every relevant review thread has been closed or resolved;
- no unresolved P0 or P1 remains.

---

# Merge policy

When a PR is ready, **merge it promptly**.

Do not intentionally delay a ready PR merely to avoid creating conflicts for other active Bug owners.

Do not serialize merges for convenience.

Do not use exclusive source-file locks.

When another active Bug becomes conflicted because a PR merged, resolving that conflict is the responsibility of that Bug's owner.

The affected bug owner should incorporate the latest default branch and continue.

---

# Conflict avoidance

The root coordinator should make a **best-effort** attempt to launch bug owners in an order that reduces obvious conflict risk.

It may cheaply inspect:

- issue descriptions;
- affected components;
- likely subsystems;
- triage notes;
- known file areas.

Prefer concurrently scheduling Bugs that appear unrelated.

This is only an optimization.

Do not delay available remediation work while attempting to construct a perfect conflict-free schedule.

Conflicts are expected and belong to the bug owners.

---

# Root coordinator responsibilities

The root coordinator is responsible for:

- establishing and validating S0;
- creating and maintaining the Epic;
- enforcing the triage barrier;
- maintaining up to 5 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, 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.

Determine the repository's actual default branch at runtime. Do not assume it is named `master`.

Whenever a merge advances the default branch HEAD and therefore publishes a new LCM HEAD, the root coordinator must:

1. observe the new default-branch HEAD;
2. install that exact new version using the repository's prescribed installation procedure;
3. verify the main LCM daemon is running;
4. verify it is healthy before continuing normal orchestration.

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 should 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.

---

# Periodic coordinator behavior

The root coordinator should otherwise remain idle and allow sub-agents to work independently.

Every **30 minutes**, proactively wake and 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 Epic if appropriate;
9. emit a concise progress report.

Do not continuously poll workers between these checks unless an event requires immediate coordinator action.

---

# Progress reports

Each 30-minute progress report should be brief and include at least:

- total Bugs in S0;
- triaged;
- closed during triage;
- remaining after triage;
- waiting for remediation;
- active remediation owners;
- PRs open;
- PRs merged;
- blocked or parked Bugs;
- Bugs remaining overall.

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;
- the 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 awaiting the user's response.

---

# 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.

---

# Completion condition

The task is complete only when every issue in S0 has reached one of these terminal states:

1. closed during triage as obsolete/non-reproducible;
2. closed during triage as a duplicate;
3. remediated through a merged PR and resolved;
4. explicitly reported to the user as blocked by a genuine condition that the orchestration system cannot resolve autonomously.

Before declaring completion:

- verify every S0 issue has a terminal state;
- verify all merged fixes are reflected on the current default branch;
- verify the Epic accurately reflects final status;
- verify the main LCM installation corresponds to the current default-branch HEAD;
- verify the LCM daemon is healthy;
- provide a concise final report.