Release 7.0.3: a correction reaches every place it applies

CHANGELOG.md

@@ -2,6 +2,27 @@
 
 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).
 
+## 7.0.3 (2026-10-21)
+
+### A correction reaches every place it applies
+
+- A defect or an owner's correction now covers every place that shares its cause or role. The lead fixes them all where the cause lives, with no guard per place. Before, the kernel spoke only of a failure that repeats.
+- In fast-fixes, feedback on one element, such as a selected component or a screenshot, is feedback on its role. The lead finds every element in that role, applies the change through the piece they share, and names the places it reached. It stays in one place only when the owner says so or the other places serve a different purpose.
+- In fast-fixes, the lead inspects the rendered result on every screen that renders what it changed, against the state it replaces, not only the screen the owner pointed at.
+- The kernel is 18 characters shorter. "Re-review only the fixes and stop when a round returns nothing that qualifies" left it, because the review playbook says the same and opens before any review or any work on findings.
+
+### Why
+
+One root session on 7.0.2 iterated on an interface for seven and a half hours. In about 24 of some 140 owner messages, the owner asked again for a change they had already asked for on another instance. Three times a shared piece changed for one screen broke another screen that had relied on it. The kernel and the workflow were in context throughout, because the host re-attached them after each of about twenty compactions, and the owner's wish for consistency survived in every summary. The wording was the gap. 6.3.4 said a second failure of one kind is a class whose other members get fixed, and its design playbook fixed the class with its sibling paths. 7.0.0 narrowed this to "when a failure repeats, fix the shared cause", which says nothing about the other instances that the decision record still promised and nothing about an owner's design correction. A comparable interface session on 6.3.4 drew one such complaint in 152 owner messages. The tasks differ, so that comparison proves no cause.
+
+Matt Pocock's skills and Superpowers, read as they stand today, scope a fix to the reported defect and say nothing about a shared component's other consumers. Nothing in either was worth taking.
+
+### Checks and evidence
+
+- This is a patch release. It restores what the decision record already promised: a fix reaches the other instances. Authority and protected-action boundaries are unchanged.
+- An isolated read-only Codex review ran one round, which also checked that the removed re-review clause keeps its path through the review playbook. It found nothing that qualified.
+- The owner declined paid model sessions for this release. No model sessions or clean-install runs were made, and the new behavior remains `UNVERIFIED`.
+
 ## 7.0.2 (2026-10-21)
 
 ### Reports the owner can read, follow-ups the lead carries

VERSION

@@ -1 +1 @@
-7.0.2
+7.0.3

docs/decisions.md

@@ -140,15 +140,15 @@ Rules, tools, and records earlier sessions made are the lead's own decisions, ev
 
 **Reopens when.** A run rewrites a rule the owner set in their own words, or keeps an agent-made rule or tool whose cost it has measured.
 
-### Fix the shared cause of a repeated failure
+### Fix every place that shares the cause or role
 
-When a failure repeats, the lead fixes its shared cause and the other instances, with no guard per instance.
+A defect or an owner's correction covers every place that shares its cause or role. The lead fixes them all where the cause lives, with no guard per place. In an iteration, feedback on one element applies to every element in its role unless the owner limits it, and the result is inspected on every screen that renders what changed.
 
-**Why.** Per-instance fixes sent the owner hunting the next one, and "fix the class" was read in the field as "add a guard for the class", so the rule names the cause as the fix, not a check.
+**Why.** Per-instance fixes sent the owner hunting the next one, and "fix the class" was read in the field as "add a guard for the class", so the rule names the cause as the fix, not a check. A rule that spoke only of repeated failures left an owner's design correction to the one element they pointed at, and a shared piece changed for one screen broke others nobody looked at.
 
 **Status.** `Contract`. Effect `UNVERIFIED`.
 
-**Reopens when.** A run sweeps unrelated surfaces on a first report or adds one guard per instance.
+**Reopens when.** A run changes places that serve a different purpose on a first report, adds one guard per place, or leaves the owner pointing at each instance of one correction.
 
 ### Design the journey and reuse maintained compositions
 

evals/cases.json

@@ -1,6 +1,6 @@
 {
   "corpus_version": 4,
-  "package_under_test": "7.0.2",
+  "package_under_test": "7.0.3",
   "purpose": "Synthetic cases for three separate instruments: activation, forced-activation CTO behavior, and host smoke. Every case names a positive success observable, the product result shared across comparison arms, and explicit required-absence events. Nothing here has been run.",
   "not_a_gate": "No model run gates a pull request. python scripts/check.py and the pytest suite validate shape and internal satisfiability and never start a model. A run happens only when the owner authorizes a paid receipt, under the limits recorded in run_limits. A deterministic check passing is never evidence of behavior.",
   "evidence_labels": {

evals/cto-cases.json

@@ -1,6 +1,6 @@
 {
   "instrument": "forced_activation_behavior",
-  "package_under_test": "7.0.2",
+  "package_under_test": "7.0.3",
   "suite_status": "not_run",
   "minimum_coverage": {
     "case_ids": [

evals/host-smoke.json

@@ -1,6 +1,6 @@
 {
   "instrument": "host_smoke",
-  "package_under_test": "7.0.2",
+  "package_under_test": "7.0.3",
   "scope": "external_candidate_receipts",
   "checks": {
     "clean_install": {

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

@@ -1,6 +1,6 @@
 {
   "name": "skiphow",
-  "version": "7.0.2",
+  "version": "7.0.3",
   "description": "Adaptive virtual CTO for founders and product owners using Claude Code or Codex. Describe the product outcome; SkipHow owns the technical lifecycle through verified completion.",
   "author": {
     "name": "mzored",

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

@@ -1,6 +1,6 @@
 {
   "name": "skiphow",
-  "version": "7.0.2",
+  "version": "7.0.3",
   "description": "Adaptive virtual CTO for founders and product owners using Claude Code or Codex. Describe the product outcome; SkipHow owns the technical lifecycle through verified completion.",
   "author": {
     "name": "mzored",

plugins/skiphow/skills/skiphow-fast-fixes/SKILL.md

@@ -11,6 +11,8 @@ Give the owner checked local results to inspect and revise while independent acc
 
 Use [delegation](../skiphow/references/delegation.md) for arriving requests, changed assignments, dependencies, isolation, and returns. Do simple work directly and group related tiny fixes. A message is not automatically a separate task or agent. Delegate independent investigation, implementation, or review when that lowers cost or useful latency within the owner's constraints, and keep the lead free to reconcile messages and results rather than tied up in long implementation a delegate could carry.
 
+Feedback on one element, such as a selected component or a screenshot, is feedback on its role. Find every element that plays that role, apply the change through the piece they share, and name the places it reached in your report. Keep it to the one place only when the owner's words do or the others serve a different purpose.
+
 Resolve engineering choices yourself. Use [product](../skiphow/references/product.md) for open product choices, plan only as much as the affected outcome needs, and keep working on what does not depend on a pending answer. Keep all accepted work accounted for through [tracked work](../skiphow/references/tracked-work.md), without a ticket for every small edit.
 
 Fix confirmed engineering findings at safe local boundaries while incoming accepted work keeps priority; an endless stream of feedback is no reason to defer every separable repair until delivery. Open [technical design](../skiphow/references/technical-design.md) when the current solution's fit is in question, and [testing](../skiphow/references/testing.md) when slow or flaky checks keep taxing progress. Improvements keep the same authority, preservation, check, and delivery boundary as requested fixes.
@@ -19,7 +21,7 @@ Fix confirmed engineering findings at safe local boundaries while incoming accep
 
 Learn the project's working base, isolation, and inspection conventions. Reuse this session's owned workspace. In a Git project, use an isolated branch and worktree where that protects other work. A project without Git, or a result that is not a page, needs neither new version control nor a server. Verify writer isolation and coordinate shared runtime resources under delegation; without safe isolation the lead is the only writer. Without delegates, work directly and report any independent review a change warranted but could not get.
 
-Combine accepted results locally under [integration](../skiphow/references/integration.md), and check the combined state with focused checks and review at the depth each change warrants under [review](../skiphow/references/review.md). Show coherent results as they become ready, with what changed and how you checked it. For an interface, inspect the rendered result and show the actual preview through a usable address or host tool. For other work, demonstrate the behavior or inspect the resulting artifact. Report an inspection you could not do as a gap. After showing a result, continue other accepted work; wait only when nothing can safely advance or the owner asks you to.
+Combine accepted results locally under [integration](../skiphow/references/integration.md), and check the combined state with focused checks and review at the depth each change warrants under [review](../skiphow/references/review.md). Show coherent results as they become ready, with what changed and how you checked it. For an interface, inspect the rendered result on every screen that renders what you changed, against the state it replaces, and show the actual preview through a usable address or host tool. For other work, demonstrate the behavior or inspect the resulting artifact. Report an inspection you could not do as a gap. After showing a result, continue other accepted work; wait only when nothing can safely advance or the owner asks you to.
 
 Before an edit or integration replaces a shown state, keep that state as a local checkpoint, even when feedback asks to revise it. In Git, commit only owned changes through the permitted commit path; elsewhere use the project's or host's safe recoverable mechanism. A message alone needs no checkpoint, and isolated work need not wait for one. If preservation is blocked, leave the shown state intact and continue only work independent of that change. An explicit instruction to discard or exclude a change takes precedence. Keep owned resources needed for continued inspection available, and record only what recovery needs under tracked work.
 

plugins/skiphow/skills/skiphow/SKILL.md

@@ -38,7 +38,7 @@ Everything you add stays, and the owner pays for it: code, tests, tooling, flags
 
 A test pays for itself when it catches a break a user or caller would notice. Before writing one, name the production change that would make it fail, or do not write it. Test behavior through the interface callers use, and mock only what you do not control. Do not write tests that pin text, constants, configuration, styling, or layout, or that check call order, mocks, your tooling, or other tests. Enforce code shape with the linter or type checker, never a test that reads source. A fixed bug gets one regression test only when it could recur unseen and a test at the real interface would catch it. When a refactor breaks tests but not behavior, the tests were wrong: replace them at the interface.
 
-A finding, a reviewer's included, is a claim to check. Act on it once you confirm it names a broken behavior or requirement, a security or data risk, or a simpler design. "Add a test", "cover more cases", "add a guard", and rewordings are not findings unless they name what breaks. Fix a confirmed finding in this run within authority; defer it only for an owner decision, a protected action, a blocker, or a cost that would hurt the outcome, and record why. When a failure repeats, fix the shared cause, not each instance with its own guard. Get independent review only where a mistake is costly to find or undo; re-review only the fixes and stop when a round returns nothing that qualifies. Stop improving when the next step buys the owner less than it costs.
+A finding, a reviewer's included, is a claim to check. Act on it once you confirm it names a broken behavior or requirement, a security or data risk, or a simpler design. "Add a test", "cover more cases", "add a guard", and rewordings are not findings unless they name what breaks. Fix a confirmed finding in this run within authority; defer it only for an owner decision, a protected action, a blocker, or a cost that would hurt the outcome, and record why. A defect or an owner's correction covers every place that shares its cause or role: fix them all where the cause lives, with no guard per place. Get independent review only where a mistake is costly to find or undo. Stop improving when the next step buys the owner less than it costs.
 
 Rules, tools, and records past sessions made, even an owner's technical pick, are your earlier decisions: revise them when they cost more than they protect. Only what the owner's own words require stays theirs. Write project instructions only for what code and tooling cannot show, never a rule that makes agents add artifacts.
 

site/evidence/index.html

@@ -56,11 +56,11 @@ <h1>Claims stop where the receipts stop.</h1>
       </div>
     </section>
 
-    <section class="section" aria-labelledby="matrix-title" data-observed-package-series="2.x" data-current-package="7.0.2" data-current-observed-scenarios="0">
+    <section class="section" aria-labelledby="matrix-title" data-observed-package-series="2.x" data-current-package="7.0.3" data-current-observed-scenarios="0">
       <div class="shell">
         <p class="section-label">01 &middot; Historical observations</p>
         <h2 id="matrix-title">What controlled 2.x runs showed.</h2>
-        <p>Historical observations below: 2.x only. Current package: 7.0.2. Retained current-package CTO scenarios with Observed receipts: 0 of 12. Eight historical 4.0.1 Claude run records remain incomplete. Current CTO scenario behavior is UNVERIFIED; configuration and deterministic checks do not establish model behavior.</p>
+        <p>Historical observations below: 2.x only. Current package: 7.0.3. Retained current-package CTO scenarios with Observed receipts: 0 of 12. Eight historical 4.0.1 Claude run records remain incomplete. Current CTO scenario behavior is UNVERIFIED; configuration and deterministic checks do not establish model behavior.</p>
         <div class="comparison-wrap wide-comparison" role="region" aria-label="Historical 2.x evidence table" tabindex="0">
           <table>
             <thead>