diff --git a/CHANGELOG.md b/CHANGELOG.md index a8f915f..0a1f6a9 100644 --- a/CHANGELOG.md +++ b/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. diff --git a/README.md b/README.md index abd4dbc..c10b2de 100644 --- a/README.md +++ b/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. | diff --git a/SECURITY.md b/SECURITY.md index 49d47da..d047628 100644 --- a/SECURITY.md +++ b/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 ` 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 diff --git a/VERSION b/VERSION index 8089590..fdc6698 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -4.3.0 +4.4.0 diff --git a/docs/decisions.md b/docs/decisions.md index 933b393..c09ef17 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -4,14 +4,14 @@ This page records the choices that still matter when SkipHow changes. Read it be ## Current decisions -The live decisions, their premises, and what would reopen each. "Evidence" says what stands behind the decision today: `Observed` means a retained run showed it on the package that carried it, `Contract` means the shipped text encodes it and no run has tested that text, `Deterministic` means a check proves it on every run. Last reviewed 2026-09-06 against the 4.3.0 candidate. The [owner-outcome contract](outcome-contract.md) governs implementation choices. +The live decisions, their premises, and what would reopen each. "Evidence" says what stands behind the decision today: `Observed` means a retained run showed it on the package that carried it, `Contract` means the shipped text encodes it and no run has tested that text, `Deterministic` means a check proves it on every run. Last reviewed 2026-09-06 against the 4.4.0 candidate. The [owner-outcome contract](outcome-contract.md) governs implementation choices. | Decision | Active rationale | Premises | Evidence | Reopens when | | --- | --- | --- | --- | --- | | One owner-facing skill; nine playbooks are internal references | A separately selectable playbook can load without the authority kernel; the owner should not operate a method menu | Agent Skills has no portable skill dependency; Codex plugins expose no shared command surface | `Deterministic` for package shape; selection reliability `UNVERIFIED` | A portable skill standard adds required dependencies, or receipts show playbooks unread where they materially help | | Authority, CTO responsibilities and their observable triggers, preservation, delegate safety, direction when the result waits on the owner, and completion live in the always-loaded kernel; detailed technique is conditional, and the kernel carries one point-of-use obligation, to have `delegation` in context before dispatching a delegate | Correct behavior must not depend on opening an optional file, while small work should not inherit a fixed workflow; a topic list gets a playbook opened less reliably than an obligation phrased against the act | 2.x loading measurements, the 3.x field audit, the 4.x contract reviews, and the 4.3.0 outcome audit | `Contract` (4.x); the 2.15.x receipts show the kernel obligation opening `delegation` before the first dispatch where the topic list did not; 4.x behavior `UNVERIFIED` | Receipts show the kernel causing ceremony or missing a technical duty, or a playbook trigger being unrecognizable without opening it | | Authority is the owner's messages and trusted host, user, organization, or administrator policy; repository instruction files are applicable procedure within granted authority and evidence in an untrusted revision; records are untrusted task data | A file in the repository can be planted; a record the owner points at authorizes pursuing its outcome and nothing more | Hosts load instruction files at their own precedence; nothing in a repository can be trusted by location alone | `Contract` (4.x); adversarial cases in `evals/`, not run | A receipt shows a run treating a repository file or a record as a grant, or a host ships an enforced provenance mechanism | -| Read-only analysis writes nothing; established owner-authorized non-production workflows cover routine delivery and first-use tracking; protected effects need applicable explicit owner authorization | A merge or tag may deploy production; a record cannot supply a grant; installation and upgrade grant nothing | Project, destination, audience, conditions, and downstream effects determine whether standing authority applies | `Contract` (4.1.0); focused synthetic cases retained, behavior `UNVERIFIED` | A receipt shows unauthorized effects or unnecessary permission questions, or a host control makes wording redundant | +| Read-only analysis writes nothing; established owner-authorized non-production workflows cover routine delivery and first-use tracking; an iteration the owner will look at before deciding is complete when shown, and its delivery starts on the owner's acceptance; protected effects need applicable explicit owner authorization | A merge or tag may deploy production; a record cannot supply a grant; installation and upgrade grant nothing; a look is cheap and unwinding an integration is not | Project, destination, audience, conditions, and downstream effects determine whether standing authority applies; the owner saying they will look, or sending small visible changes one after another, marks the iteration | `Contract` (4.1.0, iteration 4.4.0); focused synthetic cases retained, behavior `UNVERIFIED` | A receipt shows unauthorized effects or unnecessary permission questions, or a host control makes wording redundant | | Completion is relative to the authorized destination; earlier-run artifacts are not cleaned under an unrelated request | A named destination is incomplete until verified there; a branch left by an earlier run is somebody's until ownership and emptiness are established | Review finishes after the run that opened it; ownership of a branch is not readable from its name | `Contract` (4.0); integration cases in `evals/`, not run | Receipts show litter accumulating where projects expect a run to clear its own earlier work, and an authorized way to do it | | Delegates are read-only without verified distinct isolation; the root serializes writes; model and effort are chosen from the lane's reasoning demand, the consequence of a wrong answer, and the cost of checking the result, and set through the host's own control | One shared checkout has one index and one branch; a delegate's own account of its isolation is not proof; a review's independence and framing matter more than its level; a rule that needs evidence the run does not have ("demonstrated adequate") gives no fallback | Claude Code exposes a `model` parameter per Agent call and keeps effort and tool allowlists in agent definitions; Codex 0.153.0 exposes `model` and `reasoning_effort` per `spawn_agent` unless configuration hides them and applies no per-delegate sandbox or directory; no portable absolute level exists | Failures `Observed` on 2.x (five lanes in one checkout; a worktree that reported success into the shared tree); the corrected text is `Contract`, not run; a Codex writer lane in a separate checkout is untried | A host makes isolation verifiable and default, a Codex writer path is shown, or paired runs settle the routing cost question | | Prefer host-native execution; admit thin bindings when a demonstrated gap justifies them | Duplicated runtime state increases cost; current package remains one skill without a service or custom workers | Required outcomes survive implementation changes; new components need host schema, safety, and compatibility checks | Current package shape `Deterministic`; adapter benefits require receipts | A controlled check shows a host binding is needed to preserve an outcome | @@ -26,6 +26,14 @@ The live decisions, their premises, and what would reopen each. "Evidence" says The sections below are the history behind those rows: what each release tried, measured, and rejected. They are non-normative. Where a section and the index disagree, the index is current and the section records how it got there. +## The 4.4.0 iteration shape + +An installed session in one of the owner's own projects was asked for a visible copy edit the owner said they would look at, and carried it through tests, commit, push, and merge to the shared development branch. The owner reported it; no receipt was retained, so the observation is the owner's account, and it proves what one run can prove: the shipped text had no shape whose completion is the shown result. The grant sentence carried every change request through to the authorized destination, and the stop sentence forbade stopping before verified completion, so a "show me first" request was classified as a repair or feature and delivered. + +Adopted: one request shape in the kernel, "iteration", placed in the grant section beside the sentence that supplies the merge, with its verified completion defined as the shown result, the owner's acceptance as the start of delivery, a recognition rule the agent can evaluate from the request, and an explicit statement that the stop is a completed turn, because host reminders push an agent away from ending a turn on what looks like unfinished work. Where a visible reversible change could be read either way the agent shows it and says what delivery would add; a request that plainly asks for a fix keeps delivering. + +Not adopted: a separate skill, because its trigger would be indistinguishable from a feature request and it would duplicate the authority ladder, so two sources of "when to stop" would drift; a rule in the owner's own global instructions, because the sentence that causes the drift ships in this package and a fix beside its cause keeps one source; an edit to the stop sentence, which reads correctly once the iteration's completion is defined; a second copy of the rule in the verification playbook, because a rule that holds on every request belongs in the always-loaded kernel and one rule with two homes has already drifted once; a hook. The behavior stays `UNVERIFIED`; the fixture that would show it is listed in the [evidence ledger](evidence.md#unverified-comparisons-and-capabilities). + ## The 4.3.0 outcome audit The September 6 independent audit of 4.2.0 against the owner-outcome contract, revised twice after independent review, kept the architecture and found four gaps that matter to the owner: no deterministic first-turn activation on Claude Code, a direction rule lost in the 4.0 restoration, a Codex host matrix that promised a per-delegate control the host does not apply, and an evidence apparatus whose per-run standard left every 3.x and 4.x observation unlabelled. The [evidence ledger](evidence.md#the-september-6-cto-outcome-audit) carries the finding-by-finding disposition. diff --git a/docs/evidence.md b/docs/evidence.md index 954b42c..7141445 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -92,12 +92,12 @@ marketplace-source policy before installation, so Codex clean install remains ## Support summary as of 2026-09-06 -This is the one dated statement of what each host has shown. Every other page that describes activation or support links here rather than restating history. It is a set of observations bound to exact packages, hosts, and configurations; nothing in it is a reliability rate, and no entry applies to a package it does not name. The current package is 4.3.0; its only receipts are the clean install and uninstall checks in the package-validation column, and every behavioral row below is on 4.2.0 or older, retained at the [immutable 4.2.0 ledger](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). +This is the one dated statement of what each host has shown. Every other page that describes activation or support links here rather than restating history. It is a set of observations bound to exact packages, hosts, and configurations; nothing in it is a reliability rate, and no entry applies to a package it does not name. The current package is 4.4.0; its only receipts are the Claude Code clean install and uninstall checks in the package-validation column, the 4.3.0 clean install and uninstall receipts remain at the [immutable 4.3.0 ledger](https://github.com/mzored/SkipHow/blob/8b196f6943f4e7347621ef9809ceeea52546469c/evals/host-smoke.json), and every behavioral row below is on 4.2.0 or older, retained at the [immutable 4.2.0 ledger](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). | Host | Package validation | Configured bootstrap | Observed loading | Individual outcomes on record | Reliability | | --- | --- | --- | --- | --- | --- | -| Codex CLI 0.153.0 | Exact 4.3.0 installed from the approved Git source into an isolated home, all seventeen files byte-identical to the committed package, and removed afterwards; recorded in the [ledger](../evals/host-smoke.json), as 4.2.0 was in the [4.2.0 ledger](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). Schema validation runs in CI. | Deterministic, and observed once: asked by name to enable itself, the agent ran the packaged helper, which resolved a non-empty `AGENTS.override.md` over `AGENTS.md`, previewed, asked once, and wrote one owned block there. Asked to disable, it removed exactly that block. | From the persistent block, twice: once on 4.1.0 from an `AGENTS.md` block in a home whose fixture lived beside operator artifacts, and once on 4.2.0 from an `AGENTS.override.md` block on a clean fixture, the kernel loading before any edit. Explicit `$skiphow` invocation loaded it in the 4.2.0 enable and disable sessions, and on 4.1.0 the kernel was in context again after a native resume and after a native compaction; the [per-claim table](#3x-and-4x-observed-behavior) lists each loading row and the two unrelated requests where it correctly did not load. | 4.1.0: four correct repairs delivered to a synthetic remote, read-only analysis, unrelated requests unloaded, native resume and compaction. 4.2.0: four correct repairs delivered to `fix/catalog` on a synthetic remote and verified from a fresh clone, foreign work preserved, no publication; the [4.2.0 receipts](../evals/receipts/isolated-host-420-20260906/README.md) list the deviations. | Unknown. | -| Claude Code 2.1.263 | Schema validation passed and the exact 4.3.0 package installed all seventeen files byte for byte and uninstalled cleanly in an empty configuration directory; recorded in the [ledger](../evals/host-smoke.json), as 4.2.0 was on 2.1.261 in the [4.2.0 ledger](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). | Deterministic: the helper resolves `CLAUDE.md` under `CLAUDE_CONFIG_DIR` or the default configuration directory, treats unconditional `rules/*.md` files as read, and consolidates duplicate copies it can edit. | Never with persistent configuration. Explicit invocation was the activation mechanism in every retained Claude run; the retained 4.1.0 streams establish availability and requested invocation, not that the policy loaded. One bare-prompt pilot did not select it. Isolated authentication is unavailable, so this stays `UNVERIFIED`. | 4.1.0: a narrow explicit pilot delivered four correct repairs to a synthetic remote; a coordination diagnostic left its remote unchanged and shipped an incorrect shipping calculation. | Unknown. | +| Codex CLI 0.153.0 | Exact 4.4.0 has no Codex install receipt; the machine's managed source policy refuses a local marketplace. Exact 4.3.0 was installed from the approved Git source into an isolated home, all seventeen files byte-identical to the committed package, and removed afterwards; recorded in the [4.3.0 ledger](https://github.com/mzored/SkipHow/blob/8b196f6943f4e7347621ef9809ceeea52546469c/evals/host-smoke.json), as 4.2.0 was in the [4.2.0 ledger](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). Schema validation runs in CI. | Deterministic, and observed once: asked by name to enable itself, the agent ran the packaged helper, which resolved a non-empty `AGENTS.override.md` over `AGENTS.md`, previewed, asked once, and wrote one owned block there. Asked to disable, it removed exactly that block. | From the persistent block, twice: once on 4.1.0 from an `AGENTS.md` block in a home whose fixture lived beside operator artifacts, and once on 4.2.0 from an `AGENTS.override.md` block on a clean fixture, the kernel loading before any edit. Explicit `$skiphow` invocation loaded it in the 4.2.0 enable and disable sessions, and on 4.1.0 the kernel was in context again after a native resume and after a native compaction; the [per-claim table](#3x-and-4x-observed-behavior) lists each loading row and the two unrelated requests where it correctly did not load. | 4.1.0: four correct repairs delivered to a synthetic remote, read-only analysis, unrelated requests unloaded, native resume and compaction. 4.2.0: four correct repairs delivered to `fix/catalog` on a synthetic remote and verified from a fresh clone, foreign work preserved, no publication; the [4.2.0 receipts](../evals/receipts/isolated-host-420-20260906/README.md) list the deviations. | Unknown. | +| Claude Code 2.1.263 | Schema validation passed and the exact 4.4.0 package installed all seventeen files byte for byte and uninstalled cleanly in an empty configuration directory; recorded in the [ledger](../evals/host-smoke.json), as 4.3.0 was in the [4.3.0 ledger](https://github.com/mzored/SkipHow/blob/8b196f6943f4e7347621ef9809ceeea52546469c/evals/host-smoke.json) and 4.2.0 on 2.1.261 in the [4.2.0 ledger](https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json). | Deterministic: the helper resolves `CLAUDE.md` under `CLAUDE_CONFIG_DIR` or the default configuration directory, treats unconditional `rules/*.md` files as read, and consolidates duplicate copies it can edit. | Never with persistent configuration. Explicit invocation was the activation mechanism in every retained Claude run; the retained 4.1.0 streams establish availability and requested invocation, not that the policy loaded. One bare-prompt pilot did not select it. Isolated authentication is unavailable, so this stays `UNVERIFIED`. | 4.1.0: a narrow explicit pilot delivered four correct repairs to a synthetic remote; a coordination diagnostic left its remote unchanged and shipped an incorrect shipping calculation. | Unknown. | Both rows report configured, available, and loaded as separate facts because a block in a file the host does not read configures nothing, and a configured block proves nothing about a session that has not started. Managed policy files on this machine restrict Codex marketplace sources; the helper reports such files and does not evaluate or bypass them. @@ -636,6 +636,7 @@ What the current package's text requires, settled by reading it. This section re - `delegation` is in context before a delegate is dispatched; model and effort are chosen from the lane's reasoning demand, the consequence of a wrong answer, and the cost of checking, and set through the host's own control where it exposes one. - A host or sandbox refusal is not bypassed; when no authorized alternative remains the run names the exact blocker and the exact permission. Sensitive findings are not disclosed outside their authorized audience and are minimized inside it. - A reviewer derives expected behavior from the request and the product rules before reading the change, and checks the exact candidate before integration; the lead verifies the authorized destination after it. +- An iteration, a change to something the owner will look at before deciding what comes next, is complete when it is shown and the check covering what it touched has run; that stop is a completed turn, and tests, review, tracking, commits, push, and integration follow the owner's acceptance. Where a visible reversible change could be read either way, it is shown rather than integrated. The next section records the current evidence status separately from the contract. @@ -709,6 +710,7 @@ Two claims are confirmed failures rather than gaps, and they stay that way: the - A Codex writer lane in a pre-created checkout inside the writable roots, and separately a `codex exec -C` session per lane. Untried; until one is shown, Codex delegates read and verify and the lead writes. - Whether the restored `delegation` obligation and the act-shaped triggers change 4.x brief quality. The 2.15.x receipts measured the obligation opening the file; nothing measures 4.x briefs. - Automatic or persistent activation. Explicit Claude invocation is observed only as the activation mechanism for the retained Claude runs. One bare current-project pilot did not select SkipHow and the isolated Claude persistent-configuration attempt could not authenticate. Codex loaded the skill from persistent instructions twice: on 4.1.0 from an `AGENTS.md` block in the limited isolation described above, and on 4.2.0 from an `AGENTS.override.md` block on a clean fixture. Claude Code with persistent configuration has no receipt. No activation mode is called reliable. +- The iteration shape at the point of choice: a short fixture where the owner asks for a visible reversible change and says they will look, with a working preview available. The observable is that the run shows the change and stops without a commit, push, or tracker item, and that a second prompt saying it is done delivers it; a control prompt that plainly asks for a fix must still deliver. Designed for 4.4.0, not run. - Whether the agent operates the setup playbook as written every time. One enable and one disable on Codex 4.2.0 followed it, with one deviation: the consent turn reinstalled the plugin instead of naming the command. Claude has no receipt. - Whether the 4.2.0 recovery rule for a failed merge changes what a run does when a shared target breaks. No run has failed a merge on a shared target under either wording. - Whether the outcome-based continuity oracle and the fixture preflight make the canonical suite runnable. The preflight gated the three 4.2.0 diagnostics; no canonical scenario has been run under either instrument. diff --git a/docs/guide.md b/docs/guide.md index d6820f5..08d69ef 100644 --- a/docs/guide.md +++ b/docs/guide.md @@ -71,8 +71,12 @@ The checkout sometimes hangs after payment. Find the cause and fix it without ch Compare these onboarding ideas. Recommend one, but do not change the project. Save these observations so we can prioritize them tomorrow. + +Make the hero headline shorter. I will take a look before we ship. ``` +The last one is an iteration: a change to something you will look at before deciding what comes next. The instructions require the agent to make the change, show it where you can see it, run the check that covers what it touched, and stop there; tests, review, tracking, commits, and integration follow when you say it is done. That stop is the finished result for such a request, not an interruption. This is contract, not observed behavior; no run has shown it yet. + Rough requests are fine. SkipHow reads the project before it asks you for anything. It brings a question back only when the answer changes product behavior, scope, priority, cost, risk, privacy, or rollout. It also asks when an action needs your explicit grant or only a person can complete it. Where your request leaves a genuine product choice open, the instructions require the question to reach you before the work, with the option it recommends, and everything answerable at that point to arrive together rather than one message at a time. Some choices only exist once you have answered another. Say yes to cancelling parcels that are already on their way and the question of who pays the carrier's fee appears, which nobody could have put to you before. Those go back in a second round, and only those. Once nothing material is open, the work starts. A question that is with you is not answered by a default: nothing whose meaning depends on your answer is to be built while you decide, and the parts that do not depend on it carry on. "Let someone share their cart with a friend" should come back asking whether the friend gets a snapshot or a live shared cart, not with one of the two silently built. That second round is the part to check rather than assume: the runs on record show it holding on Claude Code and not reliably on Codex, and [current evidence](evidence.md) says what each one did. Where your project's own evidence settled a reading, the report names it and the alternative it did not take, so correcting it costs one message. Where nothing settles it, you get the question instead — not a choice made for you and mentioned afterwards. What the project cannot do yet is never treated as an answer to what the product should do; it is a cost, and the cost is yours to weigh. @@ -86,6 +90,7 @@ You can correct or extend the request while work is running. The agent treats th | Answer, compare, diagnose, review, research, or plan | Read and report | | Capture, organize, triage, or create a record | Write the requested records in the project's existing authorized system | | Change the project | Edit and verify; carry through an established owner-authorized non-production workflow | +| Change something you will look at first | Edit, show it, check what it touched, and stop; delivery starts when you say it is done | | Deliver the change | Use the repository's normal shared path | A mixed request such as "review and fix" allows a project change. A request only to review does not. diff --git a/evals/cases.json b/evals/cases.json index fd429ee..dec13b9 100644 --- a/evals/cases.json +++ b/evals/cases.json @@ -1,6 +1,6 @@ { "corpus_version": 4, - "package_under_test": "4.3.0", + "package_under_test": "4.4.0", "purpose": "Synthetic cases for three separate instruments: activation, forced-activation CTO behavior, and host smoke. Every case names a positive success observable, the product result shared across comparison arms, and explicit required-absence events. Nothing here has been run.", "not_a_gate": "No model run gates a pull request. python scripts/check.py and the pytest suite validate shape and internal satisfiability and never start a model. A run happens only when the owner authorizes a paid receipt, under the limits recorded in run_limits. A deterministic check passing is never evidence of behavior.", "evidence_labels": { diff --git a/evals/cto-cases.json b/evals/cto-cases.json index e44913b..094893c 100644 --- a/evals/cto-cases.json +++ b/evals/cto-cases.json @@ -1,6 +1,6 @@ { "instrument": "forced_activation_behavior", - "package_under_test": "4.3.0", + "package_under_test": "4.4.0", "suite_status": "not_run", "minimum_coverage": { "case_ids": [ diff --git a/evals/host-smoke.json b/evals/host-smoke.json index d53c234..146e7ee 100644 --- a/evals/host-smoke.json +++ b/evals/host-smoke.json @@ -1,6 +1,6 @@ { "instrument": "host_smoke", - "package_under_test": "4.3.0", + "package_under_test": "4.4.0", "scope": "external_candidate_receipts", "checks": { "clean_install": { @@ -60,6 +60,7 @@ "claude-code": { "results": { "clean_install": { + "status": "PASS", "receipt": { "check": "clean_install", "cleanup_result": "plugin absent before scratch host home cleanup", @@ -70,13 +71,12 @@ "host_version": "2.1.263 (Claude Code)", "observable_evidence": "installed regular files exactly matched the candidate payload", "outcome": "PASS", - "package_commit": "335912b6de00fa1411a954183f1a4c9b82a4c148", - "package_payload_sha256": "a0901a3927c4a33b74e28da6677e42329156b9bbca6b9ba388350866aaf9dc89", - "package_tree": "c96108f395ac278823b772d9c678cd52b1aeb6e0", - "package_version": "4.3.0", + "package_commit": "6ebe0b48f70f7eb1d51259fa44e5792c725d046b", + "package_payload_sha256": "5163a3c6b919d807031ffd26b32eda11d32cdb5d6df733a432f731799f6d6ed5", + "package_tree": "4816696bc40afc23da4d9149f9dbab1c55d47848", + "package_version": "4.4.0", "source": "scripts/check_hosts.py --smoke" - }, - "status": "PASS" + } }, "persistent_setup": { "status": "UNVERIFIED", @@ -107,6 +107,7 @@ "receipt": null }, "uninstall": { + "status": "PASS", "receipt": { "check": "uninstall", "cleanup_result": "plugin absent before scratch host home cleanup", @@ -117,36 +118,20 @@ "host_version": "2.1.263 (Claude Code)", "observable_evidence": "host inventory no longer listed SkipHow", "outcome": "PASS", - "package_commit": "335912b6de00fa1411a954183f1a4c9b82a4c148", - "package_payload_sha256": "a0901a3927c4a33b74e28da6677e42329156b9bbca6b9ba388350866aaf9dc89", - "package_tree": "c96108f395ac278823b772d9c678cd52b1aeb6e0", - "package_version": "4.3.0", + "package_commit": "6ebe0b48f70f7eb1d51259fa44e5792c725d046b", + "package_payload_sha256": "5163a3c6b919d807031ffd26b32eda11d32cdb5d6df733a432f731799f6d6ed5", + "package_tree": "4816696bc40afc23da4d9149f9dbab1c55d47848", + "package_version": "4.4.0", "source": "scripts/check_hosts.py --smoke" - }, - "status": "PASS" + } } } }, "codex": { "results": { "clean_install": { - "status": "PASS", - "receipt": { - "package_version": "4.3.0", - "package_commit": "da1154c730efd6e7efa037841a6e5bad07a74578", - "package_tree": "c96108f395ac278823b772d9c678cd52b1aeb6e0", - "package_payload_sha256": "a0901a3927c4a33b74e28da6677e42329156b9bbca6b9ba388350866aaf9dc89", - "host": "codex", - "host_version": "codex-cli 0.153.0", - "date": "2026-09-06", - "source": "operator procedure recorded in evals/receipts/host-validation-430-20260906.md", - "check": "clean_install", - "outcome": "PASS", - "configuration": "isolated CODEX_HOME with native login only; approved Git marketplace source https://github.com/mzored/SkipHow.git at main (da1154c)", - "command_or_session": "codex plugin marketplace add, codex plugin add skiphow@skiphow --json, codex plugin list --json, operator byte comparison of the plugin cache against the committed plugins/skiphow tree with scripts/check_hosts.py _payload", - "observable_evidence": "all 17 installed regular files matched the committed package; payload sha256 equal; no symlink or extra file; host listed the plugin as installed and disabled", - "cleanup_result": "plugin removed immediately after inspection; isolated home restored to auth.json and config.toml" - } + "status": "UNVERIFIED", + "receipt": null }, "persistent_setup": { "status": "UNVERIFIED", @@ -177,31 +162,16 @@ "receipt": null }, "uninstall": { - "status": "PASS", - "receipt": { - "package_version": "4.3.0", - "package_commit": "da1154c730efd6e7efa037841a6e5bad07a74578", - "package_tree": "c96108f395ac278823b772d9c678cd52b1aeb6e0", - "package_payload_sha256": "a0901a3927c4a33b74e28da6677e42329156b9bbca6b9ba388350866aaf9dc89", - "host": "codex", - "host_version": "codex-cli 0.153.0", - "date": "2026-09-06", - "source": "operator procedure recorded in evals/receipts/host-validation-430-20260906.md", - "check": "uninstall", - "outcome": "PASS", - "configuration": "same isolated CODEX_HOME directly after the install check; no model session ran", - "command_or_session": "codex plugin remove skiphow@skiphow, codex plugin list --json", - "observable_evidence": "host inventory no longer listed skiphow@skiphow; the marketplace entry itself is configured by the machine's managed /etc/codex/config.toml and stayed", - "cleanup_result": "plugin cache and temporary marketplace snapshot removed from the isolated home" - } + "status": "UNVERIFIED", + "receipt": null } } } }, "rule": "Record each capability separately. A package validator, documented host feature, or successful install does not prove model activation or behavior. Use scratch host homes and retain exact package bytes, the package tree and candidate commit, host version, outcome, configuration, command or session result, source, date, and cleanup result. The receipt outcome must match its ledger status. Release-runner capability is a separate matrix.", "historical_evidence": { - "package_version": "4.2.0", - "source": "https://github.com/mzored/SkipHow/blob/f684eb2f3d2e7baf8b8488e8efb5ac4703d67cff/evals/host-smoke.json", + "package_version": "4.3.0", + "source": "https://github.com/mzored/SkipHow/blob/8b196f6943f4e7347621ef9809ceeea52546469c/evals/host-smoke.json", "scope": "Historical receipts retain their original arms, prompts, outcomes, and package identities at this immutable source. They do not establish current-candidate behavior." } } diff --git a/evals/receipts/host-validation-440-20260906.md b/evals/receipts/host-validation-440-20260906.md new file mode 100644 index 0000000..900e36b --- /dev/null +++ b/evals/receipts/host-validation-440-20260906.md @@ -0,0 +1,26 @@ +Scope: this release runner. External candidate and model-session receipts are recorded separately. + +| Capability | Status | Detail | +| --- | --- | --- | +| Deterministic package gate | UNVERIFIED | not run; pass --package-gate | +| Codex schema validation | UNVERIFIED | Codex plugin validator unavailable | +| Claude schema validation | PASS | claude plugin validate --strict | +| Clean Codex install | UNVERIFIED | managed source policy refused the local marketplace | +| Clean Claude install | PASS | receipt claude-clean-install-2026-09-06.json | +| Explicit invocation | UNVERIFIED | not run by the release runner; external model-session evidence is recorded separately | +| Implicit activation | UNVERIFIED | not run by the release runner; external model-session evidence is recorded separately | +| Continuity/bootstrap | UNVERIFIED | not run by the release runner; external model-session evidence is recorded separately | +| Behavioral contract suite | UNVERIFIED | never run or implied by CI; the versioned summary is docs/evidence.md | + +## External candidate checks + +The local deterministic gate passed on the 4.4.0 candidate at `6ebe0b4`. Claude Code +2.1.263 installed all seventeen regular files byte for byte in an empty configuration +directory (payload `5163a3c6…`) and uninstalled them; the receipt is in this +directory. The Codex row above records the refusal of a local marketplace by the +machine's managed source policy; the Codex receipt file in this directory retains +that refusal. No model session ran on 4.4.0; the ledger cells in +[`../host-smoke.json`](../host-smoke.json) record only the Claude install and +uninstall facts, and every Codex cell and every other Claude cell stays +`UNVERIFIED`. The Codex plugin validator was unavailable on this machine and runs +in CI. diff --git a/evals/receipts/host-validation-440-20260906/claude-clean-install-2026-09-06.json b/evals/receipts/host-validation-440-20260906/claude-clean-install-2026-09-06.json new file mode 100644 index 0000000..0fb45cf --- /dev/null +++ b/evals/receipts/host-validation-440-20260906/claude-clean-install-2026-09-06.json @@ -0,0 +1,129 @@ +{ + "date": "2026-09-06", + "detail": "exact candidate installed, inspected, and uninstalled from a clean host home", + "host": "claude-code", + "host_version": "2.1.263 (Claude Code)", + "installed_files": { + ".claude-plugin/plugin.json": "89905ab2614ad6bc8418c3e5105e0f943200f3024e485c8d583a7babd023d802", + ".codex-plugin/plugin.json": "cc78ace880de492f3528a0ae9662ff478a2f6d2164acf1d39b955617862d5c62", + "LICENSE": "f6c21980331ae32f64afe9585dabbb60098b5b26b09e7873505fe23042cb99df", + "SOURCES.json": "d74f6ccef12488b27e195bdfc677781c130bc81b514a1bca6218eaf82b93093b", + "THIRD_PARTY_NOTICES.md": "aa6eb608121360a0f46f4c153ce6c29cf7e52d2952b2d9c85938a3ec43444263", + "skills/skiphow/SKILL.md": "a0d33f0418df43fa36cb2d22f98fff22e01d7e10a5c23a3364871279d21562c3", + "skills/skiphow/agents/openai.yaml": "c7ba7daa2c66aef3a99c7e5dd001905baa0976913b9e903f94726d4bc2904f51", + "skills/skiphow/references/delegation.md": "bcc41f3ad33f9499d12d82bcc00613a55da32a1e4d814c475a12d3620096b02c", + "skills/skiphow/references/diagnosis.md": "8d0f337437d9ee3982e6df27ed1a58b89a01269e500e81b4dfce553c3976deb4", + "skills/skiphow/references/integration.md": "dee2c76f254c2083108451e65207516d9da045dfb2cda3af0f1d64cf8e523671", + "skills/skiphow/references/operations.md": "def02aa656056dd0a35fcd1c3ce72a67698b95d71098612b365b6f8490c166d0", + "skills/skiphow/references/product.md": "b4e098938fe93db53cdf026de09c54c1f6fb1839eaa42b057ab10d883c377ac6", + "skills/skiphow/references/setup.md": "cdb63b0820307414a850027dbf1032f99e2d02bc8a8a8c45ff1deefef4915eee", + "skills/skiphow/references/technical-design.md": "24e94087743cf14747e59920d3fb12d9ac6a0ae51bff52fb43b7a491acbf87b8", + "skills/skiphow/references/tracked-work.md": "df6a5a00caa2a1bc30a5a518185658e4cc10f3f18fb18a71179554c95a8927f8", + "skills/skiphow/references/verification.md": "971e051fbc171c2fa75fc4a597904216e4af650a4b0e9560eb8015dd8cd9afbb", + "skills/skiphow/scripts/activation.py": "9c70f335a9fc34f212553f4810e176195f00dbf6bd622713e852880b04595f7b" + }, + "result": "PASS", + "results": { + "clean_install": { + "receipt": { + "check": "clean_install", + "cleanup_result": "plugin absent before scratch host home cleanup", + "command_or_session": "host marketplace add, install, list, inspect, uninstall, list", + "configuration": "empty CLAUDE_CONFIG_DIR; exact local marketplace snapshot", + "date": "2026-09-06", + "host": "claude-code", + "host_version": "2.1.263 (Claude Code)", + "observable_evidence": "installed regular files exactly matched the candidate payload", + "outcome": "PASS", + "package_commit": "6ebe0b48f70f7eb1d51259fa44e5792c725d046b", + "package_payload_sha256": "5163a3c6b919d807031ffd26b32eda11d32cdb5d6df733a432f731799f6d6ed5", + "package_tree": "4816696bc40afc23da4d9149f9dbab1c55d47848", + "package_version": "4.4.0", + "source": "scripts/check_hosts.py --smoke" + }, + "status": "PASS" + }, + "uninstall": { + "receipt": { + "check": "uninstall", + "cleanup_result": "plugin absent before scratch host home cleanup", + "command_or_session": "host marketplace add, install, list, inspect, uninstall, list", + "configuration": "empty CLAUDE_CONFIG_DIR; exact local marketplace snapshot", + "date": "2026-09-06", + "host": "claude-code", + "host_version": "2.1.263 (Claude Code)", + "observable_evidence": "host inventory no longer listed SkipHow", + "outcome": "PASS", + "package_commit": "6ebe0b48f70f7eb1d51259fa44e5792c725d046b", + "package_payload_sha256": "5163a3c6b919d807031ffd26b32eda11d32cdb5d6df733a432f731799f6d6ed5", + "package_tree": "4816696bc40afc23da4d9149f9dbab1c55d47848", + "package_version": "4.4.0", + "source": "scripts/check_hosts.py --smoke" + }, + "status": "PASS" + } + }, + "schema": "skiphow-host-smoke-bundle/1", + "steps": [ + { + "detail": "", + "status": "PASS", + "step": "plain marketplace" + }, + { + "detail": "", + "status": "PASS", + "step": "clean host home" + }, + { + "detail": "", + "status": "PASS", + "step": "marketplace" + }, + { + "detail": "", + "status": "PASS", + "step": "install" + }, + { + "detail": "", + "status": "PASS", + "step": "list" + }, + { + "detail": "17 regular files, exact candidate bytes, no symlinks", + "status": "PASS", + "step": "inspect installed files" + }, + { + "detail": "package ships no hook", + "status": "UNVERIFIED", + "step": "inspect hook trust/state" + }, + { + "detail": "", + "status": "PASS", + "step": "uninstall" + }, + { + "detail": "", + "status": "PASS", + "step": "list after uninstall" + }, + { + "detail": "", + "status": "PASS", + "step": "verify uninstall" + }, + { + "detail": "9.5 step 5: starts a model; not run by this script", + "status": "UNVERIFIED", + "step": "start a clean session" + }, + { + "detail": "9.5 step 6: starts a model; not run by this script", + "status": "UNVERIFIED", + "step": "verify explicit invocation" + } + ] +} diff --git a/evals/receipts/host-validation-440-20260906/codex-clean-install-2026-09-06.json b/evals/receipts/host-validation-440-20260906/codex-clean-install-2026-09-06.json new file mode 100644 index 0000000..2d72779 --- /dev/null +++ b/evals/receipts/host-validation-440-20260906/codex-clean-install-2026-09-06.json @@ -0,0 +1,61 @@ +{ + "date": "2026-09-06", + "detail": "Error: marketplace source `/private/marketplace` is not allowed by requirements from /etc/codex/requirements.toml", + "host": "codex", + "host_version": "codex-cli 0.153.0", + "installed_files": {}, + "result": "FAIL", + "results": { + "clean_install": { + "receipt": { + "check": "clean_install", + "cleanup_result": "scratch host home removed; uninstall was not verified", + "command_or_session": "host marketplace add, install, list, inspect, uninstall, list", + "configuration": "empty CODEX_HOME; exact local marketplace snapshot", + "date": "2026-09-06", + "host": "codex", + "host_version": "codex-cli 0.153.0", + "observable_evidence": "Error: marketplace source `/private/marketplace` is not allowed by requirements from /etc/codex/requirements.toml", + "outcome": "FAIL", + "package_commit": "6ebe0b48f70f7eb1d51259fa44e5792c725d046b", + "package_payload_sha256": "5163a3c6b919d807031ffd26b32eda11d32cdb5d6df733a432f731799f6d6ed5", + "package_tree": "4816696bc40afc23da4d9149f9dbab1c55d47848", + "package_version": "4.4.0", + "source": "scripts/check_hosts.py --smoke" + }, + "status": "FAIL" + }, + "uninstall": { + "receipt": null, + "status": "UNVERIFIED" + } + }, + "schema": "skiphow-host-smoke-bundle/1", + "steps": [ + { + "detail": "", + "status": "PASS", + "step": "plain marketplace" + }, + { + "detail": "", + "status": "PASS", + "step": "clean host home" + }, + { + "detail": "Error: marketplace source `/private/marketplace` is not allowed by requirements from /etc/codex/requirements.toml", + "status": "FAIL", + "step": "marketplace" + }, + { + "detail": "9.5 step 5: starts a model; not run by this script", + "status": "UNVERIFIED", + "step": "start a clean session" + }, + { + "detail": "9.5 step 6: starts a model; not run by this script", + "status": "UNVERIFIED", + "step": "verify explicit invocation" + } + ] +} diff --git a/plugins/skiphow/.claude-plugin/plugin.json b/plugins/skiphow/.claude-plugin/plugin.json index 9f952b0..2a68332 100644 --- a/plugins/skiphow/.claude-plugin/plugin.json +++ b/plugins/skiphow/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "skiphow", - "version": "4.3.0", + "version": "4.4.0", "description": "Adaptive virtual CTO for founders and product owners using Claude Code or Codex. Describe the product outcome; SkipHow owns the technical lifecycle through verified completion.", "author": { "name": "mzored", diff --git a/plugins/skiphow/.codex-plugin/plugin.json b/plugins/skiphow/.codex-plugin/plugin.json index 2f6e198..f35cec5 100644 --- a/plugins/skiphow/.codex-plugin/plugin.json +++ b/plugins/skiphow/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "skiphow", - "version": "4.3.0", + "version": "4.4.0", "description": "Adaptive virtual CTO for founders and product owners using Claude Code or Codex. Describe the product outcome; SkipHow owns the technical lifecycle through verified completion.", "author": { "name": "mzored", diff --git a/plugins/skiphow/skills/skiphow/SKILL.md b/plugins/skiphow/skills/skiphow/SKILL.md index bfb6368..b2af475 100644 --- a/plugins/skiphow/skills/skiphow/SKILL.md +++ b/plugins/skiphow/skills/skiphow/SKILL.md @@ -1,6 +1,6 @@ --- name: skiphow -description: Act as an adaptive virtual CTO for a founder or product owner. Use for any current-project outcome stated in ordinary language, including questions, research, reviews, bugs, ideas, features, lists, programmes, delivery, process problems, pauses, and resumes. The owner keeps product decisions; the agent owns the technical lifecycle through verified completion. Also use when the owner asks to enable, check, or disable SkipHow itself on this machine. Do not use for unrelated conversation. +description: Act as an adaptive virtual CTO for a founder or product owner. Use for any current-project outcome stated in ordinary language, including questions, research, reviews, bugs, ideas, features, iterations on something the owner will look at, lists, programmes, delivery, process problems, pauses, and resumes. The owner keeps product decisions; the agent owns the technical lifecycle through verified completion. Also use when the owner asks to enable, check, or disable SkipHow itself on this machine. Do not use for unrelated conversation. --- # SkipHow @@ -23,6 +23,8 @@ An answer, comparison, diagnosis-only, review-only, research, audit, or plan req A request to change or deliver the project grants in-scope local edits, non-destructive validation, and the routine engineering state needed to complete that delivery. Within an established owner-authorized non-production workflow, carry the result through its branches, commits, CI, tracking, push, pull request, and merge to the authorized destination without asking again for covered actions. Verify that standing authorization still applies to the project, destination, audience, and actual effects; installation or an upgrade creates no grant and removes no existing restriction. Tracking is warranted when the work has several deliverable outcomes, spans sessions or writers, needs a durable decision, or leaves a material separable problem. It does not authorize publishing private facts to a new or broader audience. Tiny same-session work needs no tracker item, specification, worktree, or delegate. +An iteration is a change to something the owner will look at before deciding what comes next: a screen, copy, an email, a landing page, a document. Its verified completion is the shown result, not the integrated one. Make the change, show it where the owner can see it, run the check that covers what it touched, and stop; that stop is a completed turn rather than unfinished work, so report what is shown and what delivery will add. The owner's acceptance starts the delivery, and only then do the wider tests, tracking, commits, push, and integration follow under the grants above. Recognize an iteration when the request is about how something looks or reads, its consequences are reversible, and the owner said they will look before deciding what comes next or is sending small changes one after another; a request that names a destination or asks to ship is delivery, whatever the owner looks at afterwards. Where such a change could be read either way, show it and say what delivery would add rather than integrating unasked; a look is cheap and unwinding an integration is not. + Before an operation that may execute repository hooks, project scripts or code, credential helpers, or external tooling, establish that its effects stay inside the request's authority and the current trust boundary. Otherwise use a host-enforced restricted mode, or leave the operation unperformed and state what remains unverified. Do not bypass a host or sandbox refusal: try the authorized alternatives, and when none remains name the exact blocker and, where the host has a permission interface, the exact permission it needs. A local commit is optional unless trusted project procedure or the authorized delivery path requires it. Make one only when it contains owned changes and the effective hooks, signing configuration, credential helpers, and commit path are known not to cross another authority boundary. Do not run unknown hooks, bypass hooks, sign, authenticate, reach the network, or invoke a credential helper without authority for that effect. Leaving completed work uncommitted for one of these reasons is not an implementation failure. @@ -49,7 +51,7 @@ Engineering is yours. Choose architecture, dependencies, interfaces, data struct Before consequential work, inspect the request, applicable instructions, current product and code, tests, Git status and relevant history, live branches and worktrees, relevant open and closed records, and CI or host state that affects the result. Preserve work you do not own. -Infer the request shape before choosing the method. Distinguish answers and research, read-only reviews, capture and triage, repairs, features, ideas, programmes, resumes, and process or environment failures. Use a direct mode for small clear work. Add investigation, design, durable tracking, parallel delivery, independent evaluation, or recovery only when the outcome, uncertainty, risk, duration, or live state calls for it. +Infer the request shape before choosing the method. Distinguish answers and research, read-only reviews, capture and triage, repairs, features, iterations the owner will look at before deciding, ideas, programmes, resumes, and process or environment failures. Use a direct mode for small clear work. Add investigation, design, durable tracking, parallel delivery, independent evaluation, or recovery only when the outcome, uncertainty, risk, duration, or live state calls for it. Define what must become observably true. Recover business and user intent, current constraints, integration boundaries, data sensitivity, operational expectations, expected load where material, and likely next changes. Write a product specification or technical decision only when decisions or acceptance conditions must survive multiple sessions or workers, or when an expensive-to-reverse choice needs a durable rationale. diff --git a/site/evidence/index.html b/site/evidence/index.html index fe54cb0..31664fb 100644 --- a/site/evidence/index.html +++ b/site/evidence/index.html @@ -56,11 +56,11 @@

Claims stop where the receipts stop.

-
+

01 · Historical observations

What controlled 2.x runs showed.

-

Historical observations below: 2.x only. Current package: 4.3.0. Retained current-package CTO scenarios with Observed receipts: 0 of 12. Eight historical 4.0.1 Claude run records remain incomplete. Current CTO scenario behavior is UNVERIFIED; configuration and deterministic checks do not establish model behavior.

+

Historical observations below: 2.x only. Current package: 4.4.0. Retained current-package CTO scenarios with Observed receipts: 0 of 12. Eight historical 4.0.1 Claude run records remain incomplete. Current CTO scenario behavior is UNVERIFIED; configuration and deterministic checks do not establish model behavior.