[joefeser]

Closes #160.

Candidate scope

• exact base: origin/main at 5e7b5ca9778fa420be8ad09bb72cab48015e0ec7
• source head: 8b8a51ae636f6c8d555dfd58d6cf274650c58607
• package/runtime version: 0.1.4
• release notes: docs/release/v0.1.4-release-notes.md
• published adoption baseline remains owner-signed v0.1.3 until v0.1.4 publication succeeds

Validation receipts

• bundled Python: 901 tests passed, 3 skipped
• system Python: 901 tests passed, 3 skipped
• release/platform focus: 104 tests passed
• scripts/validate_contracts.sh: passed
• scripts/run_conformance.sh: passed
• scripts/validate_public_json.py: 320 files passed
• scripts/public_safety_check.py: passed
• isolated wheel install: artifact-memory 0.1.4; installed-package smoke passed
• unsigned candidate preparation and preparation-receipt validation: passed

The current exact-head pre-merge candidate proof produced manifest digest
sha-256:75ad665c340564676a5ddabedeaa61df086762464c8ad371518ea09c00ace7c6.
It is evidence that the candidate pipeline works, not the final release digest;
assets must be regenerated from the exact reviewed merge commit.

Security and compatibility

• No private key was accessed or invoked; no tag or release was created.
• Public fixtures remain synthetic; no vault, customer, credential, local topology, or raw transcript material is included.
• Coordination and private-vault capabilities are additive and opt-in.
• Published v0.1.0-v0.1.3 contracts keep their existing meanings.
• Memory, records, receipts, context, sync, and authenticated transport grant no operational authority.
• Final signing, tag push, publication, and post-publication verification require separate exact-commit owner authorizations.

[sourcery-ai]

Reviewer's Guide

This release-candidate PR bumps Artifact Memory to 0.1.4, adds comprehensive release notes for the additive private-vault and opt-in coordination/transport capabilities, updates release documentation and synthetic receipt data, and explicitly preserves compatibility, non-authority, public-safety, and owner-controlled publication boundaries.

Sequence diagram for local-first coordination synchronization

sequenceDiagram
    participant Client as ArtifactMemoryClient
    participant Local as LocalStore
    participant Hub as AuthenticatedHub

    Client->>Local: append coordination record
    Local-->>Client: immutable record and outbox receipt
    Client->>Hub: synchronize authorized record set
    Hub-->>Client: paginated receipts and pair-set digest
    Client->>Local: apply verified union
    Client->>Hub: acknowledge exact replay
    Hub-->>Client: acknowledgement
    Client->>Local: remove acknowledged outbox receipt

Loading

Flow diagram for the 0.1.4 release-candidate publication boundary

flowchart TD
    Source[Exact reviewed merge commit] --> Validate[Run test and safety validation]
    Validate --> Prepare[Prepare unsigned candidate assets]
    Prepare --> Owner[Separate owner authorization]
    Owner --> Sign[Sign exact commit and create tag]
    Sign --> Publish[Publish release]
    Publish --> Verify[Verify tag, manifest, and publication]
    Prepare -.-> Baseline[Published adoption baseline remains v0.1.3]

Loading

File-Level Changes

Change	Details	Files
Advances the package and documented release metadata to the 0.1.4 release candidate.	Updates runtime and package versions from 0.1.3 to 0.1.4. Adds and links the v0.1.4 release notes. Updates versioning documentation to identify 0.1.4 as the current package version.	artifact_memory/__init__.py pyproject.toml README.md docs/release/versioning-and-launch.md docs/release/v0.1.4-release-notes.md
Documents the 0.1.4 private-vault, coordination, synchronization, repository-context, freshness, and authenticated transport capabilities and their safety boundaries.	Describes bounded private-vault onboarding and deterministic session-ledger importing. Documents strict coordination records, immutable local append/outbox behavior, union-based synchronization, quarantine, resource limits, and fail-closed handling. Defines repository identity, scoped context export, exact-head freshness reporting, and informational-only acceptance commands. Documents optional HTTP/WITS synchronization security properties, claim behavior, conflict handling, and unsupported deployment assumptions. Records compatibility guarantees, non-authority boundaries, remaining operational limitations, and required pre-publication verification.	docs/release/v0.1.4-release-notes.md
Refreshes the synthetic scan receipt fixture for the candidate release.	Updates the expected receipt values to match the candidate fixture state.	fixtures/synthetic/scan/v2/expected-receipt.json

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#160	Bump the reference package and runtime version from 0.1.3 to 0.1.4, update current-version and release-note navigation, and preserve v0.1.3 as the published adoption baseline.	✅
#160	Add accurate v0.1.4 release notes covering the requested private-vault, coordination, synchronization, repository identity, scoping, freshness, transport, compatibility, authority, and residual-risk information without claiming signing or publication.	✅
#160	Complete the required repository, conformance, public-safety, package/install, and release-compatibility checks, and prepare deterministic unsigned candidate assets from the exact reviewed merge commit while leaving signing, tagging, publication, and private-key use to later owner authorization.	❌	The PR reports that the validation suites and unsigned candidate preparation passed, and it explicitly avoids signing or publication. However, the reported manifest digest is only from the pre-merge candidate proof; the PR states that final assets must be regenerated from the exact reviewed merge commit. The diff does not include those final exact-merge candidate assets or evidence that the repository ACK review loop completed before merge, so this release-preparation objective is not fully satisfied by the PR itself.

Possibly linked issues

• Prepare the v0.1.4 coordination-plane release candidate #160: The PR directly implements issue Prepare the v0.1.4 coordination-plane release candidate #160 by preparing v0.1.4 candidate artifacts, documentation, version updates, and validation receipts.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[qodo-code-review]

PR Summary by Qodo

Prepare Artifact Memory 0.1.4 release candidate

⚙️ Configuration changes 📝 Documentation 🧪 Tests 🕐 20-40 Minutes

AI Description

• Set package and runtime versions to 0.1.4 without changing the v0 contract version.
• Document the candidate’s capabilities, compatibility boundaries, and required owner-signing steps.
• Regenerate synthetic scan receipts whose digests change with the runtime version.

Diagram

graph TD
  V["Version metadata"] --> F["Scan receipts"] --> T["Conformance checks"] --> C["Candidate preparation"] --> S["Owner signing"] --> P["Publication"]
  N["Release notes"] --> C

Loading

High-Level Assessment

Keep the version bump, candidate notes, and version-dependent fixture regeneration together. Separating them would leave release metadata or conformance expectations inconsistent; signing and publication correctly remain outside this PR.

Files changed (6) +136 / -11

Tests (1) +8 / -8

expected-receipt.jsonRefresh version-bound scan receipt digests +8/-8

Refresh version-bound scan receipt digests

• Replaces seven synthetic scan receipt references and their aggregate receipt ID after the runtime version change. Case outcomes, manifest digests, and schema identity remain the same.

fixtures/synthetic/scan/v2/expected-receipt.json

Documentation (3) +126 / -1

README.mdLink the 0.1.4 candidate notes +1/-0

Link the 0.1.4 candidate notes

• Adds the candidate notes alongside published and historical release documentation, distinguishing this source candidate from a published release.

README.md

v0.1.4-release-notes.mdDocument the 0.1.4 candidate +124/-0

Document the 0.1.4 candidate

• Describes private-vault onboarding, coordination and sync capabilities, repository scoping, and optional HTTP seams. Records compatibility and authority limits, verification requirements, and the fact that signing and publication have not occurred.

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

versioning-and-launch.mdUpdate the documented package version +1/-1

Update the documented package version

• Sets the reference CLI/package version in the release policy to 0.1.4 without changing its compatibility rules.

docs/release/versioning-and-launch.md

Other (2) +2 / -2

__init__.pySet runtime version to 0.1.4 +1/-1

Set runtime version to 0.1.4

• Changes the runtime version string from 0.1.3 to 0.1.4. The v0 contract version remains unchanged.

artifact_memory/init.py

pyproject.tomlSet distribution version to 0.1.4 +1/-1

Set distribution version to 0.1.4

• Changes the Python package version from 0.1.3 to 0.1.4 to match the runtime declaration.

pyproject.toml

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Approved.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. WITS canary rejects the new release ✓ Resolved

Description

The PR changes Artifact Memory's reported package version to 0.1.4, while the WITS provider helper
accepts only version 0.1.0. When WITS runs its round-trip canary with this package,
_require_release() exits before fixture generation or admission, so the cross-repository
interoperability proof cannot run.

Code

pyproject.toml[7]

+version = "0.1.4"

Relevance

●●● Strong

The exact-version interoperability gate creates a concrete cross-repository release blocker; strict
release identity bindings were accepted previously.

PR-#86
PR-#103

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the package metadata to version 0.1.4. WITS imports the installed package and
explicitly raises ENVIRONMENT_BLOCKED unless artifact_memory.__version__ is exactly 0.1.0; its
documentation and boundary requirements also bind the canary to that exact released version and
commit.

artifact-memory -> what-is-the-spec
pyproject.toml[5-8]
artifact_memory/init.py[1-4]
External repo: joefeser/what-is-the-spec, scripts/artifact_memory_round_trip_provider.py [19-30]
External repo: joefeser/what-is-the-spec, docs/coordination-memory/artifact-memory-authenticated-round-trip-v0/README.md [1-20]
External repo: joefeser/what-is-the-spec, .kiro/specs/artifact-memory-v0-wits-boundary/requirements.md [1-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The WITS round-trip provider in `what-is-the-spec` hard-rejects every Artifact Memory package whose reported version is not `0.1.0`, so installing this `0.1.4` candidate causes the canary to stop before producing or admitting its fixtures.

## Fix Focus Areas
- pyproject.toml[7-7]
- artifact_memory/__init__.py[3-3]
- /cross_repos/what-is-the-spec/scripts/artifact_memory_round_trip_provider.py[19-30]
- /cross_repos/what-is-the-spec/docs/coordination-memory/artifact-memory-authenticated-round-trip-v0/README.md[13-20]

## Recommended Fix
Coordinate a WITS change that updates its pinned Artifact Memory release, commit, signed-release evidence, and expected-version guard to a published compatible release before adopting `0.1.4`. Alternatively, keep the WITS canary on the separately installed signed `0.1.0` package and explicitly prevent `0.1.4` from being selected for that integration until the WITS contract is updated and released.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Release notes omit head-hardening detail ✓ Resolved

Description

The candidate notes describe exact-repository-head freshness but omit that the hardening was
delivered through PR #158. Readers cannot trace this claimed release behavior to the required
reviewed change, leaving the candidate documentation incomplete.

Code

docs/release/v0.1.4-release-notes.md[R60-62]

+- 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.

Relevance

●●● Strong

Release-note traceability is a clear documentation completeness issue; release documentation
corrections were accepted previously.

PR-#103

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The release-note requirement includes exact-head hardening through PR #158. The changed notes
describe freshness being linked to an exact repository head and list its evidence states, but
contain no reference to PR #158; the repository decision record confirms the exact-head hardening is
a distinct reviewed change.

Publish accurate candidate release notes and navigation
docs/release/v0.1.4-release-notes.md[60-62]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The v0.1.4 candidate notes describe exact-repository-head freshness but do not identify the required exact-head hardening delivered through PR #158.

## Fix Focus Areas
- docs/release/v0.1.4-release-notes.md[60-62]

## Recommended Fix
Update the repository identity, onboarding, context, and freshness section to state that the exact-head hardening was delivered through PR #158, while preserving the existing explanation of current, stale, dirty, unavailable, and unsupported evidence states.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Tickets: 🎫 Prepare the v0.1.4 coordination-plane release candidate

✅ Compliance rules (platform): 18 rules

✅ Cross-repo context — repo relationships

  Explored: repo: joefeser/what-is-the-spec (sha: 2a288b6a) — View relationship

Review mode: Auto: 🚀 Fast: Localized release metadata and documentation changes with minimal behavioral risk.

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[joefeser]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-06T19:35:57.016797Z	8b8a51a	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Another round soon, please!

Reviewed commit: a18b9828e1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[sourcery-ai]

Sourcery assessment

Approved.

[joefeser]

@codex REVIEW

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: 8b8a51ae63

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joefeser]

PR review loop disposition:

• Thread: Prepare Artifact Memory v0.1.4 release candidate #161 (review)
• Reason: Both Qodo findings were fixed in exact commit 8b8a51a. The release notes now identify PR Promote coordination plane from dev to main #158 hardening and distinguish the historical WITS v0.1.0 round-trip canary from the v0.1.4 coordination-plane fixtures. Both inline threads received evidence-backed replies and are resolved. The WITS pin was independently verified against current WITS origin refs and its documented historical-canary contract.
• Fixing commit: 8b8a51a
• Validation evidence: Exact-head validation passed: 901 tests with 3 expected skips in each bundled and system Python runtime; 104 focused release/platform tests; contract validation; conformance; 320 public JSON files; public-safety scan; installed-wheel smoke reporting 0.1.4; GitHub CI and macOS/Ubuntu/Windows platform checks; exact-head release-candidate preparation and receipt validation.
• Residual risk: Final release assets and manifest trailer must be regenerated from the exact merged origin/main commit. Owner signing, tag push, and release publication remain separately authorized actions.

This note records why the loop is not waiting indefinitely on this finding state.