Test Handoff Point

Lab 4 crosses root registration, external child resolution, root-owned prefab scope, world streaming, journal/mappin state, and two saveable phase owners. A final quest screenshot cannot identify which boundary worked. This protocol binds the installed candidate, clean-save lineage, visible handoff, and fresh logs across eight executions.

Use the unmodified completed checkpoint for these tests and record each result separately. The procedure covers the normal Out1 handoff; CutDestination remains unwired and is not tested by this lab.

Required environment

Record observed versions on every run. Values printed in the template are requirements, not proof of the machine that executed it.

Establish the site before installation

Lab 4 uses the same Allen Street test site and trigger geometry as Lab 3. Its center is the outdoor recycling-station cabinet row in Watson/Kabuki at:

(-1000.02, 1497.2208, 8.3)

Before installing any Lab 4 candidate, follow Lab 3’s ordinary control-route procedure. It cites the vanilla fast-travel entity, linked marker, exact depot resources, and extraction steps. Do not use Lab 4’s own marker as the only way to find a marker that is under test.

Treat access to the route and the new cqa004 world resources as Experimental until performed on the pinned game build. If the ordinary route is inaccessible, record that result. Do not silently substitute a console teleport.

Prepare clean starting save

Before installing either checkpoint:

1. choose a manual save made at Allen Street with no history of any Lab 4 candidate;
2. confirm the player is outside the 25-metre reach volume and can approach the cabinet row by the verified ordinary route;
3. copy the complete save-slot directory into your test folder;
4. record its in-game label and slot-directory name;
5. confirm that this save predates the first Lab 4 install;
6. preserve that original byte-for-byte for both clean-walk and clean-replay;
7. derive separate active-child saves before reach and between boundaries;
8. derive a separate parent-active save during the 30-second confirmation;
9. preserve the completed save used by both completed-state cases.

Use a fresh working copy for each run. Preserve the same source save for clean-walk/clean-replay, pre-reach-reload/stream-away-return, and completed-reload/completed-reinstall. Keep separate between-boundaries and parent-confirmation saves.

Do not obtain “clean” evidence by writing cqa004_completed = 0, removing the mod after a prior load, or reusing a slot that saw the start checkpoint. FactsDB, journal, phase, mappin, and world state can all survive those actions.

Build and bind the canonical candidate

Use the unmodified completed checkpoint:

candidate id: canonical
project:      CQA_Lab04_HandoffPoint.cpmodproj

1. Close the game.

2. Build and install through WolvenKit.

3. Confirm only this candidate’s pair is installed:

   archive\pc\mod\CQA_Lab04_HandoffPoint.archive
   archive\pc\mod\CQA_Lab04_HandoffPoint.archive.xl
   

4. Confirm the archive contains all seven depot resources, including the child and both sectors reached through the block.

5. Preserve those installed files until all eight executions finish.

Preflight the ownership boundary

Before Run 1, inspect the installed .archive.xl and record:

• exactly one quest.phases entry, for cqa004.questphase;
• no independent entry for cqa004_boundary.questphase;
• the journal, onscreen localization, and streaming block entries;
• no cqa004 error in a fresh ArchiveXL startup log.

This preflight does not prove the child executes. It proves the candidate under test has the intended one-root registration shape.

Run 1: clean walk

Restore a working copy of the original untouched save, keep the canonical candidate installed, and start a fresh execution.

Before entering the reach volume

Record all of these visible and state observations:

• Handoff Point, its phase, and Reach the handoff point. become active once;
• the handoff map pin becomes active once and points to the marker;
• the leave and confirmation objectives are not active;
• no second root or duplicate child activation appears.

The active reach objective and pin show child-owned work, but do not by themselves prove the prefab scope is correct. The trigger crossing and logs are also required.

Cross the reach boundary

Walk to the cabinet row and cross into the 25-metre reach volume. Confirm:

• the pin becomes inactive;
• the reach objective succeeds once;
• Clear the handoff area. becomes active once;
• the quest does not yet show the confirmation objective;
• the quest does not take its completed-save bypass.

Remain inside the 110-metre leave volume long enough to confirm the leave gate does not immediately complete.

Cross the leave boundary and observe return

Leave the 110-metre volume by ordinary movement. As soon as the leave objective succeeds, observe the child-to-parent boundary:

1. Wait for handoff confirmation. becomes active once;
2. the reach and leave sequence does not restart;
3. after 30 realtime seconds, confirmation and phase succeed;
4. the completion-fact write is reached before final quest success;
5. the quest succeeds once.

The confirmation objective is the visible evidence that child Out1 reached parent node 13.Out1 -> 14.Active. Preserve a derived save during this window for Run 4 and the final completed save for Runs 6 and 7.

Copy all four fresh logs before another execution can replace them.

Run 2: pre-reach reload

Restore the derived save made after the child activated but before reaching the 25-metre volume.

1. Load without changing the installed candidate.
2. Confirm the reach objective and pin return once.
3. Confirm leave and confirmation are not yet active.
4. Enter reach, remain inside leave, then walk outside.
5. Confirm the child returns once and the parent completes once.
6. Retain the save name, observations, and four fresh logs.

Pass requires coherent active-child restoration. Restarting the root flow or duplicating the pin is a failure even if the quest eventually completes.

Run 3: between-boundaries reload

Restore the derived save made after reach succeeded while the player remained inside the leave volume.

1. Confirm reach remains succeeded and the handoff pin remains inactive.
2. Confirm leave is active and confirmation is not active.
3. Wait briefly without crossing; the child must not return yet.
4. Walk outside the leave volume.
5. Confirm leave succeeds, confirmation activates once, and completion follows once.
6. Retain the save name, observations, and four fresh logs.

Immediate completion on load is a failure unless the retained position is actually outside the authoritative leave volume.

Run 4: post-return reload

Restore the derived save made after the child returned and while the parent’s 30-second confirmation delay was active.

1. Confirm the confirmation objective is active.
2. Confirm reach and leave do not reactivate and no pin returns.
3. Observe whether the realtime delay resumes or restarts; record the measured result rather than assuming one.
4. Confirm the parent succeeds confirmation, phase, fact, and quest once.
5. Retain the save name, timing observation, and four fresh logs.

Pass requires a coherent parent-owned continuation. The matrix records timing semantics; the procedure does not pre-label resume versus restart.

Run 5: stream away and return while child is active

Restore a working copy of the active-before-reach child save.

1. Travel by ordinary movement beyond the finite Quest descriptor box; do not use fast travel for this case.
2. Remain away long enough to collect a clear before/away/return observation.
3. Return by ordinary movement to the site.
4. Confirm the reach objective and pin remain coherent.
5. Cross reach and leave, then confirm one child return and one parent completion.
6. Retain route notes, save name, observations, and four fresh logs.

This case tests active composition across world streaming. It does not test CutDestination and does not generalize to every prefab lifetime.

Run 6: completed reload

Restore the completed save made by Run 1 with the unchanged canonical candidate installed.

Confirm:

• Handoff Point remains completed;
• reach, leave, pin, and confirmation do not reactivate;
• the external child is not invoked again;
• fresh logs contain no cqa004 error.

This is the completed-route bypass, not a second successful playthrough.

Run 7: completed reinstall

1. Close the game.
2. Remove only the two installed canonical files.
3. Reinstall the preserved copies of the same two files.
4. Load the same completed save.
5. Confirm the quest remains completed and the child does not restart.
6. Confirm ArchiveXL registers the root without a separate child entry.
7. Retain four fresh logs.

Do not rebuild between removal and reinstall. A changed archive is a new candidate and invalidates the shared record.

Run 8: clean replay

Restore a fresh working copy of the original untouched pre-install save while the canonical candidate remains installed.

Repeat the ordinary walk and record the full sequence:

root first-run route
  -> child reach/pin
  -> child leave
  -> child Out1
  -> parent confirmation
  -> parent completion

Every transition must occur once with the same installed files and no cqa004 errors. This verifies reproducibility from a second clean derivation; it does not erase the need for the six boundary-specific runs.

Retain four logs per execution

After each of the eight runs, copy these files into a run-specific private test folder before starting the next execution:

red4ext\plugins\ArchiveXL\ArchiveXL.log
red4ext\logs\red4ext.log
red4ext\logs\game.log
r6\logs\redscript_rCURRENT.log

Keep the copied logs with that run’s test notes. Search all four for cqa004, the child depot path, NodeRef errors, streaming errors, journal/localization errors, and framework failures. “No visible crash” is not an adequate log result.

Common test failures

Lab sequence: All labs · Previous: Author Handoff Point in WolvenKit · Next lab: Lab 5: First Contact.