[arjitj2]

Closes #164

What changed

Adapts Cursor Pstack 0.15.28 through d457567 as distribution 1.17.6.

• Add formal-verification creation and maintenance skills, with active-host local registration, bounded-scope reporting and verification-only updates.
• Add independent optional Setup offers and Help pointers. Generation requires explicit consent after successful smoke.
• Keep every Ketchup waiting item without a word-count cutoff. Allow Sharpen to deliver an explicitly requested rewrite while completing the task.

The shared Codex/Claude tree, saved provider policy and README content are preserved. Both formal skills remain model-invocable for parent workflows, including Setup creation after consent; the upstream manual-only flags are excluded and automatic selection remains unverified. Cursor guides and duplicate packaging remain excluded. Newer Sharpen rewrite-only and Statechart changes are separate work in #168; this is not the latest Cursor checkpoint.

Verification

• Exact-head Linux CI: 40543250946, 993 Bun passes, five platform skips, zero failures; strict/static/provenance, maintenance27, hook8 and docs16 pass.
• Exact package installed in disposable Codex and Claude profiles: 1.17.6, tree 26be5ce9990e8422b7b67b6fe683291e843359a5, all 240 files verified. Final metadata head 2c7c6e2 has the same package as host-tested 585d2dd.
• Native changed-behavior cases below, with limits stated.
• Independent exact-head Opus5.5/high Shipping verdict: PASS+NOTES at 2c7c6e2, after the invocation-flag documentation finding was fixed. Earlier incomplete and failing reviews remain recorded. No merge request is armed.

Both hosts retained all30 Ketchup items from a supplied digest; Claude renamed their labels. Sharpen calculated29 across4 CSV rows against an independent control and returned the requested rewrite. Help named the new formal pair.

Both hosts loaded the formal generator. Its inspected artifacts were staged and registered by the parent in .agents/skills/verify-token-parser or .claude/skills/verify-token-parser. Native project-skill loading and real parser checks then ran: Codex380pass / planted fault65fail / restored380pass / original380pass; Claude377pass / fault65fail / restored377pass / original377pass. This was supervised generation across phases, not autonomous one-turn creation.

Native maintenance read the actual fixture commits, distinguished a no-effect formatting change from an intentional ABC contract change and renamed implementation, and identified the old pass as stale. Updated native checks passed1381 cases in Codex and2757 checks in Claude; planted faults produced175 and350 failures respectively. A separate later commit removed character rejection without changing requirements. Both hosts reported the exact introducing commit and real counterexample, preserved the property, and left product code unchanged.

Setup guard cases used supplied success/failure/consent/harness states. Both hosts selected the correct offers and suppression rules. Existing steps1–10 are byte-identical; unchanged probes and persistence were not repeated. Full setup yes-to-generator transactions and automatic harness discovery remain unverified; generator registration/execution was checked separately. No TLA+ engine ran. The parser fallback is bounded real-code testing, not formal proof. It covers ABC! at lengths0–5 plus sampled nonstrings.

Local Node24 full suite failed:994 passes,4 failures and3 additional errors in unchanged timing fixtures. Cause is unproven; related #141 remains separate. Do not read Linux CI as a local-green claim.

Initial manual-only Skill calls were rejected; direct user slash invocations succeeded. Interrupted and ENOTFOUND attempts are retained. Codex execution stopped on temp/cache restrictions, then passed with the existing direct Python binary. Claude's maintenance proposal continued after a denied compound command; its effects were inspected and retained as a deviation. Later updated native-skill execution passed with constant commands and no denials. These results do not prove universal policy compliance, automatic skill selection or OS confinement.

Independent source review passed with notes through the approved Sol backup after Opus's terminal ENOTFOUND. Provider diversity was reduced. No-comments review found zero applicable code comments. Detailed retained receipts, commands, hashes and failures: /Users/arjitjaiswal/open-pstack-d457567/result.md.

The personal Codex1.17.5 package, unpinned fork source, assignments and all five captured model/instruction/Claude file hashes remain unchanged during validation. The guarded squash merge produced 9086657cb08d544f9e315c1b5074cac901331447. Release v1.17.6 is published, and Codex1.17.6 is enabled with all240 files verified against the released package. The unpinned fork source, assignments, other registrations and captured Claude hashes are preserved. Merged-checkpoint CI40543684140 also passed.

Documentation impact

UPSTREAM.md, CHANGELOG.md and the verification recipe record the new skills, source decisions and evidence limits. README.md is unchanged. Related monitor #1, catalog #172 and next-unit #168.

Final review limits: Codex generated-skill load evidence is indirect (native registration, intended prompts and observed execution), not a captured stdin or skill-load event. The parent supplied command sequences, so autonomous adherence to every generated step is only partly shown. The Help formal recipe is partly covered; Setup was tested separately. These are retained evidence bounds, not universal guarantees.

[arjitj2]

Independent Opus5.5/high Shipping inspection at a57749a6953240d97afb8e8a17045573c52b7086 returned NO VERDICT, not PASS.

Verdict: no verdict. This is not a PASS, and it gives no authority to land PR165 at a57749a against base a16c327. I stopped partway because the Read tool was denied, so the required checks are incomplete.

What was denied: I asked to read the two generated helpers:

• /Users/arjitjaiswal/open-pstack-d457567/codex-fixture2/verification/check_token.py
• /Users/arjitjaiswal/open-pstack-d457567/claude-fixture2/verification/check_token.py

Both requests were refused ("permissions … you haven't granted it yet"). The contract says not to retry or find another route, so I did not read them with Bash cat and did not run them without reading them first. I also did not start the remaining evidence reads. Earlier Bash reads of other files in that folder had worked.

Commands I ran and what they showed:

• Same package tree on both commits: git rev-parse 585d2dd:plugins/pstack and the same for a57749a both give 26be5ce9990e8422b7b67b6fe683291e843359a5, which has 240 files.
• Only metadata changed after testing: git diff 585d2dd a57749a touches only CHANGELOG.md, UPSTREAM.md and maintenance/upstream-ledger.json.
• README and provider files untouched: comparing base to head for README.md, poteto-mode/references/ and runner/types.ts shows no changes. Saved models, efforts, fallbacks, spending policy and provider optionality are therefore unchanged.
• Version: all three manifests go from 1.17.5 to 1.17.6, a patch bump, never a major one.
• python3 scripts/check-docs.py (CommandLineTools python3): Check-docs: ok.
• python3 scripts/fork-maintenance.py check-ledger: ledger ok: 62 entries, coverage checked.
• One combined Bash command was blocked as needing approval. I reran only the two checks above as separate single commands.

What I reviewed by reading:

• I read AGENTS.md, UPSTREAM.md, the full base-to-head diff (all 16 files, including the six changed skills), result.md, pre-final-integrity.json, maintenance-history.json, source-review-sol.md and comments-review.md.
• The ten source decisions: adapted are 16541c6, 4382e68, 75fabac, f9be7aa, 6b78e9f and 7b353f7; adopted is bc14437; excluded are 0b8e952, 0148b78 and d457567. Each matches what the diff actually changed.
  • The f9be7aa reason says the full Setup yes-path is unverified.
  • The 6b78e9f reason says no TLA+ engine ran.
  • The 7b353f7 reason keeps the record of the earlier policy deviation.
• The ledger has no entries for 88d4751 or eb4db2b, and nothing claims the fork is caught up to the latest upstream.
• The CHANGELOG and NOTICE wording does not claim formal proof, automatic skill selection or a green local suite.
• The integrity file shows all five personal hashes unchanged, product and requirements kept in both fixtures, and fault copies removed.

Not done, so these remain open:

1. Running both helpers against <host>-prebug-product.py (expected 0) and against current <host>-fixture2/token_parser.py (expected 1). Nothing was run.
2. candidate.json was not read.
3. I did not compare either host's native event logs or final replies for verify4/verify3, maintain1, maintain-verify, maintain-bug, setup-guards or manual2. I have not independently confirmed that the generated skill was natively registered, loaded and run on each host, or any of the pass and fail counts. I have only the claims in result.md.
4. I did not compare the changes against the pinned upstream.diff. My review of the decisions used the candidate diff and the earlier independent source review only.
5. The gaps listed in the brief stay as stated in result.md, not checked by me:
   • supervised multi-phase generation rather than autonomous creation;
   • a Python generated-input fallback with no TLA+ engine;
   • Setup tested only on supplied states, with no full yes-path run;
   • the earlier invocation, DNS, launcher and cache failures;
   • the Claude maintenance stop-on-denial violation;
   • the overlapping read-only commands;
   • the local suite failing (994 pass, 4 fail, 3 errors; issue141).

What would unblock this: grant read access to the two check_token.py files and to the native logs in the evidence folder, or have the parent run those reads and the two helper runs and inspect them. After that, a fresh exact-head review needs to finish items 1–4. Even then, landing would still depend on green CI for a57749a itself; CI from older commits does not count.

I wrote no files, made no Git changes and used no network.

Parent follow-up: copied77 required evidence files into the reviewer worktree with an original-path/SHA256 manifest. Parent correct-source replays returned0; bug-source replays returned1 in both fixtures. These parent checks do not replace the missing independent verdict. A scoped fresh-review approval is pending under the saved worker policy; the previous complete receipt is not treated as fallback eligibility or release approval. Final exact-head CI39811520183 is green. PR remains draft.

[arjitj2]

Independent Opus5.5/high review after explicit owner approval completed with NO VERDICT. PR #165 remains draft and unmerged.

I'm stopping here with no verdict for a57749a vs a16c327. One of my own commands was denied, and the contract says to stop on any denial without retrying or switching readers. I haven't finished the required review, so this must not be counted as PASS, PASS+NOTES or FAIL.

The denied command

To summarize the event order in .review-evidence/claude-maintain-bug.jsonl, I ran an inline python3 -I -c "..." one-liner. It returned "This command requires approval." That command was my mistake. It didn't follow your instructions: you only approved constant direct-Python runs of the copied helpers, and you ruled out scratch scripts. I haven't retried it or used Read/Grep in its place. Nothing was written to the worktree; git status shows only ?? .review-evidence/.

What I checked before stopping

Identity and packaging

• HEAD is a57749a6953240d97afb8e8a17045573c52b7086. The plugins/pstack tree is 26be5ce9990e8422b7b67b6fe683291e843359a5 at both a57749a and 585d2dd; at base a16c327 it was e678abc….
• From 585d2dd to a57749a, only CHANGELOG.md, UPSTREAM.md and maintenance/upstream-ledger.json changed. The package lists 240 files at HEAD.
• All 11 changed or policy package files I hashed with SHA-256 match candidate.json. 15 evidence files match the SHA-256 values in manifest.json.
• From base to head, README.md, provider-dispatch.md and scripts/ are unchanged. The version is 1.17.6 in all three manifests and UPSTREAM.md, a patch step from 0.15.25 to 0.15.28.

Read in full: AGENTS.md, UPSTREAM.md, the whole base-to-head diff (16 files), the changed skills, result.md, manifest.json, candidate.json, both copied check_token.py helpers, the pre-bug and bug product files, and REQUIREMENTS.md.

CLI replays (one constant command each, using /Library/Developer/CommandLineTools/usr/bin/python3 -I -B, Python 3.9.6):

Helper	Product file	Exit	Result
codex	codex-prebug-product.py	0	PASS: 1381 cases
codex	codex/token_parser.py	1	FAIL: 175 of 1381, first case 'AAA!'
claude	claude-prebug-product.py	0	PASS: all 2757 checks
claude	claude/token_parser.py	1	FAIL: 350 of 2757

All four match result.md. These are independent CLI replays, not proof that the hosts loaded the skills.

Native logs

• Claude verify3: the host's startup list includes skill verify-token-parser and plugin 1.17.6 from the snapshot. The Skill verify-token-parser call returned "Launching skill" and loaded the body from .claude/skills/verify-token-parser. Four real runs gave 377 pass, 65 fail, 377 pass, 377 pass, with no permission denials.
• Claude maintain-verify: it launched verify-token-parser, ran 2757 pass, 350 fail, 2757 pass, 2757 pass, and had no denials.
• Claude maintain-bug: it launched both skills and later runs show 350 of 2757 failing. Line 13 contains a "PASS 2757" string that I hadn't explained when the denial hit.
• Claude maintain1: shows the disclosed denied command (...check_token.py; echo "exit=$?"), as result.md says.
• Codex skills list: shows verify-token-parser at repo scope and the 1.17.6 private-cache package.
• Codex verify4: 380 pass, 65 fail, 380 pass, 380 pass.
• Codex maintain-verify: 1381 pass, 175 fail, 1381 pass, 1381 pass, with no file read of the skill.
• Codex skill-load evidence is weaker than Claude's. Codex's JSON log has no skill-load event, and the stdin prompt wasn't saved (the command ends in - and runs with --ephemeral). The evidence is registration, the agent's own report, and one indirect sign. In maintain-verify it ran "your command list without -B", which suggests it saw the updated skill text (that text uses -B). Packaged pstack skills were read from the registered 1.17.6 cache path.

Not reviewed

• claude-maintain-bug.jsonl past line 13, both setup-guards logs, codex-dialogue, and Claude's Ketchup, Sharpen and Help manual2 runs
• ci-final-a57749a.log (CI run 39811520183)
• source-review-sol.md and comments-review.md
• upstream.diff and the ten final source dispositions in the ledger
• maintenance-history.json, pre-final-integrity.json, shipping-verdict.md and shipping-receipt.json

Landing

I can't give a verdict, so landing stays blocked on a complete exact-head Shipping review. Before landing, the merge queue and automerge state also need rechecking. Nothing I saw so far contradicts result.md. The two things I'd watch in a full review:

• Whether the Codex generated-skill load evidence (registration, self-report and the -B sign, with no saved prompt) is enough.
• The disclosed unchanged-fixture failures in the local suite (issue 141).

Parent correction: the saved Codex stdin prompts exist as codex-verify4-prompt.md and codex-maintain-verify-prompt.md. They were omitted from the review pack. Their intended inputs explicitly invoke the registered project skill; they are not a captured stdin stream.

The apparent PASS text in Claude maintain-bug event13 is inside the native loaded skill body, not a new tool result. Actual later helper results report350fail.

The next assessment is prepared with all105 hash-verified evidence entries, saved prompts, the full patch and losslessly formatted logs. It needs Read/Grep/Glob only; no shell replays. The completed independent CLI checks carry as evidence. The previous two incomplete reviews are not passing verdicts. No model-sheet changes, merge, release or rollout occurred.

[arjitj2]

Independent Opus5.5/high read-only Shipping review completed with FAIL for one undocumented upstream adaptation.

Verdict: FAIL for PR165 at head a57749a6953240d97afb8e8a17045573c52b7086 against base a16c327475d9ce51c5e89741e4848d3baf21013c.

The live-test evidence holds up, and no further native run is required to fix the blocker. What blocks landing is one undocumented change from upstream. If it ships as is, the immutable v1.17.6 tag and its tag-pinned UPSTREAM.md would permanently miss it.

Landing blocker

Upstream's manual-only flag was silently removed from both formal skills.

• Upstream marks both new skills manual-only: upstream.diff:268 and :370 add disable-model-invocation: true.
• The port drops that line (base-to-head.diff:259-262, :368-371) and adds no Codex agents/openai.yaml that would turn off implicit use.
• As a result, both generators can be picked automatically in Claude Code and Codex. The descriptions include trigger phrases like "prove this invariant", so the creation skill could start writing a project skill from an ordinary request.
• There may be a good reason for the change, and the Sol review hints at it (source-review-sol.md:14):
  • Setup step 12 has to invoke the generator after an explicit yes.
  • On Claude, the flag blocks the model from loading a skill. This very run showed that when model-origin calls to manual-only skills were rejected.
  • The change also matches the port's create-verification-skill.
• The repo records every earlier invocation-flag change of this kind (UPSTREAM.md:24, :26; ledger line 104). This one appears nowhere: not in UPSTREAM.md:47, the 4382e68 or 7b353f7 ledger reasons, NOTICE.md, or CHANGELOG.md.
• Automatic selection is never tested. The retained limits say "no automatic skill selection" but do not explain why upstream's manual-only rule was dropped.

Smallest fix: a repository-only commit, with no package change, that:

• adds an UPSTREAM.md exclusion line saying the upstream disable-model-invocation: true on create-formal-verification-skill and maintain-formal-verification-skill is not applied, why, and that automatic selection is unverified;
• updates the 4382e68 and 7b353f7 ledger reasons the same way.

That needs fresh CI and a short re-review of a metadata-only diff with the package tree unchanged, but no new host runs. If you would rather restore manual-only, that changes the package and needs native retests in both hosts, including how Setup's yes path invokes the generator.

What I confirmed (by reading files only)

• Diff: all 16 files read. The README, provider-dispatch.md and types.ts are not in the diff.
  • Ketchup and Sharpen: match upstream.
  • Setup: steps 11–12 run only after step 10 succeeds, need an explicit yes, skip duplicates, and are skipped on routing-only requests (the skip range is now 2–12).
  • Help: Cursor-specific Claude install text was correctly left out.
• Version: Cursor 0.15.25 → 0.15.28 is patch-only, so 1.17.5 → 1.17.6 is correct. CI confirms the version matches across all four places.
• Provenance: the ten ledger decisions in the worktree match the diff, and reviewed_through is d457567. 88d4751 and eb4db2b are correctly absent (issue168).
• CI (ci-final-a57749a.log): ran on the merge ref eefde09 ("Merge a57749a… into a16c327…").
  • Bun: 993 pass, 5 skip, 0 fail.
  • maintenance 27 OK, session-start hook 8 OK, docs 16 OK.
  • Ledger: 62 entries OK. All static invariants OK.
  • The line CHANGELOG.md:3… sits between two check-docs: ok lines and looks like expected output from a deliberately broken docs-check test fixture, not a failure.
• Codex native logs:
  • codex-native-skills-after.json: verify-token-parser is registered at repo scope.
  • verify4: 380 pass / 65 fail (AAA!) / 380 / 380.
  • maintain1: ran the old 380-case baseline before proposing changes, read both commit diffs, and classified them as no-effect formatting plus an intended change.
  • maintain-verify: 1381 / 175 fail / 1381 / 1381.
  • maintain-bug: 175 of 1381 fail, names 243746b as the introducing commit, and separately replays parse_token('AAA!') against the real code (exit 1).
  • setup-guards: all 7 supplied cases decided correctly.
  • dialogue: all 30 A-IDs kept; Sharpen computed 29/4 and matched the control; Help names both skills; TLA+ guidance kept separate from the parser fallback.
• Claude native logs:
  • verify3, maintain-verify and maintain-bug show the Skill call, the "Launching skill" result and the loaded skill text. Results: 377/65/377/377 and 2757/350/2757/2757, with no denials.
  • maintain-bug: line 13 is the loaded skill text, which includes the parent's checkpoint note. The actual tool result on line 17 is FAIL: 350 of 2757.
  • maintain1: shows the denied …; echo "exit=$?" command, then a rerun with a simpler command. That is the disclosed stop-on-denial violation.
  • Ketchup, Sharpen and Help manual2: all three were registered as slash commands and invoked with a leading /pstack:, with no denials. I could not find the skill's text in the Ketchup log. What links the reply to the skill is wording the prompt never used, such as "No screenshot yet" and "riskiest first".

Notes (not blockers)

1. Codex load evidence is indirect. It consists of registration, the saved intended prompts that use $verify-token-parser (not a captured input stream), and real executions. One sign is strong: in maintain-verify, Codex wrote "your command list without -B". -B appears only in the updated registered skill text, not in the prompt, so that text was in context. verify4 has no such sign.
2. The parent's prompts dictated the commands in every verify phase. The skills' own steps (use -B, compare copies first) were overridden. So "follow it as the next agent would" is only partly shown, consistent with the disclosed supervised multi-phase generation.
3. The "Formal help" recipe is only partly covered. Neither Help reply mentions the two Setup offers (Setup was tested separately). The branch where covered code changed after the sync commit was not tested.
4. Ketchup format: Codex repeated the shared recommendation on every item instead of stating it once. Claude renamed the A labels.
5. Maintenance is stricter than upstream. It drops upstream's "unless the user asks" product-edit option. This is documented as verification-only maintenance.
6. Possible regression guard: a static check that Setup's generators stay model-invocable.

The required disclosed limits all still apply and must stay in the record:

• supervised generation, with parent staging and registration;
• bounded Python testing, not proof, and no TLA+ engine run;
• Setup tested only on supplied states, with no full yes path, new probes or persistence;
• steps 1–10 unchanged and not rerun;
• no automatic discovery and no guarantee of universal policy compliance or OS confinement;
• the local Node 24 suite failed (994 pass / 4 fail / 3 errors, issue141, cause unproven);
• the earlier manual-only invocation errors, interruptions, DNS failures, launcher and cache denials, and Claude's stop-on-denial deviations.

Who did what

• This review: I only read the retained files with Read, Grep and Glob. I ran no commands, scripts or replays and wrote nothing.
• Prior Opus run (shipping2-verdict.md): the four real command-line replays are its results, which I am attributing to it, not repeating. Codex: 1381 pass (exit 0) on the pre-bug file, 175 fail (exit 1) on the bug file. Claude: 2757 pass (exit 0) and 350 fail (exit 1).
• First Shipping attempt (shipping-verdict.md): package tree 26be5ce being identical at 585d2dd and a57749a, and only CHANGELOG.md, UPSTREAM.md and the ledger changing between them, come from that attempt's Git commands. I could not run Git to recheck them.

Before landing

Once the blocker is fixed, landing still needs: a fresh check of head and base, green CI on the new head, both queue fields null, and a recheck of the patch ID (the current 3f194b738ef6725d598d87fd3937df39fa0f3c5f will change with the documentation commit).

Parent disposition: accept the blocker. A metadata-only correction now documents omission of both upstream manual-only flags and why parent workflows need model invocation. The two ledger reasons explicitly retain automatic-selection limits. Package contents and README.md remain unchanged. Fresh CI and an exact-head correction review are required before landing.

[arjitj2]

Independent Opus5.5/high exact-head correction review: PASS+NOTES.

Verdict: PASS+NOTES. This covers PR165 at head 2c7c6e2fbb65ffdad61c4b156a4241b7433ec73f against patch base a16c327475d9ce51c5e89741e4848d3baf21013c. It includes the documentation correction and the unchanged-package assessment carried over from the earlier review.

Landing still needs three things from you, and I am not claiming any of them is done: fresh full CI for 2c7c6e2 passing, a fresh queue/head/base check, and a new patch-ID check.

The correction fixes the earlier FAIL

The earlier independent review (shipping-readonly-verdict.md, Opus, read-only) failed only because upstream's disable-model-invocation: true was dropped from both formal skills without being recorded. The new commit records it properly.

• What changed: invocation-docfix.diff touches only UPSTREAM.md (+2 lines) and maintenance/upstream-ledger.json (2 reasons replaced), for four insertions and two deletions. No package path changed.
• UPSTREAM.md:49 sits under ## Upstream-only exclusions, which AGENTS.md assigns as the owner of exclusions. It says:
  • Both flags, from 4382e68 and 7b353f7, are not applied to create-formal-verification-skill or maintain-formal-verification-skill. Upstream added them at upstream.diff:268 and :370.
  • Why: Setup must invoke formal creation after successful smoke and explicit consent, and the flag blocks that model-origin Skill call in Claude Code. This matches the existing regular verification pair.
  • Automatic selection in either host remains unverified.
• Ledger reasons (lines 440 and 488): both now record the exclusion, its reason, the match with the regular pair, and the automatic-selection limit. The 4382e68 reason names the Setup smoke and explicit-consent path.
• The claims match the files:
  • Neither formal SKILL.md has the flag (head frontmatter, lines 1–4; base-to-head.diff:259-262 and :368-371).
  • Neither formal skill has an agents/openai.yaml.
  • create-verification-skill and maintain-verification-skill have neither the flag nor an openai.yaml, so "matching the regular pair" is accurate.
  • setup-pstack/SKILL.md:188-192 runs step 12 only after step 10 succeeds and invokes the generator only on an explicit yes. Neither offer runs on routing-only, failed-probe, declined or failed-smoke paths.
  • The Claude Code blocking reason matches the existing precedent at UPSTREAM.md:24 (73f8be4). The earlier review also attributes it to model-origin rejections seen in this run.
• The refreshed diff includes the fix: base-to-head.diff still lists the same 16 files and its UPSTREAM.md hunk ends at blob 2673f37. That is the same post-image as the docfix diff, and the hunk contains the new paragraph (line 120).
• Choosing to document instead of restoring manual-only is acceptable. It is a deliberate, compatible port adaptation with recorded precedent, and it needs no new native run, as the earlier review said.

Notes (not blockers)

1. The reason given for maintain-formal-verification-skill is weaker. No packaged workflow invokes it from the model; Setup offers only creation and Help only links it. Its stated reason is "parent verification workflows" plus consistency with the regular pair. That is adequate, just less concrete than the Setup reason for creation.
2. NOTICE.md and CHANGELOG.md do not mention the flag exclusion. That is consistent with AGENTS.md's single-owner rule (UPSTREAM.md owns exclusions, the ledger owns decisions), and the earlier review's smallest fix did not ask for it.
3. No static check was added to keep Setup's generators model-invocable. This was optional in the earlier review and is still open.
4. Codex has no implicit-invocation control for the formal skills. That is the intended result here and is disclosed as untested automatic selection.
5. The new text is a paragraph, not a bullet like the 73f8be4 entry. This is style only.

Unchanged-package assessment, carried over with attribution

From shipping-readonly-verdict.md (independent read-only review of a57749a):

• Native evidence in both hosts holds, and no extra native run is needed.
• Version 0.15.25 → 0.15.28 maps correctly to 1.17.5 → 1.17.6.
• The ten ledger decisions are right, with reviewed_through at d457567.
• CI on merge ref eefde09 was green for a57749a. That result does not carry over to 2c7c6e2.

From earlier runs, attributed to them:

• The four real CLI replays come from shipping2-verdict.md, not from this review or the read-only one.
• Package tree 26be5ce matching at 585d2dd and a57749a comes from the Git commands in shipping-verdict.md.

From your Git inspection, which I could not recheck without Git:

• All 240 packaged files are unchanged, the package tree is 26be5ce9990e8422b7b67b6fe683291e843359a5 (same as host-tested 585d2dd), and README is unchanged.
• invocation-docfix-proof.json agrees, and nothing I read contradicts it.
• Local checks pass: check-docs, ledger 62, maintenance 27, docs 16.

The earlier FAIL and the two no-verdicts remain as they were. This PASS covers only the new candidate.

Limits that stay in the record

• Codex load evidence is indirect: registration, saved intended prompts rather than captured stdin, and real executions.
• Command phases were supervised, with the parent doing staging and registration.
• Real-code testing was bounded Python, not proof, and no TLA+ engine ran.
• Setup was tested only on supplied guard states, with no full yes path, new probes or persistence.
• The Help "Formal help" recipe is only partly covered.
• No automatic selection was tested in either host.
• The local Node 24 failures are unchanged (994 pass / 4 fail / 3 errors, issue141).
• The earlier denials, interruptions and Claude stop-on-denial deviations stay recorded.
• No OS confinement is claimed.
• Cursor 0.15.34 is separate, under issue168.

How this review was done

I only read files with Read, Grep and Glob. I ran no commands, Git, replays, installs or providers, and I wrote nothing. Plan-mode output (the plan file and ExitPlanMode) was not possible under this lane's tool narrowing, so this message is the final output. No denial occurred. You own publishing this verdict and the guarded merge, release and rollout.

Parent landing checks: fresh full CI40543250946 has now passed for 2c7c6e2fbb65ffdad61c4b156a4241b7433ec73f. All240 package files remain unchanged from the tested candidate. The new patch ID is captured; head/base and both queue fields will be rechecked immediately before the expected-head guarded merge.