Skip to content

[SDK 0.1.0] Ship a secure read-only OpenCoven SDK #31

Description

@BunsDev

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

  • 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

Explicitly excluded from 0.1.0

  • message send, stop, retry, or stream
  • conversation writes
  • attachments
  • task handoffs
  • GitHub mutations
  • speculative revision APIs
  • arbitrary HTTP or private-route escape hatches
  • offline mutation queues

Critical path

#32 roadmap/release-scope reconciliation
  ├─ OpenCoven/coven-cave#4869 operational capability truth
  └─ #33 source-locked Cave contract + compatibility health
       └─ #34 secure Cave discovery
            └─ #35 pairing + secure credential custody
                 ├─ #36 canonical reads + bounded pagination
                 └─ #37 CLI scope + native trust boundaries
                      └─ OpenCoven/chat#27 packed consumer/native integration
                           └─ #38 real-authority conformance

#35 + #36 ──> #39 profiles/diagnostics/API governance
#38 + #39 ──> #40 first-release security ship/block disposition
#40 ──> #41 release execution + registry/provenance validation
#41 ──> close this program

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

  1. Every child issue names dependencies, blockers, non-goals, acceptance criteria, and validation evidence.
  2. No issue closes on unit-test proxies alone when the behavior requires a live authority, live native trust adapter, or packed consumer.
  3. No capability is considered shipped merely because it appears in a roadmap or fixture.
  4. No credential, pairing secret, bearer, prompt, attachment content, socket handle, daemon output, or unsafe transport cause may enter diagnostics or retained evidence.
  5. No ambiguous mutation completion may be automatically replayed.
  6. Publication remains locked until every required child gate closes.
  7. External mutations in [SDK 0.1.0][P0] Execute the first public release and validate registry provenance #41 require fresh explicit authorization at execution time.

Completion definition

This issue closes only when:

  • every 0.1.0 checklist item above is complete;
  • 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions