Skip to content

Release SkipHow 4.8.0 custody of shared state - #119

Merged
mzored merged 3 commits into
mainfrom
release/480-custody
Sep 10, 2026
Merged

Release SkipHow 4.8.0 custody of shared state#119
mzored merged 3 commits into
mainfrom
release/480-custody

Conversation

@mzored

@mzored mzored commented Sep 10, 2026

Copy link
Copy Markdown
Owner

Summary

SkipHow 4.8.0. The kernel carried five prohibitions on a checkout, branch, running service, or uncommitted change the run did not create, and no counterpart duty, so "that is not my work, I will not touch it, and I do not touch uncommitted files either" was a compliant answer. Isolation protects the keyboard, not the responsibility.

Three sentences in the always-loaded kernel:

  • Shared state is still never overwritten, reset, published, deleted, or quietly absorbed, and it is no longer left unaccounted either. Where the work brings a run up against material shared state, the report says once what it appears to be, what can be read claiming it, and the one action that would settle it. Naming it is not authority to act on it: that action is taken only where the current request and the rules governing that act already allow it, and recommended otherwise while the work carries on.
  • No technical choice reaches the owner, as a question, as a menu of options, or as permission to proceed on engineering grounds. A reversible technical uncertainty is settled by taking the option the agent would defend. What reaches the owner instead is a recommendation they can decline.
  • A running result shown to the owner names the branch or revision it serves and the address serving it.

The first closes a hole 2.7.0 identified and could not close: where the litter appears after a run ends, the collector has to be the next run. An iteration parked at its shown result is correctly complete for its own session, and until now no later session had a reason to mention it again.

One proposal was refused on the text. A review argued that integration and tracked-work open only when the owner asks. Neither trigger reads that way: integration opens on a state, and tracked-work already ends its trigger with a pause, resume, or session boundary that could lose work.

Verification

  • I added or updated tests when behavior changed.
  • I ran python scripts/check.py and the relevant focused checks.
  • I ran git diff --check.
  • I ran python scripts/check_hosts.py and recorded unavailable hosts as UNVERIFIED when this changes packaging.

scripts/check.py passes in full. scripts/check_hosts.py: Claude schema validation and clean Claude install PASS; the Codex validator and clean Codex install are UNVERIFIED on this machine and covered in CI.

Cross-host review is blocked, not passed: the Codex account is at its usage limit until 2026-09-15. Three independent same-host reviews ran against the candidate and raised fifteen qualifying findings, twelve distinct after overlap, every one confirmed against the files. The sharpest: the first draft settled shared state "where the current request already reaches it", a topical test looser than both the protected-action boundary and integration's removal test, which would have authorized retiring a workspace on a reconcile request the corpus already forbids, and taking a shared port from another checkout on a read-only diagnosis. The first draft also keyed the duty to state that "no open record, review, or live session claims", the undecidable shape 2.16.0 replaced with a present-state test. Two proposed corrections were refused with the reason, both recorded in the release notes. A fourth review of the corrections confirmed the repairs hold and raised six further findings, all fixed.

The resulting behavior is UNVERIFIED on both hosts. No paid experiment was run, and AGENTS.md's evidence bar for a new obligation is unmet: docs/decisions.md records the change as the owner's decision.

Notes

  • plugins/skiphow/skills/skiphow/SKILL.md: three sentences, in Decisions you own, Work you do not own and delegates, and Verification and reporting. No heading renamed, no reference file changed, no new module, gate, or persistent state.
  • evals/cases.json: naming an earlier run's branch moves from permitted to required in the candidate arms of int-002-earlier-branch-not-cleaned-under-unrelated-change; workflow-fast-fixes-hook-conflict gains the branch or revision a shown result serves, and the address where it runs at one. foreign-uncommitted-work-preserved was left alone: naming that work is already required of every arm there.
  • docs/decisions.md, docs/evidence.md, docs/outcome-contract.md, docs/guide.md, docs/prior-art.md, CHANGELOG.md, SECURITY.md, site/evidence/index.html, VERSION, both plugin manifests.

mzored and others added 3 commits September 10, 2026 04:44
The kernel carried five prohibitions on a checkout, branch, running service,
or uncommitted change the run did not create, and no counterpart duty, so
"that is not my work and I do not touch uncommitted files" was a compliant
answer. Shared state that no open record, review, or live session claims is
now named with what it appears to be and the one action that would settle it,
settled where the current request already reaches it and recommended
otherwise. Nothing new may be written, deleted, or taken over.

Two smaller rules travel with it: no technical choice reaches the owner, and a
running result shown to them names the branch or revision and address it
serves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three independent reviews found the first draft settled shared state "where
the current request already reaches it", a topical test looser than both the
protected-action boundary and integration's removal test, and keyed the duty
to state that "no open record, review, or live session claims", which
tracked-work says twice the readable signals cannot settle.

Naming is now stated not to be authority to act on it, the claim question
moved from the trigger into the content, and the duty is bounded to state the
work brings the run up against, named once. Corpus: a vacuous required event
removed, a required address softened for fixtures that serve none. Docs: a
prohibition credited to two playbooks that do not carry it, an m4 attribution
claim, a misquoted prohibition, and an index row stamped at the wrong version.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A fourth review of the corrections confirmed the three repairs hold and found
six places where the records did not follow them: the guide and the evidence
ledger restated the corrected sentence loosely, the account of what the
previous kernel already allocated was overstated, a present-state test was
credited to the wrong releases, the scored stale-branch event covered less
than its own acceptance line, and the release notes read their own
enumeration as a remainder.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mzored
mzored merged commit 60980a5 into main Sep 10, 2026
1 check passed
@mzored
mzored deleted the release/480-custody branch September 10, 2026 01:15
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