Clarify planning boundaries and share review continuation for 6.3.1

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.3.1 (2026-10-07)
+
+Clarify planning boundaries and share independent-review continuation between plan and longrun.
+Interview answers and grants for future actions remain execution-record inputs, not an implicit switch to
+implementation. An explicit request to plan and then execute still permits that transition when preparation
+is ready, within host restrictions and existing grants, without asking again. Planning reports account for
+any implementation candidate already created.
+
+Move actual workload assessment into task drafting and keep independent challenge of every task and the
+whole specification. Preserve cohesive work, automated transformations, engineering authority, and whole-scope
+preparation. Technical criteria do not acquire an owner-approval gate.
+
+Verification now owns reviewer and implementer continuity, replacement evidence, and targeted independent
+review of material corrections and affected consequences. Briefs convey the existing scope, proof, progress,
+and return contract. Reuse valid evidence; incomplete review limits readiness. No fixed timer, role roster,
+new module, tracker, hook, or public interface is added. This PATCH clarifies existing promised behavior.
+
+One private installed session informed the change but proves no wording cause or comparative benefit.
+Five new synthetic cases cover the phase boundary, engineering authority, correction defects, replacement,
+and incomplete review, while existing task-sizing probes remain. The owner declined paid behavioral runs;
+model behavior, reliability, speed, and savings remain `UNVERIFIED`. Package shape and installation are unchanged.
+See [current evidence](docs/evidence.md#631-planning-boundaries-and-review-continuation).
+
+Independent isolated Codex source review identified a package-only review prerequisite incorrectly applied
+to the base-host eval arm and three stale instrument version fields. Both were confirmed and corrected;
+the same reviewer approved the targeted correction review with no remaining qualifying findings. No
+findings were rejected. The full local gate had 384 passes and 22 version-field failures; all 62 affected
+corpus and package/document checks passed after correction. Together these provide the local gate evidence.
+Claude schema validation passed; the pinned Codex schema validator runs in CI. Paid behavioral runs,
+clean-install sessions, and current activation/continuity observations were not run.
+
+
 ## 6.3.0 (2026-10-05)
 
 Plan prepares the whole requested scope and keeps unanswered product interviews open. Useful independent preparation

VERSION

@@ -1 +1 @@
-6.3.0
+6.3.1

docs/decisions.md

@@ -4,12 +4,12 @@ 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-05 against the 6.3.0 candidate. The [owner-outcome contract](outcome-contract.md) governs implementation choices.
+The live decisions, their premises, and what would reopen each. "Evidence" says what stands behind the decision today: `Observed` means a retained run showed it on the package that carried it, `Contract` means the shipped text encodes it and no run has tested that text, `Deterministic` means a check proves it on every run. Last reviewed 2026-10-07 against the 6.3.1 candidate. The [owner-outcome contract](outcome-contract.md) governs implementation choices.
 
 | Decision | Active rationale | Premises | Evidence | Reopens when |
 | --- | --- | --- | --- | --- |
 | Technical supervision looks across the authorized project, questions current solutions, and resolves supported engineering findings at safe boundaries, including iteration, while prioritizing the owner's outcome and stopping when further benefit does not justify cost | Passing a narrow task can leave material risk or recurring cost elsewhere; a delivery-only repair sentence can defer separable work throughout an open feedback stream | Existing authority, owner decisions, protected actions, read-only restrictions, and delivery boundaries still govern; evidence directs attention without an exhaustive audit; complete behavior and distinct verification evidence survive simplification | Clarified `Contract` in 6.2.1; two private installed sessions support inspection of cost and continuity, not causality; synthetic opportunity, coupling, setup, and continuation probes remain `UNVERIFIED` | A receipt shows speculative redesign, authority expansion, endless improvement, missed supported risks, blind extension of unsuitable code, or lost unique evidence |
-| Plan prepares the whole requested scope, keeps unanswered product interviews open, reviews actual one-agent workload, and returns an explicit short launch suited to the work | A recorded question is not completed preparation; an independent task does not authorize substituting a smaller execution scope; one common outcome can conceal heterogeneous work | Only the owner reduces the requested scope; an owner-selected workflow is preserved, and the lead owns default workflow selection, technical questions, slicing, and routing; available host controls govern waiting and no scheduler is added; mature paths and uniform automated work need no artificial foundation or quotas | Owner-requested `Contract` in 6.3.0, extending 6.2.0; one private 6.2.1 session shows a pending interview and partial handoff, not causality; new continuation and framing probes and behavioral improvement `UNVERIFIED` | A receipt shows premature launch, lost follow-up, assumptions accepted as product choices, endless or technical interviews, needless fragmentation, omitted safety, or expanded authority |
+| Plan prepares the whole requested scope, keeps unanswered product interviews open, reviews actual one-agent workload, and returns an explicit short launch suited to the work | A recorded question is not completed preparation; an independent task does not authorize substituting a smaller execution scope; one common outcome can conceal heterogeneous work | Only the owner reduces the requested scope; an owner-selected workflow is preserved, and the lead owns default workflow selection, technical questions, slicing, and routing; available host controls govern waiting and no scheduler is added; mature paths and uniform automated work need no artificial foundation or quotas | Clarified `Contract` in 6.3.1 with a shared correction-review loop and explicit planning transition; owner-requested 6.3.0 extends 6.2.0; one private 6.2.1 session shows a pending interview and partial handoff, not causality; new continuation and framing probes and behavioral improvement `UNVERIFIED` | A receipt shows premature launch, lost follow-up, assumptions accepted as product choices, endless or technical interviews, needless fragmentation, omitted safety, or expanded authority |
 | 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 |
@@ -38,6 +38,44 @@ 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.
 
+## Planning boundaries and shared review continuation
+
+Version 6.3.1 clarifies the existing planning and independent-review contracts. One private installed Claude
+session on 6.3.0 showed repeated broad review, implementation during planning after broad owner permission,
+owner-facing engineering approval, and final material corrections without independent re-review. The kernel,
+delegation, diagnosis, and verification rules were present. These observations do not establish a loading failure,
+a wording cause, or prevalence. Technical authority and whole-task sizing already had explicit instructions.
+
+The narrower text gap was that plan required review of every published task and resolution of findings without
+stating how correction coverage reaches that published candidate. Longrun explicitly preserved reviewer continuity
+and correction review. Both now use verification's shared loop. It carries candidate identity, findings, dispositions,
+affected consequences, still-applicable evidence, and the existing delegation/progress contract. Material corrections
+receive independent review; an interruption or missed expectation cannot count as reviewed readiness. Retaining an
+implementer and reviewer, or giving replacements their evidence, survives in that common execution path.
+
+Plan distinguishes grants recorded for a future executor from an explicit request to execute after preparation.
+The latter remains valid without another approval, subject to host restrictions and protected-action authority.
+The default still ends at the prepared plan and launch. The report accounts for any already-created implementation.
+Workload assessment moves from the review paragraph into drafting; review independently challenges it. No owner
+approval of technical criteria, task granularity, or engineering methods is introduced.
+
+Three candidates were weighed. Tests alone leave the correction-continuation ambiguity. The selected clarification
+reuses existing references, consolidates duplicated longrun instructions, and puts sizing where tasks are formed.
+Mandatory timers, reviewer roles, prompt templates, and another state registry would impose recurring work unsupported
+by one session. The recurring cost is limited to selected planning and independent review, with no new module or
+kernel policy. Review prose was tightened within the measured one-view limit while preserving its responsibilities.
+
+Original scenarios cover broad planning permission versus explicit execution, technical criteria beside a missing
+protected grant, unchanged evidence beside an introduced correction defect, and reviewer replacement with interrupted
+integration evidence. Existing heterogeneous, sampled, cohesive, and automated task-size cases remain intact. The
+[prior-art comparison](prior-art.md#planning-review-continuation-in-631) supports scoped correction review but does not
+prove benefit. The [evidence record](evidence.md#631-planning-boundaries-and-review-continuation) keeps behavior and savings
+`UNVERIFIED`; the owner declined paid behavioral runs. Reopen this decision if receipts show premature execution,
+unnecessary reapproval, missed consequences outside a fix diff, false readiness, or repeated broad reviews.
+
+This is PATCH: promised planning-only behavior, explicit owner authority, material independent review, installation,
+and public interfaces remain. No new workflow, default protected effect, format, or capability is added.
+
 ## Whole-scope planning and interview continuation
 
 Version 6.3.0 implements the owner's request that plan fully prepare the requested work before handing it to longrun,

docs/evidence.md

@@ -2,6 +2,51 @@
 
 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.3.1 planning boundaries and review continuation
+
+One private installed Claude Code session on exact 6.3.0 was inspected on 2026-10-07, including subagent briefs,
+returns, actual tool-result text, and owner input delivered inside the running turn. The current package text matched
+the tag. Planning instructions arrived on invocation; the kernel and relevant shared references were loaded. Two
+compactions occurred. This is one uncontrolled session, not multiple independent observations.
+
+A later reviewer was assigned broad fact checking again and returned its first final report about 25.5 minutes after
+dispatch, following an owner intervention. Its findings included material defects, so duration alone does not establish
+waste. Earlier review introduced an incorrect technical suggestion, which the reviewer later retracted. The final
+material corrections were published without targeted independent re-review. An implementation candidate had already
+been created and saved remotely, while the final answer both denied starting implementation and listed that candidate.
+Broad owner permission preceded implementation; it is not evidence of action without any possible execution reading.
+The engineering-approval request conflicted with the existing authority boundary, rather than exposing a missing rule.
+
+The source ambiguity is narrower than these observations: plan did not explain correction coverage of its published
+candidate as explicitly as longrun, and grants made while preparing future execution were insufficiently distinguished
+from a request to switch workflows. The owner selected a clarification and shared-loop consolidation. Existing workload
+assessment now appears during drafting, with independent challenge retained. No causal improvement is claimed.
+
+Five new original synthetic cases use an overlay, leaving earlier fixture identities unchanged. They cover planning
+permission, explicit plan-then-execute with an honest unavailable-review path, lead-owned technical criteria beside a
+missing protected grant, a correction that leaves one defect and introduces another, and partial replacement review.
+The existing corpus validator checks arm semantics and satisfiability. These are instruments, not behavior receipts.
+The owner declined paid behavioral comparisons; behavior, reliability, latency, and savings remain `UNVERIFIED`.
+Private transcript text, identifiers, project details, and raw logs are not published.
+
+The [decision](decisions.md#planning-boundaries-and-shared-review-continuation) records alternatives and surviving
+responsibilities. Package shape, activation, and installation are unchanged. The release matrix reports the deterministic
+gate and each host schema separately; unrun installs, activation, continuity, and behavioral coverage stay `UNVERIFIED`.
+
+Independent read-only Codex source review used isolated operating-system and host homes, a minimal temporary
+authentication reference rather than copied credentials, and the configured model at high effort. An empty-context
+control and both review turns showed no personal skill or installed-plugin paths. The first review confirmed two
+defects: a package-only review prerequisite imposed on the base-host oracle, and three stale instrument versions.
+Both were fixed. The same reviewer returned APPROVE after examining only the correction diff and its consequences;
+no finding was rejected. Source review is not a behavioral receipt. Its stated limits included private-source and
+external-source verification, which remained the maintainer's inspection responsibility.
+
+The pinned local environment's full gate produced 384 passes and 22 failures on instrument version mismatches.
+After fixing those fields and the oracle, all 62 affected corpus and package/document checks passed, with a clean
+`git diff --check`. The remaining full-run evidence applies to unchanged inputs. Local strict Claude schema validation
+passed. The pinned Codex validator is supplied by CI. No host installation mechanism changed, and no new clean-install
+or behavioral sessions were run. Release-runner results are published in the release validation matrix.
+
 ## 6.3.0 whole-scope planning and open interviews
 
 One private installed Codex session on exact 6.2.1 was inspected on 2026-10-05. The complete plan instructions arrived