# NEXT temporary contract — Preview transition accounting, migration and documentation {#root}

@status:impl/plan

[p01] This temporary normative staging unit records the owner's requirement to account for changes throughout implementation, then produce a Developer Preview 1 to Developer Preview 2 migration guide and update separately authored documentation. It specifies future work; neither preview capture, migration outcome nor documentation update is asserted now. Promote its laws into ordinary permanent specifications before production assertions cite them. Candidate home: vibevm/vibespecs/common/PROP-081-preview-change-accounting.xml, subject to a filename collision check and an explicit permanent-anchor mapping.

[p02] @fact:NEXT-A26-U001 **Two deliverables from one account of actual changes.** The campaign must leave a reviewed migration guide at docs/releases/developer-preview-1-to-2/MIGRATION.md and documentation that describes the accepted Developer Preview 2 behavior. Both derive from the same permanent change records and exact before/after captures. A release label is not a package version: all owner-controlled prototype versions remain 1.0.0 unless the owner changes that instruction. Developer Preview 1 and Developer Preview 2 do not declare public graduation, freeze a mutable package, activate compatibility support windows or authorize publication. The historical planning ancestor b1291b06d5704ee32f7486c86e1fae617fcbbddf and any existing preview tag are research inputs, never an automatic substitute for the actual starting state. Existing tags are not moved by this work. @status:spec/done

[p03] @fact:NEXT-A26-U002 **Capture the real starting product before changing it.** After execution is explicitly authorized, establish Developer Preview 1 before any campaign product implementation, including surviving accounting implementation. Record the exact repository and commit/tree, declared inclusions and exclusions, dirty or external inputs if any, package coordinates with capture/content hashes and hash recipes, source artifacts and retained retrieval locations, locks, toolchain and generator identities, platform/backend and relevant configuration. A version string or mutable locator alone is insufficient. The capture must be reproducible from retained source identities; unavailable material is identified rather than reconstructed from memory. Inventory actual capabilities, CLI commands/options/defaults/exit behavior, CLI JSON and MCP contracts, schemas/configuration, package and source classifications, generated state and user-owned data. Record what was observed, how it was observed and what remains unverified; an aspirational specification does not establish that Developer Preview 1 implemented it. Separate environment-specific observations from claims about all supported platforms. Later source or dependency drift produces an explicit new capture and affected-proof review, never a silent rewrite of the accepted starting baseline. @status:spec/done

[p04] @fact:NEXT-A26-U003 **Start permanent accounting on the first implementation day.** Store each authored impact record at the configured specification root, changes/<immutable-change-id>/release-impact.json. Bootstrap this as ordinary versioned data before the M-02 change parser exists; do not wait for M-02 to begin recording changes. Register the durable machine format, epoch, schema, corpus and generated bindings through PROP-044 before automated format I/O is introduced. Authored source data is permissible; a hand-written substitute wire parser/writer is not. M-02-B/C subsequently adopts those same immutable IDs and bytes through its document-role grammar, explicitly classifying release impact as non-normative accounting data excluded from intent/work authority and their meaningful-input hashes. A title or slug rename preserves identity. Reuse existing formats/breaks records and M-13 migration descriptors by stable reference; this record links their meaning and evidence and does not create another migration engine, resolver, scheduler or acceptance ledger. @status:spec/done

[p05] @fact:NEXT-A26-U004 **Every accepted contribution has an explicit impact disposition.** Before central acceptance of an implementation contribution, its worker proposes relevant permanent change records or a reviewed explanation that it has no user impact and no documentation impact. These are two distinct judgments; an empty list or unchecked assertion means unclassified work. Record the subject commit/content and reviewer evidence so that a later material edit reopens the affected judgment. The temporary campaigns/next/change-coverage.json bridge, created during execution, maps existing task IDs to permanent change IDs or these justified dispositions without replacing the existing plan states and acceptance evidence. Include extra tasks, repairs, integration edits, reverts, out-of-plan fixes and exact cross-repository contributions. At every workstream gate and final release audit, independently reconcile the complete actual starting-to-candidate commit range and capability/interface diff with that accounting. Completing 201 originally planned tasks, having one row per task or inspecting changed filenames alone cannot prove coverage. @status:spec/done

[p06] @fact:NEXT-A26-U005 **A change record states what the user experiences and why we believe it.** Its registered schema carries an immutable change ID; affected interfaces, audiences, platforms and prerequisite capabilities; captured before and after behavior; permanent specification anchors; implementation commit/content identities; and independently retained review/test evidence. Distinguish introduced, changed, removed, fixed and intentionally unchanged behavior without treating a source edit as proof of an observable difference. Give each migration and documentation obligation an explicit disposition, rationale and evidence state. Preserve historical records for reverted or superseded changes and link their replacement/reversal IDs; the final guide uses the net Developer Preview 1 to Developer Preview 2 effect, not a concatenation of intermediate edits. A reverted change contributes no surviving migration step unless it left an independently evidenced state consequence. Record amendments retain history and identity; reusing an ID for a different change is forbidden. Permanent records refer to permanent change, capture and commit identities, not load-bearing NEXT task IDs, temporary XML anchors or campaign paths. @status:spec/done

[p07] @fact:NEXT-A26-U006 **Migration instructions are executable claims with honest limits.** For each affected audience/platform, classify the required action as none, manual, automated, rebuild or unsupported, with a reason. Link the authoritative formats/breaks and M-13 descriptors wherever they govern the same change. Each action names exact source and target captures, prerequisites, ordered recipe, expected result, verification, safe repeat behavior and recovery after partial failure. Identify user-owned inputs, generated outputs, preservation requirements, backup/restore boundaries and possible data loss. Rebuild derived data from retained authority; do not introduce a migrator that turns a disposable projection into truth. Edit authored data through its supported document-preserving mechanism. A documented manual action or explicitly unsupported transition is preferable to a fabricated automatic command. Commands and flags proposed by a later task remain unavailable until implemented and checked. Preserve the prototype/public-switch policy of PROP-044: this owner-requested guide and isolated migration rehearsals do not silently activate public compatibility obligations or run codemods against user repositories. @status:spec/done

[p08] @fact:NEXT-A26-U007 **Receive the independent documentation as a bound input.** NEXT-PREVIEW-DOCS-INPUT starts blocked because the owner has not supplied the documentation. It gates only work that needs that input; baseline capture, change accounting and independent implementation proceed. Intake records the exact documentation repository/root, commit or content capture, source-page inventory, generated/source ownership, build inputs and command, and its declared relationship to a product version/capture. A document presented as Developer Preview 1 documentation is checked against the captured product; that label does not establish its claims as true. Until intake, records name topics or claim families with an explicit unresolved source mapping rather than invented filenames. Preserve the other worker's current edits. Reconcile the supplied baseline, current documentation and accepted product delta as a three-way change, separating pre-existing inaccuracies from changes introduced by this campaign. If documentation lives elsewhere, bind that repository's exact inputs and allowed write scope before edits; a host path assumption grants no cross-repository write authority. @status:spec/done

[p09] @fact:NEXT-A26-U008 **Map changes to documentation claims, including missing pages.** At intake, resolve each pending topic to actual source page/anchor or an explicit page-to-create obligation. Keep the mapping and edit/review/test evidence beside the permanent release index. Cover users of each changed interface, installation and upgrade paths, configuration, examples, troubleshooting, generated reference material and new capabilities absent from the supplied documentation. The accounting must detect an undocumented feature even when no existing page mentions it. Retire or redirect obsolete claims and pages according to the actual documentation contract; do not leave a removed command in an otherwise unchanged tutorial. Update generated documentation from its source and generator, and authored prose at its owned source. Record which assertions are checked by builds, links, examples or behavioral tests and which require editorial review. Any subsequent product, documentation-source or relevant build-input drift invalidates only the affected proof and mapping; it never silently inherits acceptance from earlier bytes. @status:spec/done

[p10] @fact:NEXT-A26-U009 **Expose a deterministic, complete transition index.** The permanent docs/releases/developer-preview-1-to-2/transition.json identifies the two product captures, documentation captures, change records and their final dispositions, migration recipes, documentation claim mappings and retained evidence. Additional bounded evidence/mapping files may live beside it with explicit identities. Its schema, generated I/O and corpus follow PROP-044; vocabulary and wire policy are not duplicated in a hand-written renderer. A machine consumer receives strict versioned JSON with deterministic ordering, explicit missing/unsupported/unverified outcomes and every scoped record accounted for, including reviewed no-impact, reverted and superseded dispositions. A renderer may produce a migration draft and documentation work list from those records, but rendering is not semantic review and does not accept work. Review the guide's ordering, prerequisites, omission risks and plain-language explanation against the actual product. This is tooling for recorded release facts, not a new runtime vibe command, background scheduler or source of execution permission. @status:spec/done

[p11] @fact:NEXT-A26-U010 **Schedule accounting before implementation and documentation before release closure.** NEXT-PREVIEW-BASE.1 through .3 establish the starting capture and permanent accounting before the first M-task. NEXT-PREVIEW-BIND.1 and .2 integrate the same records with the accepted M-02-B/C document roles and M-13-C/M-16-C capture/migration boundaries, without postponing initial records until those prerequisites exist. NEXT-PREVIEW-DOCS.1 receives documentation as soon as its input is available; it need not wait for implementation to finish. NEXT-PREVIEW-DOCS.2 and .3 complete and verify the resulting documentation after all 17 workstreams and their current impact audits. NEXT-PREVIEW-RELEASE.1 through .3 reconcile full change coverage, prepare the guide and transition candidate, rehearse migration and prove that the durable outputs do not depend on campaign files after the workstreams, binding and documentation groups are complete. These are additions to the existing task graph, never replacements for required task gates. NEXT-CLOSE.3 alone seals the final Developer Preview 2 subject after removal. The detailed plan must express these prerequisites mechanically; prose ordering alone is insufficient. @status:spec/done

[p12] @fact:NEXT-A26-U011 **Verify the transition on captured starting states.** Rehearse representative documented user journeys from Developer Preview 1 to the exact Developer Preview 2 candidate, covering each supported migration mechanism and materially different data/platform class. Cases include preserved user data, stale input refusal, interrupted steps, safe repeat and recovery, unavailable resources, superseded/reverted changes and missing documentation or evidence. Bind results to the actual artifacts, configuration, toolchain and invoked checks; source similarity, a rendered guide or a skipped/zero-test invocation is not success. State unavailable platform coverage separately and retain the artifact and reason instead of inventing a pass. Cross-check behavior and documentation examples so that a guide which succeeds with different flags or a different capture fails its claimed proof. Use existing required affected checks and focused failure cases; source mutation testing remains limited to a concrete suspicious signal under the installed verification-economy rule. Any changed result subject triggers the affected rerun and central review. @status:spec/done

[p13] @fact:NEXT-A26-U012 **Seal the final subject without self-reference, then retain ordinary product artifacts.** Before retirement, promote all twelve clauses to accepted permanent anchors and retain the captures, records, guide, documentation mappings, schema/generator and meaningful proof outside both campaign zones. This unit becomes eligible for retirement only after NEXT-PREVIEW-RELEASE is accepted; that eligibility is not the final Developer Preview 2 seal. Remove the campaign scaffolding and run the permanent reference, format/codegen, product and transition checks with those paths absent. In NEXT-CLOSE.3, create or identify product/documentation commit C containing the final product, updated documentation, guide and scaffold removal, and bind the final evidence to C and the exact separately retained documentation/package captures. Seal transition.json in a subsequent narrowly scoped evidence/index attestation commit that identifies C and its relevant content hashes; it must contain no hidden product, documentation-claim or migration-recipe delta. The attestation does not hash itself or claim C contains its future commit ID. Any such delta creates a new candidate C and requires affected checks before resealing. Permanent consumers can reconstruct and verify both preview subjects and the two requested outputs without campaigns/next, its task bridge, temporary XML, personal plan or a retained campaign checker. Commit history may preserve execution archaeology but is never the sole home of a product law or required migration instruction. @status:spec/done