Skip to content

Promote v0.1.4 main to dev and document attestation access - #163

Merged
joefeser merged 7 commits into
devfrom
integration/promote-main-to-dev-ce8b01f50a1f
Oct 8, 2026
Merged

joefeser merged 7 commits into
devfrom
integration/promote-main-to-dev-ce8b01f50a1f

Conversation

@joefeser

@joefeser joefeser commented Oct 7, 2026 •

Copy link
Copy Markdown
Owner

Source binding

This promotes the released v0.1.4 source snapshot into dev and 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, dev will contain this additional documentation until a later normal promotion.

Validation receipts

  • python3 -m unittest discover -s tests through scripts/validate_contracts.sh: 901 passed, 3 expected skips.
  • scripts/run_conformance.sh: passed.
  • Focused release, candidate, and signing-policy tests: 53 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:

  • Add published v0.1.4 release notes covering private-vault onboarding, coordination, synchronization, authenticated HTTP seams, compatibility, and verification guidance.

Bug Fixes:

  • Clarify that GitHub CLI attestation verification may require authenticated API access even when release assets and attestation pages are public.

Enhancements:

  • Update package and documentation baselines from v0.1.3 to v0.1.4 while preserving historical release references and immutable release artifacts.
  • Add regression coverage ensuring private-vault onboarding documentation consistently identifies v0.1.4 as the supported release baseline.

Build:

  • Bump the Python package version to 0.1.4 and update related fixture expectations.

Documentation:

  • Document v0.1.4 release capabilities, compatibility boundaries, verification evidence, and attestation access requirements.

Tests:

  • Add documentation-regression tests for coherent v0.1.4 baseline references.

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.

@sourcery-ai

sourcery-ai Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

Reviewer's Guide

This 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 access

flowchart 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
Loading

File-Level Changes

Change Details Files
Promote the v0.1.4 release snapshot and align package metadata with the new release version.
  • Updates the runtime and packaging versions from 0.1.3 to 0.1.4.
  • Adds the v0.1.4 candidate/release notes and links them from the README.
  • Updates the versioning policy table to identify 0.1.4 as the current package version.
artifact_memory/__init__.py
pyproject.toml
README.md
docs/release/v0.1.4-release-notes.md
docs/release/versioning-and-launch.md
Document the bounded attestation-verification access limitation observed after publication.
  • Explains that GitHub CLI attestation verification can require an authenticated API session despite public release assets and attestation pages.
  • Separates this platform access requirement from the independently validated download, checksum, signing, replay, and installation checks.
  • Defines offline bundle/trusted-root handling and the current scope boundary for independent attestation publication.
docs/release/versioning-and-launch.md
Refresh the synthetic scan receipt fixture for the promoted release snapshot.
  • Updates the expected receipt values to match the promoted source and release state.
fixtures/synthetic/scan/v2/expected-receipt.json

Possibly linked issues


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

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Promote v0.1.4 to dev and clarify attestation access

📝 Documentation ⚙️ Configuration changes 🕐 20-40 Minutes

Grey Divider

AI Description

• Promote the released v0.1.4 source version and refresh version-bound synthetic scan receipts.
• Add v0.1.4 release notes covering coordination features, compatibility, and authority limits.
• Clarify that public attestations may still require an authenticated GitHub CLI session to verify.
Diagram

graph TD
  Source["v0.1.4 snapshot"] --> Package["Package version"] --> Scan["Scan receipts"]
  Source --> Notes["Release notes"] --> Index["README index"]
  Source --> Guide["Verification guide"] --> CLI["GitHub CLI"] --> API["Attestation API"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Publish bundles and trusted roots independently
  • ➕ Could support verification without authenticated access to GitHub's attestation API.
  • ➖ Adds bundle distribution, trust-root custody, and ongoing maintenance obligations outside this promotion's scope.

Recommendation: Keep the bounded documentation correction. It accurately separates anonymous artifact verification from CLI attestation access without changing published v0.1.4 assets or taking on an unrequested offline distribution commitment.

Files changed (6) +156 / -11

Tests (1) +8 / -8
expected-receipt.jsonRefresh version-bound scan receipt digests +8/-8

Refresh version-bound scan receipt digests

• Replaces the seven synthetic case receipt references and aggregate receipt ID. Case outcomes and manifest bindings remain unchanged; the scan receipts include the runtime version in their digest-bearing content.

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

Documentation (3) +146 / -1
README.mdLink the v0.1.4 candidate notes +1/-0

Link the v0.1.4 candidate notes

• Adds the v0.1.4 notes to the release-documentation index alongside earlier release notes.

README.md

v0.1.4-release-notes.mdDocument the v0.1.4 release scope and boundaries +133/-0

Document the v0.1.4 release scope and boundaries

• Adds release notes for private-vault onboarding, coordination records and synchronization, repository scoping, and optional HTTP seams. Records compatibility, WITS canary pinning, authority limits, and the distinction between reviewed source and signed publication.

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

versioning-and-launch.mdClarify authenticated attestation verification +12/-1

Clarify authenticated attestation verification

• Updates the documented package version to 0.1.4. Explains that GitHub CLI may require login to fetch attestation bundles even when release assets and the attestation page are public, without treating that requirement as a release-integrity failure.

docs/release/versioning-and-launch.md

Other (2) +2 / -2
__init__.pySet the runtime version to 0.1.4 +1/-1

Set the runtime version to 0.1.4

• Updates the package's reported version from 0.1.3 to 0.1.4 without changing its protocol version.

artifact_memory/init.py

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

Set the distribution version to 0.1.4

• Aligns the build and package metadata version with the promoted runtime version.

pyproject.toml

@qodo-code-review

Copy link
Copy Markdown

Code Review by Qodo

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

Grey Divider


Remediation recommended

1. PR description omits impact statements 📘 Rule violation § Compliance
Description
The supplied PR description never includes an explicit security-impact or compatibility-impact
statement. Reviewers must infer those effects from surrounding release and attestation details
instead of finding the required declarations in the PR record.
Code

docs/release/versioning-and-launch.md[R234-241]

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

●●● Strong

Active compliance rule requires explicit impact statements; accepted release PRs consistently add
explicit security and compatibility boundaries.

PR-#161
PR-#103

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 3181010 requires explicit security and compatibility statements in the pull request
description. The supplied description discusses attestation access, release integrity, and unchanged
artifacts but contains no clearly labeled security-impact or compatibility-impact statement; the
changed documentation confirms the attestation boundary being discussed.

Rule 3181010: Document security and compatibility impact in pull request descriptions
docs/release/versioning-and-launch.md[234-241]

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 pull request description does not explicitly address security implications or compatibility implications, as required by the compliance checklist.

## Fix Focus Areas
- docs/release/versioning-and-launch.md[234-241]

## Recommended Fix
Update the pull request description with clearly labeled `Security impact` and `Compatibility impact` sections. State the security effect of the attestation-access documentation change and explicitly describe whether the release artifacts, APIs, schemas, CLI behavior, and existing verification paths remain compatible.

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

Dismiss ↗ | View ↗


Grey Divider

Context sources
✅ Compliance rules (platform): 18 rules
✅ Cross-repo context — repo relationships
  Explored: repo: joefeser/what-is-the-spec (sha: 2a288b6a) — View relationship
Review mode: Auto: ⚖️ Balanced: Version, package metadata, fixtures, and release documentation changes warrant careful review.

Grey Divider

Tip of the day
💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread docs/release/versioning-and-launch.md Resolved

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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

Comment thread docs/release/v0.1.4-release-notes.md Resolved
Comment thread README.md Resolved
Comment thread docs/release/v0.1.4-release-notes.md Resolved
@joefeser

joefeser commented Oct 8, 2026

Copy link
Copy Markdown
Owner Author

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread README.md Resolved
Comment thread docs/release/v0.1.4-release-notes.md Resolved
@chatgpt-codex-connector

Copy link
Copy Markdown

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-08T14:17:16.168161Z 1d1bd40 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.

@baz-reviewer

baz-reviewer Bot commented Oct 8, 2026 •

Copy link
Copy Markdown

Review this PR on Baz

Baz Summary

Promote the v0.1.4 release baseline across the package metadata, onboarding guidance, README, release notes, and versioning documentation. Clarify authenticated GitHub CLI attestation access, refresh scan receipts and regression coverage, and preserve historical release and artifact boundaries.

Topics

TopicDetails
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)
  • fixtures/synthetic/scan/v2/expected-receipt.json
  • tests/test_private_vault_onboarding_slice.py
Latest Contributors(1)
UserCommitDate
joseph.feser@gmail.comPin adoption guidance ...October 08, 2026
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)
  • README.md
  • artifact_memory/__init__.py
  • docs/onboarding/private-project-vault.md
  • docs/onboarding/repository-adoption.md
  • docs/quickstart.md
  • docs/release/v0.1.4-release-notes.md
  • docs/release/versioning-and-launch.md
  • pyproject.toml
Latest Contributors(1)
UserCommitDate
joseph.feser@gmail.comAlign v0.1.4 post-rele...October 08, 2026

Merger  Activate to get a short verdict whether this PR is good to go or not

Skills  Activate Skill Maintainer to keep your skills up to date

Planner  This PR would have been improved with Baz Planner - Try it now

@qodo-code-review

Copy link
Copy Markdown

ⓘ Qodo reviews are paused because your workspace is out of credits. Ask your workspace admin to add credits to resume reviews. Manage billing

@joefeser

joefeser commented Oct 8, 2026

Copy link
Copy Markdown
Owner Author

PR review loop disposition:

  • Comment: Promote v0.1.4 main to dev and document attestation access #163 (comment)
  • Reason: Qodo top-level summary duplicates the resolved PR-body impact finding. The PR body now contains explicit Security impact and Compatibility impact sections; all six associated inline findings were fixed, evidenced, and resolved. Current head a41aebe is an ancestry-only merge of dev and has the same tree as fixing commit 7b02cfb.
  • Fixing commit: 7b02cfb
  • Validation evidence: On fixing commit 7b02cfb: 902 tests passed with 3 expected skips; 62 focused onboarding/release tests passed; contract validation, conformance, public-safety, and diff checks passed. Git diff confirms current head a41aebe is tree-identical.
  • Residual risk: Current-head hosted checks and fresh reviewer evidence are still pending; this disposition settles only the duplicated Qodo summary and grants no merge authority.

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

@joefeser

joefeser commented Oct 8, 2026

Copy link
Copy Markdown
Owner Author

PR review loop owner override:

  • PR: 163
  • Head: 9463ef9
  • Stop reason: POST_REVIEW_FIX_HEAD
  • Reason: Owner accepts the post-review-fix-head freshness risk because every required-review finding was patched or dispositioned, all threads are resolved, and exact-head Baz evidence is clean.
  • Residual risk: Medium: Codex and Qodo reviewed the earlier head; the current delta consists of evidence-backed documentation corrections and regression coverage.
  • Validation evidence: Exact head 9463ef9: 902 tests passed with 3 expected skips; contract validation, conformance, public-safety, macOS/Ubuntu/Windows platform checks, and both CI runs passed; merge state clean; zero unresolved threads and zero actionable findings.
  • Fresh review recommended: no
  • Owner decision: This is a human owner risk decision, not bot approval.

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.

@joefeser
joefeser merged commit f4b6204 into dev Oct 8, 2026
7 checks passed
@joefeser
joefeser deleted the integration/promote-main-to-dev-ce8b01f50a1f branch October 8, 2026 14:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant