From cb50b55c8539d34e3899a57a2eb5191ca9027d8d Mon Sep 17 00:00:00 2001 From: mzored Date: Wed, 2 Sep 2026 02:20:34 +0400 Subject: [PATCH 1/4] fix: bound the frontier by the owner's result Two installed 2.13.0 campaigns kept building enabling machinery for a day after the owner's stated result had come to wait on the owner's own steps, and campaign direction, opened three times, replaced the architecture each time instead of deferring the direction. The frontier is now bounded by the requested result, defer is a direction outcome, the recovery exemption is gone, the provenance rule reaches sequencing claims and the run's own records, and a unit that spawns its own prerequisite is a named signal. Co-Authored-By: Claude Fable 5.1 --- CHANGELOG.md | 15 +++++++++++++++ SECURITY.md | 4 ++-- VERSION | 2 +- docs/decisions.md | 8 +++++++- docs/evidence.md | 15 +++++++++++++++ docs/prior-art.md | 2 ++ plugins/skiphow/.claude-plugin/plugin.json | 2 +- plugins/skiphow/.codex-plugin/plugin.json | 2 +- plugins/skiphow/skills/skiphow/SKILL.md | 6 +++--- .../skiphow/references/advancing-tracked-work.md | 4 ++-- .../skiphow/references/campaign-direction.md | 8 ++++---- .../skills/skiphow/references/execution-health.md | 2 +- 12 files changed, 54 insertions(+), 16 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 442feea..c0db77d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,21 @@ All notable changes to SkipHow 2.x appear in this file. Earlier release notes remain available on [GitHub Releases](https://github.com/mzored/SkipHow/releases). +## 2.14.0 (2026-09-02) + +### Changed + +- The frontier is bounded by the owner's result. `advancing-tracked-work` treats an open, unblocked item as takeable only when it lies on the path from live state to the requested result; an item beyond that destination is reported as takeable and deferred rather than resolved on the way. When nothing takeable reaches the result, the run stops with the human batch instead of filling the wait with enabling work the request did not name. Where the request names only the tracker, the result is recovered from the records' own parent outcome or the product brief. The always-loaded kernel states the same measure beside its continuation rule. +- `campaign-direction` recovers the premise from the owner's request and the owner's recorded decisions, not from a parent record the run or an audit wrote. The sentence that let security, money, recovery, and operational work produce no evidence of the result is gone; that work names the obstacle to the stated result it removes, like any other. Deferring an off-path direction is an outcome beside keep, simplify, replace, and retire, and replacing the architecture of off-path work is named as not a response. When deferral would carry the result past an unsettled risk or rollout consequence, that consequence is the one product question. With no takeable unit that reaches the result, admission stops; spare capacity admits nothing. +- The kernel extends the 2.13.1 provenance rule: a record's claim that something must precede the owner's result is a proposal on the same footing, and a record the run itself wrote carries only the authority of the request it served. A unit that must create a new prerequisite of its own before it can finish is a named trigger for `campaign-direction` and a stream anomaly in `execution-health`. + +### Evidence + +- Two owner-run installed Codex campaigns on 2.13.0 drifted the same way. One asked for the tasks blocking first payments; its real blockers integrated in about seventeen hours and the remaining thirty went to one backup-recovery lineage of eight tracker items, each new one a prerequisite for resuming the last, ending uncommitted on a defect. The run admitted that lineage at hour one to use free capacity, thirty minutes after computing a money path that did not contain it, on the strength of an audit finding that said recovery precedes traffic. The other asked to exhaust the takeable frontier of a tracker built from a complexity audit; it closed twelve tooling and evidence items over twenty-three hours while the item the audit had called most important waited on the owner. A third run of eight hours on a scoped bug-and-staging request showed no deviation and its result was accepted. +- `campaign-direction` was opened in the first campaign three times and each pass replaced the architecture of the same direction. The 2.13.1 kernel wording reached that run mid-way and fifteen more hours followed on the same lineage. That is one session showing the released text in context and not stopping the drift; two sessions show the drift under the same text. The wording defects are readable in the files: premise recovered from records the run wrote, an exemption for recovery work, no defer outcome, and a frontier defined by blockers alone. Details are in `docs/evidence.md`. +- Every per-lane rule in `execution-health` worked as written in those runs. No numeric limit was added; a two-hour rule and a one-item-per-session rule were both refused again, see `docs/decisions.md`. +- Behavior on the new wording is `UNVERIFIED` until a paired receipt or the owner's next long campaign; see `docs/evidence.md`. + ## 2.13.1 (2026-08-31) ### Fixed diff --git a/SECURITY.md b/SECURITY.md index 98013a0..f65759d 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -4,8 +4,8 @@ | Version | Supported | | --- | --- | -| 2.13.x | Yes | -| 2.12.x and earlier | No | +| 2.14.x | Yes | +| 2.13.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 diff --git a/VERSION b/VERSION index 94f15e9..edcfe40 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.13.1 +2.14.0 diff --git a/docs/decisions.md b/docs/decisions.md index 026f4cd..6842736 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -98,6 +98,8 @@ Three heavier alternatives were rejected. Matt Pocock's `grilling` asks across t The controlled fixture kept the prompt, repository, host isolation, and model fixed while changing the package. Exact 2.13.0 made both findings `Ready`, including a capability absent from the authoritative product brief. Candidate revisions exposed three narrower failures: one kept both findings proposed instead of trusting the brief for the accepted core flow; one preserved the disputed item as proposed but deferred the decision; another recast it as a technical contract question. Those results produced the authoritative-brief exception, the current-result ask, and the capability-versus-implementation wording. A later candidate loaded the skill and kept the core repair `Ready` and the disputed capability `Proposed`, but still did not ask. An exact-package repeat did not load the skill and promoted both. The text defect and its point-of-use reach are fixed; reliable end-to-end behavior remains `UNVERIFIED`. Revisit this if receipts still promote a loaded proposal without asking, or if ordinary well-specified work starts acquiring unnecessary clarification rounds. +Version 2.14.0 extends the distinction after an installed campaign showed its gap. A record's claim that its work must precede the owner's result is the same kind of statement as a claim that a capability belongs in the product: a proposal until the request, an authoritative brief, or an owner decision adopts it. And a record the run writes during the request does not become an owner decision by being read back an hour later; it carries only the authority of the request it served. The first campaign in [current evidence](evidence.md) turned an audit finding into a parent item that said recovery precedes traffic, then recovered that item as the settled premise every time it rechecked direction. + ## What the owner decided is a record, not a message An answer the owner gives is a decision the project carries. Where the request authorizes a record, it is written where the work is tracked, with what it settled and the option they turned down, before anything depending on it is built. When the owner asks to settle what they want before work starts, `product-spec` turns that into a document they can read back: a vocabulary in their own words settled before the outcomes, the outcome stated as what a person will be able to do, each decision with its rejected alternative, and what is deliberately out of scope. @@ -158,7 +160,11 @@ The owner required this correction to live inside SkipHow rather than depend on Current comparable projects keep the heavier mechanisms SkipHow rejects. [`improve-codebase-architecture`](https://github.com/mattpocock/skills/blob/6654f6b60cd9d5be8b54c6fafe44346dabeb3b76/docs/engineering/improve-codebase-architecture.md) is an owner-invoked periodic check that ends with the owner choosing a candidate. [Paperclip](https://github.com/paperclipai/paperclip/blob/3623a369aa15c3ccb9d696f176049db4ed241248/docs/start/core-concepts.md) keeps goals, budgets, strategy approval, and board pause in a control plane. [Superpowers' plan executor](https://github.com/obra/superpowers/blob/b36e0829c6d0140e93cfef2ca599b1b07d4a7797/skills/executing-plans/SKILL.md) returns to review inside a mandatory plan workflow. SkipHow adopts none of those control mechanisms. -Revisit this if the method opens on healthy product slices with no shared machinery, asks the owner to choose a technical correction, re-argues settled direction without new evidence, stops independent lanes, starts more work than the current integration path can absorb, expands into an unrequested repository survey, or a comparable campaign reproduces the same drift. +Version 2.14.0 answers the first real campaigns run on that method, and they reproduced the drift with the method open. Two installed Codex campaigns on 2.13.0, described in [current evidence](evidence.md), spent thirty and twenty-three hours on enabling machinery after the owner's stated result had come to wait on the owner's own steps. `campaign-direction` was opened three times in the first and each pass replaced the architecture of the same backup-recovery direction. Three properties of its text made that the only reachable outcome. It recovered the premise from the parent record and recorded decisions, which the run itself or an earlier audit had written; the parent item said "before traffic" because the run wrote it that way at hour one. It exempted security, money, recovery, and operational work from producing customer-visible evidence, which was the class of work observed. Its outcomes were keep, simplify, replace, or retire a technical direction, with the owner asked only when no technically adequate option remained, so a rebuild from clean integration was always available and the sequencing question never reached anyone. `advancing-tracked-work` supplied the admission: the frontier was whatever was unblocked, the rule on a human block was to set it aside and carry on with what remained takeable, and nothing measured the remainder against the result. The 2.13.1 provenance sentence reached the first run mid-way and fifteen more hours followed, because it named capability scope and said nothing about a claim that work must come first or about records the run had written itself. + +The change bounds the frontier by the requested result, adds defer as a direction outcome, deletes the exemption, extends the provenance rule to sequencing claims and to the run's own records, and names one further observable signal, a unit that must create a new prerequisite of its own before it can finish. Wayfinder in `mattpocock/skills` already had the frontier half of this, a ticket found to sit beyond the destination is ruled out of scope rather than resolved on the route, and the 2.6.0 adaptation had not taken it; it is taken now as an idea, in SkipHow's words. Two heavier answers were refused again. A whole-request time bound, which the owner's own follow-up analyst proposed as two hours without progress toward the user scenario, is a number no run can justify across projects. One item per session, which wayfinder keeps, was rejected in 2.6.0 and the owner's own prompt for the second campaign said not to stop after one task; the defect was never that the runs did several items but that the items were off the path. The product choice underneath, stop and hand back when the result waits on the owner and only enabling work remains, is the owner's, and they made it after seeing the runs: SkipHow is meant to act as the technical director, not to spend days on work a second agent then calls low priority. + +Revisit this if the method opens on healthy product slices with no shared machinery, asks the owner to choose a technical correction, re-argues settled direction without new evidence, stops independent lanes, starts more work than the current integration path can absorb, expands into an unrequested repository survey, a run stops and hands back a batch while an enabling item the owner's own request named sat takeable, or a comparable campaign reproduces the same drift. ## A design method opens on what the project holds, not on how important the choice feels diff --git a/docs/evidence.md b/docs/evidence.md index fc5e0c0..f0f64d4 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -224,8 +224,23 @@ Candidate 2.13.1 runs exposed useful boundaries rather than a clean pass. The fi The receipts show that the old package allowed the promotion and that loaded candidate wording can preserve the distinction, but not that the complete behavior is reliable. Claude behavior remains `UNVERIFIED`; no Codex behavior run was accepted. +### A campaign kept building after its result came to wait on the owner + +Three owner-run installed Codex Desktop sessions over 2026-08-31 and 2026-09-01 were read from the host's own transcripts for this change, with per-message usage and timestamps. The transcripts are private and are not retained here. + +The first asked the run to close the tasks blocking first payments and real traffic, granted production, and asked for human-only steps to be batched. It ran 36.8 hours, spawned 61 delegates, issued 1,784 delegate waits, and processed 137 million input tokens, 99 per cent cached. The 2.13.0 kernel governed from the start and the 2.13.1 kernel reached its context at hour 22. Its two genuine blockers, a public OAuth defect and a receipt-contact rule, were integrated by hour 17. From hour one it also admitted a backup-recovery item, in its own words to use free capacity, thirty minutes after it had computed the money path without that item; the item's "before traffic" premise came from an audit finding recorded two weeks earlier. That lineage then produced eight tracker items, each new one written as a prerequisite for resuming the last, four independent reviews, three architectures, and about 1,700 uncommitted lines when the owner returned and paused it. `campaign-direction` was opened in context three times and each pass replaced the architecture. Fifteen hours of that followed the 2.13.1 wording. A fresh session the next day, asked by the owner why it had taken so long, answered in ten minutes that the lineage protected a CI proof of disaster recovery rather than the product, and proposed a plan whose first item was the one human step the run had asked for at minute thirty-five. + +The second asked the run to exhaust the takeable internal frontier of a tracker that an earlier session had built from a complexity audit. It ran 22.9 hours as one orchestrator with forked delegates and closed twelve items: CI routing, size budgets, evidence packaging, Markdown tooling, benchmark isolation. The audit those items came from had said the evidence system was the excess and that a device test with real people, recorded as a human-gated item, was the most important next step. A fresh session the next day, asked whether there was anything to play yet, counted 75 commits and roughly 9,800 lines since the audit with no new game behavior. + +The third asked for reproducible bugs and staging blockers on one campaign, then a staging release. It ran 8.2 hours, mostly on the project's own release gate and two flaky tests, released to staging, and the owner checked staging the next morning and accepted it. It shows a scoped request staying scoped, and nothing else. + +Counted in whole sessions: two show the drift under the same text; one of those shows the 2.13.1 kernel in context and not stopping it. Every per-lane rule in `execution-health` was followed, with twenty-minute checkpoints and three-attempt stops throughout; what no text supplied was a measure of the remaining takeable work against the owner's result once that result waited on the owner. The wording defects are readable in the files and are listed in the changelog and decision history. + +Version 2.14.0 bounds the frontier by the result, adds defer as a direction outcome, deletes the recovery exemption, extends the provenance rule to sequencing claims and to the run's own records, and names prerequisite-spawning as a signal. No paired receipt has been made on the new wording. + ## Still unverified +- Whether the 2.14.0 frontier bound and defer outcome stop a run when its result waits on the owner and only enabling work remains. Two installed 2.13.0 campaigns show the drift and one shows the 2.13.1 text in context without stopping it; no run has been made on the new wording, and the owner's standing preference is to wait for a real campaign rather than close the line with a fixture. - 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. - 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. diff --git a/docs/prior-art.md b/docs/prior-art.md index a385177..96f6f8c 100644 --- a/docs/prior-art.md +++ b/docs/prior-art.md @@ -61,6 +61,8 @@ Version 2.10.1 acts on something this page had already cited as a symptom rather Version 2.13.1 re-read three current approaches to unresolved product intent. Matt Pocock's [`grilling`](https://github.com/mattpocock/skills/blob/6654f6b60cd9d5be8b54c6fafe44346dabeb3b76/skills/productivity/grilling/SKILL.md) supplies a recommended answer with every owner question and keeps facts the agent can find out of the interview. Superpowers' [`brainstorming`](https://github.com/obra/superpowers/blob/b36e0829c6d0140e93cfef2ca599b1b07d4a7797/skills/brainstorming/SKILL.md) classifies the work and requires human approval before implementation, including for bounded tasks. Autonomous PM's [`assumption-mapper`](https://github.com/mlobo2012/autonomous-pm-plugin/blob/6eac45cbd79182fa0920b24a33c988d4380b4fe3/agents/assumption-mapper.md) separates assumptions from evidence and records evidence strength through a standing role and evidence store. SkipHow takes only the provenance distinction: current state, a proposal, and an accepted owner decision are different evidence. It rejects the full interview, universal approval, standing role, score, and new record system. The owner answers only an unresolved material product consequence, with the recommended outcome first, and the project keeps the answer in its existing records. No source text was taken. +Version 2.14.0 returns to `wayfinder` for the half of its frontier that 2.6.0 left behind. Read as it stands on 2026-09-02, it rules a ticket out of scope when an answer shows it sits beyond the destination, rather than resolving it on the route, and it keeps a human-in-the-loop ticket resolvable only through the live exchange, never by the agent standing in for the human. The out-of-scope rule is adapted as an idea and written in SkipHow's words: the frontier is bounded by the owner's result, and an unblocked item beyond it is reported as deferred rather than taken. Its one-ticket-per-session rule stays rejected, now with the owner's own prompt as a second reason. `implement-spec` in the same repository has a frontier and no stop or value rule, and Superpowers' `executing-plans` stops on every blocker to ask inside its mandatory plan workflow; neither is adapted. Paperclip's budgets stay in the control plane SkipHow does not ship. No source text was taken; the reasoning is in [decision history](decisions.md). + ## Ideas read and rejected Rejection is part of the record, so the same argument does not get reopened. diff --git a/plugins/skiphow/.claude-plugin/plugin.json b/plugins/skiphow/.claude-plugin/plugin.json index c9a5504..ee65f03 100644 --- a/plugins/skiphow/.claude-plugin/plugin.json +++ b/plugins/skiphow/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "skiphow", - "version": "2.13.1", + "version": "2.14.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", diff --git a/plugins/skiphow/.codex-plugin/plugin.json b/plugins/skiphow/.codex-plugin/plugin.json index c110ed3..fa09380 100644 --- a/plugins/skiphow/.codex-plugin/plugin.json +++ b/plugins/skiphow/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "skiphow", - "version": "2.13.1", + "version": "2.14.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", diff --git a/plugins/skiphow/skills/skiphow/SKILL.md b/plugins/skiphow/skills/skiphow/SKILL.md index 18c394e..a39d13d 100644 --- a/plugins/skiphow/skills/skiphow/SKILL.md +++ b/plugins/skiphow/skills/skiphow/SKILL.md @@ -19,7 +19,7 @@ Production or staging changes, public releases, payments, repository settings, a Translate the owner's language into technical work internally. Do not ask them to choose libraries, branches, test commands, schemas, architecture, or other engineering mechanics. Report a technical decision as settled; do not invite the owner to approve, overturn, or request the alternative. When a product choice needs their input, explain the visible consequences in plain language and recommend one option. An ask for a protected action or a human-only step is put the same way: say what it changes for them, their account, or their exposure, with the technical decision already taken. Never put a choice between technical options to them, and where the ask exists because a step is theirs to perform, ask for that step rather than for approval of the way around it. -Continue while a safe authorized step can advance the result. Do not pause for confirmation over a reversible technical choice; stop only at verified completion, an owner-requested pause, or a protected, material product, human-only, or external blocker. +Continue while a safe authorized step can advance the result. When the result itself waits on the owner, a grant, or an external party, what remains takeable is measured against that result and not against free capacity: work that reaches the result stays takeable, work whose place before it rests only on a record's say-so is deferred with that record, and the owner receives the batch rather than a run that fills the wait. Do not pause for confirmation over a reversible technical choice; stop only at verified completion, an owner-requested pause, or a protected, material product, human-only, or external blocker. Keep the working state you create inside the project or the host's own area. When a task needs an isolated checkout, use the host's mechanism or the location the repository already ignores, never a new directory beside it. Read the applicable repository instructions and enough live state to preserve work you do not own, which includes work another session is doing right now: a checkout, branch, or running service you did not create is shared, and uncommitted changes in it are somebody's. Never overwrite, reset, publish, or quietly absorb unrelated changes. Where the host can tell you whether another session is working in this project, that is part of the live state to read; reading in parallel is safe, and one writer at a time in a checkout is not a preference but what its single branch and index allow. Use plans, delegates, worktrees, review, and other process only when they help this request or the repository requires them. @@ -38,7 +38,7 @@ Read the method that governs an act before that act, not after it. Whether its t - For a new or broadly stated outcome, or a user-visible choice that project evidence cannot settle, use [product decisions](references/product-decisions.md). - For an owner asking to settle what they want before work starts, use [product spec](references/product-spec.md). - For a technology, architecture, or system-shape choice that nothing already in the project answers, or a maintained capability that may replace existing custom code, use [technical design](references/technical-design.md). -- For active or recorded multi-unit work with repeated repairs, competing implementations of one product behavior, technical or delivery machinery expanding after its target was met, technical and process growth without new evidence of the requested result, or active work outrunning current integration and verification capacity, use [campaign direction](references/campaign-direction.md). +- For active or recorded multi-unit work with repeated repairs, competing implementations of one product behavior, technical or delivery machinery expanding after its target was met, technical and process growth without new evidence of the requested result, a unit that must create a new prerequisite of its own before it can finish, or active work outrunning current integration and verification capacity, use [campaign direction](references/campaign-direction.md). - For a disposable experiment that is cheaper than debate, use [prototype](references/prototype.md). - For a material interface or module boundary, or for an existing structure the owner asks to improve, use [codebase design](references/codebase-design.md). - For durable automated coverage, use [testing](references/testing.md). @@ -76,7 +76,7 @@ A tracked item is closed when its work is integrated, not when it is verified on Dispose of every material problem the work discovers. Fix it when it blocks the requested result or cannot be separated safely. When the request authorizes project changes, leave one deduplicated record where this project already tracks work, written so a later session can act on it without repeating the investigation. Otherwise report it. Recording a problem is not permission to work on it. -Where the requested result leaves open a material choice in what a person using the product gets, and available project evidence cannot settle it, that choice is the owner's: ask before building, each question carrying the option you recommend. Code and current behavior establish what exists. Issues, audits, recommendations, and proposed plans establish what was recorded or suggested; none by itself establishes that the owner wants a material capability kept, expanded, or prioritized. A request to audit, organize, plan, or carry that material forward does not adopt every proposal it contains. Adoption requires the current request to choose the product outcome, an authoritative product brief, or a recorded owner decision. When preparing a record exposes a material capability present only in code or a proposal, the current result asks whether that capability belongs in the product and recommends the product outcome; it does not replace that question with implementation discovery or defer it to the agent that will use the record. Ask in one round everything you can ask now, rather than one exchange at a time. A choice whose terms depend on an answer you do not have yet cannot be asked yet, so when their answer makes such a choice material, ask that one too, and build as soon as nothing material is left open. An answer is not permission to settle what it opened. Having asked, do not build, commit, or report as settled any behavior whose product meaning depends on the answer; a default, a switch, or anything else you could change later is still that choice made for them. Carry on meanwhile with the parts that do not depend on it. What the project cannot do yet answers no such question. That is a cost for the owner to weigh, not a reading for you to take. A product reading the project settled for you belongs in the result you report and in whatever record the work leaves, named with the alternative you did not take. Describing the behavior you built is not naming the choice, because the owner cannot correct an option they never learn existed. A result that hides a product choice you made is not finished. Telling them afterwards is not a substitute for asking: where you find you have already built a material product choice that was theirs, say so and ask, and that work stays unfinished until their answer and what you built agree. This paragraph gives the owner no ratification or reversal right over technical decisions. Where the request authorizes a record, their answer is one the project now carries: write it where the work is tracked, with what it settled and the option they turned down, before anything depending on it is built. +Where the requested result leaves open a material choice in what a person using the product gets, and available project evidence cannot settle it, that choice is the owner's: ask before building, each question carrying the option you recommend. Code and current behavior establish what exists. Issues, audits, recommendations, and proposed plans establish what was recorded or suggested; none by itself establishes that the owner wants a material capability kept, expanded, or prioritized. A record's claim that something must precede the owner's result is a proposal on the same footing, and a record this run wrote carries only the authority of the request it served; reading it back later adds none. A request to audit, organize, plan, or carry that material forward does not adopt every proposal it contains. Adoption requires the current request to choose the product outcome, an authoritative product brief, or a recorded owner decision. When preparing a record exposes a material capability present only in code or a proposal, the current result asks whether that capability belongs in the product and recommends the product outcome; it does not replace that question with implementation discovery or defer it to the agent that will use the record. Ask in one round everything you can ask now, rather than one exchange at a time. A choice whose terms depend on an answer you do not have yet cannot be asked yet, so when their answer makes such a choice material, ask that one too, and build as soon as nothing material is left open. An answer is not permission to settle what it opened. Having asked, do not build, commit, or report as settled any behavior whose product meaning depends on the answer; a default, a switch, or anything else you could change later is still that choice made for them. Carry on meanwhile with the parts that do not depend on it. What the project cannot do yet answers no such question. That is a cost for the owner to weigh, not a reading for you to take. A product reading the project settled for you belongs in the result you report and in whatever record the work leaves, named with the alternative you did not take. Describing the behavior you built is not naming the choice, because the owner cannot correct an option they never learn existed. A result that hides a product choice you made is not finished. Telling them afterwards is not a substitute for asking: where you find you have already built a material product choice that was theirs, say so and ask, and that work stays unfinished until their answer and what you built agree. This paragraph gives the owner no ratification or reversal right over technical decisions. Where the request authorizes a record, their answer is one the project now carries: write it where the work is tracked, with what it settled and the option they turned down, before anything depending on it is built. Where a plan carries work across several units and the request authorizes recording that plan — as the record the owner asked for, or as the state an authorized change needs to finish safely — it belongs where this project keeps tracked work rather than only in a local file or in this conversation. diff --git a/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md b/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md index ae4dfe1..e082428 100644 --- a/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md +++ b/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md @@ -2,7 +2,7 @@ Use this when the owner asks to carry on with what the project already has on record, rather than naming one thing to do. [Tracked work](tracked-work.md) owns the life of an individual item, including claiming it and what closing it requires; this owns crossing several of them in one session and knowing when to stop. -The frontier is what is takeable right now: open items whose blockers are all closed and that nothing else is already working on. Everything else is either blocked, claimed, or done. Work the frontier and nothing else, because an item you take out of order either duplicates a lane already running or builds on a result that does not exist yet. +The frontier is what is takeable right now: open items whose blockers are all closed, that nothing else is already working on, and that lie on the path from live state to the requested result. An item beyond that destination is out of this run's scope however ready it is: report it as takeable and deferred rather than resolving it on the way, because a record's word that it comes first is a proposal and not the request. Where the request names only the tracker and no result, recover the result from the records' own parent outcome or the product brief; a parent that names only machinery is a direction signal for [campaign direction](campaign-direction.md). Everything else is either blocked, claimed, deferred, or done. Work the frontier and nothing else, because an item you take out of order either duplicates a lane already running or builds on a result that does not exist yet. Take items in the order the project itself records. Where the tracker carries a priority, that order is the answer and re-deriving it wastes the pass that produced it. Where it carries none, take the oldest first. A recorded order you believe is wrong is a reason to run [prioritization](prioritization.md) and say so, never a reason to quietly take something else; reordering the owner's work without telling them is a product decision made in silence. @@ -16,6 +16,6 @@ Independent frontier items may run concurrently, one delegate each, under [deleg An item's stated outcome bounds what this pass delivers. It does not decide what may be changed, because the owner's request still decides that and a record is evidence of intent rather than authority. A material problem found while carrying an item out is disposed of under the kernel's rule for problems the work discovers, rather than absorbed into the item in hand; that is what keeps the item reviewable and keeps a run from becoming an open-ended sweep nobody asked for. -Stop when the frontier is empty, or when everything left on it is blocked on a decision only the owner can make, an action only they can grant, or an external party. Do not stop at the first such block: set it aside, carry on with what remains takeable, and bring the accumulated questions back in one round rather than one at a time. A lane that has stopped making measurable progress is stopped and diagnosed under [execution health](execution-health.md), not waited on and not retried a fourth time. +Stop when the frontier is empty, or when everything on it that reaches the result is blocked on a decision only the owner can make, an action only they can grant, or an external party. Do not stop at the first such block: set it aside, carry on with what remains takeable and still reaches the result, and bring the accumulated questions back in one round rather than one at a time. When nothing takeable reaches the result, the run ends there with the batch; filling that wait with enabling work the request did not name is the failure this rule exists to prevent, and the report says what was deliberately not taken and why. A lane that has stopped making measurable progress is stopped and diagnosed under [execution health](execution-health.md), not waited on and not retried a fourth time. Report the run as one reconciliation against what the owner asked for: what closed or reached review and on what evidence, what is blocked and on whom, what was newly recorded, and what is still takeable. A list of items touched is not that report, because it does not say whether the owner can now do anything they could not do before. diff --git a/plugins/skiphow/skills/skiphow/references/campaign-direction.md b/plugins/skiphow/skills/skiphow/references/campaign-direction.md index addec05..84e7c16 100644 --- a/plugins/skiphow/skills/skiphow/references/campaign-direction.md +++ b/plugins/skiphow/skills/skiphow/references/campaign-direction.md @@ -2,14 +2,14 @@ Use the owner's requested result as the measure of a multi-unit technical direction. Inspect only the proposed or active work when live evidence shows repeated repairs, competing implementations of one product behavior, internal machinery delaying the outcome it protects or expanding after its stated target was met, or active work that the current integration and verification path cannot absorb. Do not turn this check into a repository survey or absorb adjacent cleanup. -Recover the shared premise from the request, its parent record, recorded decisions, and live project state. For an existing direction, count evidence produced or discovered since the premise or its affected records were last settled. Mere size is not evidence. Code and tests normally grow while a result is being built, and justified security, money, recovery, or operational work may produce no immediate customer-visible change. The question is whether the next work removes a named obstacle to the result, proves a needed part of it, or only extends the mechanism and its own assurance. +Recover the shared premise from the owner's request as stated, the decisions the owner recorded, and live project state. A parent record or an audit finding says what somebody proposed, and a record this run wrote says only what this run decided; neither is the premise, and a record's claim that its work must precede the result is a proposal like any other. For an existing direction, count evidence produced or discovered since the premise or its affected records were last settled. Mere size is not evidence, and code and tests normally grow while a result is being built. The question is whether the next work removes a named obstacle to the result, proves a needed part of it, or only extends the mechanism and its own assurance. Security, money, recovery, and operational work answer it the same way as any other work, by naming the obstacle to the stated result that they remove; producing no customer-visible change is not itself an answer. When the signal appears during decomposition's existing cold read, include the direction there. Otherwise read the owner's outcome, live constraints, proposed or recorded units, recent repairs and conflicts, current product evidence, and relevant maintained capabilities without adopting the argument that produced the plan. Name the simplest coherent direction, which work to keep, replace, or retire, and what evidence would make that answer wrong. Do not add a second review pass. When replacing the direction would be expensive to undo, use [technical design](technical-design.md)'s existing independent read for that replacement decision. -The agent owns whether to keep, simplify, replace, or retire a technical direction when accepted product behavior stays the same. Apply [technical design](technical-design.md) to the replacement choice and [codebase design](codebase-design.md) when competing implementations or compatibility layers are the problem. Compare the options against the same constraints without treating sunk work as a reason to keep it. Reopen the decision when new evidence changes the engineering judgment. +The agent owns whether to keep, simplify, replace, retire, or defer a technical direction when accepted product behavior stays the same. A direction that is not on the path from live state to the requested result is deferred, not rebuilt: stop its lanes at their next safe boundary, leave one record of what it established and what it waits on, and take the next unit that reaches the result. Replacing the architecture of off-path work is not a response to its being off-path. Apply [technical design](technical-design.md) to the replacement choice and [codebase design](codebase-design.md) when competing implementations or compatibility layers are the problem. Compare the options against the same constraints without treating sunk work as a reason to keep it. Reopen the decision when new evidence changes the engineering judgment. -Ask only when no technically adequate option stays within the product behavior, scope, priority, committed cost, risk, privacy, and rollout the project has already settled, or when the next act is protected or human-only. Use [product decisions](product-decisions.md), bring one recommendation in product consequences, and keep technical alternatives out of the question. Ask for the unresolved product consequence, not approval of the architecture that produced it. A technical correction that stays inside settled product bounds needs no approval. +Ask only when no technically adequate option stays within the product behavior, scope, priority, committed cost, risk, privacy, and rollout the project has already settled, or when the next act is protected or human-only. Use [product decisions](product-decisions.md), bring one recommendation in product consequences, and keep technical alternatives out of the question. Ask for the unresolved product consequence, not approval of the architecture that produced it. Where deferring would carry the result past a risk or rollout consequence the owner has not settled, such as launching without a safeguard a record said must come first, that consequence is the question, put in product terms with one recommendation; the mechanism behind it is not. A technical correction that stays inside settled product bounds needs no approval. -Readiness does not create admission capacity. Admit only as many independent units as the run can keep isolated, integrate one by one, and revalidate against live state without sibling work invalidating their evidence. Prefer the next unit that can prove the owner's result over another unit that only expands enabling machinery. No fixed number is portable, and instruction text cannot impose a global limit across sessions it cannot see. +Readiness does not create admission capacity. Admit only as many independent units as the run can keep isolated, integrate one by one, and revalidate against live state without sibling work invalidating their evidence. Prefer the next unit that can prove the owner's result over another unit that only expands enabling machinery. When no takeable unit reaches the result, admission stops there; spare capacity admits nothing. No fixed number is portable, and instruction text cannot impose a global limit across sessions it cannot see. When a direction signal appears, stop affected lanes at their next safe boundary, keep independent work moving, and reconcile what active lanes established. Do not interrupt a non-idempotent external action halfway through. Where the request authorizes the affected records, correct or supersede them before recomputing the frontier. Otherwise report what the evidence invalidated. If the evidence opens a product choice, leave dependent records blocked on the owner's answer instead of rewriting the product outcome. Resume only after the technical cause is addressed, at the capacity current evidence supports. Without new evidence, continue without re-arguing settled direction. diff --git a/plugins/skiphow/skills/skiphow/references/execution-health.md b/plugins/skiphow/skills/skiphow/references/execution-health.md index 655dbc8..17086b0 100644 --- a/plugins/skiphow/skills/skiphow/references/execution-health.md +++ b/plugins/skiphow/skills/skiphow/references/execution-health.md @@ -8,7 +8,7 @@ Once a lane has a live handle, remains inside that expectation, and belongs to n Treat a lane as anomalous when it breaches that expectation, repeats the same failure without new evidence, stays active without measurable progress, grows in scope or diff unexpectedly, or produces evidence that conflicts with another source. Divergence between local results, the shared branch, and any external system is itself an anomaly. -Treat a work stream as anomalous when repairs or integration conflicts keep growing, sibling changes repeatedly invalidate one another, delivery machinery delays the product work it exists to protect, or technical and process work keeps expanding without new evidence of the requested result. Stop affected lanes at their next safe boundary, admit no new work to that stream, and apply [campaign direction](campaign-direction.md). Keep independent work moving. Resume only after the cause is addressed and at the capacity current evidence supports. +Treat a work stream as anomalous when repairs or integration conflicts keep growing, sibling changes repeatedly invalidate one another, a unit has to create a new prerequisite of its own before it can finish, delivery machinery delays the product work it exists to protect, or technical and process work keeps expanding without new evidence of the requested result. Stop affected lanes at their next safe boundary, admit no new work to that stream, and apply [campaign direction](campaign-direction.md). Keep independent work moving. Resume only after the cause is addressed and at the capacity current evidence supports. On a lane anomaly, stop that lane and keep independent work moving. Capture the smallest useful diagnostics, then classify the cause: implementation, test, environment, dependency, infrastructure, performance, coordination, specification, or external system. Correct the highest-leverage cause rather than the nearest symptom, rerun the smallest reproducer first, and resume only on new evidence. From 4f42c101c31f3cb3bbe4cb6fbf963c0b5be585a1 Mon Sep 17 00:00:00 2001 From: mzored Date: Wed, 2 Sep 2026 02:28:32 +0400 Subject: [PATCH 2/4] fix: address independent review of the frontier bound Tracker-only requests keep their records as the request; recorded owner order is not overridden; deferral records only where authorized; records carrying an owner answer keep that authority; evidence counts one drift session, not two, and states observations rather than demonstrated behavior. Co-Authored-By: Claude Fable 5.1 --- CHANGELOG.md | 6 +++--- docs/decisions.md | 2 +- docs/evidence.md | 2 +- plugins/skiphow/skills/skiphow/SKILL.md | 2 +- .../skills/skiphow/references/advancing-tracked-work.md | 4 ++-- .../skiphow/skills/skiphow/references/campaign-direction.md | 4 ++-- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c0db77d..4520db8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -12,9 +12,9 @@ All notable changes to SkipHow 2.x appear in this file. Earlier release notes re ### Evidence -- Two owner-run installed Codex campaigns on 2.13.0 drifted the same way. One asked for the tasks blocking first payments; its real blockers integrated in about seventeen hours and the remaining thirty went to one backup-recovery lineage of eight tracker items, each new one a prerequisite for resuming the last, ending uncommitted on a defect. The run admitted that lineage at hour one to use free capacity, thirty minutes after computing a money path that did not contain it, on the strength of an audit finding that said recovery precedes traffic. The other asked to exhaust the takeable frontier of a tracker built from a complexity audit; it closed twelve tooling and evidence items over twenty-three hours while the item the audit had called most important waited on the owner. A third run of eight hours on a scoped bug-and-staging request showed no deviation and its result was accepted. -- `campaign-direction` was opened in the first campaign three times and each pass replaced the architecture of the same direction. The 2.13.1 kernel wording reached that run mid-way and fifteen more hours followed on the same lineage. That is one session showing the released text in context and not stopping the drift; two sessions show the drift under the same text. The wording defects are readable in the files: premise recovered from records the run wrote, an exemption for recovery work, no defer outcome, and a frontier defined by blockers alone. Details are in `docs/evidence.md`. -- Every per-lane rule in `execution-health` worked as written in those runs. No numeric limit was added; a two-hour rule and a one-item-per-session rule were both refused again, see `docs/decisions.md`. +- Two owner-run installed Codex campaigns on 2.13.0 spent a day each on enabling machinery. One asked for the tasks blocking first payments; its real blockers integrated in about seventeen hours and the remaining thirty went to one backup-recovery lineage of eight tracker items, each new one a prerequisite for resuming the last, ending uncommitted on a defect. The run admitted that lineage at hour one to use free capacity, thirty minutes after computing a money path that did not contain it, on the strength of an audit finding that said recovery precedes traffic. The other asked to exhaust the takeable frontier of a tracker built from a complexity audit; it did exactly that, closing twelve tooling and evidence items over twenty-three hours while the item the audit had called most important waited on the owner, and nothing in the package made it say so or ask whether to go on. A third run of eight hours on a scoped bug-and-staging request showed no deviation and its result was accepted. +- `campaign-direction` was opened in the first campaign three times and each pass replaced the architecture of the same direction. The 2.13.1 kernel wording reached that run mid-way and fifteen more hours followed on the same lineage. That is one session showing the released text in context and not stopping the drift; the second shows the tracker-only request shape the package could not measure. The wording defects are readable in the files: premise recovered from records the run wrote, an exemption for recovery work, no defer outcome, and a frontier defined by blockers alone. Details are in `docs/evidence.md`. +- The transcripts show the per-lane rules of `execution-health` being applied in those runs. No numeric limit was added; a two-hour rule and a one-item-per-session rule were both refused again, see `docs/decisions.md`. - Behavior on the new wording is `UNVERIFIED` until a paired receipt or the owner's next long campaign; see `docs/evidence.md`. ## 2.13.1 (2026-08-31) diff --git a/docs/decisions.md b/docs/decisions.md index 6842736..fba3532 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -160,7 +160,7 @@ The owner required this correction to live inside SkipHow rather than depend on Current comparable projects keep the heavier mechanisms SkipHow rejects. [`improve-codebase-architecture`](https://github.com/mattpocock/skills/blob/6654f6b60cd9d5be8b54c6fafe44346dabeb3b76/docs/engineering/improve-codebase-architecture.md) is an owner-invoked periodic check that ends with the owner choosing a candidate. [Paperclip](https://github.com/paperclipai/paperclip/blob/3623a369aa15c3ccb9d696f176049db4ed241248/docs/start/core-concepts.md) keeps goals, budgets, strategy approval, and board pause in a control plane. [Superpowers' plan executor](https://github.com/obra/superpowers/blob/b36e0829c6d0140e93cfef2ca599b1b07d4a7797/skills/executing-plans/SKILL.md) returns to review inside a mandatory plan workflow. SkipHow adopts none of those control mechanisms. -Version 2.14.0 answers the first real campaigns run on that method, and they reproduced the drift with the method open. Two installed Codex campaigns on 2.13.0, described in [current evidence](evidence.md), spent thirty and twenty-three hours on enabling machinery after the owner's stated result had come to wait on the owner's own steps. `campaign-direction` was opened three times in the first and each pass replaced the architecture of the same backup-recovery direction. Three properties of its text made that the only reachable outcome. It recovered the premise from the parent record and recorded decisions, which the run itself or an earlier audit had written; the parent item said "before traffic" because the run wrote it that way at hour one. It exempted security, money, recovery, and operational work from producing customer-visible evidence, which was the class of work observed. Its outcomes were keep, simplify, replace, or retire a technical direction, with the owner asked only when no technically adequate option remained, so a rebuild from clean integration was always available and the sequencing question never reached anyone. `advancing-tracked-work` supplied the admission: the frontier was whatever was unblocked, the rule on a human block was to set it aside and carry on with what remained takeable, and nothing measured the remainder against the result. The 2.13.1 provenance sentence reached the first run mid-way and fifteen more hours followed, because it named capability scope and said nothing about a claim that work must come first or about records the run had written itself. +Version 2.14.0 answers the first real campaigns run on that method, and they reproduced the drift with the method open. Two installed Codex campaigns on 2.13.0, described in [current evidence](evidence.md), spent thirty and twenty-three hours on enabling machinery while the product result had come to wait on the owner's own steps; the first against its stated result, the second under a request that named the frontier itself as the result. `campaign-direction` was opened three times in the first and each pass replaced the architecture of the same backup-recovery direction. Retire was among its outcomes, and three properties of its text bear on why no pass reached it. It recovered the premise from the parent record and recorded decisions, which the run itself or an earlier audit had written; the parent item said "before traffic" because the run wrote it that way at hour one. It exempted security, money, recovery, and operational work from producing customer-visible evidence, which was the class of work observed. Its outcomes were keep, simplify, replace, or retire a technical direction, with the owner asked only when no technically adequate option remained, so a rebuild from clean integration was always available and the sequencing question never reached anyone. `advancing-tracked-work` supplied the admission: the frontier was whatever was unblocked, the rule on a human block was to set it aside and carry on with what remained takeable, and nothing measured the remainder against the result. The 2.13.1 provenance sentence reached the first run mid-way and fifteen more hours followed, because it named capability scope and said nothing about a claim that work must come first or about records the run had written itself. The change bounds the frontier by the requested result, adds defer as a direction outcome, deletes the exemption, extends the provenance rule to sequencing claims and to the run's own records, and names one further observable signal, a unit that must create a new prerequisite of its own before it can finish. Wayfinder in `mattpocock/skills` already had the frontier half of this, a ticket found to sit beyond the destination is ruled out of scope rather than resolved on the route, and the 2.6.0 adaptation had not taken it; it is taken now as an idea, in SkipHow's words. Two heavier answers were refused again. A whole-request time bound, which the owner's own follow-up analyst proposed as two hours without progress toward the user scenario, is a number no run can justify across projects. One item per session, which wayfinder keeps, was rejected in 2.6.0 and the owner's own prompt for the second campaign said not to stop after one task; the defect was never that the runs did several items but that the items were off the path. The product choice underneath, stop and hand back when the result waits on the owner and only enabling work remains, is the owner's, and they made it after seeing the runs: SkipHow is meant to act as the technical director, not to spend days on work a second agent then calls low priority. diff --git a/docs/evidence.md b/docs/evidence.md index f0f64d4..a2b11d4 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -234,7 +234,7 @@ The second asked the run to exhaust the takeable internal frontier of a tracker The third asked for reproducible bugs and staging blockers on one campaign, then a staging release. It ran 8.2 hours, mostly on the project's own release gate and two flaky tests, released to staging, and the owner checked staging the next morning and accepted it. It shows a scoped request staying scoped, and nothing else. -Counted in whole sessions: two show the drift under the same text; one of those shows the 2.13.1 kernel in context and not stopping it. Every per-lane rule in `execution-health` was followed, with twenty-minute checkpoints and three-attempt stops throughout; what no text supplied was a measure of the remaining takeable work against the owner's result once that result waited on the owner. The wording defects are readable in the files and are listed in the changelog and decision history. +Counted in whole sessions: one shows drift from the stated result under the shipped text, and shows the 2.13.1 kernel in context and not stopping it. The second complied with its request as written, because the request named the frontier itself as the result; what it shows is a request of that shape producing a day of tooling with no product evidence and no sentence in the package that would make the run say so or ask whether to continue. The transcripts show the per-lane rules of `execution-health` being applied throughout, twenty-minute checkpoints and three-attempt stops included; what no text supplied was a measure of the remaining takeable work against the owner's result once that result waited on the owner. The wording defects are readable in the files and are listed in the changelog and decision history. Version 2.14.0 bounds the frontier by the result, adds defer as a direction outcome, deletes the recovery exemption, extends the provenance rule to sequencing claims and to the run's own records, and names prerequisite-spawning as a signal. No paired receipt has been made on the new wording. diff --git a/plugins/skiphow/skills/skiphow/SKILL.md b/plugins/skiphow/skills/skiphow/SKILL.md index a39d13d..182f43d 100644 --- a/plugins/skiphow/skills/skiphow/SKILL.md +++ b/plugins/skiphow/skills/skiphow/SKILL.md @@ -76,7 +76,7 @@ A tracked item is closed when its work is integrated, not when it is verified on Dispose of every material problem the work discovers. Fix it when it blocks the requested result or cannot be separated safely. When the request authorizes project changes, leave one deduplicated record where this project already tracks work, written so a later session can act on it without repeating the investigation. Otherwise report it. Recording a problem is not permission to work on it. -Where the requested result leaves open a material choice in what a person using the product gets, and available project evidence cannot settle it, that choice is the owner's: ask before building, each question carrying the option you recommend. Code and current behavior establish what exists. Issues, audits, recommendations, and proposed plans establish what was recorded or suggested; none by itself establishes that the owner wants a material capability kept, expanded, or prioritized. A record's claim that something must precede the owner's result is a proposal on the same footing, and a record this run wrote carries only the authority of the request it served; reading it back later adds none. A request to audit, organize, plan, or carry that material forward does not adopt every proposal it contains. Adoption requires the current request to choose the product outcome, an authoritative product brief, or a recorded owner decision. When preparing a record exposes a material capability present only in code or a proposal, the current result asks whether that capability belongs in the product and recommends the product outcome; it does not replace that question with implementation discovery or defer it to the agent that will use the record. Ask in one round everything you can ask now, rather than one exchange at a time. A choice whose terms depend on an answer you do not have yet cannot be asked yet, so when their answer makes such a choice material, ask that one too, and build as soon as nothing material is left open. An answer is not permission to settle what it opened. Having asked, do not build, commit, or report as settled any behavior whose product meaning depends on the answer; a default, a switch, or anything else you could change later is still that choice made for them. Carry on meanwhile with the parts that do not depend on it. What the project cannot do yet answers no such question. That is a cost for the owner to weigh, not a reading for you to take. A product reading the project settled for you belongs in the result you report and in whatever record the work leaves, named with the alternative you did not take. Describing the behavior you built is not naming the choice, because the owner cannot correct an option they never learn existed. A result that hides a product choice you made is not finished. Telling them afterwards is not a substitute for asking: where you find you have already built a material product choice that was theirs, say so and ask, and that work stays unfinished until their answer and what you built agree. This paragraph gives the owner no ratification or reversal right over technical decisions. Where the request authorizes a record, their answer is one the project now carries: write it where the work is tracked, with what it settled and the option they turned down, before anything depending on it is built. +Where the requested result leaves open a material choice in what a person using the product gets, and available project evidence cannot settle it, that choice is the owner's: ask before building, each question carrying the option you recommend. Code and current behavior establish what exists. Issues, audits, recommendations, and proposed plans establish what was recorded or suggested; none by itself establishes that the owner wants a material capability kept, expanded, or prioritized. A record's claim that something must precede the owner's result is a proposal on the same footing, and a record this run wrote carries the authority of the request and of any owner answer it holds, and no more; reading it back later adds none. A request to audit, organize, plan, or carry that material forward does not adopt every proposal it contains. Adoption requires the current request to choose the product outcome, an authoritative product brief, or a recorded owner decision. When preparing a record exposes a material capability present only in code or a proposal, the current result asks whether that capability belongs in the product and recommends the product outcome; it does not replace that question with implementation discovery or defer it to the agent that will use the record. Ask in one round everything you can ask now, rather than one exchange at a time. A choice whose terms depend on an answer you do not have yet cannot be asked yet, so when their answer makes such a choice material, ask that one too, and build as soon as nothing material is left open. An answer is not permission to settle what it opened. Having asked, do not build, commit, or report as settled any behavior whose product meaning depends on the answer; a default, a switch, or anything else you could change later is still that choice made for them. Carry on meanwhile with the parts that do not depend on it. What the project cannot do yet answers no such question. That is a cost for the owner to weigh, not a reading for you to take. A product reading the project settled for you belongs in the result you report and in whatever record the work leaves, named with the alternative you did not take. Describing the behavior you built is not naming the choice, because the owner cannot correct an option they never learn existed. A result that hides a product choice you made is not finished. Telling them afterwards is not a substitute for asking: where you find you have already built a material product choice that was theirs, say so and ask, and that work stays unfinished until their answer and what you built agree. This paragraph gives the owner no ratification or reversal right over technical decisions. Where the request authorizes a record, their answer is one the project now carries: write it where the work is tracked, with what it settled and the option they turned down, before anything depending on it is built. Where a plan carries work across several units and the request authorizes recording that plan — as the record the owner asked for, or as the state an authorized change needs to finish safely — it belongs where this project keeps tracked work rather than only in a local file or in this conversation. diff --git a/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md b/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md index e082428..272ec0f 100644 --- a/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md +++ b/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md @@ -2,9 +2,9 @@ Use this when the owner asks to carry on with what the project already has on record, rather than naming one thing to do. [Tracked work](tracked-work.md) owns the life of an individual item, including claiming it and what closing it requires; this owns crossing several of them in one session and knowing when to stop. -The frontier is what is takeable right now: open items whose blockers are all closed, that nothing else is already working on, and that lie on the path from live state to the requested result. An item beyond that destination is out of this run's scope however ready it is: report it as takeable and deferred rather than resolving it on the way, because a record's word that it comes first is a proposal and not the request. Where the request names only the tracker and no result, recover the result from the records' own parent outcome or the product brief; a parent that names only machinery is a direction signal for [campaign direction](campaign-direction.md). Everything else is either blocked, claimed, deferred, or done. Work the frontier and nothing else, because an item you take out of order either duplicates a lane already running or builds on a result that does not exist yet. +The frontier is what is takeable right now: open items whose blockers are all closed, that nothing else is already working on, and that lie on the path from live state to the requested result. An item beyond that destination is out of this run's scope however ready it is: report it as takeable and deferred rather than resolving it on the way, because a record's claim that it must come first is a proposal unless the owner set it. Where the request names the tracker itself as the result, the records are the request and none is deferred on this ground; recover the result their parent outcome or the product brief names so the report can say what reached it, and when what remains takeable is only machinery while the item that would reach that result waits on the owner, that is a direction signal for [campaign direction](campaign-direction.md) to put to them, not a reason to take something else quietly. Everything else is either blocked, claimed, deferred, or done. Work the frontier and nothing else, because an item you take out of order either duplicates a lane already running or builds on a result that does not exist yet. -Take items in the order the project itself records. Where the tracker carries a priority, that order is the answer and re-deriving it wastes the pass that produced it. Where it carries none, take the oldest first. A recorded order you believe is wrong is a reason to run [prioritization](prioritization.md) and say so, never a reason to quietly take something else; reordering the owner's work without telling them is a product decision made in silence. +Take items in the order the project itself records. Where the tracker carries a priority, that order is the answer and re-deriving it wastes the pass that produced it. Order settles which takeable item comes first; it does not put an item on the path, and deferring one beyond the destination is reported, not a reordering. Where it carries none, take the oldest first. A recorded order you believe is wrong is a reason to run [prioritization](prioritization.md) and say so, never a reason to quietly take something else; reordering the owner's work without telling them is a product decision made in silence. Reconcile the technical direction as well as the items before taking the frontier. When live state shows repeated repairs at one boundary, competing implementations of one product behavior, or growing technical and delivery machinery without new evidence of the requested result, apply [campaign direction](campaign-direction.md) before admitting more work. Supersede affected technical records and recompute the frontier before executing more of that direction. Do not reopen settled direction without one of those signals. Recorded work is evidence of intent, not proof that its technical direction is still right. diff --git a/plugins/skiphow/skills/skiphow/references/campaign-direction.md b/plugins/skiphow/skills/skiphow/references/campaign-direction.md index 84e7c16..eb5bb25 100644 --- a/plugins/skiphow/skills/skiphow/references/campaign-direction.md +++ b/plugins/skiphow/skills/skiphow/references/campaign-direction.md @@ -2,11 +2,11 @@ Use the owner's requested result as the measure of a multi-unit technical direction. Inspect only the proposed or active work when live evidence shows repeated repairs, competing implementations of one product behavior, internal machinery delaying the outcome it protects or expanding after its stated target was met, or active work that the current integration and verification path cannot absorb. Do not turn this check into a repository survey or absorb adjacent cleanup. -Recover the shared premise from the owner's request as stated, the decisions the owner recorded, and live project state. A parent record or an audit finding says what somebody proposed, and a record this run wrote says only what this run decided; neither is the premise, and a record's claim that its work must precede the result is a proposal like any other. For an existing direction, count evidence produced or discovered since the premise or its affected records were last settled. Mere size is not evidence, and code and tests normally grow while a result is being built. The question is whether the next work removes a named obstacle to the result, proves a needed part of it, or only extends the mechanism and its own assurance. Security, money, recovery, and operational work answer it the same way as any other work, by naming the obstacle to the stated result that they remove; producing no customer-visible change is not itself an answer. +Recover the shared premise from the owner's request as stated, the decisions the owner recorded, and live project state. A parent record or an audit finding says what somebody proposed, and a record this run wrote says what this run decided, apart from an answer the owner gave that it carries; neither is the premise, and a record's claim that its work must precede the result is a proposal like any other. For an existing direction, count evidence produced or discovered since the premise or its affected records were last settled. Mere size is not evidence, and code and tests normally grow while a result is being built. The question is whether the next work removes a named obstacle to the result, proves a needed part of it, or only extends the mechanism and its own assurance. Security, money, recovery, and operational work answer it the same way as any other work, by naming the obstacle to the stated result that they remove; producing no customer-visible change is not itself an answer. When the signal appears during decomposition's existing cold read, include the direction there. Otherwise read the owner's outcome, live constraints, proposed or recorded units, recent repairs and conflicts, current product evidence, and relevant maintained capabilities without adopting the argument that produced the plan. Name the simplest coherent direction, which work to keep, replace, or retire, and what evidence would make that answer wrong. Do not add a second review pass. When replacing the direction would be expensive to undo, use [technical design](technical-design.md)'s existing independent read for that replacement decision. -The agent owns whether to keep, simplify, replace, retire, or defer a technical direction when accepted product behavior stays the same. A direction that is not on the path from live state to the requested result is deferred, not rebuilt: stop its lanes at their next safe boundary, leave one record of what it established and what it waits on, and take the next unit that reaches the result. Replacing the architecture of off-path work is not a response to its being off-path. Apply [technical design](technical-design.md) to the replacement choice and [codebase design](codebase-design.md) when competing implementations or compatibility layers are the problem. Compare the options against the same constraints without treating sunk work as a reason to keep it. Reopen the decision when new evidence changes the engineering judgment. +The agent owns whether to keep, simplify, replace, retire, or defer a technical direction when accepted product behavior stays the same. A direction that is not on the path from live state to the requested result is deferred, not rebuilt: stop its lanes at their next safe boundary, record what it established and what it waits on where the request authorizes that record and report it otherwise, and take the next unit that reaches the result. Replacing the architecture of off-path work is not a response to its being off-path. Apply [technical design](technical-design.md) to the replacement choice and [codebase design](codebase-design.md) when competing implementations or compatibility layers are the problem. Compare the options against the same constraints without treating sunk work as a reason to keep it. Reopen the decision when new evidence changes the engineering judgment. Ask only when no technically adequate option stays within the product behavior, scope, priority, committed cost, risk, privacy, and rollout the project has already settled, or when the next act is protected or human-only. Use [product decisions](product-decisions.md), bring one recommendation in product consequences, and keep technical alternatives out of the question. Ask for the unresolved product consequence, not approval of the architecture that produced it. Where deferring would carry the result past a risk or rollout consequence the owner has not settled, such as launching without a safeguard a record said must come first, that consequence is the question, put in product terms with one recommendation; the mechanism behind it is not. A technical correction that stays inside settled product bounds needs no approval. From 3ce981dc74f4b16dd7af77a089fd748d0223bfc2 Mon Sep 17 00:00:00 2001 From: mzored Date: Wed, 2 Sep 2026 02:35:46 +0400 Subject: [PATCH 3/4] fix: tracker-only requests report the machinery-only frontier, not stop Co-Authored-By: Claude Fable 5.1 --- .../skiphow/skills/skiphow/references/advancing-tracked-work.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md b/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md index 272ec0f..304dcca 100644 --- a/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md +++ b/plugins/skiphow/skills/skiphow/references/advancing-tracked-work.md @@ -2,7 +2,7 @@ Use this when the owner asks to carry on with what the project already has on record, rather than naming one thing to do. [Tracked work](tracked-work.md) owns the life of an individual item, including claiming it and what closing it requires; this owns crossing several of them in one session and knowing when to stop. -The frontier is what is takeable right now: open items whose blockers are all closed, that nothing else is already working on, and that lie on the path from live state to the requested result. An item beyond that destination is out of this run's scope however ready it is: report it as takeable and deferred rather than resolving it on the way, because a record's claim that it must come first is a proposal unless the owner set it. Where the request names the tracker itself as the result, the records are the request and none is deferred on this ground; recover the result their parent outcome or the product brief names so the report can say what reached it, and when what remains takeable is only machinery while the item that would reach that result waits on the owner, that is a direction signal for [campaign direction](campaign-direction.md) to put to them, not a reason to take something else quietly. Everything else is either blocked, claimed, deferred, or done. Work the frontier and nothing else, because an item you take out of order either duplicates a lane already running or builds on a result that does not exist yet. +The frontier is what is takeable right now: open items whose blockers are all closed, that nothing else is already working on, and that lie on the path from live state to the requested result. An item beyond that destination is out of this run's scope however ready it is: report it as takeable and deferred rather than resolving it on the way, because a record's claim that it must come first is a proposal unless the owner set it. Where the request names the tracker itself as the result, the records are the request and none is deferred on this ground; recover the result their parent outcome or the product brief names so the report can say what reached it, and when what remains takeable is only machinery while the item that would reach that result waits on the owner, the report leads with that, so the owner can reshape the request; it is not a reason to stop or to take something else quietly. Everything else is either blocked, claimed, deferred, or done. Work the frontier and nothing else, because an item you take out of order either duplicates a lane already running or builds on a result that does not exist yet. Take items in the order the project itself records. Where the tracker carries a priority, that order is the answer and re-deriving it wastes the pass that produced it. Order settles which takeable item comes first; it does not put an item on the path, and deferring one beyond the destination is reported, not a reordering. Where it carries none, take the oldest first. A recorded order you believe is wrong is a reason to run [prioritization](prioritization.md) and say so, never a reason to quietly take something else; reordering the owner's work without telling them is a product decision made in silence. From 0261423f615a5191b06cf31bb5eb8ed0091a6cbd Mon Sep 17 00:00:00 2001 From: mzored Date: Wed, 2 Sep 2026 02:51:48 +0400 Subject: [PATCH 4/4] docs: record the matched non-regression pair for 2.14.0 Co-Authored-By: Claude Fable 5.1 --- CHANGELOG.md | 2 +- docs/evidence.md | 6 ++++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 4520db8..0ca9a06 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,7 +15,7 @@ All notable changes to SkipHow 2.x appear in this file. Earlier release notes re - Two owner-run installed Codex campaigns on 2.13.0 spent a day each on enabling machinery. One asked for the tasks blocking first payments; its real blockers integrated in about seventeen hours and the remaining thirty went to one backup-recovery lineage of eight tracker items, each new one a prerequisite for resuming the last, ending uncommitted on a defect. The run admitted that lineage at hour one to use free capacity, thirty minutes after computing a money path that did not contain it, on the strength of an audit finding that said recovery precedes traffic. The other asked to exhaust the takeable frontier of a tracker built from a complexity audit; it did exactly that, closing twelve tooling and evidence items over twenty-three hours while the item the audit had called most important waited on the owner, and nothing in the package made it say so or ask whether to go on. A third run of eight hours on a scoped bug-and-staging request showed no deviation and its result was accepted. - `campaign-direction` was opened in the first campaign three times and each pass replaced the architecture of the same direction. The 2.13.1 kernel wording reached that run mid-way and fifteen more hours followed on the same lineage. That is one session showing the released text in context and not stopping the drift; the second shows the tracker-only request shape the package could not measure. The wording defects are readable in the files: premise recovered from records the run wrote, an exemption for recovery work, no defer outcome, and a frontier defined by blockers alone. Details are in `docs/evidence.md`. - The transcripts show the per-lane rules of `execution-health` being applied in those runs. No numeric limit was added; a two-hour rule and a one-item-per-session rule were both refused again, see `docs/decisions.md`. -- Behavior on the new wording is `UNVERIFIED` until a paired receipt or the owner's next long campaign; see `docs/evidence.md`. +- One matched isolated Claude Code pair on a five-minute fixture showed exact 2.13.1 and this package behaving the same: closing the items on the payment path, continuing past a human-gated item rather than stopping at it, marking audit-derived infrastructure as proposed, and putting the backups-before-money question to the owner as a risk choice. That is a non-regression receipt; the drift lives in day-long installed runs, so the improvement stays `UNVERIFIED` until the owner's next long campaign. See `docs/evidence.md`. ## 2.13.1 (2026-08-31) diff --git a/docs/evidence.md b/docs/evidence.md index a2b11d4..4e438b7 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -236,11 +236,13 @@ The third asked for reproducible bugs and staging blockers on one campaign, then Counted in whole sessions: one shows drift from the stated result under the shipped text, and shows the 2.13.1 kernel in context and not stopping it. The second complied with its request as written, because the request named the frontier itself as the result; what it shows is a request of that shape producing a day of tooling with no product evidence and no sentence in the package that would make the run say so or ask whether to continue. The transcripts show the per-lane rules of `execution-health` being applied throughout, twenty-minute checkpoints and three-attempt stops included; what no text supplied was a measure of the remaining takeable work against the owner's result once that result waited on the owner. The wording defects are readable in the files and are listed in the changelog and decision history. -Version 2.14.0 bounds the frontier by the result, adds defer as a direction outcome, deletes the recovery exemption, extends the provenance rule to sequencing claims and to the run's own records, and names prerequisite-spawning as a signal. No paired receipt has been made on the new wording. +Version 2.14.0 bounds the frontier by the result, adds defer as a direction outcome, deletes the recovery exemption, extends the provenance rule to sequencing claims and to the run's own records, and names prerequisite-spawning as a signal. + +One matched Claude Code pair was then run on a throwaway shop repository whose tracker held two takeable items on the payment path, one human-gated item on it, and two audit-derived infrastructure items off it, with the same Get5Stars-shaped prompt, settings sources and MCP disabled, the package passed as a session plugin, and the init event naming Claude Code 2.1.258, Opus 5, and the exact package path each time. Exact 2.13.1 and the candidate both did the same thing in about five minutes: closed the two path items, continued past the human gate rather than stopping at it, found that the payment adapter never charged anything and recorded that as the real blocker, marked both audit items proposed, put the backups-before-money question to the owner as a risk choice with a recommendation, and stopped with one batch. Both opened the frontier method. The pair shows that the new wording keeps a run moving through a human gate and does not add a question or a gate; it does not show the improvement, because the released text already behaved correctly on a five-minute fixture, as the 2.13.0 pairs also found. What the installed campaigns show and the fixture cannot is a run twenty hours in, holding records it wrote itself, with free delegate capacity and nothing left on the path. ## Still unverified -- Whether the 2.14.0 frontier bound and defer outcome stop a run when its result waits on the owner and only enabling work remains. Two installed 2.13.0 campaigns show the drift and one shows the 2.13.1 text in context without stopping it; no run has been made on the new wording, and the owner's standing preference is to wait for a real campaign rather than close the line with a fixture. +- 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. - 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.