7.4 KiB
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:
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.
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.