P0 control: Operationalize Coven Automations v1 through Cave’s canonical Beads graph and GitHub mirrors

[BunsDev]

Parent program: #854
Initial P0 graph: #816, #855, #856, #857, #858

Outcome

Create and continuously reconcile one operational delivery graph for Coven Automations v1. Beads must represent implementation dependencies, ownership, status, evidence, and execution sequencing; GitHub must represent the durable public outcomes and acceptance gates. Neither tracker may become a second runtime ledger or silently disagree about what is P0.

This issue authorizes tracker setup and synchronization through the repository’s reviewed workflow. It does not authorize direct unreviewed edits to mutable Beads history, concurrent schema migrations, or manually rewriting generated mirror bodies.

Canonical tracker roles

Beads owns

• implementation dependency graph;
• task/quest assignment and active execution ownership;
• current priority and blocked state;
• branch/worktree linkage where supported;
• interaction/delivery evidence references;
• generated GitHub mirror synchronization inputs.

GitHub owns

• public outcome and rationale;
• canonical acceptance criteria and release gates;
• cross-repository issue links;
• durable PR/release/conformance evidence links;
• design/governance decisions that must remain legible outside one local Beads store.

Coven runtime owns

• automation definitions and revisions;
• occurrences, runs, attempts, leases, approvals, artifacts, events, and receipts.

Tracker data must never be queried as production automation state.

Phase 1 — inspect and establish the writer

• Inspect the current Coven Beads schema/version, supported CLI/workflow, mirror generator, and repository instructions.
• Identify whether Native familiar automations: replace harness-owned schedules with durable Coven routines #816 already maps to a Bead; reuse it rather than duplicating the foundation.
• Designate exactly one checkout/process as schema migrator and canonical writer for this setup.
• Refuse concurrent independent migrations or direct writes from unrelated worktrees.
• Record the exact Beads tool version, schema version, source branch/worktree, and pre-change integrity/status report.
• Use a reviewed branch/PR for persisted tracker changes; do not routinely mutate interaction logs directly on main.

Phase 2 — create the canonical Bead graph

Create or map one Bead per public outcome. Use exact GitHub links and preserve one-to-one outcome mapping.

Program

• Coven Automations v1 program → Program: Coven Automations v1 — reliable, identity-bound familiar routines #854
  • priority: P0 program/control
  • owns release gates and cross-repository rollup
  • must not be used as a catch-all implementation task

Foundation

• Native Coven routine foundation → Native familiar automations: replace harness-owned schedules with durable Coven routines #816
  • preserve existing Bead if present
  • mark implementation status from evidence, not assumptions
  • close only after landed parts, tests, daemon wiring, Cave compatibility, docs, and remaining deltas are reconciled

P0 workstreams

• Protocol schemas/state/idempotency/changefeed → P0: Specify coven.automations.v1 schemas, state machines, idempotency, and changefeed #855
  • depends on Native familiar automations: replace harness-owned schedules with durable Coven routines #816
• Scheduler time/retry/cancel/fencing/recovery → P0: Harden automation time, retries, cancellation, fencing, and crash recovery #856
  • depends on Native familiar automations: replace harness-owned schedules with durable Coven routines #816 and P0: Specify coven.automations.v1 schemas, state machines, idempotency, and changefeed #855 where state/error semantics are required
• Principal/familiar/authority/approval/receipt binding → P0: Bind automation runs to principal authority, familiar revisions, capabilities, approvals, and receipts #857
  • depends on Native familiar automations: replace harness-owned schedules with durable Coven routines #816 and P0: Specify coven.automations.v1 schemas, state machines, idempotency, and changefeed #855
  • additionally depends on upstream Familiar Contract and Threads profile outcomes once created
• Conformance/chaos/SLO/operator diagnostics → P0: Build automations conformance, chaos, SLO, and operator diagnostics #858
  • depends on P0: Specify coven.automations.v1 schemas, state machines, idempotency, and changefeed #855, P0: Harden automation time, retries, cancellation, fencing, and crash recovery #856, and P0: Bind automation runs to principal authority, familiar revisions, capabilities, approvals, and receipts #857

P1 ecosystem workstreams

Add one Bead per SDK, Cave, Psyche, docs, organization-canary, Familiar Contract, and Threads issue created under #854. These generally depend on #855 and, where authority-bearing, #857; exact dependencies must be explicit rather than inferred from a broad program parent.

Dependency rules

The minimum graph is:

#816 foundation
  ├─ #855 protocol
  ├─ #856 scheduler reliability
  └─ #857 identity + authority

#855 ─┬─> #856
      └─> #857

#855 + #856 + #857 -> #858 certification
#858 -> v1 release gate

#855 -> SDK read/types/changefeed
#855 + #857 -> SDK mutations/approvals
#855 + #856 + #857 -> Cave oversight/recovery
#855 + #857 -> Psyche adapter
upstream Familiar/Threads profiles -> #857

Do not encode P2 event triggers, multi-host routing, hosted execution, or broad external action adapters as implicit P0 blockers.

Priority policy

Use a strict shared policy:

• P0: current v1 correctness, security, data-loss/duplicate-execution risk, authority violation, broken migration, or certification blocker.
• P1: committed SDK/product/docs/ecosystem work required to make the certified core usable and operable.
• P2: post-v1 expansion or research that must not silently enter the release critical path.

Every P0 Bead must have:

• one accountable owner;
• one canonical GitHub outcome;
• explicit dependencies;
• a current acceptance gate;
• an active or explicitly blocked disposition;
• evidence requirements;
• no contradictory closed public mirror.

Roadmap artifact

Add or update one reviewed roadmap document, preferably under a scoped path such as:

docs/roadmaps/coven-automations-v1.md

It should be generated from or reconciled against the tracker and include:

• canonical ownership diagram;
• P0/P1/P2 table;
• Bead ↔ GitHub mapping;
• dependency graph;
• release gates;
• active blockers;
• exact evidence links;
• last synchronization time/tool version;
• generated-content warning where applicable.

Do not duplicate mutable run status in prose. The document should link to authoritative tracker state and preserve stable decisions/gates.

Synchronization invariants

Add a safe drift report that flags:

• Bead closed while GitHub outcome is open, and vice versa;
• Bead priority differing from the canonical roadmap;
• P0 Bead without an active P0 outcome;
• GitHub outcome without exactly one Bead mapping;
• unknown/ambiguous parent or dependency mapping;
• generated mirror body edited outside the generator contract;
• completed work lacking PR/test/release evidence;
• cross-repository issue moved/closed without graph reconciliation;
• concurrent schema/writer state;
• tracker output containing secrets, private prompts, terminal dumps, credentials, unrestricted paths, or sensitive identity/authority payloads.

The drift check should be runnable locally and in CI without ambient production credentials. It should report identifiers, statuses, priorities, links, and evidence references only.

Evidence and completion semantics

A Bead may close only when the corresponding GitHub acceptance criteria are satisfied or the outcome is explicitly cancelled/superseded with rationale. Required evidence should include, as applicable:

• PR/merge commit and exact source revision;
• exact verification commands/results;
• schema/vector/conformance artifact revisions;
• migration/rollback proof;
• cross-repository canaries;
• security/privacy/authority impact;
• release artifact digest and certification report;
• remaining known limitations.

A GitHub issue should not be closed merely because a Bead has no active assignee or a partial implementation landed.

Suggested operating cadence

• Reconcile automatically on reviewed tracker changes.
• Run drift detection in relevant PR CI.
• Publish a concise program rollup at least weekly while P0 is active.
• Escalate immediately for duplicate-execution, silent missed occurrence, false-success, authority bypass, corruption, or broken migration findings.
• Review P1/P2 priority and dependency leakage at every release gate.

Acceptance criteria

• Program: Coven Automations v1 — reliable, identity-bound familiar routines #854, Native familiar automations: replace harness-owned schedules with durable Coven routines #816, P0: Specify coven.automations.v1 schemas, state machines, idempotency, and changefeed #855, P0: Harden automation time, retries, cancellation, fencing, and crash recovery #856, P0: Bind automation runs to principal authority, familiar revisions, capabilities, approvals, and receipts #857, and P0: Build automations conformance, chaos, SLO, and operator diagnostics #858 each map to exactly one Bead.
• Cross-repository child outcomes map one-to-one as they are created.
• Dependencies and P0/P1/P2 priorities match the canonical roadmap.
• One writer/schema owner and reviewed change path are documented.
• A roadmap artifact and machine-readable mapping are committed through review.
• Drift detection catches state, priority, parent, evidence, and generated-mirror disagreement.
• No tracker data is treated as automation runtime truth.
• The final Program: Coven Automations v1 — reliable, identity-bound familiar routines #854 release rollup can be generated from reconciled state and exact evidence.

Non-goals

• Replacing GitHub with Beads or Beads with GitHub.
• Using Beads as familiar identity, orchestration protocol, runtime ledger, or audit receipt store.
• Editing generated issue bodies as the durable fix.
• Closing work merely to reduce issue count.
• Putting P2 expansion on the v1 critical path.

Initial evidence packet

Attach the pre-change tracker report, created/reused Bead IDs, Beads version/schema, reviewed PR, mirror-sync run, drift report, final mapping, and before/after P0 dependency graph.

[BunsDev]

Operational correction and execution handoff — 2026-08-30

Repository inspection confirmed that the canonical OpenCoven familiar execution queue is Cave’s existing embedded-Dolt Beads graph, not a .beads store in this repository.

Canonical implementation path:

• Roadmap and reviewed operating contract: docs: operationalize Coven Automations v1 roadmap and Beads rollout coven-cave#5219
• Live Beads/Dolt seed, dependency verification, sync, and evidence task: P0: Seed Coven Automations v1 into Cave’s canonical Beads/Dolt execution graph coven-cave#5220
• Existing Beads operating epic: cave-hlv
• Live database: OpenCoven/coven-cave embedded Dolt database cave

The #859 outcome therefore means:

1. create/reuse one Automations v1 delivery epic under Cave’s established Beads operating graph;
2. create/reuse exactly one surface:shared Bead per GitHub outcome;
3. validate every dependency using the installed bd dep help, bd dep list, and bd ready --json rather than assuming edge direction;
4. synchronize only through Cave’s bounded pnpm beads:sync workflow and record before/after refs/dolt/data OIDs;
5. treat .beads/issues.jsonl as a public-scrubbed review export, never as canonical state or a hand-edited sync mechanism;
6. keep GitHub as public outcome/review/CI truth and Coven as production automation lifecycle truth;
7. attach the exact mapping, diagnostics, dependency report, sync evidence, and drift fixtures back to this issue.

Do not initialize a competing Beads database in OpenCoven/coven. The original tracker roles and acceptance gates remain valid; references to inspecting the “current Coven Beads schema” should be read as inspecting Cave’s canonical Beads/Dolt schema and supported workflow through #5220.