EPIC #185 — Earn Hive ACMM autonomy for RCC; architect must read this issue body; Hive may improve readiness but never self-promote authority

[joshyorko]

Outcome

Make joshyorko/rcc deliberately promotable through KubeStellar Hive's operational ACMM trust levels on a self-hosted Hive installation without confusing file-presence maturity signals with actual authorization to let agents change or merge RCC.

The goal is not to maximize an ACMM score. The goal is to make each increase in Hive authority earned by deterministic RCC repository controls.

The target end state is:

Hive observes RCC
    ↓
L1/L2 advisory work
    ↓
RCC deterministic quality gates become reliable
    ↓
L3 measurement / quality-gated issue creation
    ↓
security and workflow boundaries become mechanically enforced
    ↓
L4 security-aware PR creation
    ↓
risk classification + human merge controls are reliable
    ↓
L5 semi-autonomous hold-gated PRs
    ↓
RCC-specific deterministic merge policy + audit/kill switch
    ↓
selective L6 full autonomy where the repository can actually defend itself

This issue is an RCC repository-governance / automation program. It is independent of Environment Artifact identity and runtime architecture except where those areas define sensitive paths or required tests.

---

Important terminology: two different ACMM concepts exist

KubeStellar currently exposes two related but distinct maturity concepts:

1. Hive operational ACMM — six trust levels, L1 through L6.
   This controls what Hive agents are permitted to do: advisory analysis, issue creation, hold-gated PR creation, and eventually merge-on-green behavior.

2. Codebase maturity scanning / file-presence criteria.
   This can open [ACMM L…] issues based on recognized filenames/directories and repository patterns.

Do not treat satisfying a file-presence heuristic as proof that RCC is safe for the corresponding Hive operational permission.

Several existing scanner findings are already stale or structurally mismatched with RCC. Examples include criteria looking for a generic ci.yml even though RCC has a real OS Robot matrix in .github/workflows/rcc.yaml, or looking for web-style E2E directories even though RCC's executable acceptance layer is Robot Framework.

Policy: we may satisfy or close scanner criteria when they represent useful RCC practices, but we must not create dummy files, duplicate orchestration, or weaken existing architecture merely to move a dashboard score.

---

Hive operational trust model to design against

Use current Hive v4 semantics as the source of truth.

Hive level	Operational meaning for RCC	RCC stance
L1 — Inception	advisory guidance only	safe baseline
L2 — Advisory	broader advisory analysis, no GitHub writes	safe once repo guidance is coherent
L3 — Quality-Gated	measured operation; quality may create issues	requires trustworthy measurement/CI signals
L4 — Security-Aware	security-aware issue creation and selected hold-gated PR behavior	requires security gates and protected workflow boundaries
L5 — Semi-Autonomous	multiple agents may create hold-gated PRs; humans still merge	requires mechanical risk classification and branch protection
L6 — Fully Autonomous	eligible agent PRs may merge on green CI	requires RCC-specific deterministic merge policy, audit, recovery, and selective sensitive-path human gates

Promotion is always an operator decision. RCC should expose evidence that makes that decision defensible.

---

Current RCC evidence

Hive is not hypothetical here. A self-hosted Hive instance has already exercised RCC with advisory/measured/hold-gated agents and opened useful issues, including:

• [scanner] run-from-bundle artifact directory can escape the workarea and write outside the project #128 / [sec-check] run-from-bundle allows artifact directory path traversal #177 — untrusted bundle artifact-path traversal;
• [scanner] ZIP bootstrap extraction follows archive symlinks #129 — ZIP bootstrap symlink traversal;
• [quality] Restore test prerequisites for embedded assets and journal #130 / [quality] Make generated embedded assets available to the Go test workflow #180 — generated embedded assets prevent reliable repository-wide coverage in some execution paths;
• [quality] Add coverage for operations and command paths #131 — operations/command coverage gaps;
• [architect] Move import-time runtime initialization behind an explicit bootstrap boundary #132 — import-time global initialization / embedding boundary;
• [guide] Update stale setup guidance and repository structure references #133, [guide] CONTRIBUTING lists outdated Go toolchain version #178, [guide] README codecov badge links master branch #179 — documentation drift;
• [ci-maintainer] Rcc workflow fails before jobs are created #134 — workflow failed before jobs were created;
• [ci-maintainer] Lint workflow blocked by 26 golangci-lint findings #135 — lint failures;
• [quality] Add deterministic tests for anywork concurrency and cleanup paths #181 — anywork concurrency/cleanup coverage gaps;
• [quality] Increase journal package coverage beyond 11.3% #182 — journal coverage only 11.3% in the measured run;
• [scanner] Environment lease recovery must fail closed on weak owner identity #183 — lease recovery can fall back to weak PID-only ownership.

That is evidence that Hive can already discover meaningful work in RCC. The next step is not more permission by default; it is to make RCC's merge and evidence contract strong enough to trust that permission.

---

Gate 0 — establish the repository as the source of truth

Existing strengths to preserve:

• AGENTS.md defines repository structure, toolkit-first development, testing, and durable-learning receipts.
• docs/agent-boundaries.md and repository-local skills define agent behavior.
• .github/pull_request_template.md already requires linked issue, observable behavior, safety impact, change class, exact verification, delivery truth, and documentation receipt.
• docs/change-classification.md defines Maintenance, Behavioral, and Sensitive changes.
• docs/review-rubric.md defines correctness, compatibility, safety, verification, delivery truth, and scope review.
• RCC development is already toolkit-first and self-hosting.

Required corrections

• Add a SECURITY.md describing supported versions, vulnerability reporting, trust boundaries, and disclosure expectations.
• Add/confirm CODEOWNERS or an equivalent ruleset for sensitive paths.
• Define one canonical machine-readable repository trust/risk policy consumed by CI/Hive gates.
• Document which Hive operational level RCC is currently approved for and why.

---

L1 → L2 readiness — advisory operation

L1/L2 agents cannot mutate GitHub, so the primary requirement is good context and deterministic local orientation.

Required RCC contract

• AGENTS.md exists and routes work through RCC's actual toolkit.
• PR review rubric exists.
• change classification exists.
• issue/PR templates exist.
• repository-local skills/guidance exist.
• stale guidance found by Hive ([guide] Update stale setup guidance and repository structure references #133/[guide] CONTRIBUTING lists outdated Go toolchain version #178/[guide] README codecov badge links master branch #179 and related findings) is reconciled or explicitly dispositioned.
• automated/generated ACMM heuristic issues are marked as operationally relevant, stale, satisfied, or not-applicable rather than left as an undifferentiated score backlog.

Operator precondition

Hive should use a repository-scoped GitHub App / allowlist even when agents are advisory, so later level changes do not require redesigning credentials.

---

L2 → L3 readiness — quality measurement must be real

L3 is where Hive begins relying on measured quality signals and may create issues from them. RCC must therefore have measurements that cannot be trivially false-green.

Coverage

Current RCC has a real Coverage gate, but the global line threshold is currently only 20%. A single global number is not sufficient for high-autonomy RCC.

Adopt a ratcheted model instead of blindly copying another repository's percentage:

• repository-wide coverage must compile/run reproducibly after generating embedded assets;
• no unexplained coverage regression from the protected baseline;
• critical packages receive explicit floors separate from global coverage;
• critical concurrency/security/lifecycle paths are tested even when line coverage appears adequate;
• generated assets and journal state are reproducible in CI ([quality] Restore test prerequisites for embedded assets and journal #130/[quality] Make generated embedded assets available to the Go test workflow #180);
• [quality] Add deterministic tests for anywork concurrency and cleanup paths #181 and [quality] Increase journal package coverage beyond 11.3% #182 become inputs to critical-package floors rather than isolated findings;
• coverage result is uploaded/persisted as evidence that Hive can cite.

Suggested critical package set should include at least the active equivalents of:

• environment artifact identity/validation;
• artifact provider/CAS;
• environment lifecycle/leases;
• htfs relocation/materialization;
• archive/bundle extraction;
• settings/provider profile mutation;
• release/version logic;
• concurrency primitives used by worker execution.

Deterministic test gates

• toolkit-first focused tests are canonical for agents;
• go test ./... cannot false-green because generated assets are absent;
• Robot acceptance matrix is required for behavior changes;
• workflow syntax is validated before GitHub evaluates the workflow;
• no required gate can pass solely by skipping the behavior it claims to test;
• promotion receipts name exact SHA, commands, platforms, skipped gates, and artifacts.

Do not promote to L3 because a scanner finds a filename. Promote when the measurements are trustworthy.

---

L3 → L4 readiness — security and CI boundaries become mandatory

At L4, security-oriented agents can create issues and selected agents can begin hold-gated PR behavior. RCC's security pipeline must be reliable before granting that authority.

Immediate concrete gaps

CodeQL

The current CodeQL workflow still targets master while RCC's active branch is main.

• change CodeQL push/PR targets to main;
• verify the scan actually executes on a representative PR;
• pin third-party actions by immutable SHA consistent with RCC's stronger workflows;
• decide whether security-extended / quality queries are justified;
• make the security result a required check for relevant changes.

Workflow self-protection

The main Rcc workflow currently ignores .github/workflows/** and .dagger/** path changes.

That is dangerous at high autonomy because an agent could modify the machinery that determines whether it is safe while avoiding the normal runtime suite.

• add a workflow/meta-CI lane for workflow/Dagger changes;
• run actionlint or equivalent deterministic workflow validation;
• consider zizmor or another GitHub Actions security/static checker;
• verify required-check names cannot disappear silently when a workflow file is changed;
• ensure workflow changes receive human/CODEOWNER review at least through L5 and likely remain sensitive at L6.

Security baseline

• create SECURITY.md;
• keep CodeQL active on main;
• add govulncheck / equivalent Go vulnerability checking;
• validate dependency/action provenance and pinned third-party Actions;
• add focused archive/filesystem traversal tests for [scanner] run-from-bundle artifact directory can escape the workarea and write outside the project #128/[scanner] ZIP bootstrap extraction follows archive symlinks #129/[sec-check] run-from-bundle allows artifact directory path traversal #177;
• resolve or explicitly gate [scanner] Environment lease recovery must fail closed on weak owner identity #183 before autonomous environment cleanup/lease changes;
• define threat-model / trust-boundary guidance for untrusted ZIP/bundle/provider inputs;
• ensure secret redaction tests cover provider profiles/auth, logs, errors, JSON, and workflow artifacts.

Commit provenance

Hive signs agent commits with DCO sign-off. RCC should mechanically check it if DCO is part of the repository contract.

• add a DCO/sign-off required check or explicitly document why another provenance mechanism supersedes it.

---

L4 → L5 readiness — hold-gated PR autonomy

L5 means many Hive agents may create PRs, but humans still control merge. This is the ideal near-term operating level for RCC while the architecture is evolving quickly.

GitHub repository ruleset

Configure and document a main-branch ruleset equivalent to:

• no direct pushes to main;
• PR required;
• required status checks are explicit and non-optional;
• stale approvals are dismissed when head changes;
• required checks must apply to the exact PR head;
• unresolved review conversations block merge where useful;
• administrators bypass only through an audited break-glass process;
• force pushes/deletion disabled;
• sensitive paths require a human/CODEOWNER approval;
• hold-gated Hive PRs cannot merge until hold removal/human approval.

CODEOWNERS / sensitive paths

Treat at least these areas as Sensitive unless stronger evidence narrows them:

• .github/workflows/** and release automation;
• .dagger/** and contained promotion tooling;
• common/version.go / release versioning;
• Environment Artifact schema/identity code;
• provider/CAS/auth code;
• environment lease/GC/repair code;
• htfs/**, remotree/**, archive/bundle extraction paths;
• settings and credential resolution;
• security policy / risk policy / CODEOWNERS themselves.

Machine-readable risk classification

docs/change-classification.md is a strong human contract. L5 needs mechanical enforcement too.

Add a repository-local policy (format open) that can deterministically classify or escalate a PR using changed paths and declared behavior.

Minimum outcomes:

Maintenance
    -> focused checks
    -> Hive PR may remain hold-gated

Behavioral
    -> focused + full affected runtime/Robot evidence
    -> human merge

Sensitive
    -> security/compatibility/platform/rollback evidence
    -> mandatory human/CODEOWNER review
    -> never silently downgraded by agent declaration

A small diff is not automatically low risk.

AI review evidence

• any automated review applies to an exact SHA;
• material code changes invalidate prior AI review approval;
• review receipts remain visible/auditable;
• agent-generated PR description identifies agent/backend/model/issue when available;
• policy distinguishes AI review evidence from required human approval.

---

L5 → L6 readiness — selective fully autonomous merge

Do not enable blanket L6 merely because the Hive dashboard says all criteria are present.

L6 means green CI can become merge authority. RCC therefore needs a deterministic RCC trust gate that is stronger than any individual agent.

RCC trust gate

Implement through repository CI and/or an RCC-specific deterministic Hive hive-project.yaml pipeline stage.

The gate should consume:

• changed paths;
• declared change class;
• linked issue/work item;
• exact PR head SHA;
• required test results;
• coverage delta / critical-package floors;
• security scan results;
• generated-asset consistency;
• platform/runtime evidence when applicable;
• review/hold state;
• dependency/release/workflow flags;
• policy exceptions with actor/reason.

It should emit one machine-readable result:

AUTONOMOUS_MERGE_ELIGIBLE
HUMAN_REVIEW_REQUIRED
BLOCKED

Default L6 policy recommendation

Selective L6, not universal L6.

Maintenance and low-risk behavioral changes may become autonomous once the gate is proven. Sensitive changes should continue to require a human until there is very strong evidence to relax a specific class.

Sensitive/manual-by-default at L6 should initially include:

• release/tag/publishing workflows;
• changes to required checks/rulesets/risk policy itself;
• credentials/auth/provider security;
• archive extraction and path-security boundaries;
• Manifest/Artifact identity or compatibility changes;
• signature/trust/revocation policy (Add Environment Artifact provenance, SBOM, signatures, revocation, and trust policy #126);
• lease/GC/crash-recovery semantics (Complete environment lease, crash recovery, repair, and garbage-collection semantics #122/[scanner] Environment lease recovery must fail closed on weak owner identity #183);
• new external dependencies with executable/build-time behavior;
• cross-platform compatibility claims;
• deletion/retirement of legacy compatibility surfaces such as rccremote.

The level controls what Hive can do; RCC policy controls what a given change is eligible to do.

Merge queue / stale-green protection

Before autonomous merge:

• configure GitHub merge queue or an equivalent serializing merge gate if available;
• workflows required for merge support merge_group where GitHub merge queue requires it;
• re-test against the synthetic merge result / latest target branch;
• avoid a PR merging because it was green against a stale base while another autonomous PR changed the same assumptions.

Self-modifying CI protection

A PR must not be able to remove/weaken the check that decides the PR may merge.

• branch/ruleset protects required workflow files;
• CODEOWNER/human review protects policy and merge-gate changes;
• checks are defined so changing workflow triggers a separate trusted validator;
• privileged/release credentials are unavailable to untrusted PR execution.

Audit trail

Retain a durable receipt for autonomous merges containing at least:

• Hive instance;
• operational ACMM level;
• agent role/backend/model where available;
• source issue/task;
• PR number;
• exact head and merge SHAs;
• change/risk class;
• required checks and results;
• coverage/security deltas;
• hold/review decisions;
• policy revision;
• any human override/exception;
• release side effects, if any.

Do not build a second agent orchestrator inside RCC merely to satisfy a codebase scanner criterion. Hive is already the orchestrator.

Demotion / kill switch

L6 is incomplete without a safe way to reduce authority.

Document and test the operator procedure to:

• switch RCC from L6 → L5/L2 quickly;
• disable merge authority without disabling observation;
• revoke/rotate the Hive GitHub App installation/token;
• stop/drain Hive contributors;
• preserve open PR/evidence state;
• recover after a bad autonomous merge.

---

Self-hosted Hive / k3s operator preconditions

These are not RCC source-code features, but they are part of the trust argument for allowing higher repository authority.

Before L5/L6 on the self-hosted k3s instance:

• use a GitHub App installed only on authorized repositories rather than a broad PAT where possible;
• keep RCC explicitly allowlisted;
• use tier-scoped GitHub installation tokens;
• verify Hive's full forced-egress proxy mode is active, not degraded/best-effort;
• on Kubernetes/k3s, verify the Hive pod has the NET_ADMIN capability required by Hive's forced proxy-egress gate and that namespace Pod Security policy permits it;
• use least-privilege ServiceAccount/RBAC;
• keep provider/model secrets in Kubernetes Secrets or the configured local proxy path and out of agent-visible repo state;
• pin the deployed Hive v4 image/revision and record upgrades;
• back up Hive's durable state/config before changing operational ACMM level;
• test a deliberate L5/L6 demotion before relying on L6 merge autonomy.

If forced-egress enforcement is not active, do not describe the instance as fully constrained merely because the repo allowlist exists.

---

Existing RCC issue graph this program should consume

Runtime / product safety

• Make Holotree the cloud-native environment engine: cryptographic artifacts, providers, node-local materialization, and leases #118 — Environment Artifact / Holotree engine umbrella.
• Ship Environment Artifacts v1 in RCC v18.19.0 and freeze the v18 compatibility contract #120 — v18.19 Environment Artifacts release lane.
• Prove Environment Artifact portability and compatibility on every supported RCC platform #121 — platform/ABI compatibility.
• Complete environment lease, crash recovery, repair, and garbage-collection semantics #122 — lease/crash recovery/repair/GC.
• Production-harden Environment Artifact providers for enterprise networks, resumable transfer, quotas, and retention #123 — production provider hardening.
• Converge Hololib ZIP, robot bundles, offline archives, and OCI carriers on Manifest v1 identity #124 — archive/bundle/OCI carrier convergence.
• Build an evidence-driven Holotree benchmark suite and select materializer/storage optimizations #125 — evidence-driven performance/materializer decisions.
• Add Environment Artifact provenance, SBOM, signatures, revocation, and trust policy #126 — provenance/SBOM/signatures/revocation/trust policy.
• Coordinate cold environment builds and cache prewarming without a shared writable Holotree #127 — cold-build coordination/prewarming.

Hive-discovered operational gaps

• [scanner] run-from-bundle artifact directory can escape the workarea and write outside the project #128/[scanner] ZIP bootstrap extraction follows archive symlinks #129/[sec-check] run-from-bundle allows artifact directory path traversal #177 — archive/bundle filesystem security.
• [quality] Restore test prerequisites for embedded assets and journal #130/[quality] Make generated embedded assets available to the Go test workflow #180/[quality] Add deterministic tests for anywork concurrency and cleanup paths #181/[quality] Increase journal package coverage beyond 11.3% #182 — reproducible test prerequisites and weak coverage areas.
• [architect] Move import-time runtime initialization behind an explicit bootstrap boundary #132 — bootstrap/global runtime initialization boundary.
• [ci-maintainer] Rcc workflow fails before jobs are created #134/[ci-maintainer] Lint workflow blocked by 26 golangci-lint findings #135 — CI and lint correctness.
• [scanner] Environment lease recovery must fail closed on weak owner identity #183 — lease ownership/recovery safety.

Do not duplicate those issues here. This issue defines the autonomy gate that consumes their outcomes.

---

Codebase-maturity scanner issue triage

Review the existing [ACMM L…] dashboard issues separately and classify each as:

1. Satisfied — the RCC capability now exists under a recognized or equivalent file.
2. Useful gap — implement it because RCC actually benefits.
3. Equivalent capability / scanner mismatch — document and close or upstream the heuristic mismatch.
4. Not applicable — do not build web/Claude-specific artifacts into RCC merely for a score.
5. Wrong architectural layer — e.g. auto-issue generation or multi-agent orchestration already belongs to Hive rather than RCC.

Examples that should be re-evaluated immediately because equivalent RCC artifacts now exist include:

• [ACMM L0] Add Issue templates #137 issue templates;
• [ACMM L0] Add Coverage gate #138 coverage gate;
• [ACMM L3] Add PR acceptance metric #146 PR metrics;
• [ACMM L3] Add PR review rubric #147 review rubric;
• [ACMM L3] Add Quality dashboard #148 quality report;
• [ACMM L3] Add CI test matrix #149 CI matrix semantics;
• [ACMM L6] Add Change classification #167 change classification.

Examples that should not automatically be implemented merely to satisfy filenames include:

• [ACMM L0] Add E2E tests #136 web-style E2E detection when RCC uses Robot acceptance;
• [ACMM L2] Add CLAUDE.md instruction file #139–[ACMM L2] Add Prompts catalog #142 editor/harness-specific instruction files where AGENTS.md and repository-local skills are canonical;
• [ACMM L6] Add Auto issue generation #159 auto-issue generation;
• [ACMM L6] Add Multi-agent orchestration #160 multi-agent orchestration;
• [ACMM L6] Add Strategic dashboard #161 duplicate strategy dashboard if Hive already owns that operational view.

---

Recommended promotion sequence

Near term

Operate RCC at L5 hold-gated, not L6.

Hive is already useful at this level: scanner, security, quality, CI-maintainer, architect, and guide agents can create work and PRs while a human remains the merge boundary.

Before considering L6, close the structural trust gaps in this issue.

Promotion evidence bundle

For every operator promotion, capture a short immutable receipt:

repo: joshyorko/rcc
from: Lx
to: Ly
commit: <main SHA>
hive version: <v4 build/SHA>
hive instance: <instance>
required checks: <names + status>
open blocking findings: <list>
coverage policy revision: <digest/ref>
risk policy revision: <digest/ref>
branch/ruleset revision: <ref>
security gate status: <status>
k3s forced-egress status: <full/degraded>
approved by: <human/operator>
reason: <evidence>

Promotion should be reversible.

---

Acceptance

L3-ready

• repository-wide measurement is reproducible and cannot false-green on missing generated assets;
• coverage policy includes no-regression and critical-package treatment;
• Robot/runtime checks are deterministic and required where applicable;
• scanner heuristic backlog is triaged rather than treated as the operational truth.

L4-ready

• CodeQL/security workflows target main and actually run;
• workflow/Dagger changes are validated rather than ignored by the main trust model;
• SECURITY.md and security boundaries exist;
• archive/path traversal and critical lease/security findings are fixed or explicitly hold-blocking;
• commit/dependency/action provenance gates are documented and enforced.

L5-ready

• branch/ruleset prevents direct unreviewed changes to main;
• required checks are exact-head and non-skippable;
• CODEOWNERS/human approval protects sensitive paths;
• machine-readable risk classification is enforced;
• Hive hold-gated PRs cannot merge until human release of the hold;
• agent review/evidence is durable and SHA-specific.

L6-eligible

• deterministic RCC trust gate emits autonomous/human/block decisions;
• merge queue/stale-base protection is proven;
• self-modifying workflow/policy changes cannot authorize themselves;
• low-risk autonomous changes have a soak history at L5 with measured false-positive/regression outcomes;
• sensitive changes remain human-gated unless separately proven safe;
• autonomous merge audit trail exists;
• k3s Hive forced-egress enforcement is confirmed full-strength;
• demotion/kill-switch procedure is tested;
• a human explicitly promotes RCC to L6 based on the recorded evidence.

---

Non-goals

• Gaming the Console/codebase ACMM scanner with dummy files.
• Making RCC depend on Hive.
• Reimplementing Hive's multi-agent orchestrator inside RCC.
• Automatically making every Sensitive change L6-mergeable.
• Treating coverage percentage alone as autonomy proof.
• Treating an LLM review as a replacement for deterministic CI/security gates.
• Giving release credentials to ordinary PR execution.
• Assuming the k3s deployment is fully constrained without verifying Hive's forced-egress mode.

[joshyorko]

Hive execution contract for this epic

This issue is intentionally being handed to Hive as an L5 self-improvement tranche. The repository is the thing being improved; Hive's authority is not.

Invariant: Hive may autonomously improve RCC's readiness for higher autonomy. Hive may not autonomously grant itself higher authority.

Use joshyorko/rcc#185 as the source of truth. The architect should read the full issue body before decomposing the work. The issue title explicitly carries this instruction because the current label-trigger planning path mints the epic from title + labels and does not copy the GitHub issue body into epic Notes.

Phase A — trust foundation — agent suitable at L5

Decompose and execute deterministic RCC repository improvements such as CI/coverage truth, CodeQL/main correction, workflow/meta-CI validation, SECURITY.md, CODEOWNERS/risk-policy machinery, security/test findings, documentation truth, and exact-SHA evidence. Hive may split/bundle these into dependency-bearing child beads and create hold-gated PRs.

Phase B — L5 soak and evidence — agent execution, human judgment

Allow scanner, quality, sec-check, ci-maintainer, guide, architect, strategist, and related lanes to work the resulting ready graph. Capture accepted/rejected/corrected PRs, regressions, false positives, duplicate work, coverage/security changes, and evidence quality. Hive may improve the controls in response to that evidence; humans remain merge authority.

Phase C — L6 authority boundary — implementation may be agent suitable; promotion is human required

Hive may implement the deterministic RCC trust gate, merge-queue/stale-green protection, audit receipts, self-modifying-CI protection, and demotion/kill-switch mechanics. The desired gate result is one of:

AUTONOMOUS_MERGE_ELIGIBLE
HUMAN_REVIEW_REQUIRED
BLOCKED

The following are operator decisions, not autonomous completion criteria:

• changing RCC's operational Hive ACMM level;
• granting a broader GitHub token/mode/capability;
• removing L5 holds or human merge requirements;
• weakening required checks, CODEOWNERS, rulesets, risk policy, or security boundaries;
• deciding that a Sensitive change class may auto-merge;
• enabling blanket L6.

Treat those as human_required even if the current planner metadata is not itself a hard authorization boundary. The hard boundary remains Hive's L5 ISSUES_AND_PRS mode + hold-gated PR policy and the repository's own merge controls.

Dependency doctrine

Create actual bead DependsOn edges for ordering that matters. Do not rely on prose-only GitHub dependency references: current convergence admission gates ReadyQueue and selectTask from the bead ledger, and a candidate with no dependency-bearing intent record is intentionally admitted.

Prefer the smallest useful DAG. Do not create dummy ACMM files simply to satisfy scanner filename heuristics; implement RCC-native controls backed by code/test truth.

Completion

This epic is complete when RCC can produce evidence that makes a human promotion decision defensible. Do not interpret completion as authorization to promote the Hive instance.