You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ship the first public OpenCoven SDK as a coherent, identity-preserving read-only protocol release. A separately installed client must be able to discover the owner-local Cave and Coven authorities, verify compatibility, obtain a user-approved Cave credential, securely retain it, and read only the canonical state it was granted.
Why this is the release boundary
The repository has mature package boundaries, operation controls, package verification, stress/property tests, and a fail-closed release system. The remaining gap is the end-to-end developer journey: the release machinery is ahead of the public protocol surface and its real-consumer proof.
The first release establishes recognition and authorized observation before action. Message sends, streaming, attachments, task handoffs, and privileged GitHub mutations follow in separately reviewed authority milestones.
Included in 0.1.0
Cave and Coven discovery
compatibility health and minimum-client negotiation
Cave pairing, consent, credential custody, status, and local forget
owner-local Coven health with live peer/pipe identity validation
canonical Cave familiars, projects, conversations, and messages
explicit bounded pagination and reconciliation behavior
deterministic, secret-safe CLI diagnostics and supported read commands, or an explicit decision to defer the CLI package
non-secret profiles, redacted diagnostics, and public API governance
packed-package consumer integration
cross-repository real-authority conformance
first-release security disposition
trusted npm publishing, provenance, and registry validation
#45 does not block 0.1.0 unless it discovers unique release-relevant work, provenance ambiguity, dirty canonical state, or verification interference.
Program rules
Every child issue names dependencies, blockers, non-goals, acceptance criteria, and validation evidence.
No issue closes on unit-test proxies alone when the behavior requires a live authority, live native trust adapter, or packed consumer.
No capability is considered shipped merely because it appears in a roadmap or fixture.
No credential, pairing secret, bearer, prompt, attachment content, socket handle, daemon output, or unsafe transport cause may enter diagnostics or retained evidence.
No ambiguous mutation completion may be automatically replayed.
Publication remains locked until every required child gate closes.
the exact released artifacts have a passing real-authority record;
the security review recommends ship;
registry bytes and provenance match the reviewed release manifest;
ordinary future publishing uses protected OIDC with no token fallback;
root/package documentation points to the released supported surface and its known limitations.
Plan of record
The repository roadmap/design and dependency graph are maintained by the planning PR associated with #32. Release execution evidence belongs in #41 and is linked here before closure.
Outcome
Ship the first public OpenCoven SDK as a coherent, identity-preserving read-only protocol release. A separately installed client must be able to discover the owner-local Cave and Coven authorities, verify compatibility, obtain a user-approved Cave credential, securely retain it, and read only the canonical state it was granted.
Why this is the release boundary
The repository has mature package boundaries, operation controls, package verification, stress/property tests, and a fail-closed release system. The remaining gap is the end-to-end developer journey: the release machinery is ahead of the public protocol surface and its real-consumer proof.
The first release establishes recognition and authorized observation before action. Message sends, streaming, attachments, task handoffs, and privileged GitHub mutations follow in separately reviewed authority milestones.
Included in 0.1.0
Explicitly excluded from 0.1.0
Critical path
Execution checklist
Contract and release truth
Protocol implementation
Real consumer and evidence
Release gates
Post-0.1 roadmap
Parallel non-blocking maintenance
#45 does not block 0.1.0 unless it discovers unique release-relevant work, provenance ambiguity, dirty canonical state, or verification interference.
Program rules
Completion definition
This issue closes only when:
Plan of record
The repository roadmap/design and dependency graph are maintained by the planning PR associated with #32. Release execution evidence belongs in #41 and is linked here before closure.