Owner clarification, 2026-09-12: «тебе не нужно начинать кампанию. Нужно только довести процесс ее планирования до конца.» This deliverable is planning only. Phase 0 and implementation remain unstarted; NEXT-EXECUTION-AUTHORITY stays blocked until a later explicit owner instruction starts execution. A generated plan or GOAL file is not that instruction.

PLANNED. Written against main commit b1291b06d5704ee32f7486c86e1fae617fcbbddf; worktree vibevm-next, branch next. This change authors a future campaign, not its Phase 0 or product implementation. The full product floor remains unmeasured here; Phase 0 establishes the relevant starting frontier through affected checks rather than a mandatory whole-product run.

Read the common project boot, resolve the exact user-local context, read complete plan.toml, this contract and the selected task packet. The smaller executor follows the standard planning profile: one bounded task, explicit witnesses, exact checks and central review. Model names are examples of desired executor capability, not a safety/quality exemption.

Current owner rulings and permanent project specs/tests govern; frozen input files record revision-4 design and baseline evidence, not an ongoing two-output-only review restriction. Accepted preferences D-001...D-026 remain binding; only D-022 is open. This campaign never activates autonomous publication B or prototype graduation.

No implementation commit, passing product panel, native smoke or completed milestone is asserted at authoring. Executing coordinators record reviewed commits, deltas, prediction outcomes and actual gate evidence locally and in appropriate integrator records; before this zone is removed, all durable knowledge and evidence moves to permanent homes.

Owner commissioning words, 2026-09-11: сделай от ветки main в репозитории vibevm отдельный worktree, в котроом дальше продолжи работу. Допустим, worktree = vibevm-next и бранч next. Перейди в него и сделай следующую работу. Возьми наш план и преврати его в детальный план кампании по реализации, который смогла бы сделать более простая модель - например, opus 5 или gpt-5.6-sol в режиме (effort) high. Вероятно, нужно написать для этой кампании XML-спецификацию и для нее дерево работ для mult-user-planning. Спецификация и задачи должны быть так прописаны, что общая идея: по мере реализации все "спецификации кампании" должны быть удалены пока не останутся нормальные спецификации vibevm (props, feats, etc). Тебе понятно что нужно сделать, что и зачем это нужно?

Preserve the complete revision-4 scope: exact sources/content classification, choices, change/lifecycle/closure, boot debugger, external adapters and derivatives, releases, HOME/Linux/Docker, Nix-inspired independent supply chain, IDE compatibility and Extreme Total Observability. The IDE/plugin/MVP and full Linux distro remain outside this implementation campaign.

Baseline contains exactly 17 milestones, 86 stable work-package IDs, 26 owner decision rows and 34 review findings. All 86 groups remain in the task tree; their smaller child tasks are inventoried by campaign.py check. Optional tracker and unapproved real external publication are explicit dispositions, never erased requirements. The baseline ID sets, not counts alone, are the coverage oracle.

The original normative staging inventory contains 60 XML contract units and 229 source-clause anchors. The owner's preview-transition requirement adds NEXT-A26 with 12 clauses: 61 units and 241 clauses in total. Further growth requires explicit replan with stable IDs. Exit: zero active temporary normative clauses, zero temporary campaign files in the declared zones, and zero permanent dependencies on their paths/addresses. Destination existence alone does not prove semantic preservation.

Exact source captures: campaigns/next/inputs/REFINED-IMPLEMENTATION-PLAN.md and PROJECT-REVIEW.md, revision 4, bound by manifest.json SHA-256 values. They are temporary archaeological inputs, not permanent product specifications. The original external review pair remains untouched.

At worktree creation the branch started at the planning baseline commit and its common boot matched the already-read main boot. Later compatible multi-user-planning changes and their generated boot are recorded in this branch's history. Neither that historical comparison nor the planning ancestor fixes the eventual DP1 product capture. The current exact user-local binding belongs to next; no main context or custody is reused.

manifest.json retains all 34 evidence-qualified findings and the original architecture/atom source text. Source reading is not execution evidence. Revalidate a cited seam when its bytes changed; do not repeat the whole architectural investigation unless the task's assumptions are falsified.

Earlier probe found Docker CLI/Buildx but unavailable Linux engine; availability must be re-probed at the Docker gate. Native targets and external bridge worktrees need explicit resource bindings; a Windows build or Docker userspace test is not a macOS native smoke or Linux boot test.

Each D-ID has its own temporary contract in next/contracts/NEXT-D-NNN.xml. Settled decisions are not reopened by stale prototype source notes. D-022 recommendation A is not consent: only backend-specific M-15-E waits for that decision. If B is chosen, expand its compatibility tasks before they become ready.

The task that establishes a product contract creates/updates its permanent PROP/FEAT anchors before dependent production code/tests cite them. Candidate permanent homes PROP-070...PROP-081 are planned filenames, not current implementation or already resolvable citations. Check name collisions on the actual branch before minting; any reassignment is an explicit mapping update.

Temporary XML stages new normative clauses only until promotion. Existing source laws are referenced or amended at their own homes. Do not copy campaign text into permanent specs as a historical campaign chapter; rewrite it as ordinary product law, including rationale/rejected alternatives and testable obligations.

The early M-13/M-16/M-14/M-06 seams can remain a DAG while delivering independently testable local operations. Any prerequisite requiring its own completed consumer falsifies this prediction and requires replan.

The existing resolver/compiler/registry/artifact/deploy authorities can support the design without a second solver/compiler/evidence authority or permanent workflow daemon. A necessary parallel authority falsifies the assumption and must be justified centrally.

A fresh standard-profile coordinator can execute the first ready task from its packet without rereading the entire frozen review or inventing a missing gate. A missing input, prospective command mislabelled existing, or unbounded write perimeter falsifies packet readiness.

After permanent promotion, deleting this whole campaign zone will not change the product's output or break schema/fact/reference/build/behavior checks. Any surviving dependency falsifies disposability and blocks close.

Phase 0 is disposable probes and baseline capture, with no surviving implementation edits or implementation commits. It proves branch/context/input binding, records actual affected baseline checks or matching prior evidence, and classifies unavailable and unmeasured areas. No full panel is required merely to begin. A failed product assumption revises its affected contract before implementation; an unavailable later resource blocks that resource gate, not unrelated work.

The 17 M-IDs are workstreams, not a linear execution order. Schedule ready leaf tasks by explicit dependencies. In particular M-16-A sits between M-13-A/B; M-16-B precedes M-14-B/C; M-16-C precedes public source/operation consumers; M-11-D stays before M-03-D/E; M-15-K precedes Linux payload/backend execution. Never wait for the whole containing milestone when a dependency names one group.

campaigns/next/tasks/M-NN-X.json and the four supplemental NEXT-PREVIEW group files use the same authoritative task format: goal, exact read/write perimeter, ordered steps, positive/negative cases, checks, observable acceptance, safe stop and proposed Conventional Commit subject. All 201 original task identities and behavioral cases remain; 11 supplemental tasks bring the total to 212. The owner's verification correction replaces broad test recipes with target/case bindings and refreshes their explicit hash witnesses. plan.seed.toml carries the complete portable hierarchy; task instructions are not duplicated into the goal projection. Every implementation packet carries preview-control and verification obligations and resolves NEXT-A26 or its accepted permanent replacements.

Bind each task to the minimum sufficient affected build/test targets, cases and named consumer contracts before dispatch; update the binding against the actual diff before acceptance. Preserve applicable negative/invariant and conditional independent oracles. Do not run unfiltered crate suites or global test lists by default. verification-policy.json binds the permanent multi-user-planning verification-selection law. Intermediate workstream reviews and Phase 0 use affected checks; the designated whole-product gate is NEXT-CLOSE.3. Additional broad runs need an explicit full-check request or demonstrated crosscutting impact without adequate narrower proof. Reuse valid per-step evidence and execute failed/invalidated/unrun steps without fabricating a green tail. This latest owner instruction supersedes older blanket-panel wording in frozen planning inputs and staging excerpts; their behavioral obligations remain.

If a child cannot land coherently green, regroup it with the smallest dependent child rather than commit broken scaffolding. Record that replan by stable identities/dispositions. A parser/type/command still marked proposed must be introduced by its task or remain an explicit unmet prerequisite.

The owner's bounded parallelism improvement preserves all existing task identities, dependencies and acceptance states. The read-only campaign.py parallel-frontier command delegates to the installed steward-parallel analyzer and reports candidate batches, read/write or resource conflicts, recorded active work and candidates for review. It neither starts jobs nor grants authority. Exact packets narrow existing outer paths, bind accepted inputs and selected checks, and name one shared integration owner. Keep heavy command concurrency within observed resource capacity and candidate production within review capacity. The permanent protocol is @spec://org.vibevm.world/multi-user-planning/flows/multi-user-planning/parallel-execution#root.

Incoming documentation remains behind its existing bound-input gate. After the owner supplies its source, revision and ownership, adapt affected packet perimeters, topic mappings and verification inputs; preserve current work and existing documentation prerequisites. Independent bounded subwork can share a ready task, but the parent closes only after its full obligation and integration proof. This improvement does not remove sibling-order edges or advance the final documentation stage.

Owner requirement, 2026-09-12: account for campaign changes so the result supports both a Developer Preview 1 to Developer Preview 2 migration document and updating the separately authored documentation that the owner will supply. The normative staging contract is next/contracts/NEXT-A26.xml; preview-control.json binds its task/gate obligations without becoming a second execution plan.

After Phase 0, NEXT-PREVIEW-BASE captures the actual DP1 before surviving implementation and establishes permanent accounting. Every original first child depends on BASE.3. BIND adopts the same records in M-02 roles and links existing migration/capability authority. DOCS.1 receives the independent documentation as soon as its bound input exists; DOCS.2/.3 finish after all 17 workstreams. RELEASE prepares complete migration and documentation evidence before retirement. These edges are explicit in the shared and local plan; missing documentation blocks its own dependents, not the accounting bootstrap.

Every accepted contribution, including extra fixes, needs a permanent impact record or separate reviewed reasons for no user impact and no documentation impact. Workstream gates compare actual changes and interface/capability deltas against this account. The final guide uses net DP1-to-DP2 behavior, with checked recipes and explicit recovery limits. Documentation updates use the supplied baseline, current authored sources and accepted product changes, including newly needed pages.

Permanent change attachments live under the configured spec root's changes directory; the transition index, MIGRATION.md, documentation map and evidence live in docs/releases/developer-preview-1-to-2/. Existing format break notes and M-13 migration descriptors remain their own authority. The task-to-change bridge is temporary. NEXT-CLOSE.3 seals DP2 only after the scaffold is absent and permanent checks pass; an earlier candidate is not final DP2. A subsequent evidence/index attestation identifies the verified product/docs commit without hashing itself or concealing later product changes.

Input/source drift: compare the actual diff with the task's witnesses; refine the affected work package, preserving mandate coverage. Do not restart all 86 groups or invent a compatibility promise.

Missing Docker/native/external package resources: preserve candidate artifacts and return resource-blocked for the exact gate. Continue independent ready work. Local fake fixtures cannot be relabelled native/platform/end-to-end proof.

A worker report is candidate evidence. Root reviews the actual change and meaningful checks before acceptance. Transport failure/timeouts do not imply its files are useless; inspect and preserve unique work.

Promotion drift or remaining references: keep the temporary unit, repair the canonical mapping and rerun exact proof. Never delete first, weaken the reference scan or carry unique product knowledge only in personal plan/history.

No product implementation in this authoring commit; no full Linux distro/ISO/VMware commissioning; no IDE/plugin/MVP; no live B activation, prototype graduation, boot quotas, language-package-manager replacement or unbounded repair scheduler. Future horizons are named in the plan and must move to durable product/backlog homes before this zone disappears.

Work that eventually edits the two external bridge repositories uses separately bound isolated checkouts. This worktree's authoring grant does not write their current live directories. Actual external publication requires one concrete current-A batch authorization after artifacts/diff/evidence are ready; no repeated approval within the unchanged authorized batch.

Use the exact local binding/settings/complete plan and tree. No formal handoff, custody claim or repository-global personal cursor is created. Old campaign-plans repository-resumption wording is adapted to shared contracts/integrator facts; multi-user-planning owns personal state locally.

From the intended checkout: git status --short; git branch --show-current; python -B campaigns/next/campaign.py check --context <resolved-context>; python -B campaigns/next/campaign.py frontier --context <resolved-context>; python -B campaigns/next/campaign.py task <ready-id> --context <resolved-context>. Execute commands separately and check each actual exit status. The no-context check validates only the portable seed, not this developer's current coverage.

For a new contributor, resolve/create an exact multi-user-planning binding and initialize once from plan.seed.toml. Existing context plans are merged by stable IDs; never overwritten from the seed. Read the full local plan, then the task file and its listed contracts. Goal refresh uses the installed steward-goal renderer; no user-local absolute path belongs in the shared seed.

A computed ready leaf is only dependency-ready; inspect actual inputs, closed write paths, resource binding and current authorization before execution. A blocked owner gate is not answered by time, --assume-yes or a previous unrelated approval.

promotion.toml accounts for every original source-clause ID/hash. For each, record accepted permanent target anchors/hashes, meaningful retained test/evidence, acceptance commit and semantic review. The checker validates structure/witnesses, not meaning or test truth. Permanent code/tests/build inputs never cite this temporary zone; pending facts remain available here until their permanent home is accepted. Compound Markdown blocks are represented as one anchored requirement paragraph with the exact original block retained in an adjacent literal fence, so the current XML/Markdown pivot preserves the IR; source-unit hashes bind both forms.

For each unit: complete its required workstream gates; promote all clauses and retarget references; run campaign.py retirement-check --context <context> --unit <unit>; inspect the removal diff; explicitly remove only that unit and mark its ledger entry retired. Later packets follow its permanent targets. No automatic recursive deletion command is provided.

Before final deletion, complete every required implementation/verification task and disposition optional/external horizons under actual owner policy; retain all unique facts, decision rationale, predictions, scope exclusions and evidence outside this zone. Accept the preview-transition candidate, documentation coverage and NEXT-A26 promotion before removal. Remove campaign files with an explicit reviewed file list. Then run permanent facts/reference/codegen/conform checks, the full unchanged-tree panel, decisive product journeys and DP1-to-DP2 migration/documentation proof with this zone absent. Seal the final DP2 product/docs capture under the permanent contract. Final correctness cannot require campaign.py, its seed, frozen input copies, task bridge or a deleted XML file.

Update the actual local plan bottom-up, preserving historical acceptance and permanent evidence references. Do not keep a completed campaign falsely active to satisfy the current goal renderer: it refuses terminal selected campaigns. Report that limitation or select another genuinely open portfolio only if one exists. No unique product law may remain only in local plan/GOAL.

OPEN D-022: start alongside pacman/libalpm (recommended A) or immediate engine replacement B. Generic target/backend interfaces proceed. Backend-specific execution waits; B requires explicit additional compatibility decomposition.

Concrete publication/CI external installation authorization, availability of required native/Docker resources, future B activation and prototype graduation remain distinct events. This plan does not manufacture any of them. No new policy confirmation is required for already accepted D-IDs.

Initially empty for implementation. Bind real commits to planned subjects, exact affected/full gates and prediction verdicts while fresh. Personal cursor/candidates remain local; shared accepted operational facts live in permanent repository homes. Before deletion, promote durable lessons and keep only non-load-bearing history in Git.

Optional tracker; actual public writes held by owner; full Linux/VMware/boot; actual IDE/plugin/LSP/DAP clients; full backend replacement if D-022 chooses A; unrelated future analyzers/autonomy/graduation remain named, with authority/trigger/permanent home. Implementation gaps cannot be reclassified as optional merely to close.

The intended end state is ordinary VibeVM product specifications, code, executable acceptance and user documentation. There is no permanent campaign-spec layer, no permanent reference to NEXT's task IDs/paths and no hidden dependency on its maintenance scripts.