Roadmap: establish Psyche as OpenCoven's canonical orchestration protocol #9

Outcome

Establish Psyche as OpenCoven's canonical, implementation-independent orchestration protocol: the source of truth for task, lane, execution, lease, approval, receipt, recovery, and cross-surface continuity semantics.

This issue is the public roadmap and reconciliation control plane for OpenCoven/psyche. It coordinates repository readiness, protocol publication, compatibility ownership, the Psyche Build reference-client path, and release/governance readiness without turning any UI, runtime, tracker, process, or persistence provider into protocol identity.

Current baseline — 2026-08-26

The repository already contains a substantial Rust contract foundation:

• canonical records, identifiers, digests, validation, and structured errors in psyche-core;
• durable append-only records, migrations, quarantine, retention, and crash recovery in psyche-store;
• a typed Coven adapter boundary in psyche-coven;
• bounded surface ports in psyche-surfaces;
• runtime and CLI composition;
• deterministic G2 conformance, property, migration, crash, and evidence checks across Linux, macOS, and Windows.

The primary gap is not an absence of protocol work. It is public productization and ownership clarity: there is no root README/agent entrypoint, no active roadmap, no published compatibility policy, no versioned consumer graduation path, and no tracked first conforming client.

Canonical ownership

Psyche owns:

• orchestration identities and correlation;
• task, graph, lane, attempt, delegation, and delivery contracts;
• capability/lease, approval, receipt, cancellation, recovery, and terminal-state semantics;
• deterministic canonicalization and compatibility behavior;
• adapter conformance requirements.

Psyche does not own:

• familiar/person-binding identity, which belongs to the Familiar Contract;
• protected-surface authorization decisions, which belong to Coven Threads;
• daemon persistence/session authority, which belongs to Coven;
• product UI, worktree, tmux, terminal, or provider-specific state;
• Beads or GitHub planning state;
• a particular durable-state implementation outside Psyche's own protocol record contract.

90-day delivery plan

Dates are planning targets, not permission to weaken an acceptance gate.

Workstreams

Critical path and concurrency

1. Land Psyche repository and agent-readiness foundation #10 establishes the repository entrypoint and deterministic verification surface.
2. Define OpenCoven cross-repository protocol ownership and compatibility #12 may proceed in parallel because ownership must be settled before stable publication.
3. Publish Psyche protocol v1 schemas, golden vectors, and conformance runner #11 publishes the consumer profile only after Land Psyche repository and agent-readiness foundation #10 is usable and Define OpenCoven cross-repository protocol ownership and compatibility #12 approves canonical boundaries.
4. Prove Psyche Build as the first Psyche-conforming reference client #13 starts inventory/mapping now, but implementation pins a Psyche artifact only after Publish Psyche protocol v1 schemas, golden vectors, and conformance runner #11.
5. Establish Psyche security, release, support, and governance readiness #14's minimum security floor may proceed immediately; stable release work follows Publish Psyche protocol v1 schemas, golden vectors, and conformance runner #11 and Prove Psyche Build as the first Psyche-conforming reference client #13.

Protocol implementation may continue behind existing G2 contracts while documentation/readiness work lands, but no new downstream duplicate contract should be introduced before #12 resolves ownership.

Global acceptance criteria

• Every protocol identity and transition has one canonical owner.
• No stable identity depends on a Bead ID, GitHub issue, tmux pane, process, filesystem path, provider session, transport endpoint, or UI component.
• A clean checkout exposes one documented bootstrap path and one fast/full verification interface.
• Protocol schemas and golden vectors are versioned and consumable without copying internal Rust types by hand.
• Unknown major versions, unknown enums, widened authority, stale correlation, and ambiguous effects fail closed.
• Psyche Build passes a pinned cross-repository conformance canary as the first reference client.
• Compatibility, migration, downgrade, deprecation, and rollback policies are explicit.
• Release and support claims are tied to immutable artifacts and retained evidence.
• Active work, deferred work, and historical design records are clearly separated.

Tracking rules

• This issue owns public roadmap state; implementation PRs own reviewable slices; retained evidence owns runtime claims.
• Each child outcome must name its owner, dependencies, non-goals, acceptance gate, and evidence location.
• A merged diff does not close an outcome until the relevant compatibility or runtime evidence is linked.
• Any cross-repository contract change must identify all producers/consumers and update pinned canaries in the same delivery train.
• No big-bang Psyche Build rewrite: current behavior is wrapped behind adapters and migrated incrementally.
• Reconcile this issue whenever scope, priority, support status, canonical ownership, or reference-client sequencing changes.

Non-goals

• Replacing Coven, Threads, Familiar Contract, or Psyche Build.
• Making cloud/team operation a prerequisite.
• Treating documentation or test counts alone as proof of end-to-end behavior.
• Publishing an unstable crate/API merely to satisfy a date.
• Coupling Psyche's durable model to Beads, GitHub, tmux, worktrees, or a specific provider.

Evidence

Link the readiness PR, protocol artifacts, conformance-runner release, cross-repository ownership decision, Psyche Build canary, CI runs, security/release controls, and final reference-flow evidence here.