# P18-REG-KITCHEN-LEGACY14 source submission

Requirement: `legacy_preservation`. Base remains
`9b1a18c1eb25ca1300dcd59da78423c0dda2f498`. This is uncounted support;
original30/88 and the acceptance denominator do not change. Product code, P04,
settings, thresholds, suite policy, fixture bytes and fixture authority are unchanged.

## Diagnosis and exact migration

The old14 writer is v1, while the approved P18 relationship service saves a v2
container. The five typed differences are all below
`/systems/runtime/relationships`: version 1 becomes 2, `legacy` is added,
`original_relationships` is added, and `threshold_candidates` and
`next_candidate_sequence` move into `legacy`. The retained full native typed
inputs are 159552 and 159680 bytes, an increase of 128 bytes. Their SHA-256 values
are respectively `a2f8992853ba9497539cdfcb74d22c83c76011f2acf73f9e8e3e7241620ddca0`
and `a2f3e75181071f94946369df6f3a6256998dd7d776441766bccc9b9c3ccf5d8d`.
They diagnose the earlier failure; they are never substituted into a new run.

The genuine local `write-checkpoint.var` contains the old v1 dictionary at byte
offsets [143668,143816): **148 bytes**, SHA-256
`ed2cafb629f4d08249f8cd147c7ff9fc715ff641c24809a93e66a1229d4105c4`.
This was obtained by reading the original fixture bytes, including its dictionary
header, StringName keys, typed empty Dictionary arrays, and int values. The new
native proof independently hashes `var_to_bytes(old)` and the whole fixture file.

The pure validator requires the exact old field set/key encoding, int version 1,
byte-identical nested legacy, int version 2, exact v2 field set, unchanged sequence,
byte-identical compatibility projection and typed empty original records. It builds
the container in the service's insertion order with StringName keys and typed
`Array[Dictionary]`. Original values stay unconfigured: no conversion from old
five-axis values and no guessed original initialization.

After the existing identity/saveID-bound IO1 replacement, a reader copy with just
relationships reversed to v1 must equal the entire expected writer byte stream.
Only that subtree is then replaced. Whole typed bytes, Dictionary equality,
SimulationDigest, IO validity, envelope, replaced==1 and published IDs remain
required. Only legacy14 opts in. new14 has the same behavior and proof shape.

Seventeen in-memory controls cover an outside change, each legacy field deleted
and changed, sequence +1, nonempty originals, actual versions 0/3/string, equal
reordered/reencoded dictionaries, and a byte-identical deep-copy positive control.
Every attempt checks both caller inputs and both attempted copies for mutation.
There are 17 new assertions plus one fresh proof-file assertion, so the native
success path is expected to report 163 checks (the existing 145 remain). This
arithmetic is a gate expectation, not an observed native result. The final print
wording and schema are unchanged; the marker contract continues to derive counts
from raw output (`fixed_check_count_used: false`).

## Source map and authority

`MAIN9B_COMPLETE_SOURCE_REFS.json` was read locally after its 376039-byte SHA-256
`dc43e665be3f02d14513f0b8c4248d410175dcfb118171d8cbe0e62ef764a2e4`
was checked. Its canonical 1338 keys exclude docs. The only changed selected entry
is `tests/business/test_required_kitchen.gd`; all other 1337 keys and hashes match.
The selected map hash before this change is
`533a4177918a9da4d4982aa9862cb7420c25d30c2458e36aab9c071c4d3a7139`.
Absolute production paths in those records are provenance, never input paths.

The completion-marker contract is a separately pinned, second changed existing
file. Its pre-change bytes were 188089 with SHA-256
`6ce6b28c5985e8a4f13b78bfeb1f1e09f6216d874fb01e0656ec1633bfa01cd7`.
Only the kitchen source SHA and actual marker line position change; authority,
template, count policy and other entries remain byte-for-byte unchanged.
The newly added support directory is the third allowed path group. The tree as a
whole is not described as exactly two paths. See `delta-manifest.json`.

Root's selected full-run map must be exactly these current 1338 files plus
`tools/check_p04_order_evidence.py`, 78235 bytes, SHA-256
`f5b44827958f2ae352fe5c4bc3a1ffd4211ec7a41fc4c0759c8b954891662324`.
This is the fixed supplied reviewed P04 QA source, not permission to edit P04 or
read its build. The verifier compares local relative keys and full file pins,
rejecting additions, drops and stale sources. It introduces no selector exclusions.

Static reference search:

```sh
rg -l 'test_required_kitchen\.gd' autoload scripts scenes data tests assets tools project.godot export_presets.cfg Makefile AGENTS.md
rg -l 'test_required_kitchen\.gd' docs
```

The first command returned no matches (exit 1). The second finds documentation
and archived manifests only; there are no other source consumers of the test.
The test itself is the edited definition. This search does not rewrite manifests.

## Root-only finite local diagnostic procedure

Worker has run **no tests, engine, Runner, Git or agents**. Python support files
were compiled in memory only. GDScript import/parse and native results are pending.
Root must use the existing `godot` guarded launcher supported by the current tools;
do not point any command directly at a player profile. Run from this checkout in
one shell, stop on the first nonzero exit, and do not retry into an existing output.
If an output already exists, retain it and obtain a newly registered build before
a new collection. The helper uses the existing `execute_phase`, Guard, owned outer
launcher and `run_p18_relationship_tests.py` roster/archive APIs. It changes no
production collector, policy or threshold. All source copying is private.

```sh
export BUILD_OUTPUT_DIR=/Users/korizatou114/Projects/TheTree-managed-worktrees/p18-kitchen-regression-r02/.runtime/P18-REG-KITCHEN-LEGACY14/build
set -e
python3 docs/plans/original-completion-2026-10-02/execution/p18-kitchen-legacy-support/root_diagnostic.py --phase parse
python3 docs/plans/original-completion-2026-10-02/execution/p18-kitchen-legacy-support/root_diagnostic.py --phase kitchen
python3 docs/plans/original-completion-2026-10-02/execution/p18-kitchen-legacy-support/root_diagnostic.py --phase affected
python3 docs/plans/original-completion-2026-10-02/execution/p18-kitchen-legacy-support/root_diagnostic.py --phase full
python3 docs/plans/original-completion-2026-10-02/execution/p18-kitchen-legacy-support/verify_support.py --verify-only --marker-contracts docs/plans/original-completion-2026-10-02/execution/completion_marker_contracts.json
```

Order is import/all-script parse, required_kitchen alone, all business plus all
s4 relationship tests/all s6/P18 affected set, then the new standard full178.
Every phase retains import/parse and exact-source receipts; the full phase invokes
the unchanged `run_all_tests.main` with the explicit 1339 source input and marker
contract. `archive_profiles` retains all actual private profiles under the build,
including the kitchen typed proofs, checked against native inventories. The
read-only verifier reads those receipts, raw stdout/stderr/native logger streams,
and PID lifecycle evidence; it launches nothing and emits no PASS of its own.
Missing future evidence correctly exits nonzero and does not block writing code.

Root will formally verify P04 separately in P04A repair. Independent Opus review,
integration and final verification remain required before any original-unit credit.
No native Windows behavior or whole-unit completion is claimed.