Release 2.16.0: reachable delegate methods, a readability pass, and one home per rule

CONTRIBUTING.md

@@ -28,7 +28,7 @@ python scripts/check.py --pytest tests/test_package.py -q
 - Update `docs/decisions.md` when evidence changes architecture, the product contract, or security policy. Update `docs/evidence.md` when supported claims or known limits change. Link to durable source material instead of adding one file per run or release.
 - `scripts/check.py` validates one top-level owner skill, recursive reachability of every Markdown file under its `references/` library, the required continuity-hook metadata and accepted command shape, aligned versions, and the personal-path and provider-model-ID boundaries it scans. Do not reintroduce fixed method counts, role sets, model tiers, prose spellings, or word budgets. Record package-invariant changes and their evidence in `docs/decisions.md`, then update the check in the same change.
 - Preserve upstream license, copyright, path, and inspected revision whenever a method copies or adapts source text. Record borrowed ideas and rejected alternatives in [the design](docs/design.md) and [decision history](docs/decisions.md).
-- Write direct English prose. Use active voice, sentence-case headings, straight quotes, and concrete claims.
+- Write direct English prose. Use active voice, sentence-case headings, straight quotes, and concrete claims. Open each method with a scope line repeating the trigger `SKILL.md` carries for it, give any file over roughly four hundred words subheadings, keep one idea to a sentence, and use a list only where the content is already a set. No em dashes; prefer two sentences to a semicolon.
 
 ## Verify a pull request
 

SECURITY.md

@@ -4,8 +4,8 @@
 
 | Version | Supported |
 | --- | --- |
-| 2.14.x | Yes |
-| 2.13.x and earlier | No |
+| 2.16.x | Yes |
+| 2.15.x and earlier | No |
 
 Security review covers the packaged owner skill, its linked methods, host manifests,
 marketplace metadata, continuity hook, release checks, and documented authority

VERSION

@@ -1 +1 @@
-2.14.0
+2.16.0

docs/evidence.md

@@ -160,6 +160,50 @@ None of `decomposition`, `delegation` or `execution-health` reached context in a
 
 These sessions are the maintainer's own work, not controlled runs: the package version, repository, and prompt all vary, and nothing here is paired. They are evidence about what reached the model and what the run cost, which is readable from the transcript, and not about whether the wording caused the outcome.
 
+### The delegate methods did not reach the sessions that dispatched delegates
+
+A 2026-09-02 scan read twenty-four installed sessions on the maintainer's own projects, from 2026-08-29 onward and on packages between 2.8.0 and 2.14.0, together with all 102 delegate transcripts beneath them. Twenty-two carried the kernel; fifteen dispatched delegates, ninety-one times at the root and twelve times below it. Method loading was established by searching each transcript for the reference file's own opening sentence, not its path, and the persisted overflow files were swept as well, which changed one session's answer.
+
+Of the fifteen sessions that dispatched delegates, `delegation` was in context before the first spawn in four and `model-routing` in five. `execution-health` reached one of the twenty-four at any point and none before a dispatch. `decomposition` also reached one.
+
+Thirty-one of the ninety-one spawns named no level for the delegate, which on this host inherits the session's. Split by whether the routing text was in context: three of fifty where it was, twenty-eight of forty-one where it was not. One session dispatched twenty-three lanes with twenty-two unrouted and read no method file at all; twenty-one of its twenty-eight delegates ran on the session's model, its longest lane ran 147 minutes, and its delegates consumed 587M cached input tokens, half the delegate total across the whole scan. Another dispatched four read-only verification lanes with no level named, all four on the session's model. In a third the owner interrupted to name `model-routing` by file path; the text reached context eight seconds later and three unrouted delegates too late.
+
+Three requirements the kernel compresses fared worse than the one it does not. A stated completion condition appears in thirty-one of ninety-one briefs and the instruction to return a blocking unknown in thirty-seven, while the delegate's boundary, which the kernel does not summarise, appears in ninety of ninety-one. Twelve briefs in one session handed a single delegate two to five tracker items each, one of them stating that they were strictly sequential. Where the methods did load the briefs met all four requirements: four of four in one session, five of five in another.
+
+No brief in the scan set a duration expectation, and no lane was stopped for exceeding one. Stalls were caught by inspection after a completion notification rather than by a breach: one root found three lanes that had backgrounded their own checks and stopped without committing, diagnosed the pattern and resumed each, at a cost of 106 delegate-minutes plus 22 to redo. One root blocked its own turn twice on a foreground sleep loop, roughly fifty-four minutes with six delegates live and thirty-five per cent of that session's span, and stopped only when the owner said so.
+
+Delegates carried 54 per cent of output tokens and 68 per cent of cached input across the twenty-four sessions, 3,543,563 output against the roots' 3,044,894, and 2,409 delegate-minutes against a delegate-live union near 600, so roughly fourfold parallelism where lanes were used. No delegate transcript contained the kernel or any method text, and none of the 210 `Skill` calls delegates made anywhere in the tree named the owner skill. Twelve delegates dispatched delegates of their own, to a maximum of two levels below the root, all of them as ordinary agents.
+
+These are the maintainer's own sessions, not controlled runs: version, repository and prompt all vary, and nothing is paired. They measure what reached the model and what the run cost. They do not show that the old wording caused the outcome, and the counts are an upper bound on conformance because a rule the run noticed and dropped leaves no trace.
+
+### Paired runs on 2.15.0 did not reproduce the delegate loading failure, or fix it
+
+Six isolated sessions ran on a throwaway five-defect fixture, three on 2.14.0 and three on the 2.15.0 candidate, in a fresh copy of the fixture per run, with the package passed as a session plugin and every setting source dropped. A first prompt that described five independent defects and asked for them in parallel produced no delegate in any of the six runs, on either package, and all six fixed the defects directly. A second prompt that named parallel lanes explicitly produced five delegates in every run on both packages.
+
+In those six dispatching runs, all thirty spawns named no level for the delegate, and no run on either package opened `delegation`, the routing text, or `execution-health`. The kernel loaded in every run. So the reworded method-list line did not fire in a clean session, exactly as 2.11.0's fixture runs failed to reproduce the loading failure they were built for, and this fixture does not discriminate between the packages.
+
+That result is why the kernel keeps one obligation at the point of use rather than relying on the method list alone. It is evidence against the sufficiency of the trigger rewrite and not evidence for it, and the pass reports it as such. The fixture is small, the sessions are short, and one prompt per cell separates nothing from noise.
+
+### The kernel obligation reached the method where the method list did not
+
+Three further sessions ran on the released 2.15.0 tree, on the same fixture, prompt, host, and session model as the six above. That package differs from the candidate arm in exactly one file: `SKILL.md` carries the obligation to read `delegation` before dispatching a delegate.
+
+`delegation` was in context before the first spawn in two of the three runs, and in both of the two that selected the skill at all; the third never loaded the kernel, which is the discovery variance one run per cell cannot separate from noise. The candidate arm was zero of three with the skill loaded in all three. Five of the fifteen spawns named a level, against none in either earlier arm.
+
+The run that read the method and still named no level is the useful one. It opened `delegation`, made the routing judgment explicitly, and wrote in its own message that each lane would run "at ordinary level (bounded fix against a stated test spec)". It then passed no level in any of the five dispatches. It also placed all five lanes in one checkout, reasoning that no two touched the same file, with the isolation rule in context. So the obligation is shown to get the file opened, and opening the file is not shown to produce either the routing or the isolation. The first is a property of the text and three runs can support it; the second is a run deviating from text that was plain and in context, which no number of sessions this small can generalize.
+
+Three more sessions ran the same way on the shipped 2.15.1 tree, which adds the readability pass and the two completed scope lines. All three loaded the skill, all three opened `delegation` before the first spawn, and all fifteen spawns named a level, every one of them the cheapest available. Read as a non-regression check on the readability pass, that is what it is. Read as a claim that structure caused the difference from 2.15.0's two of three and five of fifteen, it is three runs per arm against a difference of one run, and the pass does not make that claim.
+
+`execution-health` opened in none of the twelve runs. Its trigger names a step that could take real time, and nothing in a five-defect fixture is one.
+
+### One rule with two homes had already drifted
+
+Version 2.16.0 compared every sentence of seven words or more in the kernel and the twenty-three methods against every other, 865 sentences and 373,680 pairs, ranked by shared vocabulary. Forty-nine pairs passed the threshold and four were one rule with two homes. Of the remaining forty-five, nineteen pair a method-list trigger with the scope line that repeats it, thirteen pair a kernel invariant with the technique beneath it, and thirteen are two methods stating adjacent rules in their own terms.
+
+One of the five had already drifted, which is the evidence for the rule rather than an argument for it. `tracked-work` said an item the code has already overtaken is reported as done rather than redone; `advancing-tracked-work` said it closes as done rather than being rebuilt. Reporting and closing are different acts, and closing needs a write grant that reporting does not. Nobody edited both.
+
+A fifth, the regression-observation rule stated twice inside `testing` under two different qualifiers, scored below the threshold because the two statements share almost no vocabulary. It was found by reading. That is the measured limit of the scan: it finds repetition, not restatement.
+
 ### Long installed runs kept waking without new evidence
 
 A 2026-08-30 audit examined four large installed Codex task trees from the maintainer's own projects. The three largest roots made 1,785 delegate wait calls. Of those, 855 expired with an explicit timeout and no mailbox activity. For two roots, each timeout was joined by call identifier to its result and then to the next model turn, with any interval containing another message excluded. All 472 unchanged timeouts qualified. The following turns processed 62,931,387 input tokens, 62,568,704 of them cached. This is repeated context traffic, not unique tokens. Six root compactions occurred across roughly 43 hours, so the larger repeated cost was waking and reprocessing a large root context rather than compaction itself.
@@ -244,10 +288,10 @@ One matched Claude Code pair was then run on a throwaway shop repository whose t
 
 - Whether the 2.14.0 frontier bound and defer outcome stop a long run when its result waits on the owner and only enabling work remains. One installed 2.13.0 campaign shows the drift with the 2.13.1 text in context, and a matched five-minute pair shows both packages already behaving correctly at that scale, so the fixture is not where the defect lives. The line closes only on the owner's next long installed campaign.
 - The outside read of a consequential design decision. Ten runs made the decision well and none took an outside read. Codex had the method open in all five of its runs; no Claude session in the pass opened it at all. Three kernel wordings changed nothing on either host. The rule is stated and does not execute.
-- Delegation under the shipped wording. No fixture run in the pass spawned a delegate for any reason; the largest fixture, six capabilities over 2,725 lines, was carried in one pass by both hosts. The installed sessions above show delegation happening at scale but with the governing methods absent from context, so they say what delegation costs and not whether the wording works.
+- Delegation under the shipped wording. The installed sessions above show delegation happening at scale but with the governing methods absent from context, so they say what delegation costs and not whether the wording works. The 2.15.0 kernel obligation is now measured to get `delegation` opened before the first dispatch, and one of those runs read it and routed nothing anyway. Whether the method's own rules hold once it is open is unmeasured, and `execution-health` has never opened in a fixture run.
 - Whether the 2.12.0 observation rule reduces root context traffic or the reconciliation rule prevents integrated working state from accumulating. Both changes answer installed failures, but neither has run in a comparable session.
 - Whether a rule moved into the kernel is followed. The installed sessions carried the kernel's worktree-placement rule and one breached it anyway, so kernel placement is shown to change what is read and not yet what is done.
-- Whether routing a delegate down is cheaper in total rather than per token. No paired run measures it.
+- Whether routing a delegate down is cheaper in total rather than per token. No paired run measures it. What the 2026-09-02 scan adds is the cost of naming no level at all, which is not the same question.
 - Whether the second round is reliable on Codex. It happened in one of three released-package sessions on the cancellation fixture, and in the shared-basket pair before it. When it does happen, nothing gets built, which is the part this release adds.
 - Whether the corrected wording in `project-setup` puts the setup record somewhere both hosts read.
 - The tracked-work rule 2.8.0 puts in the kernel. No run has been made on it. Whether work carried on a review branch acquires an item before that branch, whether the item is claimed before investigation, and whether linked closure is wired at branch creation rather than left to a later session are all unmeasured. The rule is the owner's decision, recorded as one, and the evidence bar `AGENTS.md` sets for a mandatory step is not met.

plugins/skiphow/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "skiphow",
-  "version": "2.14.0",
+  "version": "2.16.0",
   "description": "Outcome-first orchestration for Claude Code and Codex. Describe the product result; the agent chooses the engineering method and proves the outcome.",
   "author": {
     "name": "mzored",

plugins/skiphow/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "skiphow",
-  "version": "2.14.0",
+  "version": "2.16.0",
   "description": "Outcome-first orchestration for Claude Code and Codex. Describe the product result; the agent chooses the engineering method and proves the outcome.",
   "author": {
     "name": "mzored",