Skip to content

[SDK 0.1.0][P0] Prove the packed SDK with cross-repository real-authority conformance #38

Description

@BunsDev

Parent: #31

Completed prerequisites:

Remaining release gate:

  • passing real-authority evidence for linux-x64 and win32-x64

Outcome

Produce a repeatable, redacted conformance run that proves the complete packed SDK journey against real release-mode Cave and Coven authorities through the actual native trust and credential boundaries.

Why this is a release gate

Package tests prove components. They cannot observe listener behavior, proxy/body gates, Next request normalization, filesystem ownership, connected Unix peer credentials, Windows named-pipe ownership, native keychain behavior, packed installation, or the composed consumer lifecycle. Cave’s current conformance evidence explicitly lists the SDK and Chat as not covered.

Required journey

Cave

install packed SDK
→ discover release-mode Cave
→ negotiate health compatibility
→ create pairing request
→ observe pending
→ approve through Cave authority
→ exchange once
→ store bearer through native SecretStore
→ read familiars/projects/conversations/conversation/messages
→ restart consumer
→ reuse credential
→ revoke through Cave authority
→ verify every authenticated read refuses it

Coven

install packed SDK
→ discover owner-local daemon endpoint
→ validate endpoint and trusted executable path where applicable
→ connect
→ inspect the live Unix peer or Windows pipe identity
→ request health
→ preserve structured daemon errors

Required negative/fault scenarios

  • pairing deny, expiry, wrong secret, replay, shared failure budget, and rate limit;
  • missing Content-Length: 0 control case and correct exchange case;
  • proxy rejection bodies versus Client v1 envelopes;
  • stale/replaced discovery records and Cave instance replacement;
  • malformed/non-canonical cursors and reconcile_required;
  • revoked credential across all canonical reads;
  • malicious COVEN_HOME, symlink/replaced socket, wrong owner/mode, wrong peer UID;
  • constructed or foreign Windows pipe, failed ownership provider, executable trust failure;
  • bounded connect/read/body/frame deadlines;
  • missing native keychain/trust binding;
  • no source checkout or workspace-link dependency.

Evidence format

Each record must include:

  • exact Cave, Coven, SDK, and consumer commits;
  • OS, architecture, runtime, and package-manager versions;
  • packed tarball SHA-256 values;
  • Cave and Coven release versions;
  • stable assertion IDs;
  • pass/fail/skip plus diagnostic ID;
  • explicit notCovered list;
  • no credentials, pairing secrets, prompts, message bodies, attachments, command output, private filesystem contents, or socket handles.

Harness quality requirements

  • declare the complete expected assertion ID set;
  • fail on missing, duplicate, or unexpected IDs;
  • never count a skip as a pass;
  • negative-test every assertion helper;
  • mutation-test representative authority defects, not only helper functions;
  • isolate temporary Cave/Coven homes and verify the operator’s real state is untouched;
  • retain artifacts only after redaction and digesting.

Dependencies

Acceptance criteria

  • One command or documented operator procedure produces a deterministic evidence record.
  • The complete Cave and Coven journeys pass on every release-supported OS/architecture.
  • SDK and Chat are absent from notCovered for the read-only 0.1.0 journey.
  • Producer fixture bytes, SDK vendored bytes, packed bytes, and consumer lock digests match.
  • Every required assertion ID appears exactly once.
  • Representative broken-authority mutations are caught.
  • The harness cannot touch the operator’s real Cave, Coven, credentials, or projects.
  • Retained evidence passes secret/content redaction scans.
  • A release candidate cannot advance without a named passing evidence record.

Validation

The conformance harness is itself tested through negative fixtures, missing-assertion mutations, authority mutations, redaction scans, and reproducibility checks.

Non-goals

This issue does not add write APIs, use unit-test proxies as final evidence, or make every conformance journey part of ordinary path-aware PR CI. Expensive real-authority execution may remain an explicit release gate if the evidence validator and scenario ownership remain in CI.

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