TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p18-01-code/IMPLEMENTATION.md

P18-01-CODE implementation handoff

Status: submitted for Runner validation; no acceptance or unit completion claimed.

Scope: dedicated original relationship state, lossless legacy snapshot preservation, Runtime registration and read projection, and the contract-listed tests and collector. Production initial values and gameplay coefficients are not supplied or inferred.

Validation: worker static inspection only; authoritative native local and affected validation, independent review, and integration belong to Runner.

Source inspection: HEAD matches d2a1f80a61. The acceptance specification without its final newline matches the contract SHA256 04e9ae701b6ee1e399542564add695ca7fce54499e52dd2e907b1dbdc23a366d.

Submitted behavior

• OriginalRelationshipState stores explicit directional subject/protagonist/rival facts with Affection, Lust, Netorare and shield current/max. All fields are required for a configured record. Numeric inputs must be finite numbers; shield current must be nonnegative and at most max, and max equals Affection. No additional emotion ranges, coefficients or production values are imposed.
• RelationshipService retains its five-axis API. Its v2 snapshot contains the whole v1 payload under legacy, plus separate original_relationships. Top-level relationships is a compatibility projection for existing consumers; disagreement with legacy.relationships is rejected. Additional legacy fields, raw aliases, collection order and untouched values survive migration. The existing normalized state remains usable; only actual legacy changes are merged into retained raw facts. Aliases never initialize original fields.
• Registration uses register_original_relationship with the complete payload. Runtime validates the protagonist against player, the subject against hired UNIQUE staff and its canonical role, and heroine/rival identities and reciprocal counterpart references against the existing unique-character catalog. Rival catalog membership does not invent recruitment. No new original update policy, contact, route, attack, threshold or duel behavior is defined.
• Snapshot restore validates candidates before replacing live services, then rebinds the identity validator to live staff. Existing legacy actor references must resolve against player, restored staff or restored guests.
• Every staff-management row exposes original_relationship. Missing records have configured: false and null values, distinct from explicit zero. Configured projections are copies, so reads and caller edits cannot change service state.

Validation and handoff

Two new s4 suites exercise explicit/unset/zero data, malformed and nonfinite values, identity invariants, lossless raw aliases/extensions, new and mixed round trips, atomic service/Runtime rejection, actual hiring/commands, restore/rebind and reports. Existing test bodies and limits are unchanged. New marker and suite-policy rows are pinned to the exact new test sources.

python3 -B tools/run_p18_relationship_tests.py --prepare-only previews the exact seven-suite roster, source bytes, capacity and all-script parse count without engines, profiles, stage creation or test execution. The native collector reuses run_all_tests.source_refs/execute_phase and the existing Guard, owned_outer, diagnostic, artifact, PID, marker and cleanup gates. It stops at the first failure; Runner owns repair/validation sequencing and independent review.

Worker checks: Python AST syntax, JSON/source-marker consistency, allowed-path inspection, unchanged pre-existing marker/policy records, and git diff whitespace. Native import, GDScript parse and all seven suites remain unexecuted by worker. Worker reinspection on 2026-10-13 confirmed the existing submitted implementation and repeated Python AST, specification digest, exact new marker/policy source hashes, unchanged existing marker/policy records, and git diff --check. Prepare-only exited 0: seven suites, 1,311 source files / 67,287,056 bytes, 308 parse paths, nine future native phases, 381,859,856 conservative required bytes and 1,773,187,072 available bytes. Engines and stages were both zero; actual checks were null and formal acceptance was false. Capacity is a preview at that instant, not a reservation or native result. An initial shell here-document temporary-file attempt was denied with operation not permitted; normal allowed-path patch edits worked. No isolation rule or permission was relaxed.

P18-C-1 through P18-C-3 are implementation submissions, not accepted results. P18-C-4 awaits Runner native local/affected evidence, separate Opus review, integration and final affected validation. The original P18-01 unit remains in_progress: ordinary Japanese UI rendering/equality, approved production values, all-seven recruitment, final full required roster and applicable Windows final acceptance remain outstanding. No git writes, other agents or Runner controls were used by worker.