Repository navigation
Promote v0.1.4 main to dev and document attestation access - #163
Conversation
Prepare Artifact Memory v0.1.4 release candidate
Reviewer's GuideThis PR promotes the exact v0.1.4 main snapshot into dev, updates package and release documentation to 0.1.4, and records a narrowly scoped clarification that GitHub CLI attestation verification may require authenticated API access while preserving the distinction between that limitation and the release-integrity checks that passed. Flow diagram for v0.1.4 release verification accessflowchart TD
A[v0.1.4 published release] --> B[Anonymous release downloads]
A --> C[Checksums and owner-signed tag]
A --> D[Deterministic replay and isolated installation]
A --> E[Public attestation page]
A --> F[GitHub CLI attestation verification]
B --> G[Passed]
C --> G
D --> G
E --> G
F --> H[Authenticated GitHub API access may be required]
G --> I[Release-integrity checks remain distinct]
H --> I
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
PR Summary by QodoPromote v0.1.4 to dev and clarify attestation access
AI Description
Diagram
High-Level Assessment
Files changed (6)
|
Code Review by Qodo
1. PR description omits impact statements
|
There was a problem hiding this comment.
Hey - I've found 3 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="docs/release/v0.1.4-release-notes.md" line_range="15-17" />
<code_context>
+
+## 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
</code_context>
<issue_to_address>
**Vault guide rejects supported release**
When a reader follows the private-project vault guide after v0.1.4 is published, the guide still says published v0.1.3 lacks the semantic validator and advises pinning a reviewed commit until a newer release, even though this promoted v0.1.4 includes the guide and validator. Private-vault adopters are directed away from the supported release to a source checkout.
Update the guide to identify v0.1.4 as a sufficient release baseline and remove the obsolete instruction to pin a commit until a newer release.
</issue_to_address>
### Comment 2
<location path="README.md" line_range="91" />
<code_context>
[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),
+[v0.1.4 candidate notes](docs/release/v0.1.4-release-notes.md),
[published 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
</code_context>
<issue_to_address>
**Published release appears unreleased**
When readers use the README after this promotion is merged, the README labels v0.1.4 as candidate notes and calls v0.1.3 the published release, so readers are told that v0.1.4 is not yet published even though its release and assets exist.
Label v0.1.4 as the published release and distinguish the post-release documentation update from the unchanged release assets.
</issue_to_address>
### Comment 3
<location path="docs/release/v0.1.4-release-notes.md" line_range="9-11" />
<code_context>
+repository-bound freshness and scoping, and optional authenticated HTTP seams
+for WITS coordination.
+
+Release status is established only by an owner-signed annotated `v0.1.4` tag
+and its verified release-manifest binding. This reviewed source document does
+not claim that signing, publication, or attestation has occurred.
+
+## Private-vault onboarding
</code_context>
<issue_to_address>
**Release status is self-contradictory**
When a reader uses the v0.1.4 notes to understand its release status, the disclaimer says this document does not claim signing or publication occurred, but the same notes report a post-publication check and successful owner-signed tag verification. Readers get conflicting statements about whether release evidence exists.
Clarify that the notes are not themselves binding release proof while explicitly describing the post-publication verification results.
</issue_to_address>Sourcery assessment
Approval pending. 2 findings to address first.
Blocking findings: docs/release/v0.1.4-release-notes.md:17, docs/release/v0.1.4-release-notes.md:11
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1d1bd40751
ℹ️ 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".
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
| Topic | Details | ||||||
|---|---|---|---|---|---|---|---|
| Validation Updates | Refresh synthetic scan receipt expectations and add regression assertions that private-vault onboarding documentation consistently references the published v0.1.4 baseline.Modified files (2)
Latest Contributors(1)
| ||||||
| v0.1.4 Documentation | Update the supported baseline to v0.1.4, document its onboarding, coordination, compatibility, verification, and attestation-access guidance, and retain prior release references as historical.Modified files (8)
Latest Contributors(1)
|
|
ⓘ Qodo reviews are paused because your workspace is out of credits. Ask your workspace admin to add credits to resume reviews. Manage billing |
|
PR review loop disposition:
This note records why the loop is not waiting indefinitely on this finding state. |
|
PR review loop owner override:
This note accepts stale required-review risk for this exact PR head only. It does not request bot review, resolve findings, or merge the PR. |
Source binding
origin/mainsnapshot:ce8b01f50a1f3cc05761b5900202a9a7b53829b5origin/devtarget at branch creation:a3798d057590efe48622737f6afb031aeb31f8d5integration/promote-main-to-dev-ce8b01f50a1f1d1bd40This promotes the released v0.1.4 source snapshot into
devand adds one bounded documentation correction: GitHub CLI attestation verification may require authenticated API access even when the release and attestation page are public. Anonymous asset download, checksum, owner-signature, replay, and installation verification remain distinct and passed for v0.1.4.The v0.1.4 tag, release, and published assets are unchanged. The documentation commit is intentionally post-release and is not part of v0.1.4 or current
main; after merge,devwill contain this additional documentation until a later normal promotion.Validation receipts
python3 -m unittest discover -s teststhroughscripts/validate_contracts.sh: 901 passed, 3 expected skips.scripts/run_conformance.sh: passed.python3 scripts/public_safety_check.py: passed over 468 commits, 5,862 historical objects, and 782 current paths.git diff --check: passed.Summary by Sourcery
Promote the v0.1.4 release baseline into development and align documentation and validation guidance with the published release.
New Features:
Bug Fixes:
Enhancements:
Build:
Documentation:
Tests:
Security impact
Documentation and documentation-regression tests only. The change makes GitHub API authentication requirements explicit; it adds no credentials, secret handling, authority, network call, workflow permission, release mutation, or executable behavior. The owner-signed v0.1.4 tag and seven published assets remain unchanged.
Compatibility impact
No schema, protocol, CLI, package, fixture, release asset, or existing verification-path behavior changes. The README and private-vault guide now identify published v0.1.4 as the supported baseline, while historical v0.1.0-v0.1.3 artifacts and meanings remain unchanged.