# 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 d2a1f80a613e7c77b02b941026bc49c2d85db863.
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.