Promote v0.1.4 main to dev and document attestation access

README.md

@@ -88,7 +88,8 @@ Versioning and release requirements are in
 [the release policy](docs/release/versioning-and-launch.md) and
 [the readiness audit](docs/release/public-readiness-audit.md). The current
 [support boundary](SUPPORT.md),
-[published v0.1.3 release notes](docs/release/v0.1.3-release-notes.md), historical
+[published v0.1.4 release notes](docs/release/v0.1.4-release-notes.md), historical
+[v0.1.3 release notes](docs/release/v0.1.3-release-notes.md), historical
 [v0.1.2 release notes](docs/release/v0.1.2-release-notes.md), historical
 [v0.1.1 release notes](docs/release/v0.1.1-release-notes.md), historical
 [v0.1.0 release notes](docs/release/v0.1.0-release-notes.md), and historical

artifact_memory/__init__.py

@@ -1,4 +1,4 @@
 """Provider-free Artifact Memory v0 reference runtime."""
 
-__version__ = "0.1.3"
+__version__ = "0.1.4"
 CONTRACT_VERSION = "v0"

docs/onboarding/private-project-vault.md

@@ -5,12 +5,12 @@ bounded context pack for a human or fresh agent. Artifact Memory remains a
 provider-free local CLI. It does not discover private projects, grant access,
 or authorize work.
 
-Use an owner-signed release that contains this guide, or an explicitly reviewed
-commit containing the semantic context-pack validator, and record that exact
-version in the private vault README. The published `v0.1.3` release predates
-that validator and is not a sufficient baseline for this workflow. Until a
-newer release is published, pin the exact reviewed commit instead of relying on
-the package version alone.
+Use owner-signed `v0.1.4` or a later release that retains this guide and the
+semantic context-pack validator, and record that exact version in the private
+vault README. Published `v0.1.4` is a sufficient release baseline for this
+workflow; `v0.1.3` predates the validator and is not. When evaluating behavior
+that has not reached an owner-signed release, pin the exact reviewed commit
+instead of relying on an unreleased package version.
 
 ## Keep the public repository and private vault separate
 

docs/onboarding/repository-adoption.md

@@ -5,7 +5,7 @@ importing private project context. They are bounded handoffs, not authority
 grants. Copy the smallest prompt that matches the integration being attempted.
 
 The implementation baseline is the owner-signed
-[`v0.1.3`](https://github.com/joefeser/artifact-memory/releases/tag/v0.1.3)
+[`v0.1.4`](https://github.com/joefeser/artifact-memory/releases/tag/v0.1.4)
 release. An adopter must record the exact Artifact Memory tag or commit and the
 schema identifiers it uses. Documentation can be corrected or expanded between
 software releases; a documentation merge does not modify the signed release or
@@ -32,7 +32,7 @@ Expected mode: read-only architecture and boundary audit. Do not edit code,
 issues, discussions, settings, or workflows.
 
 Evaluate whether <ADOPTING_REPOSITORY> should integrate Artifact Memory using
-the owner-signed v0.1.3 release.
+the owner-signed v0.1.4 release.
 
 1. Fetch both repositories and report the exact repo/ref/SHA inspected for
    each. Do not rely on a moving local branch.
@@ -69,13 +69,13 @@ Use this after the fit audit identifies a useful seam.
 ```text
 Expected mode: bounded implementation in <ADOPTING_REPOSITORY> only.
 
-Implement one provider-free Artifact Memory v0.1.3 conformance proof governed
+Implement one provider-free Artifact Memory v0.1.4 conformance proof governed
 by <ISSUE_URL>.
 
 Pinned inputs:
 - Fetch and verify exact <ADOPTING_REPOSITORY_REF>; report its SHA before
   editing.
-- Pin Artifact Memory to owner-signed tag v0.1.3, record the resolved commit,
+- Pin Artifact Memory to owner-signed tag v0.1.4, record the resolved commit,
   and record every negotiated schema identifier.
 - Use wholly synthetic records and artifact bytes created for this fixture.
 
@@ -124,7 +124,7 @@ For <PROVIDER_OR_PRODUCT>, implement only the declaration and synthetic
 boundary fixture governed by <ISSUE_URL>.
 
 1. Pin and report exact SHAs for the provider repository and Artifact Memory
-   v0.1.3.
+   v0.1.4.
 2. Keep provider schema references as provider contracts; do not copy their
    schema text or product logic into Artifact Memory core schemas.
 3. Declare exact adapter identity/version, supported contracts, input/output
@@ -149,15 +149,15 @@ dynamic loading, remote execution, task creation, or provider mutation.
 
 ## Prompt: authority-safe context consumption
 
-The v0.1.3 exporter supports frozen context-pack v2/v3 and negotiated v4. V4 is
+The v0.1.4 exporter supports frozen context-pack v2/v3 and negotiated v4. V4 is
 required when lifecycle exclusions must be receipted. Caller selection and
 freshness are disclosed assertions, not authenticated authorization or inferred
 truth.
 
 ```text
 Expected mode: bounded informational context-pack integration.
 
-Consume one synthetic Artifact Memory v0.1.3 context pack in
+Consume one synthetic Artifact Memory v0.1.4 context pack in
 <ADOPTING_REPOSITORY>, governed by <ISSUE_URL>.
 
 1. Pin exact producer and consumer SHAs and negotiate an explicit supported
@@ -199,7 +199,7 @@ the claim.
 Expected mode: read-only evidence review. Do not patch or broaden scope.
 
 Review the completed Artifact Memory adoption proof at exact
-<ADOPTING_REPOSITORY_SHA> against owner-signed Artifact Memory v0.1.3.
+<ADOPTING_REPOSITORY_SHA> against owner-signed Artifact Memory v0.1.4.
 
 Report:
 1. exact repositories, refs, SHAs, release tag, and schema versions inspected;
@@ -223,7 +223,7 @@ caller selection, records, context, manifests, or successful checks.
 
 A merge to `main` is not automatically a release. Documentation, examples, and
 other reviewed source changes may merge without creating a tag or GitHub
-Release. The signed `v0.1.3` tag and its published assets remain immutable.
+Release. The signed `v0.1.4` tag and its published assets remain immutable.
 
 A new software release is appropriate when publishable runtime behavior,
 package contents, normative schemas, compatibility promises, or release-bound

docs/quickstart.md

@@ -59,7 +59,7 @@ explicit outcomes.
 
 To evaluate Artifact Memory from another repository, start with the read-only
 fit audit in the [repository adoption prompts](onboarding/repository-adoption.md).
-The prompts pin implementation claims to the owner-signed v0.1.3 release and
+The prompts pin implementation claims to the owner-signed v0.1.4 release and
 keep product meaning and operational authority with their owning systems.
 
 To use private operational context from a vault outside every Git worktree,

docs/release/v0.1.4-release-notes.md

@@ -0,0 +1,136 @@
+# Artifact Memory 0.1.4 release notes
+
+Artifact Memory 0.1.4 is a private-vault onboarding and coordination-plane
+update over v0.1.3. It adds a CLI-first path for bounded private operational
+context, strict portable coordination records, local-first synchronization,
+repository-bound freshness and scoping, and optional authenticated HTTP seams
+for WITS coordination.
+
+Release status is not established by this editable document alone. It is
+established by the owner-signed annotated `v0.1.4` tag, its verified
+release-manifest binding, and the published asset set. Those immutable release
+artifacts and the post-publication attestation workflow have since been
+verified; this source copy summarizes that evidence but is not a substitute
+for replaying it.
+
+## Private-vault onboarding
+
+- The private-project guide and synthetic end-to-end fixture demonstrate
+  canonical records outside Git, replaceable SQLite projections, literal
+  search, bounded context-pack v4 export, and independent informational recall.
+- Public fixtures remain wholly synthetic. Real vault records, generated
+  private views, credentials, raw conversations, and private topology remain
+  outside the public repository.
+- The session-ledger importer converts a bounded dated Markdown done log into
+  deterministic private draft knowledge records. It rejects undated content,
+  oversized input, unsafe paths, immutable collisions, and credential-like
+  material before publishing any record.
+- A generated projection or context pack remains a disposable view rather than
+  the canonical source. Storage does not imply encryption or backup, and
+  expiry does not establish deletion or global erasure.
+
+## Coordination records and local-first synchronization
+
+- Strict TaskPacket, WorkReceipt, and AccessLabel schemas preserve portable
+  UUID identity, display-name provenance, typed evidence, predecessor
+  transitions, project-scoped permissions, and explicit no-authority fields.
+- Revision identity remains the complete `(record_id, revision_digest)` pair.
+  Local and hub sets merge by union; different revisions of one logical record
+  coexist, while different bytes claiming the same complete pair are
+  quarantined rather than auto-resolved.
+- Local append writes immutable coordination records and an outbox receipt
+  before network synchronization. Pending HTTP outcomes survive interruption
+  and require exact replay and acknowledgement before removal.
+- Sync verifies complete authorized history, current task leaves, pair-set
+  digests, bounded pagination, continuation binding, and explicit exclusion
+  counts. Withheld identities are not disclosed by count-only receipts.
+- Resource limits are checked before expensive parsing, canonicalization, or
+  uniqueness comparison. Unsafe files, links, reparse points, oversized state,
+  recursive JSON, out-of-profile canonical values, and interrupted local apply
+  fail with typed outcomes.
+
+## Repository identity, onboarding, context and freshness
+
+- A committed `.agent-memory/repo.json` binds a repository to a stable UUID and
+  public-safe display name without treating a path, remote URL, hostname, or
+  checkout location as identity.
+- Project onboarding validates the exact server-bound label and repository
+  identity, synchronizes the authorized set, and publishes immutable link,
+  kickoff, receipt, attempt, checkpoint, and recovery evidence transactionally.
+- Scoped coordination context export uses the latest authorized projection and
+  effective AccessLabel. Grant/deny overlap, stale or ambiguous bindings, and
+  unsupported required extensions fail closed.
+- Freshness is linked to an exact repository head. A kickoff pack may report
+  current, stale, dirty, unavailable, or unsupported evidence without claiming
+  global task truth.
+- The exact-head hardening reviewed through PR #158 bounds retained
+  coordination reads, project-UUID sets, interrupted-apply recovery, and
+  canonicalization failure paths while preserving typed outcomes.
+- Acceptance commands are escaped and rendered as untrusted informational
+  data. Artifact Memory never executes them or promotes them into tool policy.
+
+## Authenticated HTTP coordination seams
+
+- The optional HTTP sync adapter uses standard-library TLS, refuses redirects
+  and URL credentials, ignores environment proxies, and permits cleartext only
+  for literal loopback fixtures. Bearers are supplied out of band through an
+  environment variable or in-memory API and are not persisted.
+- The adapter verifies the expected logical hub, principal, exact AccessLabel,
+  sequential page receipts, complete authorized pair set, and the existing
+  local projection contract. It does not create a second coordination store.
+- `artifact-memory claim` accepts one explicit exact open TaskPacket reference.
+  The authenticated hub alone mints and admits a claimed successor; the client
+  performs a second verified pull and reports only reference-bound evidence.
+- Claim conflicts never select a fallback task. Lost or invalid responses are
+  unverified outcomes, and retries require the same original exact reference.
+- The synthetic WITS bridge fixtures demonstrate protocol interoperability on
+  one machine. They do not establish deployed two-host operation, automatic
+  worker launch, production availability, or HTTP project onboarding.
+
+## Compatibility
+
+- Published v0.1.0-v0.1.3 schemas retain their original meanings. Existing
+  record, context-pack, exchange, retention, release, search, and projection
+  contracts are not silently reinterpreted.
+- Coordination schemas and CLI commands are additive and opt-in. Existing
+  provider-free record, projection, search, context, and release commands
+  remain available.
+- The local-directory sync adapter and deterministic fixture behavior remain
+  supported. HTTP transport requires separately provisioned compatible WITS
+  routes, bearer capabilities, retained labels, origin/project ownership, and
+  server token policy.
+- WITS's original authenticated round-trip v0 canary remains intentionally
+  pinned to the owner-signed Artifact Memory 0.1.0 package and rejects other
+  package versions. Run that historical canary in its dedicated 0.1.0
+  environment; do not substitute 0.1.4 until WITS separately updates its
+  release binding and expected-version guard. The v0.1.4 coordination HTTP
+  fixtures are separate, explicitly pinned interoperability evidence.
+- Repository onboarding writes a new strict public identity manifest only when
+  explicitly invoked. Existing repositories are not discovered or modified
+  automatically.
+
+## Authority and remaining limitations
+
+Artifact Memory preserves and transports informational evidence. Records,
+labels, receipts, context packs, kickoff packs, successful sync, and an
+authenticated transport grant no execution, mutation, routing, disclosure,
+credential, spending, deployment, approval, declassification, or merge
+authority. A WITS Task Packet or HACP route remains a separate authority-bearing
+contract enforced by its owning system.
+
+The reference runtime is not a hosted coordination service, scheduler, agent
+runner, credential manager, or global deletion system. HTTP project onboarding
+and automatic worker launch remain unsupported. Integrity and provenance do not
+establish authenticity or trust; unsigned evidence remains
+`integrity-verified / issuer-unverified`. Generated indexes remain replaceable,
+and private-vault custody, encryption, backup, retention, and disclosure policy
+remain operator responsibilities.
+
+## Verification
+
+Before publication, run the complete unit and conformance suites, public-safety
+and public-JSON scans, installed-package smoke test, platform matrix, release
+compatibility checks, deterministic candidate preparation, and the signed-tag
+release-candidate verifier against the exact owner-approved commit. Publication
+then triggers the separate keyless attestation workflow; that supplemental
+workflow does not replace owner signing.

docs/release/versioning-and-launch.md

@@ -6,7 +6,7 @@ Artifact Memory versions five surfaces independently:
 | --- | --- | --- |
 | Protocol | Product protocol generation such as `v0`. | Describes the supported product contract set; it is not an implementation API promise. |
 | Schemas | Every schema identifier ends in its own `/vN`. | Breaking field, identity, authority, or required-behavior changes require a new schema version. |
-| Reference CLI/package | Python package semantic version, currently `0.1.3`. | Before 1.0, implementation APIs may change; versioned record and receipt contracts are not silently reinterpreted. |
+| Reference CLI/package | Python package semantic version, currently `0.1.4`. | Before 1.0, implementation APIs may change; versioned record and receipt contracts are not silently reinterpreted. |
 | Adapters/providers | Provider-owned contract `/vN` plus the Artifact Memory adapter-manifest version. | Provider schemas remain provider contracts and never become core schemas implicitly. |
 | Fixtures/receipts | Each vector and receipt schema has its own `/vN`. | Checked receipts bind exact fixture bytes and cannot be carried forward after vectors change. |
 
@@ -231,6 +231,17 @@ gh attestation verify <asset> \
   --deny-self-hosted-runners
 ```
 
+GitHub CLI attestation verification may require authenticated API access even
+for a public repository. During the v0.1.4 post-publication check, anonymous
+release downloads, checksums, owner-signed tag verification, deterministic
+replay, and isolated installation all passed, and the public attestation page
+was anonymously reachable; `gh attestation verify` still required a logged-in
+GitHub CLI session to fetch and verify the bundles. That access requirement is
+platform friction, not a release-integrity failure, and this project does not
+claim fully anonymous attestation verification. Independently publishing
+bundles and offline trusted-root material remains out of scope until a product
+requirement justifies the extra custody and maintenance surface.
+
 Online verification depends on GitHub's attestation API and current Sigstore
 trust roots. For offline use, preserve the downloaded attestation bundle and a
 trusted-root snapshot, then follow GitHub's offline verification procedure.