Repository navigation
chore(pin): consume core-candidate-2026.08.05.2 with ToolSpec and effect verification - #1
Merged
Merged
Conversation
…ect verification The §12 surface this product plan depends on is now complete in the pinned core. Verified end to end before pinning: verify_core_pin.py against the published release (6 artifacts, all hashes match), then the compatibility suite against the wheel installed from those verified assets — 43 passed. - The pin now covers tool_spec_v1.yaml and postcondition_contract_v1.yaml as well as the wheel. Agreeing with core about the CODE while disagreeing about what a ToolSpec is, or what an effect status means, is exactly the drift a pin exists to prevent. - test_effect_verification_is_honestly_absent did its job and is replaced by positive contract tests rather than deleted: the five statuses, the non-terminality of both unknowns, declared-delta-only comparison, and the rule that an unreadable object is never reported as a mismatch. Those are the properties this product's incident handling relies on, so a future core that changed them must fail here. - record_effect is required on both clients; sync/async drift would force callers into a per-client branch the product plan forbids. Still a prerelease, and the README says why: no external review has run against this build, Gate B is not closed, and a tool without a declared postcondition reader reports EFFECT_UNSUPPORTED — recorded so the absence is visible, not a verified effect.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The REMORA surface this product plan (§12) depends on is now complete in the pinned core, so the pin moves from
core-candidate-2026.08.05tocore-candidate-2026.08.05.2(716f6bd, built from a clean checkout).Verified before pinning, not after
The compatibility suite ran against the wheel installed from the verified assets, not from a convenient local copy.
What the pin now covers
tool_spec_v1.yamlandpostcondition_contract_v1.yamljoin the wheel, OpenAPI export, SDK snapshot and lifecycle schema. Agreeing with core about the code while disagreeing about what a ToolSpec is, or what an effect status means, is exactly the drift a pin exists to prevent.The absence test did its job
test_effect_verification_is_honestly_absentexisted so the FT-04 gap could not drift into place unnoticed. It fired, and it is replaced by positive contract tests rather than deleted — these are the properties this product's incident handling relies on, so a future core that changed them must fail here:EFFECT_UNOBSERVABLEandEFFECT_VERIFIER_FAILEDare not terminal — if core made them terminal, this product would start closing incidents that are still openrecord_effectis now required on both clients: sync/async drift would force callers into a per-client branch the product plan forbids.Still a prerelease
No external review has run against this build and Gate B is not closed. And effect verification only covers tools that declare a postcondition reader — a tool without one reports
EFFECT_UNSUPPORTED, recorded so the absence is visible rather than assumed away. The README states both.