Tutorial Island live run - 2026-07-28

Outcome

Failed. The run did not complete Tutorial Island.

The documented agentic harness failed because its Gradle task launched the n3Plugins installer and the external-plugin manifest lacked the hidden test plugins. The base Tutorial Island plugin was therefore run through Agent Server in the same rev239 client. It required one manual widget intervention at name creation, then halted at the Gielinor Guide exit after exhausting the transition retry budget.

Supplemental live continuation reached fishing and exposed another listener-backed widget-owner failure after catching a shrimp. The controller dispatched dialogue continues at varp 50, but the visible Click here to continue control remained open.

This report records live observations. Do not treat a DISPATCHED result as success without the corresponding client or game-state postcondition.

Repair status

The launcher, manifest registration, exact-profile login flow, Profiles settings panel, listener-aware name/dialogue dispatch, shift-drop workflow, reachable door-perimeter approach, dialogue-specific postconditions, and synthetic-click overlay were repaired in source on 2026-07-28. Focused/static validation is recorded by the implementing change. The historical failures below remain the last live evidence: do not promote repaired behavior to LIVE_VERIFIED until a fresh installed-client run produces new result and screenshot artifacts.

Environment

Item	Observed value
Date	2026-07-28
Execution profile	WINDOWS_LOCAL
RuneLite revision	239
Expected RuneLite version	1.12.33
n3Plugins version	5.5
World	308
Test profile label	TEST_1
Login	Manual after automatic profile selection did not complete
Initial tutorial varplayer	281 = 1
Initial location	(3094, 3107, 0)
Plugin config change	startPaused: true -> false for the run; restored to true afterward
Evidence sources	Agent Server state, plugin catalogue/config, widget search/description, plugin logs, varplayer reads, and canvas captures

The profile label is a non-secret test identifier. Do not record login credentials, stored profile values, or account-identifying game names.

Execution timeline

Stage	Observation	Result
Harness launch	runAgenticTest launched com.n3plugins.Main, which is the installer entrypoint	Harness did not run
Runtime registration	Loaded plugin catalogue did not contain N3 Test Runner or Tutorial Island Test	No harness timeout, result.json, or harness screenshot set
NAME_ENTRY, varp 1	Name field focus, typing, and Look up name were dispatched and confirmed	Advanced to visible Set name UI
NAME_ENTRY, varp 1	Controller repeatedly reported Name interface active; waiting for functional child	Autonomous run stalled
Manual evidence probe	Native op 1 was dispatched to the listener-backed Set name owner	Appearance interface became visible
Appearance and guide	Plugin completed appearance and progressed through varps 1 -> 2 -> 3 -> 7 -> 10	Confirmed autonomous progress after manual intervention
Settings setup, varp 7	Shift-drop configuration returned WIDGET_NOT_FOUND without opening All settings or searching for the setting	Fail-open warning; run continued
WALK_TO_SURVIVAL, varp 10	Repeated approach dispatches targeted (3098, 3107, 0) while the walker returned to IDLE	No door interaction or movement postcondition
Terminal state	Retry budget reached 6/6 at player (3095, 3108, 0)	Controller halted
Supplemental fishing replay, varp 50	After catching a shrimp, widget 12648448 displayed Click here to continue	Repeated continue dispatches did not close or advance the widget

The controller halted approximately 4 minutes 42 seconds after it started. The plugin was then disabled and startPaused=true was restored.

Error 1: agentic harness is not launchable

Evidence

• runAgenticTest sets mainClass = 'com.n3plugins.Main'.
• com.n3plugins.Main is the desktop installer entrypoint, not a RuneLite client entrypoint.
• runelite-plugin.properties does not list TestRunnerPlugin or TutorialIslandTestPlugin.
• The attached client's loaded-plugin catalogue contained the base Tutorial Island plugin but neither hidden test plugin.
• No build/n3-test-results/result.json was produced by the real client.

This also identifies Source-of-Truth drift: the registered-plugin table says both hidden test plugins are registered, while the live manifest omits them.

Proposed fix

1. Replace the runAgenticTest installer main class with a launcher that starts the installed RuneLite hijack/client path and passes n3.test.mode, n3.test.script, n3.test.profile, and n3.test.outputDir into the RuneLite JVM.
2. Add TestRunnerPlugin and TutorialIslandTestPlugin to runelite-plugin.properties, keeping them hidden through their descriptors.
3. Add a packaging test that reads the produced external-plugin manifest and asserts that both test classes are present and loadable.
4. Add a Windows-native orchestration command. The existing Bash loop is not the primary WINDOWS_LOCAL path.
5. Reconcile N3PLUGINS_SOURCE_OF_TRUTH.md only after the manifest and packaged jar agree.

Acceptance criteria

• The launcher opens RuneLite, not the installer.
• The runtime plugin catalogue contains both hidden test plugins.
• An exact saved TEST_ label is selected without manual login.
• A controlled failure writes result.json, at least the start/failure screenshots, and the expected nonzero process exit.
• A successful wrapper completion exits zero only after the COMPLETE postcondition.

Error 2: Set name functional owner is not resolved

Evidence

After name lookup, the visible text node was:

Property	Value
Packed widget ID	36569107 (558:19)
Text	Set name
Actions	none
Listener	none

Searching by action found the live interaction owner at the same packed address with:

Property	Value
Parent ID	36569092
Action	Set name
getOnOpListener()	present
Dispatch mode	NATIVE_CC_OP
Bounds	(200, 267), 120 x 30

The controller's raw widgetVisible(NAME_SET) gate did not recognize this actionable owner and waited. A single native op-1 dispatch to the resolved owner produced the required postcondition: the name interface closed and appearance customization opened.

Proposed fix

1. Resolve NAME_SET by action ownership, not by visibility of only the raw/static widget instance.
2. Promote an actionless label or dynamic child to the visible owner exposing Set name.
3. Because the owner has getOnOpListener(), dispatch native CC_OP; do not force a raw widget packet for this control.
4. Make the functional-child wait bounded. If the owner cannot be resolved, halt with the root, candidate IDs, parent/index, visibility, actions, listener flags, and selected dispatch mode.
5. Add controller/runtime tests covering an actionless text child plus a listener-backed action owner at the same packed address.

Acceptance criteria

• From a clean varp-1 account, the plugin finds and invokes the Set name owner without manual intervention.
• A captured menu/widget event identifies native op 1 on the listener-backed owner.
• The observed postcondition is appearance-root visibility; DISPATCHED alone is insufficient.
• The controller cannot remain in waiting for functional child indefinitely.

Error 3: shift-drop workflow never opens or searches All settings

Evidence

At varp 7, client setup logged:

Client settings skipped: shift-drop setting unsupported: WIDGET_NOT_FOUND

The client did not open the All settings interface and did not search for shift-drop before returning this result. Live source confirms that setShiftDropEnabled(...) returns WIDGET_NOT_FOUND with Shift-drop preference has no revision-stable runtime setter; it performs no interface navigation, search, control resolution, dispatch, or read-back. The result does not establish that the live shift-drop control or its mapping is missing.

The current fail-open behavior allowed Tutorial Island to continue, so this workflow omission was not the terminal failure.

Proposed fix

1. Open the Settings tab, then open All settings, observing each interface postcondition before continuing.
2. Focus the All settings search control, search for shift drop, and wait for the filtered result to become visible.
3. Resolve the visible shift-drop toggle and its actual interaction owner, including action and listener metadata, before selecting a dispatch mode.
4. Dispatch the toggle only when read-back shows the setting is not already enabled.
5. Verify the enabled state through the live setting or control state, then clear/close the search interface as needed for the tutorial flow.
6. Preserve fail-open behavior for an unavailable optional setting, but only classify it as unsupported after the navigation and search steps have run and produced bounded diagnostic evidence.

Acceptance criteria

• Logs and captured widgets show All settings opened and shift drop searched.
• When supported, the correct toggle owner is invoked and the setting is read back as enabled.
• When unsupported after a real search, the plugin emits one bounded warning containing the search/control evidence and continues without repeated writes.

Error 4: Gielinor Guide exit approach is not route-feasible

Terminal evidence

TutorialIsland transition unresolved stage=WALK_TO_SURVIVAL varp=10
expectedObjectId=9398 expectedTile=WorldPoint(x=3098, y=3107, plane=0)
player=WorldPoint(x=3095, y=3108, plane=0) walkerStatus=IDLE retry=6/6

Before the halt, every approach attempt returned an accepted start message similar to:

Started Tutorial Island walker path (PLANNING)

The observed state did not confirm movement: the player remained near the original position, the walker returned to IDLE, and no Open interaction or door postcondition was observed. The exact door tile is an object tile and should not be assumed to be a walkable destination.

Proposed fix

1. Select a route-feasible adjacent interaction tile from the door object's reachable perimeter rather than walking to the object tile itself.
2. Treat walker planning/dispatch as pending. Confirm player progress, active path state, or arrival within interaction distance before consuming a transition retry.
3. When the walker returns to IDLE without progress, record the planning termination reason and recompute from the live object plus collision state.
4. Once adjacent, resolve object 9398, verify its live Open action, and interact with the concrete object instance.
5. Extend the terminal diagnostic with exact/near matching object counts, interactable/reachable state, hint type/tile, walker target and termination reason, and available menu actions.

Acceptance criteria

• The player reaches a valid adjacent tile.
• A captured interaction identifies object 9398 and action Open.
• One of the declared postconditions is observed: door disappearance/morph, entry into the Survival area, or tutorial varplayer advancement.
• Repeated PLANNING -> IDLE without movement cannot be reported as successful approach dispatches.

Error 5: post-shrimp Click here to continue targets the wrong widget owner

Evidence

After a shrimp was caught, the client remained at tutorial varplayer 50 with packed widget 12648448 visible. Describing the raw widget returned:

Property	Value
Packed widget ID	12648448
Parent ID	10617399
Actions	none
Listener	present
getOnOpListener()	absent
Selected dispatch mode	RAW_PACKET
Bounds	(20, 361), 479 x 96

Searching the live widget tree by text found the actionable dynamic child:

Property	Value
Packed widget ID	12648448
Runtime child index	2
Text	Click here to continue
Action	Continue
Listener	present
getOnOpListener()	present
Selected dispatch mode	NATIVE_CC_OP

The plugin log repeatedly alternated between:

action=Continue dialogue status=DISPATCHED message=Queued dialog continue

and:

status=Confirmed Continue dialogue

The visible widget remained open and varplayer 281 remained 50. Those generic confirmations were false positives; the required dialogue or tutorial-stage postcondition was not observed.

Proposed fix

1. Make continue-widget discovery return the visible actionable dynamic child, not the actionless root/container sharing its packed ID.
2. Resolve the owner using visible text plus the Continue action and promote to the child with getOnOpListener().
3. Dispatch native CC_OP for this owner. Do not send a raw widget packet to the actionless container.
4. Replace the generic TutorialActionObservation inequality check for dialogue continuation with a dialogue-specific postcondition: the owner disappears, the dialogue content/owner changes, or the tutorial varplayer advances.
5. Do not record Confirmed Continue dialogue because unrelated client observation data changed after dispatch.
6. Bound repeated continuation attempts and halt with the root/child IDs, runtime index, text, actions, listener flags, dispatch mode, current varplayer, and unchanged postcondition.
7. Add a live-shaped controller/runtime test for the post-shrimp varp-50 interface, including an actionless root and listener-backed dynamic child at the same packed ID.

Acceptance criteria

• After the shrimp enters inventory, the plugin identifies runtime child index 2 as the interaction owner.
• A captured interaction records native op 1 / Continue on the listener-backed child.
• The widget disappears or changes and varplayer advances beyond 50.
• No Confirmed Continue dialogue status is emitted while the same owner and varplayer remain unchanged.
• The controller cannot retry the unchanged continue interface.

Rerun order

1. Repair and statically verify the harness launcher, manifest registration, and packaged-jar loading contract.
2. Replay name creation until Set name advances without intervention.
3. Replay varp 10 in manual stage mode and capture object/menu/path evidence.
4. Replay the post-shrimp varp-50 continue interface and capture the native owner plus observed dialogue/varplayer postcondition.
5. Run the 1,800-second Tutorial Island harness from an exact TEST_ profile.
6. Run a complete unattended replay before promoting any remaining matrix rows to LIVE_VERIFIED.

Related authority:

• docs/[agent-testing-loop.md`](../agent-testing-loop.md)
• docs/agent/[AGENTIC_TESTING_LOOP.md`](../agent/AGENTIC_TESTING_LOOP.md)
• docs/_internal/[tutorial-island.md`](../_internal/tutorial-island.md)
• docs/_internal/[tutorial-island-transition-catalogue.md`](../_internal/tutorial-island-transition-catalogue.md)
• docs/validation/[tutorial-island-rev239.md`](tutorial-island-rev239.md)