Repository navigation
Make the new-PC install guides followable from the pinned release; add the release-move flow, a docs-consistency test and a receipt-staleness report - #134
Conversation
…them honest Fix the 21 findings of the 2026-09-23 new-PC documentation inventory: derive the release tag and commit from adoption/manifest.json instead of quoting them, run release_due.py on the default branch before the pinned checkout, state bootstrap pin coverage per profile and platform, mark steps the pinned release lacks, add the macOS get-the-catalog block and ordered steps, correct the platform-status rules and identity examples in the contribution guide, and refresh stale counts, gates and hosted-smoke citations. Add "Moving a host to a new release" to adoption/update.md, a docs consistency test, and a report-only receipt staleness script with a scheduled workflow that uploads its report as an artifact. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…t choice Mutation checks found two gaps: fenced commands inside list items were not scanned for mutually exclusive flags, and no staleness test told the newest bound receipt from the oldest. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…re-records Review round 2 of the new-PC guides change: - The macOS install path (Homebrew prerequisites, socraticode, darwin-binary and embedding-model pins, launchd, embedding acceptance) landed in #94 after v2026.09.23. The pages and next-host-stages.md now say what that tag does (brews only jq, installs 7 of 8, npm resolves the darwin binaries unverified) instead of describing main as the pinned release. - Step notes name the release they were written against ("added after `vT`", "changed after `vT`"), so they stay true at every later tag and a re-pin needs no doc edit. The profile table shows "(X at `vT`)" where the pinned release's pin files differ. - The docs test checks those notes per heading section and top-level numbered step, detects changed install inputs (release_due only sees missing paths), verifies the pin-coverage notes against the tag's own files, and rejects component_matrix.py --write --check. - receipt_staleness: pin_moved now fires only for a host and stage whose newest judgeable receipt is at a retired pin, and lists them; it clears once the host re-records. - Bootstrap step 2 uses --allow-unpinned for partly pinned profiles; update.md defines HOST_CHECKOUT/RUN_DIR and records in the default-branch clone; the handbook says macos-arm64-foundation replaces foundation-cpu at order 1 on macOS. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…baseline installs in step 2 Walkthrough at v2026.09.23: bootstrap-linux.sh --profile recovery exits 3 naming restic,qdrant; rerun with --allow-unpinned restic,qdrant installs ai-memory plus the node/uv/gh baseline into a scratch ECO_INSTALL_ROOT and exits 0, as step 2 now says. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ch; state the macOS tag-to-main path Review round 3: the scheduled staleness report ran on a shallow clone, where every receipt fails catalog_revision validation (now fetch-depth: 0, with a test that fails for any receipt-reading workflow that checks out shallow, mutation-checked). The pin confirmation now errors instead of printing nothing. The macOS page says the tag's bootstrap provisions neither the embedding model nor config/qdrant.yaml and that until the re-pin a Mac runs from step 2 onward from a default-branch clone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…esolution # Conflicts: # adoption/bootstrap.md # docs/next-host-stages.md # manifests/evidence.json
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. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b07c0f0246
ℹ️ 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".
| The simulation rung is ready by the checker's arithmetic (every required sim | ||
| gate established); paper and live are not, blocked on the adaptive-paper | ||
| broker trial and the live gates. Catalog inclusion does not authorize live |
There was a problem hiding this comment.
At this commit, python3 scripts/trading_gates.py --check reports rung_ready.paper: true with an empty blocking.paper, and catalogs/us-equities/gates-20260922.json marks adaptive-paper-broker-trial established. This new prose—and the paper row immediately above it—therefore incorrectly presents the trial as blocking; adoption/update.md repeats the same stale state, which can send readers to redo an established gate instead of advancing to the remaining live work.
Useful? React with 👍 / 👎.
New PCs can now follow the install guides top to bottom from the release pinned in
adoption/manifest.json, and the catalog keeps adapting as hosts move to new releases.Fixes from a read-only inventory of main. 21 findings were verified against code,
--helpoutput and a fresh-clone walkthrough atv2026.09.23:bootstrap.mdquoted the previous release's commit. Every page now reads tag and commit from the manifest and fails loudly on a mismatch.release_due.py, which isn't in the pinned tag. It now runs on the default branch before checkout.foundation-cpuandmacos-arm64-foundationare fully pinned; the rest go through their recipes. The macOS profile is now listed.config/qdrant.yaml.--write --checkcommand that doesn't run was removed, broken links were fixed, and the handbook, README and contributing-evidence docs now match the enforced rules.New: "Moving a host to a new release" (
adoption/update.md). It covers how a host learns about a newer release, the re-pin PR flow (immutable Release,gh attestation verify,release_due.pystrict mode), what to re-run (changed pins, then receipts, which bind to the pin), and how receipts reach the catalog.New:
tests/test_adoption_docs_consistency.py. It checks:14 of 14 mutants are caught.
New:
scripts/receipt_staleness.pyplus the weeklyreceipt-staleness.yml. It is report-only and least-privilege, with full history. It flags receipts older than 30 days and receipts whose pin moved, and it stays outside the generated matrix so--checkstays deterministic. 8 of 8 mutants are caught, and a test enforcesfetch-depth: 0for every receipt-reading workflow.main (#130) was merged in and the conflicts in bootstrap.md and next-host-stages.md resolved, keeping both sides. That includes main's new-host loop link and
hardware_profile.py --record-host.Checks
--check, host_receipts validate, the focused suites, actionlint and zizmor (0 findings). Guarded gitleaks found no leaks.🤖 Generated with Claude Code