Prepare workload-bounded parallel plans and short launches for 6.2.0

CHANGELOG.md

@@ -2,6 +2,43 @@
 
 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.2.0 (2026-10-03)
+
+### Changed
+
+- Plan's existing independent task review assesses context, heterogeneous implementation, manual output, checks,
+  review, and integration together. A single outcome is insufficient proof of one-agent feasibility; supported size
+  findings preserve acceptance and dependencies in smaller independently verifiable slices. Large uniform automated
+  changes can stay whole, and implementation, checks, and handoff steps without separate outcomes remain one task.
+- Work lacking an established component path starts with a thin real slice and only its necessary structure, preserving
+  safety, integrity, and compatibility. Mature paths are reused. The whole accepted scope remains prepared in advance,
+  with actual blockers, independent preparation, shared resources, and assumptions to recheck at dispatch.
+- Ready plans return an explicit host-native longrun invocation and one delivery sentence referencing accepted records
+  and destination. An owner-selected workflow survives. Only otherwise-missing project, subset, or run constraints are
+  added, with authorization provenance; task content and SkipHow policy stay in their sources.
+- Arm-aware scenarios cover workload boundaries and sampling, useful grouping, first-path and mature planning,
+  parallel readiness and resources, short launches, selected workflows, and blocked sources or preparation.
+
+### Compatibility
+
+Compatible MINOR capability in the optional plan workflow. Public skill names, kernel, authority boundaries, package
+layout, installation, and existing execution workflows are unchanged. No new stage, module, scheduler, size score,
+quota, inventory gate, or sizing ledger. Unfinished preparation remains blocked, and launch text grants no new actions.
+Tracer bullets and to-tickets inspired the ideas; wording and fixtures are original.
+
+### Validation
+
+New behavioral scenarios and improvement claims remain `UNVERIFIED`. No paid behavioral comparison was run, and no
+context-fit, cost, or parallel-execution gain is claimed. See [the evidence ledger](docs/evidence.md#620-workload-based-planning-and-short-launches).
+The release matrix separates deterministic checks, host schemas, installation, activation, continuity, and behavior.
+Prose changes within the existing package structure require no fresh clean-install experiment.
+
+An isolated read-only Codex review of source candidate `af8223e` returned APPROVE with no qualifying findings or
+nonqualifying suggestions. It confirmed surviving responsibilities, valid comparison arms, and aligned 6.2.0 records.
+Both host and operating-system homes were isolated; the transcript confirmed the configured model, read-only sandbox,
+and absence of personal skill or installed-plugin paths. The minimum authentication reference and review scratch were
+removed on exit. Claude strict schema validation passed locally; the pinned Codex validator remains required in CI.
+
 ## 6.1.2 (2026-10-03)
 
 ### Changed

README.md

@@ -132,6 +132,22 @@ Use these when you know the work pattern you want. Ordinary requests still need
 
 Explicit `skiphow-plan` invocation requests durable planning records within the authorized audience. A read-only constraint overrides that default. Automatic selection for an ordinary planning question does not grant tracker writes. Unavailable tracking leaves complete issue drafts and a blocker.
 
+Plan reviews each assignment's actual context, implementation, verification, review, and integration load. It prepares
+the whole accepted scope as bounded vertical slices with real dependencies and parallel work. A new component path
+starts with a thin working slice; a mature project reuses its established path. The planner keeps large checkable
+automated changes whole and avoids steps that have no independently verifiable result.
+
+Ready plans end with a short launch using the target host's explicit invocation syntax. Longrun is the default unless
+you already chose another workflow. For example, with a concrete accepted plan and destination:
+
+```text
+$skiphow-longrun
+Deliver the accepted implementation scope in issue #42 to the development branch.
+```
+
+Tasks carry requirements and dependencies, so the launch adds only otherwise-missing project, subset, or run constraints.
+Preparation and inaccessible sources remain explicit blockers, and the prompt creates no new authorization.
+
 Fast-fixes accepts new changes, revisions, and cancellations while accepted work continues. The lead handles tiny fixes directly and delegates independent work when that pays, with verified writer isolation and coordination of shared resources. It shows an inspected preview, demonstrated behavior, or an artifact as appropriate to the project; a browser and Git are not prerequisites. Before replacing a shown state, it preserves a recoverable checkpoint, using local commits in Git projects. Focused tests may run, including pytest or browser tests, while full delivery gates wait. Explicit requests to wait or restrict tests still govern.
 
 Acceptance keeps fast-fixes in local iteration. Say `deploy-ready` or `clean` to reconcile the delivery set, including running assignments, and begin preparation. Corrections receive affected review and revalidation; later work stays accounted for outside that delivery. Say `deploy prod` to authorize the specified production release. Preparation and contextual clean alone do not authorize production or arbitrary deletion. Hosts determine when messages arrive and which delegation or continuation controls exist; the plugin adds no background scheduler.

SECURITY.md

@@ -4,8 +4,8 @@
 
 | Version | Supported |
 | --- | --- |
-| 6.1.x | Yes |
-| 6.0.x, 5.1.x, 5.0.x, 4.8.x, 4.7.x, 4.6.x, 4.5.x, 4.4.x, 4.3.x, 4.2.x, 4.1.x, and 4.0.x | No; upgrade to 6.1.x, reviewing the 6.0 iteration defaults when coming from 5.x or earlier; existing authorization stays unchanged |
+| 6.2.x | Yes |
+| 6.1.x, 6.0.x, 5.1.x, 5.0.x, 4.8.x, 4.7.x, 4.6.x, 4.5.x, 4.4.x, 4.3.x, 4.2.x, 4.1.x, and 4.0.x | No; upgrade to 6.2.x, reviewing the 6.0 iteration defaults when coming from 5.x or earlier; existing authorization stays unchanged |
 | 3.0.x and earlier | No |
 
 Security review covers the packaged owner skill, its linked playbooks, host manifests,

VERSION

@@ -1 +1 @@
-6.1.2
+6.2.0

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-03 against the 6.1.2 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.2.0 candidate. The [owner-outcome contract](outcome-contract.md) governs implementation choices.
 
 | Decision | Active rationale | Premises | Evidence | Reopens when |
 | --- | --- | --- | --- | --- |
+| Plan reviews actual one-agent workload, prepares bounded vertical slices across the accepted scope, proves an absent component path with a thin real slice, and returns an explicit short longrun launch unless the owner selected another workflow | One common outcome can conceal heterogeneous work; a generic short-prompt instruction permits missing invocation or repeated task and policy content | The owner requested these optional plan behaviors; existing delegation and longrun own execution, reslicing, writer isolation, and resource coordination; mature paths and uniform automated work need no artificial foundation or quotas | Owner-requested `Contract` in 6.2.0; two private 6.1.1 planning sessions show differing handoffs, not causal improvement; new scenarios and behavioral benefit `UNVERIFIED` | A receipt shows oversized assignments passing review, unnecessary fragmentation, invented blocking edges, safety deferred from a first slice, repeated launch content, or authority lost or expanded |
 | 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 |
@@ -37,6 +38,47 @@ 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.
 
+## Workload-based planning and a short execution launch
+
+Version 6.2.0 implements the owner's accepted planning contract. Two private Codex sessions carrying the full 6.1.1
+plan text returned different handoffs: a short launch omitted explicit longrun, while another supplied a longer one
+after an owner follow-up and repeated execution guidance. The previous workflow required only a short prompt; this
+establishes freedom in its shape, not violation of a prior explicit-longrun default or a general model failure rate.
+The workload complaint motivates an explicitly requested review clarification; no transcript establishes its cause.
+
+The existing mandatory review of every published task now weighs context, heterogeneous changes, manual output,
+verification, review, and integration together. A common outcome does not establish one-agent feasibility. Existing
+measurements, comparable work, or a representative sample can settle material uncertainty. Supported size findings
+name the load, credible smaller independently verifiable cuts, and surviving acceptance and dependencies. Splits
+must repay repeated context and coordination costs. Tools and review corrections remain part of one implementation
+assignment. Large uniform automated changes and small cohesive work can stay whole. No score, inventory gate,
+universal file or context limit, sizing registry, or new review stage is added.
+
+For a path not yet established through the components, plan selects a thin first slice with real behavior and only
+the structure it needs, preserving required safety, integrity, and compatibility. The entire accepted scope is still
+prepared as bounded tasks, with the earlier result and later assumptions named for rechecking at dispatch. Independent
+preparation can start sooner. Mature projects reuse their path; compatible migrations and mechanical changes retain
+their existing treatment. Actual blocking results differ from shared-write, runtime-resource, and capacity constraints.
+Two consumers of a settled API need no dependency edge solely for that reason.
+
+Ready scope gets one explicit workflow invocation and one delivery sentence pointing to the concrete accepted records
+and agreed destination. Longrun is the default, using the target host's syntax; an owner-selected workflow survives.
+Only otherwise-missing project, subset, and run constraints are added. Existing records carry acceptance, dependencies,
+and authorization provenance; the launch copies no task content or CTO policy and creates no grant. Inaccessible
+sources and unfinished preparation remain blockers to affected scope. This is a compatible optional-workflow capability,
+so it receives a MINOR version without changing the kernel, authority, package structure, or installation.
+
+Alternatives rejected: a prompt generator or new scheduler for a prose-only gap, an unconditional skeleton stage in
+every project, horizontal setup/implementation/test/handoff tickets with no standalone outcome, numeric size quotas,
+and leaving accepted later tasks for decomposition during longrun. Existing longrun and delegation already preserve
+an outgrown assignment's work and evidence and return its remaining scope for reassessment.
+
+[Prior art](prior-art.md#bounded-plans-and-first-working-paths-in-620) records the primary sources and rejected mechanisms.
+The new acceptance scenarios are arm-aware and unrun. Deterministic validation and independent instruction review
+do not prove model reliability, context fit, parallel execution, or lower token cost. Reopen this decision on receipts
+showing oversized accepted tasks, microtask overhead, invented dependencies, omitted first-slice protections, or lost
+launch constraints and authority.
+
 ## Sufficient reuse and concrete complexity findings
 
 Version 6.1.2 implements the owner's requested clarifications after inspecting Ponytail at

docs/evidence.md

@@ -2,6 +2,39 @@
 
 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.2.0 workload-based planning and short launches
+
+Two private installed Codex planning sessions from 2026-10-02 carried the full 6.1.1 plan text. One returned a short
+launch without explicit longrun. Another returned a longer launch after an owner follow-up requesting longrun and
+reference-only task content, and repeated execution guidance. No transcript, project identity, private issue content,
+or personal path is retained here. These observations establish differing handoffs under the prior generic prompt
+requirement, not a failure rate or the cause of oversized tasks. The owner explicitly requested the new plan capability.
+
+The existing task review now assesses complete one-agent workload and requires supported smaller cuts when a task
+is too large. A conditional thin first working path, real parallel readiness and resource constraints, and a two-line
+launch are added inside plan. The kernel, delegation, and longrun retain their existing responsibilities, including
+outgrown-assignment recovery. [Prior art](prior-art.md#bounded-plans-and-first-working-paths-in-620) and
+[the decision](decisions.md#workload-based-planning-and-a-short-execution-launch) record the sources, scope, and alternatives.
+
+New arm-aware scenarios cover heterogeneous umbrella tasks, uncertain workload sampling, uniform automated changes,
+artificial microtasks, a first working path and mature reuse, real blocking edges and shared resources, host-native
+short launches and selected workflows, constraint provenance, and blocked preparation or sources. Existing migration,
+localization, small-change, and isolation cases remain. Every new scenario is `UNVERIFIED`; no paid behavioral
+comparison was run. Corpus checks establish scenario semantics, not successful agents, context savings, or parallelism.
+
+The release matrix keeps the deterministic package gate, each host schema, each clean install, explicit invocation,
+implicit activation, continuity, and behavioral suite separate. No package structure or installation mechanism changes,
+so fresh installation and activation experiments are not required and remain visible as `UNVERIFIED`.
+
+The independent read-only Codex review of source candidate `af8223e` against `b5c3a88` returned APPROVE with no
+qualifying findings or nonqualifying suggestions. It read the changed records, checked all existing corpus cases
+survived, and inspected the focused checks' scope 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.
+The transcript confirmed the configured model, read-only sandbox, and no personal skill or installed-plugin paths.
+The reference and scratch were removed on exit. Subsequent edits record this verdict only; review establishes
+independent inspection, not behavioral evidence. Claude strict schema validation passed locally; Codex schema validation
+uses the pinned validator in CI, unavailable locally.
+
 ## 6.1.2 sufficient reuse and concrete complexity findings
 
 The owner requested this clarification after a read-only comparison with Ponytail revision