Add the iteration request shape and release 4.4.0

CHANGELOG.md

@@ -2,6 +2,25 @@
 
 All notable changes to SkipHow 2.x and later appear in this file. Earlier release notes remain available on [GitHub Releases](https://github.com/mzored/SkipHow/releases).
 
+## 4.4.0 (2026-09-06)
+
+The kernel gains one request shape it had no name for: an iteration, a change to something the owner will look at before deciding what comes next. Its completion is the shown result, not the integrated one. Installing or upgrading SkipHow still grants no authority.
+
+### Changed
+
+- A request to change a screen, copy, an email, a landing page, or a document that the owner has said they will look at, or is sending as a series of small changes, is an iteration. The run makes the change, shows it where the owner can see it, runs the check that covers what it touched, and stops; the kernel states that this stop is a completed turn rather than unfinished work, so a host that pushes against ending a turn on a pause does not push the run on to integration. The owner's acceptance starts the delivery, and only then do tests, review, tracking, commits, push, and integration follow under the existing grants. Where a visible reversible change could be read either way the run shows it and says what delivery would add; a request that plainly asks for a fix keeps delivering. The shape appears in the skill description and the request-shape list, and the rule lives in the grant section beside the sentence that carries every other change through to the authorized destination. No playbook changed.
+
+### Documentation
+
+- The owner guide names the shape, gives an example request, and adds it to the table of what a request allows. The decision history records why it is one kernel paragraph and not a separate skill, an owner-side instruction, an edit to the stop sentence, a second copy in the verification playbook, or a hook. The evidence ledger records the contract sentence and the fixture that would show it.
+- One independent Codex review round on the kernel wording returned two findings, both confirmed against the file and fixed: the deferred list named review, which contradicted the kernel's rule that every change gets a fresh review of its final state, so the shown result is now reviewed like any other final state and only the wider tests, tracking, commits, push, and integration wait for acceptance; and the recognition rule caught a request that named a destination and added that the owner would look there afterwards, so a request that names a destination or asks to ship is delivery whatever the owner looks at afterwards. Nothing was refused; the round returned no non-qualifying findings.
+
+### Compatibility and evidence
+
+This is a minor release. Within existing authority the kernel withholds one default action, integration, for a shape the owner marks by saying they will look; the same words that ended the drift before, "it is done" or "ship it", start delivery. No authority boundary, public skill name, or record format changes, and existing grants and restrictions survive the upgrade.
+
+The observed defect is the owner's account of one installed session in their own project, not a retained receipt; it proves that the shipped text lacked the shape, which is what one run can prove. The behavior of the new wording is `UNVERIFIED`; the fixture that would show it is listed in [docs/evidence.md](docs/evidence.md). On the exact 4.4.0 package, Claude Code 2.1.263 installed and uninstalled the seventeen files in an empty configuration directory; those two cells of `evals/host-smoke.json` are `PASS` with the receipt in `evals/receipts/host-validation-440-20260906/`, the Codex clean install is `UNVERIFIED` because the machine's managed source policy refuses a local marketplace, every other cell is `UNVERIFIED`, and the 4.3.0 receipts remain at their immutable source.
+
 ## 4.3.0 (2026-09-06)
 
 The always-loaded kernel regains the duties an independent audit found weakened since the 4.0 restoration: a direction rule for work that has come to wait on the owner, one point-of-use obligation before dispatching a delegate, a routing rule the model can apply without evidence it does not have, owned temporary state in the completion reconciliation, and a refusal rule that names the missing permission instead of asking the owner to choose a command. The delegation playbook states per host what delegate controls exist and what a run must verify. The evidence instrument judges receipts per claim. Installing or upgrading SkipHow still grants no authority.

README.md

@@ -37,7 +37,7 @@ This is a responsibility handoff, not a fixed development pipeline. A small requ
 | More autonomy risks losing product control | The owner still decides visible behavior, scope, cost, risk, privacy, rollout, and protected actions. |
 | Every request becomes a ceremony | Process scales with the work. Specs, tickets, TDD, worktrees, subagents, and review appear only when the request or project needs them. |
 | "Done" means the agent stopped | Completion needs fresh evidence. Anything blocked or unverified stays visible. |
-| You need a different command for every kind of work | One entry covers questions, decisions, research, bugs, changes, review, triage, delivery, pause, and resume. |
+| You need a different command for every kind of work | One entry covers questions, decisions, research, bugs, changes, iterations you want to look at first, review, triage, delivery, pause, and resume. |
 | Long or delegated work becomes your coordination job | Continuity, reconciliation, integration, and any tracking your project calls for remain engineering work for the agent. |
 | Autonomy widens side effects | Production, releases, credentials, access, material deletion, and other protected actions require an explicit grant. |
 

SECURITY.md

@@ -4,8 +4,8 @@
 
 | Version | Supported |
 | --- | --- |
-| 4.3.x | Yes |
-| 4.2.x, 4.1.x, and 4.0.x | No; upgrade to 4.3.x without changing existing authorization |
+| 4.4.x | Yes |
+| 4.3.x, 4.2.x, 4.1.x, and 4.0.x | No; upgrade to 4.4.x without changing existing authorization |
 | 3.0.x and earlier | No |
 
 Security review covers the packaged owner skill, its linked playbooks, host manifests,
@@ -15,7 +15,7 @@ services keep their own security policies.
 
 ## Package validation, 2026-09-06
 
-Version 4.3.0 is validated per capability in [`evals/host-smoke.json`](evals/host-smoke.json); Claude Code 2.1.263 clean install and uninstall, and Codex CLI 0.153.0 clean install from the approved Git source and uninstall, each carry one receipt on the exact 4.3.0 package in [`evals/receipts/host-validation-430-20260906/`](evals/receipts/host-validation-430-20260906/); every other row is `UNVERIFIED` until a receipt made on 4.3.0 is recorded, and the 4.2.0 receipts, including persistent setup, explicit fallback, and playbook load, remain at their [immutable source](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). The [dated support summary](docs/evidence.md#support-summary-as-of-2026-09-06) states what each host has shown for each package it names. The previous 4.1.1 receipts remain in `evals/receipts/host-validation-411-20260905/`; the September 5 isolated Codex diagnostics remain 4.1.0 observations, and the [September 6 diagnostics](evals/receipts/isolated-host-420-20260906/README.md) are separate 4.2.0 observations.
+Version 4.4.0 is validated per capability in [`evals/host-smoke.json`](evals/host-smoke.json); Claude Code 2.1.263 clean install and uninstall carry one receipt on the exact 4.4.0 package in [`evals/receipts/host-validation-440-20260906/`](evals/receipts/host-validation-440-20260906/), and every other row is `UNVERIFIED` until a receipt made on 4.4.0 is recorded. The 4.3.0 receipts, Claude Code 2.1.263 clean install and uninstall and Codex CLI 0.153.0 clean install from the approved Git source and uninstall, remain in [`evals/receipts/host-validation-430-20260906/`](evals/receipts/host-validation-430-20260906/) and at the [immutable 4.3.0 ledger](https://github.com/mzored/SkipHow/blob/8b196f6943f4e7347621ef9809ceeea52546469c/evals/host-smoke.json), and the 4.2.0 receipts, including persistent setup, explicit fallback, and playbook load, remain at their [immutable source](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). The [dated support summary](docs/evidence.md#support-summary-as-of-2026-09-06) states what each host has shown for each package it names. The previous 4.1.1 receipts remain in `evals/receipts/host-validation-411-20260905/`; the September 5 isolated Codex diagnostics remain 4.1.0 observations, and the [September 6 diagnostics](evals/receipts/isolated-host-420-20260906/README.md) are separate 4.2.0 observations.
 
 The historical 4.1.0 candidate passed both host schema validators. Claude Code 2.1.261
 installed all fifteen regular files byte for byte and uninstalled them in a
@@ -74,7 +74,7 @@ page under `learn.chatgpt.com`; the redirect target is the page actually read.
 | Per-agent read-only controls | Subagent frontmatter takes a `tools` allowlist, `disallowedTools`, and `permissionMode`, whose values include `plan` for read-only exploration. `permissionMode` is ignored for plugin subagents and overridden by a parent in bypass, accept-edits, or auto mode, so only a `tools` allowlist checked to have applied is a read-only boundary. | [Subagents](https://code.claude.com/docs/en/sub-agents) | 2026-09-06 | none | `UNVERIFIED` (documented) |
 | Worktree isolation | `isolation: worktree` runs a subagent in a temporary git worktree. | [Subagents](https://code.claude.com/docs/en/sub-agents) | 2026-09-04 | none | `UNVERIFIED` (documented) |
 | Plugin validation | Manifest `.claude-plugin/plugin.json`; `claude plugin validate <path>` validates it and `--strict` treats warnings as errors. | [Plugins](https://code.claude.com/docs/en/plugins) | 2026-09-04 | 2.1.259 | `PASS` (`scripts/check_hosts.py`, 2026-09-04) |
-| Clean installation | `claude plugin marketplace add`, `claude plugin install --scope user`, `claude plugin uninstall --scope user`; `CLAUDE_CONFIG_DIR` points the host at a scratch home. | [Discover plugins](https://code.claude.com/docs/en/discover-plugins), [Skills](https://code.claude.com/docs/en/skills) | 2026-09-06 | 2.1.263 | `PASS` (`scripts/check_hosts.py --smoke`: clean home, install, 17 regular files matching exact 4.3.0 payload `a0901a39…`, uninstall verified; [ledger](evals/host-smoke.json)) |
+| Clean installation | `claude plugin marketplace add`, `claude plugin install --scope user`, `claude plugin uninstall --scope user`; `CLAUDE_CONFIG_DIR` points the host at a scratch home. | [Discover plugins](https://code.claude.com/docs/en/discover-plugins), [Skills](https://code.claude.com/docs/en/skills) | 2026-09-06 | 2.1.263 | `PASS` (`scripts/check_hosts.py --smoke`: clean home, install, 17 regular files matching exact 4.4.0 payload `5163a3c6…`, uninstall verified; [ledger](evals/host-smoke.json)) |
 
 ### Codex CLI
 
@@ -85,7 +85,7 @@ page under `learn.chatgpt.com`; the redirect target is the page actually read.
 | Per-agent read-only controls | Custom agents are TOML files in the Codex home `agents/` directory or the project `.codex/agents/` and the page says they may set `sandbox_mode` per agent, naming a read-only agent as the example, and that subagents otherwise inherit the parent's sandbox policy and permission mode. In the `rust-v0.153.0` source, `core/src/agent/role.rs` applies developer instructions, model, reasoning effort and summary, verbosity, personality, service tier, features, and skills, and not `sandbox_mode`; `role_tests.rs` asserts a role cannot expand the parent's permissions. | [Subagents](https://developers.openai.com/codex/subagents), [openai/codex `role.rs`](https://github.com/openai/codex/blob/rust-v0.153.0/codex-rs/core/src/agent/role.rs) | 2026-09-06 | none | `UNVERIFIED` (documented; not applied in source as of 2026-09-06, so a subagent inherits the parent's sandbox) |
 | Worktree isolation | The subagents page documents no worktree or separate-checkout option for a subagent, and `spawn_agent` takes an agent type, the message, and where exposed `model` and `reasoning_effort`, with no working directory, worktree, or sandbox parameter. | [Subagents](https://developers.openai.com/codex/subagents), [openai/codex `multi_agents_spec.rs`](https://github.com/openai/codex/blob/rust-v0.153.0/codex-rs/core/src/tools/handlers/multi_agents_spec.rs) | 2026-09-06 | none | `UNVERIFIED` (no per-delegate directory or sandbox exists in this version; a separate-checkout writer lane is untried) |
 | Plugin validation | Manifest `.codex-plugin/plugin.json`. There is no `codex plugin validate` subcommand; validation runs the `validate_plugin.py` script shipped with the plugin-creator system skill in the Codex repository, which CI checks out at a pinned commit. | [openai/codex plugin-creator scripts](https://github.com/openai/codex/tree/333beecd41281b1350688b417a2f20c66e2a743e/codex-rs/skills/src/assets/samples/plugin-creator/scripts) | 2026-09-04 | none locally | `UNVERIFIED` locally (validator not on this machine); required to `PASS` in CI |
-| Clean installation | `codex plugin marketplace add`, `codex plugin add`, `codex plugin list --json`, `codex plugin remove` exist in `codex plugin --help`; `CODEX_HOME` relocates the host home. The plugins page documents the plugin browser and uninstall but none of these commands. | [Plugins](https://developers.openai.com/codex/plugins), `codex plugin --help` 0.153.0 | 2026-09-06 | 0.153.0 | `PASS` for exact 4.3.0 from the approved Git source in an isolated home: 17 regular files byte-identical to the committed package, then removed ([ledger](evals/host-smoke.json)); the release runner's local marketplace is still refused by the managed `/etc/codex/requirements.toml` source policy |
+| Clean installation | `codex plugin marketplace add`, `codex plugin add`, `codex plugin list --json`, `codex plugin remove` exist in `codex plugin --help`; `CODEX_HOME` relocates the host home. The plugins page documents the plugin browser and uninstall but none of these commands. | [Plugins](https://developers.openai.com/codex/plugins), `codex plugin --help` 0.153.0 | 2026-09-06 | 0.153.0 | `UNVERIFIED` for exact 4.4.0: the release runner's local marketplace is refused by the managed `/etc/codex/requirements.toml` source policy; exact 4.3.0 was installed from the approved Git source in an isolated home, 17 regular files byte-identical to the committed package, then removed ([4.3.0 ledger](https://github.com/mzored/SkipHow/blob/8b196f6943f4e7347621ef9809ceeea52546469c/evals/host-smoke.json)) |
 
 ### Codex surfaces
 

VERSION

@@ -1 +1 @@
-4.3.0
+4.4.0