Clarify sufficient reuse and complexity review (6.1.2)

CHANGELOG.md

@@ -2,6 +2,38 @@
 
 All notable changes to SkipHow 2.x and later appear in this file. Earlier release notes remain available on [GitHub Releases](https://github.com/mzored/SkipHow/releases).
 
+## 6.1.2 (2026-10-03)
+
+### Changed
+
+- Simplification compares solutions that preserve complete accepted behavior by total cost. A short diff, built-in
+  feature, or existing dependency qualifies only when it meets the actual constraints.
+- A complexity finding names the redundant construct, its consequence, a cheaper replacement or justified deletion,
+  and the responsibilities that must survive. Existing design and verification paragraphs carry the clarification.
+- Three new arm-aware scenarios cover a shared invariant beyond the reported operation and paired native-capability
+  choices. The composition-review scenario now requires its maintained replacement and preserved selection, focus,
+  unsaved-change protection, and error recovery. The executable oracle accepts two correct repairs and rejects a
+  plausible repair limited to the reported operation.
+
+### Compatibility
+
+Patch release clarifying existing design and review responsibilities. The kernel, public skills, authority boundaries,
+installation behavior, and workflow contracts are unchanged. No new mode, hook, dependency, review stage, line-count
+target, or debt registry. Ponytail inspired the ideas; wording and fixtures are original.
+
+### Validation
+
+All new and strengthened behavioral scenarios remain `UNVERIFIED`. Deterministic oracle and corpus checks prove their
+own contracts, not agent behavior. No paid behavioral comparison was run and no measured savings or reliability gain
+is claimed. See [the evidence ledger](docs/evidence.md#612-sufficient-reuse-and-concrete-complexity-findings).
+The release validation matrix reports package checks, host schemas, clean installation, activation, continuity, and
+behavior separately; prose changes inside the existing package structure require no new clean-install experiment.
+
+An isolated read-only Codex review returned APPROVE with no qualifying findings or nonqualifying preferences.
+It confirmed preserved responsibilities, complete public-operation acceptance, valid comparison arms, and aligned
+version and evidence records. Both host and operating-system homes were isolated; the session header and context
+confirmed the configured model, read-only sandbox, and absence of personal skill or installed-plugin paths.
+
 ## 6.1.1 (2026-10-01)
 
 ### Changed

VERSION

@@ -1 +1 @@
-6.1.1
+6.1.2

docs/decisions.md

@@ -4,10 +4,11 @@ This page records the choices that still matter when SkipHow changes. Read it be
 
 ## Current decisions
 
-The live decisions, their premises, and what would reopen each. "Evidence" says what stands behind the decision today: `Observed` means a retained run showed it on the package that carried it, `Contract` means the shipped text encodes it and no run has tested that text, `Deterministic` means a check proves it on every run. Last reviewed 2026-10-01 against the 6.1.1 candidate. The [owner-outcome contract](outcome-contract.md) governs implementation choices.
+The live decisions, their premises, and what would reopen each. "Evidence" says what stands behind the decision today: `Observed` means a retained run showed it on the package that carried it, `Contract` means the shipped text encodes it and no run has tested that text, `Deterministic` means a check proves it on every run. Last reviewed 2026-10-03 against the 6.1.2 candidate. The [owner-outcome contract](outcome-contract.md) governs implementation choices.
 
 | Decision | Active rationale | Premises | Evidence | Reopens when |
 | --- | --- | --- | --- | --- |
+| Simplification preserves complete accepted behavior at the lowest total cost; a complexity finding names a redundant construct, its consequence, a cheaper replacement or justified deletion, and surviving responsibilities | A short diff or native capability can omit required behavior, and a deletion can remove necessary focus, change protection, or recovery | The owner requested clarification after the Ponytail comparison; existing design and verification references already own these judgments | Clarified `Contract` in 6.1.2; three new unrun scenarios and one strengthened review scenario; deterministic oracle checks are not model evidence | A receipt shows insufficient reuse accepted as complete, needless machinery retained, or a complexity finding losing a required responsibility |
 | Briefs convey a compact, evidenced handoff; bulky artifacts stay accessible by reference through review and return checks; corrections carry current evidence and unresolved findings; shortened check output retains the check's own terminal status | The lead can read a return-size rule without conveying it to the worker, and a filter can succeed while the check fails | Small results can stay inline; all findings, blockers, and uncertainty survive; the lead still verifies current state and destination; no file format, size quota, or new coordinator is required | Clarified `Contract` in 6.1.1 after three private installed sessions and owner-approved implementation; four unrun cases; causal and behavioral effects `UNVERIFIED` | A receipt shows lost findings, inaccessible proof treated as acceptance, blanket report files, repeated bulk copied into the coordinator, or a filter status accepted as check status |
 | Fast-fixes coordinates incoming local work across stacks, preserves shown states, and continues independent work; plan distinguishes unanswered choices from execution readiness; deploy-ready reconciles active work into a checked candidate | The owner explicitly requested live orchestration; the old fast-fixes required a browser, Git worktree, stop after every shown result, and deferred every pytest/e2e invocation | Existing delegation, tracking, integration, and verification cover the shared responsibilities; host controls determine concurrency and message timing; restrictions and protected-action grants survive upgrades | Owner-requested `Contract` in 6.0.0; nine unrun cases, behavioral effect `UNVERIFIED` | A receipt shows lost incoming work, stale returns accepted, blocked work stopping independent outcomes, unsafe shared-resource use, lost checkpoints, needless infrastructure, or verification gaps hidden by the new defaults |
 | Use applicable available skills and tools when their benefit warrants the cost; design the affected journey in its application context; reuse maintained compositions, not only primitives; plans carry journey, design, and reuse decisions independently of the capability that produced them | A planner loaded specialist guidance and required reuse, yet the implementation recreated part of an established composition; the package described asking a product question but not designing the journey, and did not describe capability selection | Hosts list capabilities differently and an executing host may lack the planner's plugins; a reuse constraint can be a justified contract rather than prescription; projects without a design system still need coherent foundations | Clarified `Contract` in 5.1.5 after two private 5.1.1 sessions and an owner request; behavioral effect `UNVERIFIED` | A receipt shows a recreated maintained composition despite a carried reuse constraint, specialist ceremony on settled or non-interface work, invented or installed capabilities, or owner questions about routine interaction details |
@@ -36,6 +37,32 @@ The live decisions, their premises, and what would reopen each. "Evidence" says
 
 The sections below are the history behind those rows: what each release tried, measured, and rejected. They are non-normative. Where a section and the index disagree, the index is current and the section records how it got there.
 
+## Sufficient reuse and concrete complexity findings
+
+Version 6.1.2 implements the owner's requested clarifications after inspecting Ponytail at
+`c982cd411abb53323c4baa1baa3c2f020b8d0b08`. No private sessions were inspected for this change, and the comparison
+established no SkipHow behavioral defect. The prior-art record credits ideas rather than copied wording or code.
+The owner selected a patch to the existing design and review guidance, with unrun regression scenarios and no paid
+behavioral comparison.
+
+The design paragraph now chooses among solutions that preserve complete accepted behavior, at the lowest total cost.
+Short diffs, built-in features, and existing dependencies must satisfy the actual constraints before they qualify.
+The review paragraph now makes an unnecessary-complexity finding concrete: the construct, consequence, cheaper
+replacement or justified deletion, and responsibilities to preserve. Both replace existing sentences behind existing
+triggers. The kernel, workflow contracts, authority, public skills, and installation behavior stay unchanged.
+
+| Responsibility | Execution path | Acceptance scenario |
+| --- | --- | --- |
+| Repair the cause beyond the reported manifestation | Existing diagnosis feedback loop and verification regression guidance | `bug-shared-balance-invariant`: both public operations preserve nonnegative balances and valid transfers and withdrawals |
+| Reuse a sufficient maintained capability | `technical-design` reuse guidance, with complete behavior as a constraint | `design-native-capability-sufficient` and `design-native-capability-insufficient`: native range selection in one case, maintained availability calendar in the other |
+| Remove evidenced duplication without losing behavior | `verification` review guidance | `ux-duplicated-composition-review`: maintained sheet and slot-selection body preserve selection, focus, unsaved-change protection, and error recovery |
+
+Leaving the wording unchanged and adding only cases would cost less editing, but would omit the clarification the
+owner requested. A new universal procedure, mode, hook, or debt ledger would add recurring process and state without
+evidence that capable agents need it. Treating fewer lines or native capability as an unconditional win would fail the
+complete-behavior constraint. The existing references cover the distinct failure domains without another module.
+No run shows that this wording changes decisions or saves effort; all four scenarios remain `UNVERIFIED`.
+
 ## Proportionate handoffs and terminal check evidence
 
 The owner approved an information-flow correction after three private installed longrun sessions were inspected,

docs/evidence.md

@@ -2,6 +2,33 @@
 
 This page separates package checks from observed model behavior. The full 2.0 evidence remains in the immutable [`v2.0.1` research snapshot](https://github.com/mzored/SkipHow/tree/1c811262e6acdbdc58a2ee862b54e0b8d3478eaa/docs/research/2026-08-27).
 
+## 6.1.2 sufficient reuse and concrete complexity findings
+
+The owner requested this clarification after a read-only comparison with Ponytail revision
+[`c982cd411abb53323c4baa1baa3c2f020b8d0b08`](https://github.com/dietrichgebert/ponytail/tree/c982cd411abb53323c4baa1baa3c2f020b8d0b08).
+No private chats were inspected and no local behavioral defect was demonstrated. The existing design and review
+paragraphs now state sufficient reuse at the lowest total cost and the evidence a complexity finding carries.
+[Prior art](prior-art.md#sufficient-reuse-and-complexity-review-in-612) records the adopted ideas, rejected mechanisms,
+and primary sources. [The decision](decisions.md#sufficient-reuse-and-concrete-complexity-findings) records the scope and alternatives.
+
+Three new arm-aware cases cover a shared invariant missed by repairing only the reported operation, sufficient native
+date selection, and a native date input that cannot express required availability. The existing composition-review case
+now requires its maintained replacement and preserved selection, focus handling, unsaved-change protection, and error
+recovery. The fixtures and wording are original. The executable balance oracle is checked against two correct repair
+shapes, the unfixed fixture, and a plausible transfer-only repair using the existing materializer, without Git setup
+or model execution. These deterministic results validate the oracle, not an agent's ability to satisfy it.
+
+All new and strengthened behavioral scenarios remain `UNVERIFIED`. No paid comparison was run, and no claim is made
+about measured savings, compaction, or improved model reliability. Package checks, host schema validation, installation,
+activation, continuity, and behavioral coverage retain separate rows in the release validation matrix. Prose changes
+inside the existing package structure do not require a new clean-install experiment.
+
+The independent read-only Codex review returned APPROVE with no qualifying findings or wording preferences. It
+inspected the candidate files and oracle without running models against the corpus. Host and operating-system homes
+were isolated, with a controlled reference to the minimum authentication file rather than a credential copy; that
+reference was removed on exit. The session header and context confirmed the configured model, read-only sandbox,
+and no personal skill or installed-plugin paths. Review establishes independent inspection, not behavioral evidence.
+
 ## 6.1.1 proportionate handoffs and check status
 
 Three private installed Claude Code longrun sessions were inspected, two on 6.1.0 and one on 6.0.0. They remain

docs/prior-art.md

@@ -14,6 +14,7 @@ SkipHow exists because I used the popular agent frameworks on my own work first
 | [GSD](https://github.com/open-gsd/gsd-core) | Fresh context per unit, dependency-aware parallelism, proportional depth | No large command tree, mandatory phases, or parallel state files |
 | [Mesa](https://github.com/msoedov/mesa) | Atomic ownership, event-driven wake-up | No fixed roles, embedded tracker, or company simulation |
 | [Autonomous PM](https://github.com/mlobo2012/autonomous-pm-plugin) | Provenance and separation of facts from assumptions | No standing personas or mandatory scoring |
+| [Ponytail](https://github.com/dietrichgebert/ponytail) | Sufficient reuse, concrete complexity findings, and regression probes beyond the reported path | Complete accepted behavior and total cost govern simplification; no line-count objective, mode, hook, or debt ledger |
 
 ## What went wrong for me
 
@@ -115,6 +116,32 @@ An idea from another project becomes a focused method or a kernel invariant only
 
 The reasoning behind each rule that survived is in [decision history](decisions.md), and what real runs have and have not shown is in [current evidence](evidence.md).
 
+## Sufficient reuse and complexity review in 6.1.2
+
+Read on 2026-10-03 at Ponytail revision `c982cd411abb53323c4baa1baa3c2f020b8d0b08`.
+Its [implementation skill](https://github.com/dietrichgebert/ponytail/blob/c982cd411abb53323c4baa1baa3c2f020b8d0b08/skills/ponytail/SKILL.md)
+and [review skill](https://github.com/dietrichgebert/ponytail/blob/c982cd411abb53323c4baa1baa3c2f020b8d0b08/skills/ponytail-review/SKILL.md)
+make reuse and complexity concrete. SkipHow adopts the ideas in original wording within its existing design and review
+paragraphs: compare sufficient solutions by total cost, and identify the unnecessary construct, consequence, replacement,
+and surviving responsibilities. Shorter code and native capabilities qualify only when accepted behavior survives.
+
+Ponytail's [comprehension experiment](https://github.com/dietrichgebert/ponytail/blob/c982cd411abb53323c4baa1baa3c2f020b8d0b08/benchmarks/results/2026-06-22-issue-245-217-comprehension.md)
+uses unreported related paths to distinguish a general repair from one matching the complaint. SkipHow's original
+synthetic fixture applies that question to two public balance operations; the oracle grades behavior and accepts
+different repair shapes. Paired date-selection probes distinguish sufficient native reuse from omitted availability
+requirements. The existing duplicated-composition probe requires the maintained replacement and preserved focus,
+unsaved-change protection, and recovery. These cases have not been run on a model.
+
+SkipHow does not adopt a shortest-diff or line-count objective, unconditional standard-library or native reuse, a rigid
+one-test rule, intensity modes, hook-managed state, or a persistent debt registry. Existing operation guidance already
+covers known ceilings and triggers, so no parallel rule is added. The owner's request authorizes the clarifications;
+inspection alone does not demonstrate a local behavior defect or justify a universal procedure.
+
+The upstream [agentic report](https://github.com/dietrichgebert/ponytail/blob/c982cd411abb53323c4baa1baa3c2f020b8d0b08/benchmarks/results/2026-06-18-agentic.md)
+and [cost report](https://github.com/dietrichgebert/ponytail/blob/c982cd411abb53323c4baa1baa3c2f020b8d0b08/benchmarks/results/2026-06-17-cost-verification.md)
+describe their own tasks, models, and measurements. They were not reproduced here and establish neither SkipHow's
+behavior nor its savings. Ponytail is MIT licensed; no source text or code is copied or adapted in this release.
+
 ## Proportionate delegation handoffs in 6.1.1
 
 Read on 2026-10-01. Claude Code's [subagent guidance](https://code.claude.com/docs/en/sub-agents#run-parallel-research)

evals/README.md

@@ -61,6 +61,19 @@ A case is run only when the owner authorizes a paid receipt.
 
 ## The arms
 
+The 6.1.2 simplification probes remain `UNVERIFIED`. `bug-shared-balance-invariant` uses `shared-balance`:
+the report names transfer, while acceptance exercises transfer and withdrawal with valid, exact-balance, excessive,
+zero, and negative amounts. The grader uses the fixture's original `tests/balance_checks.py` against the delivered
+implementation rather than trusting an edited oracle. `tests/test_simplification_fixtures.py` materializes scratch
+fixtures through the existing helper and proves that the oracle accepts two complete repair shapes and rejects both
+the unfixed implementation and a plausible transfer-only repair. It creates no Git repositories and starts no models.
+
+`design-native-capability-sufficient` and `design-native-capability-insufficient` use separate settled requirement
+sections of `planning-readiness` as read-only recommendation probes. They reward native range selection where sufficient
+and the maintained availability calendar where disabled dates are required, while rejecting omitted behavior and needless
+machinery. The strengthened `ux-duplicated-composition-review` requires the maintained sheet replacement and preserved
+selection, focus, unsaved-change protection, and error recovery. These synthetic probes do not prove browser behavior.
+
 The `ux-*` cases and `specialist-non-interface-task` use later sections of `planning-readiness`. Their capability lists
 are synthetic text, so they probe whether a plan or review applies suitable specialist guidance, preserves decisions
 across hosts, selects maintained compositions, designs proportionately, and surfaces hidden product choices. They do not