diff --git a/docs/research/playerbots-execution.json b/docs/research/playerbots-execution.json
index c3f2bb4da..906afb02a 100644
--- a/docs/research/playerbots-execution.json
+++ b/docs/research/playerbots-execution.json
@@ -468,7 +468,9 @@
         "PB-001 found no existing line-of-sight Gate in targeted cast admission. Add the appropriate shared Gate with supported exemptions and client/bot parity coverage so the movement prerequisite responds to a real typed Refusal. Channel actions remain unsupported until their running lifecycle is correlated.",
         "The historical Actor cast bypasses the player spellbook check. PB-003 owns the appropriate shared Gate for the new runner and must coordinate with provisioning in PB-005. An unlearned heal must refuse without cast, power, or cooldown changes.",
         "Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.",
-        "Shared design keeps one durable objective and one foreground action. A moving leader refreshes the companion destination without replacing the retained heal identity. Each parallel branch must prove behavior against merged prerequisites."
+        "Shared design keeps one durable objective and one foreground action. A moving leader refreshes the companion destination without replacing the retained heal identity. Each parallel branch must prove behavior against merged prerequisites.",
+        "The companion recovery fixture must cover critical health at a reached leader destination. A permanent survival Hold cannot block both useful self-recovery and necessary bounded provisioning.",
+        "The latest companion diagnostic passed five of six cases, including the real ally heal, moving leader, recovery, and populated upgrade. Independent Spec review then found three gaps: heal targets could change between prerequisite movement legs, channel rotations could hide a supported heal, and seed repair accepted an altered effect set. Standards review also requires an explicit wait for missing group metadata and independent cast Gate tests. These corrections and new behavior cases are in progress; final acceptance remains pending."
       ],
       "acceptance_evidence": []
     },
@@ -537,7 +539,10 @@
       "evidence": [],
       "notes": [
         "Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.",
-        "Agreed integration performs at most one provisioning operation per eligible Cohort tick, with no foreground action. Spawn and level-up arm reconciliation; they do not grant resources outside current control and Account ownership checks."
+        "Agreed integration performs at most one provisioning operation per eligible Cohort tick, with no foreground action. Spawn and level-up arm reconciliation; they do not grant resources outside current control and Account ownership checks.",
+        "The real runner hook distinguishes an applied profile operation from a recorded refusal or deferral. Only applied work consumes the tick. Satisfied checks and recorded failures allow the chosen gameplay action to continue; backoff bounds retries.",
+        "Useful survival, recovery, and defense outrank routine upkeep. New core operations return typed causes. An older String refusal may remain opaque detail but must not be classified by parsing its text.",
+        "The first runtime diagnostic passed the talent Gate case. Source corrections now distinguish recovery grants from item use, preserve truthful equipment refusal causes, and stop explicitly when bounded profile reads overflow. The corrected implementation is committed and awaits a complete clean runtime pass. Final acceptance and review remain pending."
       ],
       "acceptance_evidence": []
     },
@@ -573,7 +578,9 @@
       "notes": [
         "Imported source identifies quest 3904 as a collect-item quest backed by chest loot. The existing GameObject use operation needs Package visibility and bounded object discovery. Verify and correct the importer NextQuestInChain column mapping before relying on forward links.",
         "Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.",
-        "Catalog admission must prove a currently callable executor for every required kind. Imported destination evidence is separate from live target discovery. PB-007 owns the later autonomous quest sequence; its planned work cannot establish executor availability today."
+        "Catalog admission must prove a currently callable executor for every required kind. Imported destination evidence is separate from live target discovery. PB-007 owns the later autonomous quest sequence; its planned work cannot establish executor availability today.",
+        "The reference ClassicDB source identity stays separate from observed runtime content and destination revisions. Seeded content or a later import cannot inherit an unverified source hash. A refresh scenario must cover held objectives when the observed content changes.",
+        "The clean catalog run passed all seven admission and behavior cases with no compile warnings. Root verified 17 saved records against the exact core, Package, and Wasm identities. The eighth case, populated PB-002 upgrade, used an incorrect nested-option check; its corrected fixture awaits rerun. Independent review and final acceptance remain pending."
       ],
       "acceptance_evidence": []
     },
@@ -792,6 +799,6 @@
       "observations": {}
     }
   ],
-  "updated_at": "2026-09-08 16:51 UTC",
+  "updated_at": "2026-09-08 18:53 UTC",
   "summary": "PB-001 and PB-002 are complete and integrated. PB-003, PB-005, and PB-006 are implementing Priest companions, automatic provisioning, and supported-quest admission in parallel. The orchestrator owns shared-contract integration, review, PR merges, and the published record."
 }
diff --git a/docs/research/playerbots-rewrite.html b/docs/research/playerbots-rewrite.html
index 8b5c5d286..671e7f301 100644
--- a/docs/research/playerbots-rewrite.html
+++ b/docs/research/playerbots-rewrite.html
@@ -37,7 +37,7 @@ <h1>Playerbots rewrite proposal</h1>
 <section id="execution">
 <h2>Execution tracker</h2>
 <p>The spec and tickets below drive implementation. Expand a title for the behavior, acceptance criteria, and recorded evidence. Parent totals include every child. Completion requires reviewed evidence for every criterion and merged PRs. The final ticket also requires imported-world and attended-client observation records.</p>
-<p><strong>Updated 2026-09-08 16:51 UTC.</strong> PB-001 and PB-002 are complete and integrated. PB-003, PB-005, and PB-006 are implementing Priest companions, automatic provisioning, and supported-quest admission in parallel. The orchestrator owns shared-contract integration, review, PR merges, and the published record.</p>
+<p><strong>Updated 2026-09-08 18:53 UTC.</strong> PB-001 and PB-002 are complete and integrated. PB-003, PB-005, and PB-006 are implementing Priest companions, automatic provisioning, and supported-quest admission in parallel. The orchestrator owns shared-contract integration, review, PR merges, and the published record.</p>
 <p>Ready to start: <span id="execution-ready">No unassigned work is ready.</span>. The orchestrator republishes progress to this URL. Filters operate on this published snapshot.</p>
 <div class="execution-controls">
 <label for="execution-search">Find work <input id="execution-search" type="search" placeholder="Ticket, behavior, owner, evidence"></label>
@@ -46,7 +46,7 @@ <h2>Execution tracker</h2>
 <button type="button" id="execution-collapse">Collapse details</button>
 </div>
 <p id="execution-count" aria-live="polite">12 tickets</p>
-<div class="table-scroll execution-table"><table><thead><tr><th>Identifier</th><th>Spec and ticket hierarchy</th><th>Status</th><th>Owner</th><th>Blocked by</th><th>Pull requests</th></tr></thead><tbody><tr id="work-PB" class="parent-row" data-work-status="planned" data-work-kind="Spec" data-parent=""><td><code>PB</code><br>Spec</td><td style="padding-left:12px"><details><summary>Rewrite playerbots around durable objectives and typed action outcomes</summary><div><h3>Problem statement</h3><p>The current playerbots Package can accept an action without proving that the action completed, loses route results, treats attempted combat as quest progress, bypasses the normal cast lifecycle, and retains too little purpose across interruption, restart, and Transfer. Bots can therefore stall, repeat work, choose an obsolete target, or abandon useful intent without explaining why. The current tests also do not prove the Package and core together against real actor operations, imported content, navigation, protocol transitions, and sustained load.</p><h3>Solution</h3><p>Replace the behavior control flow with one typed Rust decision runner shared by autonomous bots and human-led companions. The runner observes bounded facts, composes supported Strategies, ranks target-bearing candidates deterministically, executes actions through core operations, records typed outcomes, and retains one durable objective with bounded failure memory. Build the rewrite through a pinned real Module and Package fixture, then prove companion behavior, provisioning, seeded quest loops, recovery, commands, restart, Transfer, load, cutover, and attended client behavior before deleting the displaced implementation.</p><h3>User stories</h3><ol><li>As an Operator, I want every bot controlled by one eligible runner, so that two behavior systems cannot issue conflicting actions.</li><li>As an Operator, I want a stopped bot to report its objective, target, chosen action, outcome, retry count, next eligible time, and content revision, so that I can diagnose it without reading source.</li><li>As an Operator, I want decision work scheduled in bounded fair batches, so that a large roster cannot monopolize a Module tick.</li><li>As an Operator, I want excess due bots deferred with recorded lag, so that overload does not silently discard durable work.</li><li>As an Operator, I want repeatable provisioning profiles, so that I can explain why a bot received a spell, item, or supply.</li><li>As an Operator, I want deployment capacity based on measured runs of 10, 25, and 100 bots, so that release limits reflect this implementation.</li><li>As a developer, I want fixed facts and time to produce the same decision, so that policy changes have reproducible tests.</li><li>As a developer, I want candidates identified by action, target, and relevant event, so that a higher score cannot retain the wrong target.</li><li>As a developer, I want each supported action to return a typed outcome, so that success, waiting, Refusal, cancellation, expiry, and infrastructure failure remain distinct.</li><li>As a developer, I want action prerequisites, alternatives, and continuers to be bounded, so that retries and cycles cannot run forever.</li><li>As a developer, I want a reproducible Module and Package fixture at pinned revisions, so that failures and fixes can be compared against the same content and geometry.</li><li>As a developer, I want casts to use the normal core cast-start lifecycle, so that cast time, interruption, cancellation, cost, and completion use the same Gates as client casts.</li><li>As a developer, I want movement outcomes to preserve route completion and coverage evidence, so that policy can distinguish progress, a partial route, blockage, and unknown coverage.</li><li>As an autonomous bot, I want one objective retained across tactical interruptions, so that defending myself does not erase my quest purpose.</li><li>As an autonomous bot, I want quest admission to require an executor for every required objective, so that unsupported quests do not trap me.</li><li>As an autonomous bot, I want to accept, travel for, complete, and turn in a supported kill quest, so that I can earn normal quest credit and XP.</li><li>As an autonomous bot, I want to find the actual drop source, loot it, and turn in a supported collect quest, so that collection progress comes from gameplay outcomes.</li><li>As an autonomous bot, I want supported talk-only chains and simple GameObject objectives executed through normal core interactions, so that a quest route does not stop at a non-combat step.</li><li>As an autonomous bot, I want the actual quest ender retained from the catalog, so that I travel to the correct turn-in Character or GameObject.</li><li>As an autonomous bot, I want death, combat, full bags, absent targets, and temporary route failure to have finite recovery rules, so that I can resume or stop with a specific reason.</li><li>As an autonomous bot, I want a failed destination deferred by map, instance, and geometry revision, so that a restart cannot immediately choose the same failed target again.</li><li>As an autonomous bot, I want skill and spell training, vanilla talents, equipment, and supplies reconciled on spawn and level-up through core Gates, so that I remain playable without receiving invalid progress.</li><li>As a human party leader, I want a companion to follow or stay on command, so that I control its position.</li><li>As a human party leader, I want a companion to assist my chosen fight or a designated target, so that it does not pull an unrelated enemy.</li><li>As a human party leader, I want companions to respect controlled enemies, so that crowd control is not broken by autonomous target choice.</li><li>As a human party leader, I want each companion to retain an explicit tank, healer, or damage role, so that party behavior remains predictable through death and Transfer.</li><li>As an injured party member, I want a Priest companion to repair range or line of sight and complete one real heal cast, so that repeated decisions do not restart the cast bar.</li><li>As a party member, I want a Warrior tank to hold the chosen fight and a Mage damage companion to act at class-appropriate range, so that role does not erase class capabilities.</li><li>As a companion, I want joining a human-led party to suspend autonomous travel and leaving it to resume a still-valid solo objective, so that control changes preserve useful intent.</li><li>As a companion, I want my role, party intent, and retained objective reconciled after restart and Transfer, so that delayed work from the old location cannot act.</li><li>As a maintainer, I want the old behavior source and obsolete state retired after both release suites pass, so that one implementation remains authoritative.</li><li>As a party member, I want companions to heal and apply useful missing buffs between fights, so that the party starts the next fight ready without repeated redundant casts.</li></ol><h3>Implementation decisions</h3><ul><li>Use a targeted Rust rewrite of the useful AzerothCore decision grammar. Do not port its C++ runtime, synthetic World Sessions, packet queues, host object graph, or WotLK rules.</li><li>Keep durable gameplay authority in the Module. Keep party authority in Realm-core. Use existing Transfer and Group Intent routing only for their realm-wide responsibilities.</li><li>Give the Package one small decision interface, one action execution interface, and one explanation read. Keep internal behavior behind those interfaces.</li><li>Represent Strategies, triggers, facts, candidates, actions, targets, outcomes, tactical modes, objective stages, and failure reasons with typed values instead of strings and dynamic lookup.</li><li>Rank candidates with integer scores and stable tie-breaking. Candidate identity includes the action, target, and relevant event. Saved random state may break equal valid choices only.</li><li>Support bounded prerequisites, alternatives, and continuers. Limit candidate count, graph depth, transitions, and route expansion independently during each decision pass.</li><li>Allow one foreground action to own movement or a cast. A higher-priority action must explicitly cancel incompatible work before it starts.</li><li>Retain the quest or party objective across tactical interruption. Store its identity, destination, stage, deadline, last verified progress, deferred destinations, bounded failure memory, and catalog revision.</li><li>Keep route segments and live target observations transient. Correlate pending work with controller generation and location so stale completions cannot advance current state.</li><li>Treat action acceptance and actual progress as different facts. Track movement, combat, cast, and quest progress with separate evidence and clocks.</li><li>Expose typed outcomes from the owning core operations for the actions the selected behaviors require. Preserve existing Gates and atomic Refusal behavior.</li><li>Route bot spells through the normal cast-start and timed completion lifecycle. A running cast stays retained until completion, interruption, cancellation, or expiry.</li><li>Preserve complete, partial, blocked, and explicit unknown-coverage movement evidence. Do not infer missing coverage only from absent sparse navigation rows.</li><li>Derive tactical mode and active Strategies from durable Character, party, combat, aura, health, threat, target, position, and capability facts. Do not create a second authoritative state machine.</li><li>Use the bounded priority order from the report: lifecycle and Transfer restrictions, immediate survival, urgent party support, the current fight, human orders, maintenance, autonomous quest work, then idle activity.</li><li>Store an indexed next-decision time per bot, process due bots in stable order with a fixed batch limit, coalesce urgent reconsideration reasons, and record lag for deferred work.</li><li>Build a versioned supported quest catalog from imported quest relations, objectives, spawns, loot sources, and actual enders. Admit only quests whose required objectives have executors.</li><li>Start autonomous release coverage with a seeded Northshire and Elwynn catalog and ordinary quest credit and earned XP. Treat this as a bounded proof rather than level 1 to 60 coverage.</li><li>Start companion release coverage with Warrior tank, Priest healer, and Mage damage capabilities. Store the explicit role and derive a deterministic vanilla default when none is chosen.</li><li>Support durable follow, stay, assist, and designated-target orders through the existing command transport. Joining a human-led party suspends solo work; leaving rechecks and resumes it when valid.</li><li>Reconcile skill and spell training, vanilla talent choices, equipment, bags, food, potions, ammo, reagents, and bounded supplies as separate idempotent actions through core Gates. Provisioning never changes level, grants quest completion, deletes quest items, or duplicates owned resources.</li><li>Add new state through an additive migration and one durable controller selector. Use record-only comparison before a small active cohort, then retire the old controller and its obsolete state after release acceptance.</li><li>Keep a bounded history of transitions and failures. Do not retain one row for each successful idle decision.</li></ul><h3>Testing decisions</h3><ul><li>Use the highest real seam available. Pure tests cover deterministic policy, durable Module and Package fixtures cover gameplay operations and navigation, Headless Client scenarios cover protocol and world transitions, and attended client observation covers visible behavior.</li><li>The baseline fixture pins core commit 95e6ad8c61540f74471e3087897e8c3ef7e065d1 and Package Collection commit c32b2fb7aa405190728034b63ce6eb9a3c0dd6be together with named imported content and geometry revisions.</li><li>Every supported action has behavioral cases for success, waiting, Refusal, cancellation, and expiry. Infrastructure failures remain separate where the seam can produce them.</li><li>Durable fixtures call real actor, cast, movement, quest, loot, item, and lifecycle operations. They do not replace gameplay with a simulated combat model.</li><li>Decision fixtures cover stable candidate order, target-bearing identity, bounded transition graphs, survival against role work, healing against following, and combat interruption against retained quest work.</li><li>Movement fixtures measure route or waypoint advancement. After 10 seconds without movement progress the bot changes approach; within 30 seconds it advances, defers the destination, or records a specific wait.</li><li>Cast fixtures prove one long cast starts once, survives intervening decisions, and ends once by completion, interruption, cancellation, or expiry.</li><li>Companion fixtures cover follow, stay, assist, designated target, controlled enemies, poor range, loss of line of sight, wounded allies and missing buffs between fights, death, regrouping, and one instance entry and exit.</li><li>Autonomous fixtures run ten seeds per starter class through the supported Northshire and Elwynn catalog. All ten runs per class must finish each supported scenario without Operator help: nine of ten is below the 95 percent requirement. Every failed run must record an explained outcome and fails the release gate.</li><li>Autonomous mandatory scenarios include kill, collect, talk-only chains, supported simple GameObject use, turn-in, death, interruption, full bags, absent targets, an unreachable giver, unsupported objectives, and restart with a retained objective.</li><li>Restart and Transfer fixtures interrupt active action and escrow stages. They prove no duplicate Character, equipment, supply grant, quest reward, or active controller and prove stale work cannot act on the old location.</li><li>Load fixtures run 10, 25, and 100 bots on one named disposable fixture and record decision time, movement time, scheduler lag, route expansions, row reads, row writes, and the slowest due bot before capacity is set.</li><li>Final observation requires one hour with 25 bots on imported content plus an attended companion session in a real unmodified 1.12.1 client. A human must collect and sign off this evidence if the implementation environment cannot run that client.</li><li>Review final behavior against this specification and repository standards after the focused and full relevant checks pass.</li></ul><h3>Out of scope</h3><ul><li>A direct or mechanical port of the complete AzerothCore playerbots runtime.</li><li>Synthetic World Sessions or packet observation inside the Package.</li><li>A user-defined action language, global string factory, client addon, or new product UI.</li><li>Claims of general level 1 to 60 quest coverage, all classes, all regions, all dungeons, or thousands of bots.</li><li>Exploration, escort, scripted-event, transport, and other quest objective types until they receive explicit executors and catalog support.</li><li>Routine catch-up teleportation through blocked geometry.</li><li>A full economy simulation or provisioning that changes level, fabricates quest credit, clears inventory, or completes prerequisite quests.</li><li>A full Deadmines run unless the team later selects it as the first dungeon milestone.</li><li>Production realm changes, live database inspection, publication, or deployment as part of implementation and local acceptance.</li></ul><h3>Further notes</h3><ul><li>The source report proposes acceptance thresholds. Implementation must measure them before treating them as release facts.</li><li>Bad or stale imported geometry can imitate a policy defect. Every route fixture and observation record names its content and geometry revisions.</li><li>The source comparison found no behavioral assertion suite in the pinned AzerothCore tree. Its architecture is evidence for design choices, not proof of LyraCore behavior.</li><li>Record provenance if any reference code is copied or translated. The architecture proposal does not make a license-compatibility conclusion.</li><li>Attended real-client observation is a release gate that may require a human after agent implementation. The implementation tickets must prepare the exact scenario, capture format, and diagnostic reads without claiming that a client session already ran.</li><li>Unresolved product choices remain level range beyond the initial catalog, the first full dungeon milestone, equipment strength beyond level-appropriate starter gear, and any explicit catch-up travel policy. They do not block the bounded first release.</li><li>The user authorized autonomous implementation, PR ownership through review, and confident merges. The HTML is the tracker; no issue publication or planning interview is required. Production changes remain outside this authorization.</li><li>The initial tracer uses real Module and Package operations with named seeded inputs. Client-derived geometry is unavailable in the current workspace. Record this absence instead of treating the seeded route as imported-world proof; PB-011 and PB-012 retain the imported-input release gates.</li></ul></div></details><small>Parent: Root</small></td><td>2/12 complete</td><td>Orchestrator</td><td>None</td><td><a href="https://github.com/LyraCoreProject/LyraCore/pull/481" rel="noopener noreferrer">Execution report #481 merged</a><br><a href="https://github.com/LyraCoreProject/LyraCore/pull/483" rel="noopener noreferrer">Progress #483</a></td></tr><tr id="work-S1" class="parent-row" data-work-status="complete" data-work-kind="Workstream" data-parent="PB"><td><code>S1</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Typed action foundation and durable runner</summary><div><p>Typed action foundation and durable runner</p></div></details><small>Parent: PB</small></td><td>2/2 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-001" class="ticket-row" data-work-status="complete" data-work-kind="Ticket" data-parent="S1"><td><code>PB-001</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Prove typed outcomes in a real pinned fixture</summary><div><p>Create the first tracer through a reproducible pinned Module and Package fixture. Drive attack, interaction, movement, and cast-start through real core operations, return typed outcomes to the Package, and capture the blocked-target and out-of-range-heal failures that the rewrite must fix.</p><h3>Acceptance criteria</h3><ul><li>The fixture records pinned core and Package commits plus the actual content and geometry input revisions, labels seeded and client-derived provenance separately, records unavailable inputs, and reproduces the same initial state and outcome.</li><li>The fixture loads and runs the real Module with the real Package; it does not substitute a simulated gameplay engine.</li><li>Attack acceptance is distinct from damage and quest progress, and an attempted attack with no hit cannot clear a quest progress clock.</li><li>Movement reports complete, safe partial, blocked, or explicit unknown-coverage evidence with route or waypoint advancement where applicable.</li><li>Interaction and cast-start return typed success, waiting, Refusal, cancellation, and expiry outcomes supported by their owning operations.</li><li>A long bot cast uses the normal core cast lifecycle and completes once without restart on later decision ticks.</li><li>The blocked target and poor-range heal cases have reproducible inputs, observed outcomes, and enough evidence to compare later runner behavior.</li><li>A written extraction comparison chooses the smaller total implementation and records why the full AzerothCore runtime is not used.</li></ul><p>Verified criteria: 8/8.</p><p>The fixture records pinned core and Package commits plus the actual content and geometry input revisions, labels seeded and client-derived provenance separately, records unavailable inputs, and reproduces the same initial state and outcome.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>All 16 final CI input records name clean core fe9caef6eb0d132c45a5d151827ab6fe64925f79 and GitHub tested Package merge 744732b50cc8135d3a06e598e07e26aa8633a434, whose parents are main c32b2fb and reviewed Package c97464f6be211525a3b36a2ee3824cf259edbdd1. Content is playerbots-seeded-actions-v1; geometry is playerbots-synthetic-nav-v1. Imported content and client geometry are explicitly unavailable.</li><li>CI Module BLAKE3: a4e921d874c49ada97f9893b4c9b41847ffdb994c670dcd3ea5673f0fab466fd. Package BLAKE3: 1b4de3cdafc56407264c216a3accda917117277914b2deffb4fbd0c3efaf29f6. The local focused Module has a different installed inventory; byte equality across those builds is not claimed.</li><li>Input manifest: https://github.com/LyraCoreProject/packages/blob/c97464f6be211525a3b36a2ee3824cf259edbdd1/playerbots/fixtures/actions.json</li><li>CI input and outcome artifacts: https://github.com/LyraCoreProject/packages/actions/runs/34229152446</li><li>The final run against merged core be3fa67d also records 16 clean input and outcome pairs. Tested Package merge b451105562bbb5deab45ceff9919b9e002aa240d has parents c32b2fb and reviewed head 0781d7e5. Module and Package identities match the preceding CI run. Artifacts: https://github.com/LyraCoreProject/packages/actions/runs/34230810246</li></ul><p>The fixture loads and runs the real Module with the real Package; it does not substitute a simulated gameplay engine.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The local fixture passed all 16 cases through compiled Module Wasm, the real Package, and private SpacetimeDB 2.7.1 Standalone nodes. The final CI run below also includes the later repeated-setup checks.</li><li>The same behavior passed in Package CI: https://github.com/LyraCoreProject/packages/actions/runs/34226546164/job/102061988209</li><li>Final fixture changes also passed all 16 cases in 166.26 seconds: https://github.com/LyraCoreProject/packages/actions/runs/34229152446/job/102070649535</li><li>The same 16 fixtures passed against merged core main before the Package merge: https://github.com/LyraCoreProject/packages/actions/runs/34230810246/job/102076215519</li></ul><p>Attack acceptance is distinct from damage and quest progress, and an attempted attack with no hit cannot clear a quest progress clock.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>playerbots_an_accepted_attack_without_a_hit_does_not_clear_quest_stall observes accepted engagement, full target health, zero quest credit, and an unchanged stall clock behind a synthetic wall. Its positive phase uses the real lethal-hit pipeline to award credit; it does not claim that the bot hit through the wall.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>Movement reports complete, safe partial, blocked, or explicit unknown-coverage evidence with route or waypoint advancement where applicable.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The complete-route and partial-route cases distinguish a proposed leg from observed arrival, retain a waypoint and search-work count, and record Unknown coverage. The blocked-target case holds position. Shared navigation tests passed 34 cases; VerifiedCells only attests consulted derived rows.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>Interaction and cast-start return typed success, waiting, Refusal, cancellation, and expiry outcomes supported by their owning operations.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The fixture covers typed cast start/wait/resolve/refusal/cancel/expire outcomes, synchronous quest completion/refusal, full-inventory and invalid-choice atomicity, source-item refusal, and dead-attacker refusal. All 16 final cases passed.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>A long bot cast uses the normal core cast lifecycle and completes once without restart on later decision ticks.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>playerbots_a_long_bot_cast_waits_for_core_completion retains one five-second cast through repeated requests and normal decision ticks, observes one START and one GO, and verifies the heal. The owning begin operation returns its exact result directly.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>The blocked target and poor-range heal cases have reproducible inputs, observed outcomes, and enough evidence to compare later runner behavior.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The blocked-target scenario and playerbots_an_out_of_range_heal_reports_the_owning_cast_gate record reproducible inputs and typed observations. The poor-range target starts at x=1400 while the bot starts at x=1200. Actions retain target, route, clipping, coverage, cast identity, and Refusal.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>A written extraction comparison chooses the smaller total implementation and records why the full AzerothCore runtime is not used.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The extraction comparison in the Package README chooses typed Rust decisions and existing Module operations. It compares the 2,967-line selection-kernel inventory with the 243,560-line C++ runtime and records host-pointer, packet, and WotLK dependencies. https://github.com/LyraCoreProject/packages/blob/c97464f6be211525a3b36a2ee3824cf259edbdd1/playerbots/README.md</li><li>https://github.com/LyraCoreProject/LyraCore/pull/482#issuecomment-5585257477</li></ul><p>Execution model: gpt-6-astra, high effort. Repositories: LyraCore Module action and navigation contracts, Official Package Collection playerbots fixture, Local durable integration tests.</p><h3>Recorded evidence</h3><ul><li>Baseline on core 95e6ad8 and Package c32b2fb: both ignored personality durable tests passed in a private loopback Standalone. This proves the existing Package fixture, not the new outcome contract.</li><li>Final local union passed 1,621 Module unit tests normally, 1,622 with debug reducers, and 32 durable cases. Default-core SpacetimeDB 2.7.1 generation matched all 995 committed Gateway binding files. Independent standards findings are resolved or explicitly accepted; Spec review found no confirmed defects.</li><li>The final Package CI run passed all 16 strengthened fixtures against core fe9caef6. Repeated interaction setup now clears only its reserved target and quest rows, including stale movement and engagement. Evidence: https://github.com/LyraCoreProject/packages/actions/runs/34229152446/job/102070649535</li><li>Core #482 merged as be3fa67d0f0c24749230560544a3e8e8b577f61d after all checks passed, including the full durable job: https://github.com/LyraCoreProject/LyraCore/actions/runs/34229150494/job/102070610422</li><li>Final Package checks against merged core main passed, including all 16 durable fixtures in 167.90 seconds. Package #25 merged as 5724de1660a2628e88320914bdd5abb0c69da517. CI: https://github.com/LyraCoreProject/packages/actions/runs/34230810246/job/102076215519</li></ul><h3>Current notes</h3><ul><li>All eight source acceptance criteria have reviewed evidence. Core #482 and Package #25 are merged.</li><li>Package CI was restored to core main after the core merge. All final checks passed before the Package merge.</li><li>Both full CodeRabbit reviews completed. The repeated-setup finding is fixed; the core CI coverage question is resolved by the paired Package durable job. Final incremental automated review was rate limited. Independent review covered the final fixture changes. All core checks passed.</li><li>The flat observation row remains intentional for SQL diagnosis. Action-specific request functions and a private recorder own production writes; PB-002 owns typed runner candidates and foreground control.</li><li>The nullable quest-credit initialization fixture preserves an existing stall. A full older-Wasm upgrade was not claimed. The new Package schema remains subject to the repository human review requirement before shipping.</li></ul></div></details><small>Parent: S1</small></td><td>complete</td><td>PB-001 implementer</td><td>None</td><td><a href="https://github.com/LyraCoreProject/LyraCore/pull/482" rel="noopener noreferrer">Core #482</a><br><a href="https://github.com/LyraCoreProject/packages/pull/25" rel="noopener noreferrer">Package #25</a></td></tr><tr id="work-PB-002" class="ticket-row" data-work-status="complete" data-work-kind="Ticket" data-parent="S1"><td><code>PB-002</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Run one durable objective through bounded decisions</summary><div><p>Build the shared decision runner around typed facts and outcomes. Retain one objective, arbitrate one foreground action, schedule bots in stable bounded batches, and explain each meaningful choice through the Package&#x27;s normal entry point.</p><h3>Acceptance criteria</h3><ul><li>Fixed facts and explicit time produce the same target-bearing candidate order and chosen action.</li><li>Strategies compose supported triggers, defaults, and priority rules without a global string registry or a second authoritative state machine.</li><li>Prerequisites, alternatives, and continuers have explicit depth, transition, candidate, and route-work limits with cycle refusal.</li><li>Only one foreground movement or cast action owns the bot, and a higher-priority action explicitly cancels incompatible work.</li><li>The durable objective records identity, destination, stage, deadline, last verified progress, bounded failures, deferred destinations, and catalog revision.</li><li>Separate movement, combat, cast, and quest progress evidence prevents an accepted action from masquerading as completion.</li><li>Due bots run in stable indexed order under a per-pass limit; excess work remains due, gets a fair next turn, and records scheduler lag.</li><li>The explanation read reports the current objective and target, chosen action and reason, last outcome, progress age, retry count, next eligible time, and relevant revision with bounded history.</li><li>The additive state migration defines defaults and backfill and adds a durable controller selector before any bot can use the new runner. Record-only mode emits no gameplay actions; cohort mode has one eligible controller and supports freeze.</li></ul><p>Verified criteria: 9/9.</p><p>Fixed facts and explicit time produce the same target-bearing candidate order and chosen action.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The pure decision tests permute input order, rank full target-bearing identities, and retain only the highest-priority offer for each identity. All ten decision cases passed in the final library runs.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/decision.rs</li></ul><p>Strategies compose supported triggers, defaults, and priority rules without a global string registry or a second authoritative state machine.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>Typed Strategy tests cover triggers, defaults, and integer priority adjustment. The common runner stamps its durable objective identity into root and nested candidates before selection.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/decision.rs</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/runner.rs</li></ul><p>Prerequisites, alternatives, and continuers have explicit depth, transition, candidate, and route-work limits with cycle refusal.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The shared limits allow 24 candidates, depth 4, 16 transitions, and one route reservation using the core expansion limit. Separate tests cover each limit, cycles, and repeated cycle refusals inside completed prerequisites.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/decision.rs</li><li>Recovery facts use a paged index and exact learned-spell membership. Runtime regressions find a usable heal beyond 25 unlearned rotations and 300 other learned spells without an unbounded eligibility scan.</li></ul><p>Only one foreground movement or cast action owns the bot, and a higher-priority action explicitly cancels incompatible work.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The final real runner suite proves cast retention through pushback, explicit survival preemption, changed-destination cancellation, and freeze. The Account ownership case preserves a later human cast while the bot relinquishes control. All 21 runner cases passed.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li></ul><p>The durable objective records identity, destination, stage, deadline, last verified progress, bounded failures, deferred destinations, and catalog revision.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The retained ReturnHome objective records destination, identity, stage, deadline, last verified progress, and catalog revision. Blocked travel defers its destination and caps failures and deferrals at four entries. Real tests cover actual arrival, deferred travel under low health, and deadline expiry.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li></ul><p>Separate movement, combat, cast, and quest progress evidence prevents an accepted action from masquerading as completion.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The final tactical movement case moves away from home for more than ten seconds, records movement progress, and leaves the home progress clock unchanged. Defense acceptance does not count as damage. Cast completion uses the exact core scheduled identity. PB-001 quest-credit and no-hit cases still pass.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite.rs</li></ul><p>Due bots run in stable indexed order under a per-pass limit; excess work remains due, gets a fair next turn, and records scheduler lag.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The real 25-bot case proves stable indexed processing in batches of 16 then 9. Excess work remains due and records lag. The populated migration also verifies bounded lazy backfill.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li></ul><p>The explanation read reports the current objective and target, chosen action and reason, last outcome, progress age, retry count, next eligible time, and relevant revision with bounded history.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The public runner row exposes the objective, target-bearing chosen action and reason, last outcome, progress age, retry count, next eligible time, and revision. Its real lifetime case caps history at eight entries and deletes Character-owned state.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li><li>The separate Recovery Scan row exposes its cursor, bounded rows scanned, retained rotation, current stage, and last completed result. Missing remains valid during a subsequent Pending scan.</li></ul><p>The additive state migration defines defaults and backfill and adds a durable controller selector before any bot can use the new runner. Record-only mode emits no gameplay actions; cohort mode has one eligible controller and supports freeze.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The final populated upgrade publishes a preceding Wasm, creates bot roster, goals, observations, and quest rows, then upgrades the same private database. Legacy and scheduler-lag defaults survive. Normal tick and hook cases prove RecordOnly and Frozen suppression and one Cohort controller. Five real core consent cases cover current ownership, invitation admission, deletion, and Transfer.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/sessionless_consent.rs</li></ul><p>Execution model: gpt-6-astra, high effort. Repositories: Official Package Collection decision and durable state, LyraCore Module scheduling and diagnostics, Pure decision and durable integration tests.</p><h3>Recorded evidence</h3><ul><li>All nine criteria have reviewed source and runtime evidence. Final reviewed heads are core 4f450074d76f8982d1a7d61898a00cf632132737 and Package 62c459770eb5b2209b7cfbf38e54857454fa69d2. The complete local correction run used clean core a4b5518 and Package dba96bb; the later changes strengthen one test and restore CI references.</li><li>The full Package union passed 1,631 library tests, 1,632 with debug reducers, all 37 action and runner cases, two personality cases, and five core consent cases. This includes a populated preceding-Wasm migration.</li><li>All 37 runtime input records agree on Module BLAKE3 dba4d702a0320e360506f9698fa52e0ef7210ce1e8f9573928599a8e3e032279 and Package Content Identity 33fcb8a217aad84f46f9ad65efdad23be24bad8e29828777de7c7e6469417161. Saved Wasm: 7,590,466 bytes; SHA256 c44a91ee92bb22ebce3de07e39caf9d7028794460a855c3b1d1f9329e473a2ae.</li><li>Final Core #486 CI passed after the test-only update, including the full durable suite and all 1,000 default Gateway binding files. The exact spellbook index needs no generated binding change. CI: https://github.com/LyraCoreProject/LyraCore/actions/runs/34248547507/job/102136730760</li><li>Corrected paired Package CI passed all 37 cases against core a4b5518. Package branch dba96bb ran as synthetic merge e786ee50bb06fc1902b9f5a8e9514669f2d0689e. All inputs are clean and the Package content identity matches local. CI Wasm BLAKE3 is 80efd76cef0d52ee0342f9bc1fe1ee011bcbace0eac7e67e68c944cd427bf659. CI: https://github.com/LyraCoreProject/packages/actions/runs/34245772629/job/102127317130</li><li>The populated local upgrade uses preceding core be3fa67d0f0c24749230560544a3e8e8b577f61d and Package 5724de1660a2628e88320914bdd5abb0c69da517. Its Wasm BLAKE3 is 1662b0963dc0e03c29ddde985f08c0ec5a6f392e899a80eac9d7789a85b1b5a9. Preceding local inventory has example, fire_nova, and playerbots; current inventory also has dungeons. CI independently builds the full preceding collection and records its own Wasm identity.</li><li>Six added regressions cover late eligible heals, retained healing eligibility, health-ratio overflow, isolated fixture timing, navigation grid edges, and a completed missing heal result that permits home movement during rescans. Independent Spec and Standards reviews cleared the final source; the orchestrator reviewed the workflow-only pin update.</li><li>The final core change, 4f450074d76f8982d1a7d61898a00cf632132737, strengthens the grid cleanup test. Its focused durable run proves that each grid corner loses all four nearby chunks while a distant chunk survives. Independent Spec and Standards reviews cleared this test-only delta, and CodeRabbit marked its finding addressed. Gameplay source is unchanged from the 37-case run.</li><li>The focused grid run records clean core 4f45007 and unchanged Package dba96bb. Its Wasm BLAKE3 is 18a320609eebb7a163154d891953decbbc5bdaa401e81d339acb06dd73eaa9e9 and SHA256 is 713ad9a2401029fd10e184c91da3a4eeee1c7e402ad206bf59b598e4afb55a0e. Package Content Identity matches the complete local suite.</li><li>CodeRabbit completed its Package correction review at dba96bb. Its remaining concern assumed absent consent blocks Legacy bots. Core action admission does not read consent, and group admission suppresses only an existing false row. A durable case proves admission before a consent row exists. The orchestrator independently verified this and the implementer resolved the comment with immutable source and behavior evidence.</li><li>Final PR CI passed all 37 cases against merged core e6a755db0a150bbf73ad97b972fe829f20f6816c and finalized its artifact upload. Actual tested Package merge d8d6d7c6574948c07d277ae55e1c899e7721ff95 has parents 5724de1660a2628e88320914bdd5abb0c69da517 and 62c459770eb5b2209b7cfbf38e54857454fa69d2. CI: https://github.com/LyraCoreProject/packages/actions/runs/34250561420/job/102143672288</li><li>The orchestrator independently checked all 37 clean final runtime records. Module Wasm BLAKE3 is 80efd76cef0d52ee0342f9bc1fe1ee011bcbace0eac7e67e68c944cd427bf659. Package Content Identity is 33fcb8a217aad84f46f9ad65efdad23be24bad8e29828777de7c7e6469417161. The strengthened grid assertion and populated migration passed.</li><li>Package #26 merged as 155c9e401afb06d5731acedf8fc35a81dbe4aaa6. Its Git tree e2558a9cf421a74f79497ef361dbbfceb911a0d1 exactly matches both the reviewed branch and the successful PR merge build.</li><li>The separate push run also passed all 37 tests, then GitHub returned HTTP 403 while finalizing its artifact upload. One retry passed all 37 cases and finalized its artifact successfully. The orchestrator verified its 37 clean inputs at core e6a755d and Package 62c4597, with the same Wasm and Package identities as the successful PR run. This closes the service failure without a source change. Retry: https://github.com/LyraCoreProject/packages/actions/runs/34250556649/job/102147886460</li></ul><h3>Current notes</h3><ul><li>SpacetimeDB 2.7.1 allows appended enum variants only when old variants stay compatible and storage size and alignment stay unchanged. Prove populated-state migration for the runner schema. Planner source: https://github.com/clockworklabs/SpacetimeDB/blob/v2.7.1/crates/schema/src/auto_migrate.rs#L826-L895</li><li>Direct damage can delay a pending cast while retaining its scheduled identity. Observe its current due time before deciding that completion is late; the objective deadline is a separate policy limit.</li><li>Record-only means no gameplay actions from either runner for the selected bot. Freeze must stop retained foreground work. Verify both through the normal Package tick entry.</li><li>The first runner behavior retains a home destination through defense and self-heal interruptions. Companion policy and quest admission remain in their dependent tickets.</li><li>Control must cover damage and invitation hooks as well as the tick. The Gateway also auto-accepts invitations for session-less Characters. The core-owned consent check covers that path for record-only and frozen bots.</li><li>The consent check acknowledges current World Shard state before Realm-core group actions. An action admitted before a concurrent freeze may finish; cross-Shard atomicity is not claimed. Controller selection clears unclaimed Group Intents in the same transaction.</li><li>The common runner entry checks current Account ownership. Relinquishment releases only the bot&#x27;s observed cast or movement identity and preserves a later human action.</li><li>Package schema changes still require human review before production shipping. Agent review and source merge do not satisfy that production gate.</li><li>All three PB-002 implementation PRs are merged. Full source reviews and the final workflow review have no unresolved finding. Both final PR and push CI runs passed and saved their artifacts.</li><li>Recovery Scan advances through at most 24 indexed rotations per pass and rechecks at most two retained rotations through exact spellbook lookups. Completed Missing remains conclusive while a new scan is Pending, so recovery cannot repeatedly interrupt useful movement.</li><li>The missing-result regression observes ReturnHome selection and a real emitted spline while movement scheduling is disabled. Separate arrival and tactical cases prove actual position advancement.</li><li>The Recovery Scan is disposable on Transfer and restarts against current content and learned spells. PB-010 still owns transfer of durable objectives and companion intent.</li></ul></div></details><small>Parent: S1</small></td><td>complete</td><td>PB-002 runner agent; integrated and reviewed by the orchestrator</td><td><a href="#work-PB-001">PB-001</a></td><td><a href="https://github.com/LyraCoreProject/LyraCore/pull/484" rel="noopener noreferrer">Core #484</a><br><a href="https://github.com/LyraCoreProject/LyraCore/pull/486" rel="noopener noreferrer">Core #486</a><br><a href="https://github.com/LyraCoreProject/packages/pull/26" rel="noopener noreferrer">Package #26</a></td></tr><tr id="work-S2" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S2</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Companions and provisioning</summary><div><p>Companions and provisioning</p></div></details><small>Parent: PB</small></td><td>0/3 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-003" class="ticket-row" data-work-status="implementing" data-work-kind="Ticket" data-parent="S2"><td><code>PB-003</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Make a Priest follow, heal, and resume</summary><div><p>Complete the first human-led companion loop. A Priest follows its party leader, retains an injured ally as the heal target, repairs range or line of sight, casts through the real lifecycle, handles interruption, and resumes following.</p><h3>Acceptance criteria</h3><ul><li>Joining a human-led party suspends autonomous travel and selects companion Strategies from durable party facts.</li><li>The Priest follows a moving leader without starting a fight against an unrelated nearby enemy.</li><li>An injured ally outranks ordinary following when the Priest has a usable heal and the survival policy permits it.</li><li>Poor range or line of sight produces a movement prerequisite that retains the injured ally and finds a reachable casting position or records a specific wait.</li><li>The heal starts one real timed cast, does not restart on repeated decisions, and observes completion or interruption through typed outcomes.</li><li>After healing, cancellation, or a recoverable interruption, the Priest resumes following without losing party control state.</li><li>Death and resurrection preserve the companion role and lead to regrouping rather than a permanent solo objective change.</li></ul><p>Verified criteria: 0/7.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection companion support behavior, LyraCore Module cast and party fact reads, Durable companion scenarios.</p><h3>Current notes</h3><ul><li>PB-001 found no existing line-of-sight Gate in targeted cast admission. Add the appropriate shared Gate with supported exemptions and client/bot parity coverage so the movement prerequisite responds to a real typed Refusal. Channel actions remain unsupported until their running lifecycle is correlated.</li><li>The historical Actor cast bypasses the player spellbook check. PB-003 owns the appropriate shared Gate for the new runner and must coordinate with provisioning in PB-005. An unlearned heal must refuse without cast, power, or cooldown changes.</li><li>Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.</li><li>Shared design keeps one durable objective and one foreground action. A moving leader refreshes the companion destination without replacing the retained heal identity. Each parallel branch must prove behavior against merged prerequisites.</li></ul></div></details><small>Parent: S2</small></td><td>implementing</td><td>Companion agent; orchestrator reviews and merges</td><td><a href="#work-PB-002">PB-002</a></td><td>Pending</td></tr><tr id="work-PB-004" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S2"><td><code>PB-004</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Complete starter roles, target choice, and crowd control</summary><div><p>Add Warrior tank and Mage damage behavior beside the Priest healer on the shared runner. Make explicit durable roles, vanilla class capabilities, chosen-target assistance, controlled-enemy avoidance, death, rest, and regrouping work through repeated party pulls.</p><h3>Acceptance criteria</h3><ul><li>Warrior, Priest, and Mage have validated ability sets at every level supported by the companion fixture.</li><li>Each companion retains an explicit tank, healer, or damage role, with a deterministic vanilla-derived default when no role was selected.</li><li>The Warrior tank chooses and holds the party&#x27;s selected fight according to survival and threat facts rather than inheriting damage-only retreat behavior.</li><li>The Mage acts at class-appropriate range and role does not force a ranged class into melee.</li><li>All companions honor the party&#x27;s chosen fight and designated target and do not initiate an unrequested pull.</li><li>Controlled enemies remain ineligible unless the control is intentionally broken by a higher-priority survival rule with a recorded reason.</li><li>Repeated-pull fixtures cover wounded allies between fights, target death or disappearance, loss of line of sight, companion death, rest, and regrouping without role abandonment.</li><li>Between fights, companions select useful missing class buffs, repair casting position when needed, apply them through real core casts, observe the resulting auras, and avoid redundant recasting while the buff remains valid.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection starter class and role behavior, LyraCore Module combat and capability facts, Durable repeated-pull party scenarios.</p></div></details><small>Parent: S2</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-003">PB-003</a></td><td>Pending</td></tr><tr id="work-PB-005" class="ticket-row" data-work-status="implementing" data-work-kind="Ticket" data-parent="S2"><td><code>PB-005</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Provision playable bots without duplicating progress</summary><div><p>Reconcile the supported bot&#x27;s skills, spells, vanilla talents, equipment, bags, food, potions, ammo, reagents, and bounded supplies on spawn and level-up through real core operations. Make each action idempotent and explain it by provisioning profile and revision.</p><h3>Acceptance criteria</h3><ul><li>Provisioning runs on spawn and level-up and periodically repairs only resources owned by the selected profile.</li><li>Spell learning, equipment, inventory, uniqueness, proficiency, class, and level rules pass through core operations. Free provisioning is an explicit profile choice; its grants remain bounded and attributable.</li><li>Skill training and vanilla talent choices follow the selected class profile through the owning core Gates. Prerequisites, earned talent points, rank limits, and level restrictions hold, and reconciliation cannot spend a point or train a rank twice.</li><li>Repeated reconciliation does not create duplicate equipment, unlimited supplies, repeated spell grants, or repeated costs.</li><li>The policy respects an equipped upgrade, does not delete quest items, and never raises a bot&#x27;s level to match a leader.</li><li>Quest credit, earned XP, loot entitlement, and quest completion remain consequences of normal gameplay operations.</li><li>Full bags, missing consumables, resource recovery, rest, and death produce bounded next actions or an explained stop.</li><li>Decision history records the provisioning profile, revision, chosen action, and typed outcome.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection provisioning policy, LyraCore Module skill, spell, talent, item, inventory, and equipment operations, Durable idempotency scenarios.</p><h3>Current notes</h3><ul><li>Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.</li><li>Agreed integration performs at most one provisioning operation per eligible Cohort tick, with no foreground action. Spawn and level-up arm reconciliation; they do not grant resources outside current control and Account ownership checks.</li></ul></div></details><small>Parent: S2</small></td><td>implementing</td><td>Provisioning agent; orchestrator reviews and merges</td><td><a href="#work-PB-002">PB-002</a></td><td>Pending</td></tr><tr id="work-S3" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S3</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Autonomous questing and recovery</summary><div><p>Autonomous questing and recovery</p></div></details><small>Parent: PB</small></td><td>0/3 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-006" class="ticket-row" data-work-status="implementing" data-work-kind="Ticket" data-parent="S3"><td><code>PB-006</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Admit supported quests from a seeded catalog</summary><div><p>Build a versioned quest catalog for the initial Northshire and Elwynn proof from imported relations, objectives, spawns, loot sources, and actual enders. Admit a quest only when every required objective has a supported executor, and retain the chosen objective and destination.</p><h3>Acceptance criteria</h3><ul><li>The catalog records quest eligibility, each objective kind, target or drop source, actual ender, work area, destination evidence, and content revision.</li><li>The initial fixture contains a named supported Northshire and Elwynn catalog with deterministic seeds for each starter class.</li><li>Admission checks ordinary core eligibility and confirms an executor for every required objective before acceptance.</li><li>Unsupported exploration, escort, scripted event, transport, and complex GameObject requirements remain explicit and cannot enter a futile loop. Mixed quests are admitted only when every required kind has an executor, including supported talk-only and simple GameObject steps.</li><li>A live creature search chooses what can be acted on now but does not decide whether a quest destination exists in imported content.</li><li>The retained objective stores the actual ender and catalog revision and survives a tactical combat interruption.</li><li>If a held quest becomes unsupported, the bot records the missing capability and proceeds to another supported objective or a specific wait without repeated abandonment and reacceptance.</li></ul><p>Verified criteria: 0/7.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection quest catalog and admission, LyraCore imported quest and world relations, Seeded durable catalog scenarios.</p><h3>Current notes</h3><ul><li>Imported source identifies quest 3904 as a collect-item quest backed by chest loot. The existing GameObject use operation needs Package visibility and bounded object discovery. Verify and correct the importer NextQuestInChain column mapping before relying on forward links.</li><li>Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.</li><li>Catalog admission must prove a currently callable executor for every required kind. Imported destination evidence is separate from live target discovery. PB-007 owns the later autonomous quest sequence; its planned work cannot establish executor availability today.</li></ul></div></details><small>Parent: S3</small></td><td>implementing</td><td>Quest catalog agent; orchestrator reviews and merges</td><td><a href="#work-PB-002">PB-002</a></td><td>Pending</td></tr><tr id="work-PB-007" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S3"><td><code>PB-007</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Finish supported autonomous quest loops</summary><div><p>Complete supported kill, collect, talk-only, and simple GameObject quest loops. The bot accepts the quest, retains its objective, travels through real navigation, executes the required gameplay, earns ordinary credit and XP, turns in to the actual ender, and selects the next supported work.</p><h3>Acceptance criteria</h3><ul><li>A supported kill quest completes through accepted combat, actual damage and death, kill credit, travel, and turn-in rather than a changed internal label.</li><li>A supported collect quest hunts an explicit eligible drop source, receives the item through real loot and inventory operations, and turns in to the catalog&#x27;s actual ender.</li><li>A supported talk-only chain advances through actual quest eligibility, giver and ender interactions, and ordinary rewards without manufacturing prerequisite completion.</li><li>At least one cataloged simple GameObject objective completes through the owning core use or loot operation, respects range and object state, and earns credit once. Unsupported scripted object behavior is refused at admission.</li><li>Quest objective progress changes only when the authoritative core gameplay outcome changes it.</li><li>The retained quest objective survives combat interruption, death, rest, and provisioning, then resumes after rechecking eligibility.</li><li>Target death, disappearance, or ineligibility cancels only the current action and selects a new eligible target or an explicit respawn wait.</li><li>A completed turn-in grants ordinary rewards once and advances to another supported catalog entry without Operator help.</li><li>Seeded scenarios cover Warrior, Priest, and Mage and produce reproducible decision and outcome histories.</li><li>A supported quest destination outside the former home leash remains reachable under the current work area and retained destination. Tactical retreat returns to an appropriate safe position in the current partition and cannot reset travel to the spawn home.</li></ul><p>Verified criteria: 0/10.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection autonomous quest behavior, LyraCore Module quest, combat, loot, inventory, and navigation operations, Seeded durable quest scenarios.</p></div></details><small>Parent: S3</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-005">PB-005</a>, <a href="#work-PB-006">PB-006</a></td><td>Pending</td></tr><tr id="work-PB-008" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S3"><td><code>PB-008</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Recover from blocked travel and stalled quest work</summary><div><p>Turn typed failure and progress evidence into finite recovery for both autonomous bots and companions. Change approach, defer destinations, invalidate stale targets, and explain waits without erasing the retained objective.</p><h3>Acceptance criteria</h3><ul><li>The blocked-target fixture cannot clear its stall clock through attack acceptance when route, damage, and quest progress remain unchanged.</li><li>After 10 seconds without movement progress the bot changes approach; within 30 seconds it advances, defers the destination, or records a specific wait.</li><li>A safe partial route remains eligible while it advances a route or waypoint within a bounded route budget.</li><li>Repeated no-progress defers a destination by map, instance, and geometry revision for a bounded period and allows another useful action.</li><li>Unknown coverage stays distinct from a verified blocked route and reports the missing imported coverage evidence.</li><li>Death, full bags, absent targets, an unreachable giver, a controlled enemy, and a broken prerequisite each end in recovery or an explained finite stop.</li><li>Recovery remains active for companions and uses follow distance, leader movement, and casting position as its progress evidence.</li><li>Restarting the fixture preserves the bounded failure memory that prevents immediate reselection of the same failed target.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-6-astra, high effort. Repositories: Official Package Collection travel and recovery behavior, LyraCore Module navigation evidence, Durable blocked-route and stalled-work scenarios.</p></div></details><small>Parent: S3</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-004">PB-004</a>, <a href="#work-PB-007">PB-007</a></td><td>Pending</td></tr><tr id="work-S4" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S4</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Commands, Transfer, and restart</summary><div><p>Commands, Transfer, and restart</p></div></details><small>Parent: PB</small></td><td>0/2 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-009" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S4"><td><code>PB-009</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Honor durable follow, stay, assist, and target orders</summary><div><p>Complete the companion command contract through the existing command transport. Persist follow, stay, assist, and designated-target orders, apply them with party authority, and resume valid solo work when human-led control ends.</p><h3>Acceptance criteria</h3><ul><li>A human party leader can issue follow, stay, assist, and designated-target orders through the existing command transport.</li><li>Each accepted order persists as typed control state and produces an explanation entry with Actor, target where relevant, and outcome.</li><li>Follow tracks the leader, stay holds the commanded location within movement tolerances, and assist limits initiation to the chosen fight.</li><li>A designated target participates in candidate identity and cannot be replaced by another proposal&#x27;s target when scores change.</li><li>Controlled enemies remain ineligible while assist or target orders are active unless an explicit higher-priority survival decision records why control was broken.</li><li>Joining a human-led party suspends autonomous travel and opportunistic grouping without deleting the solo objective.</li><li>Leaving the party invalidates companion actions, rechecks the retained solo objective, and resumes it only when it is still eligible.</li><li>Role and command state survive companion death and remain consistent after regrouping.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection commands and control state, LyraCore Gateway command transport and Module party reads, Durable join and leave scenarios.</p></div></details><small>Parent: S4</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-004">PB-004</a></td><td>Pending</td></tr><tr id="work-PB-010" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S4"><td><code>PB-010</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Preserve one controller through restart and Transfer</summary><div><p>Define and prove the lifecycle of every new bot row across Character deletion, Module restart, Gateway restart, party changes, and Transfer. Suspend local actions while Transfer is pending, rebuild transient observations on arrival, and prevent stale work from acting.</p><h3>Acceptance criteria</h3><ul><li>Each durable Package row has an explicit keep, move, rebuild, or delete rule for Character deletion and Transfer.</li><li>A pending Transfer suspends local actions and relies on authoritative Transfer state rather than timeout to create another executor.</li><li>The retained quest or party objective, control mode, role, deadlines, deferred destinations, and bounded failure memory survive their defined restart and Transfer cases.</li><li>Transient targets and route segments do not Transfer; arrival rebuilds them against the destination&#x27;s content and geometry revisions.</li><li>Pending work carries controller generation and location, and an old completion cannot advance a new action after restart or arrival.</li><li>Restart fixtures interrupt active movement, cast, provisioning, quest reward, and Transfer stages without duplicating a Character, item, supply grant, reward, or active controller.</li><li>A transferred companion retains the correct party and role on arrival, and a transferred autonomous bot resumes or invalidates its objective for a recorded reason.</li><li>One instance entry and exit through the real routing path preserves companion orders and produces arrival evidence.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-6-astra, high effort. Repositories: Official Package Collection bot row lifecycle, LyraCore Module, Gateway, Realm-core, Transfer, and Group Intent integration, Durable restart and Transfer scenarios.</p></div></details><small>Parent: S4</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-008">PB-008</a>, <a href="#work-PB-009">PB-009</a></td><td>Pending</td></tr><tr id="work-S5" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S5</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Release evidence and retirement</summary><div><p>Release evidence and retirement</p></div></details><small>Parent: PB</small></td><td>0/2 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-011" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S5"><td><code>PB-011</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Pass autonomous, companion, and load acceptance</summary><div><p>Run the complete automated release suites on the pinned core, Package, imported content, and geometry. Prove seeded autonomous work, the fixed human-led companion route, restart and Transfer behavior, bounded recovery, scheduler fairness, and measured 10, 25, and 100 bot load.</p><h3>Acceptance criteria</h3><ul><li>Run ten seeds per starter class through the supported Northshire and Elwynn catalog. All ten runs per class must finish each supported scenario without Operator help: nine of ten is below the 95 percent requirement. Every failed run must record an explained outcome and fails the release gate.</li><li>Autonomous acceptance includes kill, collect, talk-only chains, supported simple GameObject use, travel beyond the former home leash, turn-in, death, combat interruption, full bags, absent targets, an unreachable giver, and unsupported objective admission.</li><li>One human-controlled Character and four bots complete the fixed repeated-pull route with explicit roles, follow and stay, assist and designated target, wounded allies and missing buffs between fights, loss of line of sight, controlled enemies, death, regrouping, and one instance entry and exit.</li><li>The companion fixtures produce no unrequested pull, unexplained role abandonment, repeated cast start, or attack against an obsolete target.</li><li>Every supported action covers success, waiting, Refusal, cancellation, and expiry through the highest suitable behavior seam.</li><li>Restart and Transfer acceptance shows no duplicate Character, equipment, supply grant, quest reward, or controller and no stale action at the old location.</li><li>Named disposable load runs execute 10, 25, and 100 bots and record decision time, movement time, scheduler lag, route expansions, row reads, row writes, and slowest due bot.</li><li>The load report sets a measured deployment capacity, records fixture resources and revisions, and accounts for every deferred due bot without silent loss.</li><li>All relevant repository checks and both specification and standards reviews pass at the pinned revisions.</li></ul><p>Verified criteria: 0/9.</p><p>Execution model: gpt-6-astra, xhigh effort. Repositories: LyraCore and Official Package Collection acceptance suites, Headless Client protocol and world-transition scenarios, Disposable imported-world load fixture and measurement report.</p></div></details><small>Parent: S5</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-005">PB-005</a>, <a href="#work-PB-007">PB-007</a>, <a href="#work-PB-008">PB-008</a>, <a href="#work-PB-010">PB-010</a></td><td>Pending</td></tr><tr id="work-PB-012" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S5"><td><code>PB-012</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Cut over, observe, and retire the old behavior</summary><div><p>Complete the additive state cutover with one durable controller selector, compare record-only decisions, activate a small cohort, gather imported-world and attended client evidence, then delete the displaced behavior source, obsolete tests, and active old state path. Leave old table retirement as its separately reviewed migration when required by repository rules.</p><h3>Acceptance criteria</h3><ul><li>The additive state migration defines defaults and backfill, and exactly one durable selector makes one runner eligible to control each bot.</li><li>Record-only comparison on fixed facts issues no gameplay actions and reports deterministic policy disagreements before cohort activation.</li><li>A small active cohort can freeze without a second controller and can resume after the failure reason is recorded.</li><li>Both automated release suites from PB-011 pass again with the new runner selected and no old runner actions.</li><li>A one-hour imported-world observation runs 25 bots and records no unexplained stall, repeated Refusal spam, visible clipping, or idle injured healer.</li><li>An attended session in a real unmodified 1.12.1 client exercises the companion route and signs off follow, stay, assist, target choice, crowd-control respect, real casts, death, regrouping, and instance entry and exit.</li><li>If the implementation environment cannot run the real client, the exact observation script, fixture revisions, capture format, and diagnostic reads are ready, and this acceptance item remains explicitly pending human evidence.</li><li>The displaced behavior source, obsolete helper-shape tests, broad internal exports, active old controller path, and unused old state access are deleted after acceptance.</li><li>Repository checks prove the deleted behavior source cannot regain control and no production code reads or writes obsolete active state.</li><li>Any physical old-table removal has its own reviewed migration plan and does not weaken the completed single-controller cutover.</li></ul><p>Verified criteria: 0/10.</p><h3>Imported world observation</h3><p>Pending. Required before completion.</p><h3>Attended client observation</h3><p>Pending. Required before completion.</p><p>Execution model: gpt-6-astra, xhigh effort. Repositories: Official Package Collection controller cutover and source retirement, LyraCore additive state migration and architecture checks, Imported-world observation and attended client evidence.</p></div></details><small>Parent: S5</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-011">PB-011</a></td><td>Pending</td></tr></tbody></table></div>
+<div class="table-scroll execution-table"><table><thead><tr><th>Identifier</th><th>Spec and ticket hierarchy</th><th>Status</th><th>Owner</th><th>Blocked by</th><th>Pull requests</th></tr></thead><tbody><tr id="work-PB" class="parent-row" data-work-status="planned" data-work-kind="Spec" data-parent=""><td><code>PB</code><br>Spec</td><td style="padding-left:12px"><details><summary>Rewrite playerbots around durable objectives and typed action outcomes</summary><div><h3>Problem statement</h3><p>The current playerbots Package can accept an action without proving that the action completed, loses route results, treats attempted combat as quest progress, bypasses the normal cast lifecycle, and retains too little purpose across interruption, restart, and Transfer. Bots can therefore stall, repeat work, choose an obsolete target, or abandon useful intent without explaining why. The current tests also do not prove the Package and core together against real actor operations, imported content, navigation, protocol transitions, and sustained load.</p><h3>Solution</h3><p>Replace the behavior control flow with one typed Rust decision runner shared by autonomous bots and human-led companions. The runner observes bounded facts, composes supported Strategies, ranks target-bearing candidates deterministically, executes actions through core operations, records typed outcomes, and retains one durable objective with bounded failure memory. Build the rewrite through a pinned real Module and Package fixture, then prove companion behavior, provisioning, seeded quest loops, recovery, commands, restart, Transfer, load, cutover, and attended client behavior before deleting the displaced implementation.</p><h3>User stories</h3><ol><li>As an Operator, I want every bot controlled by one eligible runner, so that two behavior systems cannot issue conflicting actions.</li><li>As an Operator, I want a stopped bot to report its objective, target, chosen action, outcome, retry count, next eligible time, and content revision, so that I can diagnose it without reading source.</li><li>As an Operator, I want decision work scheduled in bounded fair batches, so that a large roster cannot monopolize a Module tick.</li><li>As an Operator, I want excess due bots deferred with recorded lag, so that overload does not silently discard durable work.</li><li>As an Operator, I want repeatable provisioning profiles, so that I can explain why a bot received a spell, item, or supply.</li><li>As an Operator, I want deployment capacity based on measured runs of 10, 25, and 100 bots, so that release limits reflect this implementation.</li><li>As a developer, I want fixed facts and time to produce the same decision, so that policy changes have reproducible tests.</li><li>As a developer, I want candidates identified by action, target, and relevant event, so that a higher score cannot retain the wrong target.</li><li>As a developer, I want each supported action to return a typed outcome, so that success, waiting, Refusal, cancellation, expiry, and infrastructure failure remain distinct.</li><li>As a developer, I want action prerequisites, alternatives, and continuers to be bounded, so that retries and cycles cannot run forever.</li><li>As a developer, I want a reproducible Module and Package fixture at pinned revisions, so that failures and fixes can be compared against the same content and geometry.</li><li>As a developer, I want casts to use the normal core cast-start lifecycle, so that cast time, interruption, cancellation, cost, and completion use the same Gates as client casts.</li><li>As a developer, I want movement outcomes to preserve route completion and coverage evidence, so that policy can distinguish progress, a partial route, blockage, and unknown coverage.</li><li>As an autonomous bot, I want one objective retained across tactical interruptions, so that defending myself does not erase my quest purpose.</li><li>As an autonomous bot, I want quest admission to require an executor for every required objective, so that unsupported quests do not trap me.</li><li>As an autonomous bot, I want to accept, travel for, complete, and turn in a supported kill quest, so that I can earn normal quest credit and XP.</li><li>As an autonomous bot, I want to find the actual drop source, loot it, and turn in a supported collect quest, so that collection progress comes from gameplay outcomes.</li><li>As an autonomous bot, I want supported talk-only chains and simple GameObject objectives executed through normal core interactions, so that a quest route does not stop at a non-combat step.</li><li>As an autonomous bot, I want the actual quest ender retained from the catalog, so that I travel to the correct turn-in Character or GameObject.</li><li>As an autonomous bot, I want death, combat, full bags, absent targets, and temporary route failure to have finite recovery rules, so that I can resume or stop with a specific reason.</li><li>As an autonomous bot, I want a failed destination deferred by map, instance, and geometry revision, so that a restart cannot immediately choose the same failed target again.</li><li>As an autonomous bot, I want skill and spell training, vanilla talents, equipment, and supplies reconciled on spawn and level-up through core Gates, so that I remain playable without receiving invalid progress.</li><li>As a human party leader, I want a companion to follow or stay on command, so that I control its position.</li><li>As a human party leader, I want a companion to assist my chosen fight or a designated target, so that it does not pull an unrelated enemy.</li><li>As a human party leader, I want companions to respect controlled enemies, so that crowd control is not broken by autonomous target choice.</li><li>As a human party leader, I want each companion to retain an explicit tank, healer, or damage role, so that party behavior remains predictable through death and Transfer.</li><li>As an injured party member, I want a Priest companion to repair range or line of sight and complete one real heal cast, so that repeated decisions do not restart the cast bar.</li><li>As a party member, I want a Warrior tank to hold the chosen fight and a Mage damage companion to act at class-appropriate range, so that role does not erase class capabilities.</li><li>As a companion, I want joining a human-led party to suspend autonomous travel and leaving it to resume a still-valid solo objective, so that control changes preserve useful intent.</li><li>As a companion, I want my role, party intent, and retained objective reconciled after restart and Transfer, so that delayed work from the old location cannot act.</li><li>As a maintainer, I want the old behavior source and obsolete state retired after both release suites pass, so that one implementation remains authoritative.</li><li>As a party member, I want companions to heal and apply useful missing buffs between fights, so that the party starts the next fight ready without repeated redundant casts.</li></ol><h3>Implementation decisions</h3><ul><li>Use a targeted Rust rewrite of the useful AzerothCore decision grammar. Do not port its C++ runtime, synthetic World Sessions, packet queues, host object graph, or WotLK rules.</li><li>Keep durable gameplay authority in the Module. Keep party authority in Realm-core. Use existing Transfer and Group Intent routing only for their realm-wide responsibilities.</li><li>Give the Package one small decision interface, one action execution interface, and one explanation read. Keep internal behavior behind those interfaces.</li><li>Represent Strategies, triggers, facts, candidates, actions, targets, outcomes, tactical modes, objective stages, and failure reasons with typed values instead of strings and dynamic lookup.</li><li>Rank candidates with integer scores and stable tie-breaking. Candidate identity includes the action, target, and relevant event. Saved random state may break equal valid choices only.</li><li>Support bounded prerequisites, alternatives, and continuers. Limit candidate count, graph depth, transitions, and route expansion independently during each decision pass.</li><li>Allow one foreground action to own movement or a cast. A higher-priority action must explicitly cancel incompatible work before it starts.</li><li>Retain the quest or party objective across tactical interruption. Store its identity, destination, stage, deadline, last verified progress, deferred destinations, bounded failure memory, and catalog revision.</li><li>Keep route segments and live target observations transient. Correlate pending work with controller generation and location so stale completions cannot advance current state.</li><li>Treat action acceptance and actual progress as different facts. Track movement, combat, cast, and quest progress with separate evidence and clocks.</li><li>Expose typed outcomes from the owning core operations for the actions the selected behaviors require. Preserve existing Gates and atomic Refusal behavior.</li><li>Route bot spells through the normal cast-start and timed completion lifecycle. A running cast stays retained until completion, interruption, cancellation, or expiry.</li><li>Preserve complete, partial, blocked, and explicit unknown-coverage movement evidence. Do not infer missing coverage only from absent sparse navigation rows.</li><li>Derive tactical mode and active Strategies from durable Character, party, combat, aura, health, threat, target, position, and capability facts. Do not create a second authoritative state machine.</li><li>Use the bounded priority order from the report: lifecycle and Transfer restrictions, immediate survival, urgent party support, the current fight, human orders, maintenance, autonomous quest work, then idle activity.</li><li>Store an indexed next-decision time per bot, process due bots in stable order with a fixed batch limit, coalesce urgent reconsideration reasons, and record lag for deferred work.</li><li>Build a versioned supported quest catalog from imported quest relations, objectives, spawns, loot sources, and actual enders. Admit only quests whose required objectives have executors.</li><li>Start autonomous release coverage with a seeded Northshire and Elwynn catalog and ordinary quest credit and earned XP. Treat this as a bounded proof rather than level 1 to 60 coverage.</li><li>Start companion release coverage with Warrior tank, Priest healer, and Mage damage capabilities. Store the explicit role and derive a deterministic vanilla default when none is chosen.</li><li>Support durable follow, stay, assist, and designated-target orders through the existing command transport. Joining a human-led party suspends solo work; leaving rechecks and resumes it when valid.</li><li>Reconcile skill and spell training, vanilla talent choices, equipment, bags, food, potions, ammo, reagents, and bounded supplies as separate idempotent actions through core Gates. Provisioning never changes level, grants quest completion, deletes quest items, or duplicates owned resources.</li><li>Add new state through an additive migration and one durable controller selector. Use record-only comparison before a small active cohort, then retire the old controller and its obsolete state after release acceptance.</li><li>Keep a bounded history of transitions and failures. Do not retain one row for each successful idle decision.</li></ul><h3>Testing decisions</h3><ul><li>Use the highest real seam available. Pure tests cover deterministic policy, durable Module and Package fixtures cover gameplay operations and navigation, Headless Client scenarios cover protocol and world transitions, and attended client observation covers visible behavior.</li><li>The baseline fixture pins core commit 95e6ad8c61540f74471e3087897e8c3ef7e065d1 and Package Collection commit c32b2fb7aa405190728034b63ce6eb9a3c0dd6be together with named imported content and geometry revisions.</li><li>Every supported action has behavioral cases for success, waiting, Refusal, cancellation, and expiry. Infrastructure failures remain separate where the seam can produce them.</li><li>Durable fixtures call real actor, cast, movement, quest, loot, item, and lifecycle operations. They do not replace gameplay with a simulated combat model.</li><li>Decision fixtures cover stable candidate order, target-bearing identity, bounded transition graphs, survival against role work, healing against following, and combat interruption against retained quest work.</li><li>Movement fixtures measure route or waypoint advancement. After 10 seconds without movement progress the bot changes approach; within 30 seconds it advances, defers the destination, or records a specific wait.</li><li>Cast fixtures prove one long cast starts once, survives intervening decisions, and ends once by completion, interruption, cancellation, or expiry.</li><li>Companion fixtures cover follow, stay, assist, designated target, controlled enemies, poor range, loss of line of sight, wounded allies and missing buffs between fights, death, regrouping, and one instance entry and exit.</li><li>Autonomous fixtures run ten seeds per starter class through the supported Northshire and Elwynn catalog. All ten runs per class must finish each supported scenario without Operator help: nine of ten is below the 95 percent requirement. Every failed run must record an explained outcome and fails the release gate.</li><li>Autonomous mandatory scenarios include kill, collect, talk-only chains, supported simple GameObject use, turn-in, death, interruption, full bags, absent targets, an unreachable giver, unsupported objectives, and restart with a retained objective.</li><li>Restart and Transfer fixtures interrupt active action and escrow stages. They prove no duplicate Character, equipment, supply grant, quest reward, or active controller and prove stale work cannot act on the old location.</li><li>Load fixtures run 10, 25, and 100 bots on one named disposable fixture and record decision time, movement time, scheduler lag, route expansions, row reads, row writes, and the slowest due bot before capacity is set.</li><li>Final observation requires one hour with 25 bots on imported content plus an attended companion session in a real unmodified 1.12.1 client. A human must collect and sign off this evidence if the implementation environment cannot run that client.</li><li>Review final behavior against this specification and repository standards after the focused and full relevant checks pass.</li></ul><h3>Out of scope</h3><ul><li>A direct or mechanical port of the complete AzerothCore playerbots runtime.</li><li>Synthetic World Sessions or packet observation inside the Package.</li><li>A user-defined action language, global string factory, client addon, or new product UI.</li><li>Claims of general level 1 to 60 quest coverage, all classes, all regions, all dungeons, or thousands of bots.</li><li>Exploration, escort, scripted-event, transport, and other quest objective types until they receive explicit executors and catalog support.</li><li>Routine catch-up teleportation through blocked geometry.</li><li>A full economy simulation or provisioning that changes level, fabricates quest credit, clears inventory, or completes prerequisite quests.</li><li>A full Deadmines run unless the team later selects it as the first dungeon milestone.</li><li>Production realm changes, live database inspection, publication, or deployment as part of implementation and local acceptance.</li></ul><h3>Further notes</h3><ul><li>The source report proposes acceptance thresholds. Implementation must measure them before treating them as release facts.</li><li>Bad or stale imported geometry can imitate a policy defect. Every route fixture and observation record names its content and geometry revisions.</li><li>The source comparison found no behavioral assertion suite in the pinned AzerothCore tree. Its architecture is evidence for design choices, not proof of LyraCore behavior.</li><li>Record provenance if any reference code is copied or translated. The architecture proposal does not make a license-compatibility conclusion.</li><li>Attended real-client observation is a release gate that may require a human after agent implementation. The implementation tickets must prepare the exact scenario, capture format, and diagnostic reads without claiming that a client session already ran.</li><li>Unresolved product choices remain level range beyond the initial catalog, the first full dungeon milestone, equipment strength beyond level-appropriate starter gear, and any explicit catch-up travel policy. They do not block the bounded first release.</li><li>The user authorized autonomous implementation, PR ownership through review, and confident merges. The HTML is the tracker; no issue publication or planning interview is required. Production changes remain outside this authorization.</li><li>The initial tracer uses real Module and Package operations with named seeded inputs. Client-derived geometry is unavailable in the current workspace. Record this absence instead of treating the seeded route as imported-world proof; PB-011 and PB-012 retain the imported-input release gates.</li></ul></div></details><small>Parent: Root</small></td><td>2/12 complete</td><td>Orchestrator</td><td>None</td><td><a href="https://github.com/LyraCoreProject/LyraCore/pull/481" rel="noopener noreferrer">Execution report #481 merged</a><br><a href="https://github.com/LyraCoreProject/LyraCore/pull/483" rel="noopener noreferrer">Progress #483</a></td></tr><tr id="work-S1" class="parent-row" data-work-status="complete" data-work-kind="Workstream" data-parent="PB"><td><code>S1</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Typed action foundation and durable runner</summary><div><p>Typed action foundation and durable runner</p></div></details><small>Parent: PB</small></td><td>2/2 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-001" class="ticket-row" data-work-status="complete" data-work-kind="Ticket" data-parent="S1"><td><code>PB-001</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Prove typed outcomes in a real pinned fixture</summary><div><p>Create the first tracer through a reproducible pinned Module and Package fixture. Drive attack, interaction, movement, and cast-start through real core operations, return typed outcomes to the Package, and capture the blocked-target and out-of-range-heal failures that the rewrite must fix.</p><h3>Acceptance criteria</h3><ul><li>The fixture records pinned core and Package commits plus the actual content and geometry input revisions, labels seeded and client-derived provenance separately, records unavailable inputs, and reproduces the same initial state and outcome.</li><li>The fixture loads and runs the real Module with the real Package; it does not substitute a simulated gameplay engine.</li><li>Attack acceptance is distinct from damage and quest progress, and an attempted attack with no hit cannot clear a quest progress clock.</li><li>Movement reports complete, safe partial, blocked, or explicit unknown-coverage evidence with route or waypoint advancement where applicable.</li><li>Interaction and cast-start return typed success, waiting, Refusal, cancellation, and expiry outcomes supported by their owning operations.</li><li>A long bot cast uses the normal core cast lifecycle and completes once without restart on later decision ticks.</li><li>The blocked target and poor-range heal cases have reproducible inputs, observed outcomes, and enough evidence to compare later runner behavior.</li><li>A written extraction comparison chooses the smaller total implementation and records why the full AzerothCore runtime is not used.</li></ul><p>Verified criteria: 8/8.</p><p>The fixture records pinned core and Package commits plus the actual content and geometry input revisions, labels seeded and client-derived provenance separately, records unavailable inputs, and reproduces the same initial state and outcome.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>All 16 final CI input records name clean core fe9caef6eb0d132c45a5d151827ab6fe64925f79 and GitHub tested Package merge 744732b50cc8135d3a06e598e07e26aa8633a434, whose parents are main c32b2fb and reviewed Package c97464f6be211525a3b36a2ee3824cf259edbdd1. Content is playerbots-seeded-actions-v1; geometry is playerbots-synthetic-nav-v1. Imported content and client geometry are explicitly unavailable.</li><li>CI Module BLAKE3: a4e921d874c49ada97f9893b4c9b41847ffdb994c670dcd3ea5673f0fab466fd. Package BLAKE3: 1b4de3cdafc56407264c216a3accda917117277914b2deffb4fbd0c3efaf29f6. The local focused Module has a different installed inventory; byte equality across those builds is not claimed.</li><li>Input manifest: https://github.com/LyraCoreProject/packages/blob/c97464f6be211525a3b36a2ee3824cf259edbdd1/playerbots/fixtures/actions.json</li><li>CI input and outcome artifacts: https://github.com/LyraCoreProject/packages/actions/runs/34229152446</li><li>The final run against merged core be3fa67d also records 16 clean input and outcome pairs. Tested Package merge b451105562bbb5deab45ceff9919b9e002aa240d has parents c32b2fb and reviewed head 0781d7e5. Module and Package identities match the preceding CI run. Artifacts: https://github.com/LyraCoreProject/packages/actions/runs/34230810246</li></ul><p>The fixture loads and runs the real Module with the real Package; it does not substitute a simulated gameplay engine.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The local fixture passed all 16 cases through compiled Module Wasm, the real Package, and private SpacetimeDB 2.7.1 Standalone nodes. The final CI run below also includes the later repeated-setup checks.</li><li>The same behavior passed in Package CI: https://github.com/LyraCoreProject/packages/actions/runs/34226546164/job/102061988209</li><li>Final fixture changes also passed all 16 cases in 166.26 seconds: https://github.com/LyraCoreProject/packages/actions/runs/34229152446/job/102070649535</li><li>The same 16 fixtures passed against merged core main before the Package merge: https://github.com/LyraCoreProject/packages/actions/runs/34230810246/job/102076215519</li></ul><p>Attack acceptance is distinct from damage and quest progress, and an attempted attack with no hit cannot clear a quest progress clock.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>playerbots_an_accepted_attack_without_a_hit_does_not_clear_quest_stall observes accepted engagement, full target health, zero quest credit, and an unchanged stall clock behind a synthetic wall. Its positive phase uses the real lethal-hit pipeline to award credit; it does not claim that the bot hit through the wall.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>Movement reports complete, safe partial, blocked, or explicit unknown-coverage evidence with route or waypoint advancement where applicable.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The complete-route and partial-route cases distinguish a proposed leg from observed arrival, retain a waypoint and search-work count, and record Unknown coverage. The blocked-target case holds position. Shared navigation tests passed 34 cases; VerifiedCells only attests consulted derived rows.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>Interaction and cast-start return typed success, waiting, Refusal, cancellation, and expiry outcomes supported by their owning operations.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The fixture covers typed cast start/wait/resolve/refusal/cancel/expire outcomes, synchronous quest completion/refusal, full-inventory and invalid-choice atomicity, source-item refusal, and dead-attacker refusal. All 16 final cases passed.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>A long bot cast uses the normal core cast lifecycle and completes once without restart on later decision ticks.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>playerbots_a_long_bot_cast_waits_for_core_completion retains one five-second cast through repeated requests and normal decision ticks, observes one START and one GO, and verifies the heal. The owning begin operation returns its exact result directly.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>The blocked target and poor-range heal cases have reproducible inputs, observed outcomes, and enough evidence to compare later runner behavior.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The blocked-target scenario and playerbots_an_out_of_range_heal_reports_the_owning_cast_gate record reproducible inputs and typed observations. The poor-range target starts at x=1400 while the bot starts at x=1200. Actions retain target, route, clipping, coverage, cast identity, and Refusal.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/fe9caef6eb0d132c45a5d151827ab6fe64925f79/module/tests/playerbots_rewrite.rs</li></ul><p>A written extraction comparison chooses the smaller total implementation and records why the full AzerothCore runtime is not used.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec review.</p><ul><li>The extraction comparison in the Package README chooses typed Rust decisions and existing Module operations. It compares the 2,967-line selection-kernel inventory with the 243,560-line C++ runtime and records host-pointer, packet, and WotLK dependencies. https://github.com/LyraCoreProject/packages/blob/c97464f6be211525a3b36a2ee3824cf259edbdd1/playerbots/README.md</li><li>https://github.com/LyraCoreProject/LyraCore/pull/482#issuecomment-5585257477</li></ul><p>Execution model: gpt-6-astra, high effort. Repositories: LyraCore Module action and navigation contracts, Official Package Collection playerbots fixture, Local durable integration tests.</p><h3>Recorded evidence</h3><ul><li>Baseline on core 95e6ad8 and Package c32b2fb: both ignored personality durable tests passed in a private loopback Standalone. This proves the existing Package fixture, not the new outcome contract.</li><li>Final local union passed 1,621 Module unit tests normally, 1,622 with debug reducers, and 32 durable cases. Default-core SpacetimeDB 2.7.1 generation matched all 995 committed Gateway binding files. Independent standards findings are resolved or explicitly accepted; Spec review found no confirmed defects.</li><li>The final Package CI run passed all 16 strengthened fixtures against core fe9caef6. Repeated interaction setup now clears only its reserved target and quest rows, including stale movement and engagement. Evidence: https://github.com/LyraCoreProject/packages/actions/runs/34229152446/job/102070649535</li><li>Core #482 merged as be3fa67d0f0c24749230560544a3e8e8b577f61d after all checks passed, including the full durable job: https://github.com/LyraCoreProject/LyraCore/actions/runs/34229150494/job/102070610422</li><li>Final Package checks against merged core main passed, including all 16 durable fixtures in 167.90 seconds. Package #25 merged as 5724de1660a2628e88320914bdd5abb0c69da517. CI: https://github.com/LyraCoreProject/packages/actions/runs/34230810246/job/102076215519</li></ul><h3>Current notes</h3><ul><li>All eight source acceptance criteria have reviewed evidence. Core #482 and Package #25 are merged.</li><li>Package CI was restored to core main after the core merge. All final checks passed before the Package merge.</li><li>Both full CodeRabbit reviews completed. The repeated-setup finding is fixed; the core CI coverage question is resolved by the paired Package durable job. Final incremental automated review was rate limited. Independent review covered the final fixture changes. All core checks passed.</li><li>The flat observation row remains intentional for SQL diagnosis. Action-specific request functions and a private recorder own production writes; PB-002 owns typed runner candidates and foreground control.</li><li>The nullable quest-credit initialization fixture preserves an existing stall. A full older-Wasm upgrade was not claimed. The new Package schema remains subject to the repository human review requirement before shipping.</li></ul></div></details><small>Parent: S1</small></td><td>complete</td><td>PB-001 implementer</td><td>None</td><td><a href="https://github.com/LyraCoreProject/LyraCore/pull/482" rel="noopener noreferrer">Core #482</a><br><a href="https://github.com/LyraCoreProject/packages/pull/25" rel="noopener noreferrer">Package #25</a></td></tr><tr id="work-PB-002" class="ticket-row" data-work-status="complete" data-work-kind="Ticket" data-parent="S1"><td><code>PB-002</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Run one durable objective through bounded decisions</summary><div><p>Build the shared decision runner around typed facts and outcomes. Retain one objective, arbitrate one foreground action, schedule bots in stable bounded batches, and explain each meaningful choice through the Package&#x27;s normal entry point.</p><h3>Acceptance criteria</h3><ul><li>Fixed facts and explicit time produce the same target-bearing candidate order and chosen action.</li><li>Strategies compose supported triggers, defaults, and priority rules without a global string registry or a second authoritative state machine.</li><li>Prerequisites, alternatives, and continuers have explicit depth, transition, candidate, and route-work limits with cycle refusal.</li><li>Only one foreground movement or cast action owns the bot, and a higher-priority action explicitly cancels incompatible work.</li><li>The durable objective records identity, destination, stage, deadline, last verified progress, bounded failures, deferred destinations, and catalog revision.</li><li>Separate movement, combat, cast, and quest progress evidence prevents an accepted action from masquerading as completion.</li><li>Due bots run in stable indexed order under a per-pass limit; excess work remains due, gets a fair next turn, and records scheduler lag.</li><li>The explanation read reports the current objective and target, chosen action and reason, last outcome, progress age, retry count, next eligible time, and relevant revision with bounded history.</li><li>The additive state migration defines defaults and backfill and adds a durable controller selector before any bot can use the new runner. Record-only mode emits no gameplay actions; cohort mode has one eligible controller and supports freeze.</li></ul><p>Verified criteria: 9/9.</p><p>Fixed facts and explicit time produce the same target-bearing candidate order and chosen action.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The pure decision tests permute input order, rank full target-bearing identities, and retain only the highest-priority offer for each identity. All ten decision cases passed in the final library runs.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/decision.rs</li></ul><p>Strategies compose supported triggers, defaults, and priority rules without a global string registry or a second authoritative state machine.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>Typed Strategy tests cover triggers, defaults, and integer priority adjustment. The common runner stamps its durable objective identity into root and nested candidates before selection.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/decision.rs</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/runner.rs</li></ul><p>Prerequisites, alternatives, and continuers have explicit depth, transition, candidate, and route-work limits with cycle refusal.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The shared limits allow 24 candidates, depth 4, 16 transitions, and one route reservation using the core expansion limit. Separate tests cover each limit, cycles, and repeated cycle refusals inside completed prerequisites.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/decision.rs</li><li>Recovery facts use a paged index and exact learned-spell membership. Runtime regressions find a usable heal beyond 25 unlearned rotations and 300 other learned spells without an unbounded eligibility scan.</li></ul><p>Only one foreground movement or cast action owns the bot, and a higher-priority action explicitly cancels incompatible work.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The final real runner suite proves cast retention through pushback, explicit survival preemption, changed-destination cancellation, and freeze. The Account ownership case preserves a later human cast while the bot relinquishes control. All 21 runner cases passed.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li></ul><p>The durable objective records identity, destination, stage, deadline, last verified progress, bounded failures, deferred destinations, and catalog revision.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The retained ReturnHome objective records destination, identity, stage, deadline, last verified progress, and catalog revision. Blocked travel defers its destination and caps failures and deferrals at four entries. Real tests cover actual arrival, deferred travel under low health, and deadline expiry.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li></ul><p>Separate movement, combat, cast, and quest progress evidence prevents an accepted action from masquerading as completion.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The final tactical movement case moves away from home for more than ten seconds, records movement progress, and leaves the home progress clock unchanged. Defense acceptance does not count as damage. Cast completion uses the exact core scheduled identity. PB-001 quest-credit and no-hit cases still pass.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite.rs</li></ul><p>Due bots run in stable indexed order under a per-pass limit; excess work remains due, gets a fair next turn, and records scheduler lag.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The real 25-bot case proves stable indexed processing in batches of 16 then 9. Excess work remains due and records lag. The populated migration also verifies bounded lazy backfill.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li></ul><p>The explanation read reports the current objective and target, chosen action and reason, last outcome, progress age, retry count, next eligible time, and relevant revision with bounded history.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The public runner row exposes the objective, target-bearing chosen action and reason, last outcome, progress age, retry count, next eligible time, and revision. Its real lifetime case caps history at eight entries and deletes Character-owned state.</li><li>https://github.com/LyraCoreProject/packages/blob/62c459770eb5b2209b7cfbf38e54857454fa69d2/playerbots/src/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li><li>The separate Recovery Scan row exposes its cursor, bounded rows scanned, retained rotation, current stage, and last completed result. Missing remains valid during a subsequent Pending scan.</li></ul><p>The additive state migration defines defaults and backfill and adds a durable controller selector before any bot can use the new runner. Record-only mode emits no gameplay actions; cohort mode has one eligible controller and supports freeze.</p><p>Reviewed by Codex orchestrator with independent GPT-6 Astra Spec and GPT-5.6 Sol Standards reviews.</p><ul><li>The final populated upgrade publishes a preceding Wasm, creates bot roster, goals, observations, and quest rows, then upgrades the same private database. Legacy and scheduler-lag defaults survive. Normal tick and hook cases prove RecordOnly and Frozen suppression and one Cohort controller. Five real core consent cases cover current ownership, invitation admission, deletion, and Transfer.</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/playerbots_rewrite/runner.rs</li><li>https://github.com/LyraCoreProject/LyraCore/blob/4f450074d76f8982d1a7d61898a00cf632132737/module/tests/sessionless_consent.rs</li></ul><p>Execution model: gpt-6-astra, high effort. Repositories: Official Package Collection decision and durable state, LyraCore Module scheduling and diagnostics, Pure decision and durable integration tests.</p><h3>Recorded evidence</h3><ul><li>All nine criteria have reviewed source and runtime evidence. Final reviewed heads are core 4f450074d76f8982d1a7d61898a00cf632132737 and Package 62c459770eb5b2209b7cfbf38e54857454fa69d2. The complete local correction run used clean core a4b5518 and Package dba96bb; the later changes strengthen one test and restore CI references.</li><li>The full Package union passed 1,631 library tests, 1,632 with debug reducers, all 37 action and runner cases, two personality cases, and five core consent cases. This includes a populated preceding-Wasm migration.</li><li>All 37 runtime input records agree on Module BLAKE3 dba4d702a0320e360506f9698fa52e0ef7210ce1e8f9573928599a8e3e032279 and Package Content Identity 33fcb8a217aad84f46f9ad65efdad23be24bad8e29828777de7c7e6469417161. Saved Wasm: 7,590,466 bytes; SHA256 c44a91ee92bb22ebce3de07e39caf9d7028794460a855c3b1d1f9329e473a2ae.</li><li>Final Core #486 CI passed after the test-only update, including the full durable suite and all 1,000 default Gateway binding files. The exact spellbook index needs no generated binding change. CI: https://github.com/LyraCoreProject/LyraCore/actions/runs/34248547507/job/102136730760</li><li>Corrected paired Package CI passed all 37 cases against core a4b5518. Package branch dba96bb ran as synthetic merge e786ee50bb06fc1902b9f5a8e9514669f2d0689e. All inputs are clean and the Package content identity matches local. CI Wasm BLAKE3 is 80efd76cef0d52ee0342f9bc1fe1ee011bcbace0eac7e67e68c944cd427bf659. CI: https://github.com/LyraCoreProject/packages/actions/runs/34245772629/job/102127317130</li><li>The populated local upgrade uses preceding core be3fa67d0f0c24749230560544a3e8e8b577f61d and Package 5724de1660a2628e88320914bdd5abb0c69da517. Its Wasm BLAKE3 is 1662b0963dc0e03c29ddde985f08c0ec5a6f392e899a80eac9d7789a85b1b5a9. Preceding local inventory has example, fire_nova, and playerbots; current inventory also has dungeons. CI independently builds the full preceding collection and records its own Wasm identity.</li><li>Six added regressions cover late eligible heals, retained healing eligibility, health-ratio overflow, isolated fixture timing, navigation grid edges, and a completed missing heal result that permits home movement during rescans. Independent Spec and Standards reviews cleared the final source; the orchestrator reviewed the workflow-only pin update.</li><li>The final core change, 4f450074d76f8982d1a7d61898a00cf632132737, strengthens the grid cleanup test. Its focused durable run proves that each grid corner loses all four nearby chunks while a distant chunk survives. Independent Spec and Standards reviews cleared this test-only delta, and CodeRabbit marked its finding addressed. Gameplay source is unchanged from the 37-case run.</li><li>The focused grid run records clean core 4f45007 and unchanged Package dba96bb. Its Wasm BLAKE3 is 18a320609eebb7a163154d891953decbbc5bdaa401e81d339acb06dd73eaa9e9 and SHA256 is 713ad9a2401029fd10e184c91da3a4eeee1c7e402ad206bf59b598e4afb55a0e. Package Content Identity matches the complete local suite.</li><li>CodeRabbit completed its Package correction review at dba96bb. Its remaining concern assumed absent consent blocks Legacy bots. Core action admission does not read consent, and group admission suppresses only an existing false row. A durable case proves admission before a consent row exists. The orchestrator independently verified this and the implementer resolved the comment with immutable source and behavior evidence.</li><li>Final PR CI passed all 37 cases against merged core e6a755db0a150bbf73ad97b972fe829f20f6816c and finalized its artifact upload. Actual tested Package merge d8d6d7c6574948c07d277ae55e1c899e7721ff95 has parents 5724de1660a2628e88320914bdd5abb0c69da517 and 62c459770eb5b2209b7cfbf38e54857454fa69d2. CI: https://github.com/LyraCoreProject/packages/actions/runs/34250561420/job/102143672288</li><li>The orchestrator independently checked all 37 clean final runtime records. Module Wasm BLAKE3 is 80efd76cef0d52ee0342f9bc1fe1ee011bcbace0eac7e67e68c944cd427bf659. Package Content Identity is 33fcb8a217aad84f46f9ad65efdad23be24bad8e29828777de7c7e6469417161. The strengthened grid assertion and populated migration passed.</li><li>Package #26 merged as 155c9e401afb06d5731acedf8fc35a81dbe4aaa6. Its Git tree e2558a9cf421a74f79497ef361dbbfceb911a0d1 exactly matches both the reviewed branch and the successful PR merge build.</li><li>The separate push run also passed all 37 tests, then GitHub returned HTTP 403 while finalizing its artifact upload. One retry passed all 37 cases and finalized its artifact successfully. The orchestrator verified its 37 clean inputs at core e6a755d and Package 62c4597, with the same Wasm and Package identities as the successful PR run. This closes the service failure without a source change. Retry: https://github.com/LyraCoreProject/packages/actions/runs/34250556649/job/102147886460</li></ul><h3>Current notes</h3><ul><li>SpacetimeDB 2.7.1 allows appended enum variants only when old variants stay compatible and storage size and alignment stay unchanged. Prove populated-state migration for the runner schema. Planner source: https://github.com/clockworklabs/SpacetimeDB/blob/v2.7.1/crates/schema/src/auto_migrate.rs#L826-L895</li><li>Direct damage can delay a pending cast while retaining its scheduled identity. Observe its current due time before deciding that completion is late; the objective deadline is a separate policy limit.</li><li>Record-only means no gameplay actions from either runner for the selected bot. Freeze must stop retained foreground work. Verify both through the normal Package tick entry.</li><li>The first runner behavior retains a home destination through defense and self-heal interruptions. Companion policy and quest admission remain in their dependent tickets.</li><li>Control must cover damage and invitation hooks as well as the tick. The Gateway also auto-accepts invitations for session-less Characters. The core-owned consent check covers that path for record-only and frozen bots.</li><li>The consent check acknowledges current World Shard state before Realm-core group actions. An action admitted before a concurrent freeze may finish; cross-Shard atomicity is not claimed. Controller selection clears unclaimed Group Intents in the same transaction.</li><li>The common runner entry checks current Account ownership. Relinquishment releases only the bot&#x27;s observed cast or movement identity and preserves a later human action.</li><li>Package schema changes still require human review before production shipping. Agent review and source merge do not satisfy that production gate.</li><li>All three PB-002 implementation PRs are merged. Full source reviews and the final workflow review have no unresolved finding. Both final PR and push CI runs passed and saved their artifacts.</li><li>Recovery Scan advances through at most 24 indexed rotations per pass and rechecks at most two retained rotations through exact spellbook lookups. Completed Missing remains conclusive while a new scan is Pending, so recovery cannot repeatedly interrupt useful movement.</li><li>The missing-result regression observes ReturnHome selection and a real emitted spline while movement scheduling is disabled. Separate arrival and tactical cases prove actual position advancement.</li><li>The Recovery Scan is disposable on Transfer and restarts against current content and learned spells. PB-010 still owns transfer of durable objectives and companion intent.</li></ul></div></details><small>Parent: S1</small></td><td>complete</td><td>PB-002 runner agent; integrated and reviewed by the orchestrator</td><td><a href="#work-PB-001">PB-001</a></td><td><a href="https://github.com/LyraCoreProject/LyraCore/pull/484" rel="noopener noreferrer">Core #484</a><br><a href="https://github.com/LyraCoreProject/LyraCore/pull/486" rel="noopener noreferrer">Core #486</a><br><a href="https://github.com/LyraCoreProject/packages/pull/26" rel="noopener noreferrer">Package #26</a></td></tr><tr id="work-S2" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S2</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Companions and provisioning</summary><div><p>Companions and provisioning</p></div></details><small>Parent: PB</small></td><td>0/3 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-003" class="ticket-row" data-work-status="implementing" data-work-kind="Ticket" data-parent="S2"><td><code>PB-003</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Make a Priest follow, heal, and resume</summary><div><p>Complete the first human-led companion loop. A Priest follows its party leader, retains an injured ally as the heal target, repairs range or line of sight, casts through the real lifecycle, handles interruption, and resumes following.</p><h3>Acceptance criteria</h3><ul><li>Joining a human-led party suspends autonomous travel and selects companion Strategies from durable party facts.</li><li>The Priest follows a moving leader without starting a fight against an unrelated nearby enemy.</li><li>An injured ally outranks ordinary following when the Priest has a usable heal and the survival policy permits it.</li><li>Poor range or line of sight produces a movement prerequisite that retains the injured ally and finds a reachable casting position or records a specific wait.</li><li>The heal starts one real timed cast, does not restart on repeated decisions, and observes completion or interruption through typed outcomes.</li><li>After healing, cancellation, or a recoverable interruption, the Priest resumes following without losing party control state.</li><li>Death and resurrection preserve the companion role and lead to regrouping rather than a permanent solo objective change.</li></ul><p>Verified criteria: 0/7.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection companion support behavior, LyraCore Module cast and party fact reads, Durable companion scenarios.</p><h3>Current notes</h3><ul><li>PB-001 found no existing line-of-sight Gate in targeted cast admission. Add the appropriate shared Gate with supported exemptions and client/bot parity coverage so the movement prerequisite responds to a real typed Refusal. Channel actions remain unsupported until their running lifecycle is correlated.</li><li>The historical Actor cast bypasses the player spellbook check. PB-003 owns the appropriate shared Gate for the new runner and must coordinate with provisioning in PB-005. An unlearned heal must refuse without cast, power, or cooldown changes.</li><li>Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.</li><li>Shared design keeps one durable objective and one foreground action. A moving leader refreshes the companion destination without replacing the retained heal identity. Each parallel branch must prove behavior against merged prerequisites.</li><li>The companion recovery fixture must cover critical health at a reached leader destination. A permanent survival Hold cannot block both useful self-recovery and necessary bounded provisioning.</li><li>The latest companion diagnostic passed five of six cases, including the real ally heal, moving leader, recovery, and populated upgrade. Independent Spec review then found three gaps: heal targets could change between prerequisite movement legs, channel rotations could hide a supported heal, and seed repair accepted an altered effect set. Standards review also requires an explicit wait for missing group metadata and independent cast Gate tests. These corrections and new behavior cases are in progress; final acceptance remains pending.</li></ul></div></details><small>Parent: S2</small></td><td>implementing</td><td>Companion agent; orchestrator reviews and merges</td><td><a href="#work-PB-002">PB-002</a></td><td>Pending</td></tr><tr id="work-PB-004" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S2"><td><code>PB-004</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Complete starter roles, target choice, and crowd control</summary><div><p>Add Warrior tank and Mage damage behavior beside the Priest healer on the shared runner. Make explicit durable roles, vanilla class capabilities, chosen-target assistance, controlled-enemy avoidance, death, rest, and regrouping work through repeated party pulls.</p><h3>Acceptance criteria</h3><ul><li>Warrior, Priest, and Mage have validated ability sets at every level supported by the companion fixture.</li><li>Each companion retains an explicit tank, healer, or damage role, with a deterministic vanilla-derived default when no role was selected.</li><li>The Warrior tank chooses and holds the party&#x27;s selected fight according to survival and threat facts rather than inheriting damage-only retreat behavior.</li><li>The Mage acts at class-appropriate range and role does not force a ranged class into melee.</li><li>All companions honor the party&#x27;s chosen fight and designated target and do not initiate an unrequested pull.</li><li>Controlled enemies remain ineligible unless the control is intentionally broken by a higher-priority survival rule with a recorded reason.</li><li>Repeated-pull fixtures cover wounded allies between fights, target death or disappearance, loss of line of sight, companion death, rest, and regrouping without role abandonment.</li><li>Between fights, companions select useful missing class buffs, repair casting position when needed, apply them through real core casts, observe the resulting auras, and avoid redundant recasting while the buff remains valid.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection starter class and role behavior, LyraCore Module combat and capability facts, Durable repeated-pull party scenarios.</p></div></details><small>Parent: S2</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-003">PB-003</a></td><td>Pending</td></tr><tr id="work-PB-005" class="ticket-row" data-work-status="implementing" data-work-kind="Ticket" data-parent="S2"><td><code>PB-005</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Provision playable bots without duplicating progress</summary><div><p>Reconcile the supported bot&#x27;s skills, spells, vanilla talents, equipment, bags, food, potions, ammo, reagents, and bounded supplies on spawn and level-up through real core operations. Make each action idempotent and explain it by provisioning profile and revision.</p><h3>Acceptance criteria</h3><ul><li>Provisioning runs on spawn and level-up and periodically repairs only resources owned by the selected profile.</li><li>Spell learning, equipment, inventory, uniqueness, proficiency, class, and level rules pass through core operations. Free provisioning is an explicit profile choice; its grants remain bounded and attributable.</li><li>Skill training and vanilla talent choices follow the selected class profile through the owning core Gates. Prerequisites, earned talent points, rank limits, and level restrictions hold, and reconciliation cannot spend a point or train a rank twice.</li><li>Repeated reconciliation does not create duplicate equipment, unlimited supplies, repeated spell grants, or repeated costs.</li><li>The policy respects an equipped upgrade, does not delete quest items, and never raises a bot&#x27;s level to match a leader.</li><li>Quest credit, earned XP, loot entitlement, and quest completion remain consequences of normal gameplay operations.</li><li>Full bags, missing consumables, resource recovery, rest, and death produce bounded next actions or an explained stop.</li><li>Decision history records the provisioning profile, revision, chosen action, and typed outcome.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection provisioning policy, LyraCore Module skill, spell, talent, item, inventory, and equipment operations, Durable idempotency scenarios.</p><h3>Current notes</h3><ul><li>Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.</li><li>Agreed integration performs at most one provisioning operation per eligible Cohort tick, with no foreground action. Spawn and level-up arm reconciliation; they do not grant resources outside current control and Account ownership checks.</li><li>The real runner hook distinguishes an applied profile operation from a recorded refusal or deferral. Only applied work consumes the tick. Satisfied checks and recorded failures allow the chosen gameplay action to continue; backoff bounds retries.</li><li>Useful survival, recovery, and defense outrank routine upkeep. New core operations return typed causes. An older String refusal may remain opaque detail but must not be classified by parsing its text.</li><li>The first runtime diagnostic passed the talent Gate case. Source corrections now distinguish recovery grants from item use, preserve truthful equipment refusal causes, and stop explicitly when bounded profile reads overflow. The corrected implementation is committed and awaits a complete clean runtime pass. Final acceptance and review remain pending.</li></ul></div></details><small>Parent: S2</small></td><td>implementing</td><td>Provisioning agent; orchestrator reviews and merges</td><td><a href="#work-PB-002">PB-002</a></td><td>Pending</td></tr><tr id="work-S3" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S3</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Autonomous questing and recovery</summary><div><p>Autonomous questing and recovery</p></div></details><small>Parent: PB</small></td><td>0/3 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-006" class="ticket-row" data-work-status="implementing" data-work-kind="Ticket" data-parent="S3"><td><code>PB-006</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Admit supported quests from a seeded catalog</summary><div><p>Build a versioned quest catalog for the initial Northshire and Elwynn proof from imported relations, objectives, spawns, loot sources, and actual enders. Admit a quest only when every required objective has a supported executor, and retain the chosen objective and destination.</p><h3>Acceptance criteria</h3><ul><li>The catalog records quest eligibility, each objective kind, target or drop source, actual ender, work area, destination evidence, and content revision.</li><li>The initial fixture contains a named supported Northshire and Elwynn catalog with deterministic seeds for each starter class.</li><li>Admission checks ordinary core eligibility and confirms an executor for every required objective before acceptance.</li><li>Unsupported exploration, escort, scripted event, transport, and complex GameObject requirements remain explicit and cannot enter a futile loop. Mixed quests are admitted only when every required kind has an executor, including supported talk-only and simple GameObject steps.</li><li>A live creature search chooses what can be acted on now but does not decide whether a quest destination exists in imported content.</li><li>The retained objective stores the actual ender and catalog revision and survives a tactical combat interruption.</li><li>If a held quest becomes unsupported, the bot records the missing capability and proceeds to another supported objective or a specific wait without repeated abandonment and reacceptance.</li></ul><p>Verified criteria: 0/7.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection quest catalog and admission, LyraCore imported quest and world relations, Seeded durable catalog scenarios.</p><h3>Current notes</h3><ul><li>Imported source identifies quest 3904 as a collect-item quest backed by chest loot. The existing GameObject use operation needs Package visibility and bounded object discovery. Verify and correct the importer NextQuestInChain column mapping before relying on forward links.</li><li>Started in isolated core and Package worktrees from merged PB-002. Shared runner composition belongs to PB-003; builds use one coordinated slot.</li><li>Catalog admission must prove a currently callable executor for every required kind. Imported destination evidence is separate from live target discovery. PB-007 owns the later autonomous quest sequence; its planned work cannot establish executor availability today.</li><li>The reference ClassicDB source identity stays separate from observed runtime content and destination revisions. Seeded content or a later import cannot inherit an unverified source hash. A refresh scenario must cover held objectives when the observed content changes.</li><li>The clean catalog run passed all seven admission and behavior cases with no compile warnings. Root verified 17 saved records against the exact core, Package, and Wasm identities. The eighth case, populated PB-002 upgrade, used an incorrect nested-option check; its corrected fixture awaits rerun. Independent review and final acceptance remain pending.</li></ul></div></details><small>Parent: S3</small></td><td>implementing</td><td>Quest catalog agent; orchestrator reviews and merges</td><td><a href="#work-PB-002">PB-002</a></td><td>Pending</td></tr><tr id="work-PB-007" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S3"><td><code>PB-007</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Finish supported autonomous quest loops</summary><div><p>Complete supported kill, collect, talk-only, and simple GameObject quest loops. The bot accepts the quest, retains its objective, travels through real navigation, executes the required gameplay, earns ordinary credit and XP, turns in to the actual ender, and selects the next supported work.</p><h3>Acceptance criteria</h3><ul><li>A supported kill quest completes through accepted combat, actual damage and death, kill credit, travel, and turn-in rather than a changed internal label.</li><li>A supported collect quest hunts an explicit eligible drop source, receives the item through real loot and inventory operations, and turns in to the catalog&#x27;s actual ender.</li><li>A supported talk-only chain advances through actual quest eligibility, giver and ender interactions, and ordinary rewards without manufacturing prerequisite completion.</li><li>At least one cataloged simple GameObject objective completes through the owning core use or loot operation, respects range and object state, and earns credit once. Unsupported scripted object behavior is refused at admission.</li><li>Quest objective progress changes only when the authoritative core gameplay outcome changes it.</li><li>The retained quest objective survives combat interruption, death, rest, and provisioning, then resumes after rechecking eligibility.</li><li>Target death, disappearance, or ineligibility cancels only the current action and selects a new eligible target or an explicit respawn wait.</li><li>A completed turn-in grants ordinary rewards once and advances to another supported catalog entry without Operator help.</li><li>Seeded scenarios cover Warrior, Priest, and Mage and produce reproducible decision and outcome histories.</li><li>A supported quest destination outside the former home leash remains reachable under the current work area and retained destination. Tactical retreat returns to an appropriate safe position in the current partition and cannot reset travel to the spawn home.</li></ul><p>Verified criteria: 0/10.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection autonomous quest behavior, LyraCore Module quest, combat, loot, inventory, and navigation operations, Seeded durable quest scenarios.</p></div></details><small>Parent: S3</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-005">PB-005</a>, <a href="#work-PB-006">PB-006</a></td><td>Pending</td></tr><tr id="work-PB-008" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S3"><td><code>PB-008</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Recover from blocked travel and stalled quest work</summary><div><p>Turn typed failure and progress evidence into finite recovery for both autonomous bots and companions. Change approach, defer destinations, invalidate stale targets, and explain waits without erasing the retained objective.</p><h3>Acceptance criteria</h3><ul><li>The blocked-target fixture cannot clear its stall clock through attack acceptance when route, damage, and quest progress remain unchanged.</li><li>After 10 seconds without movement progress the bot changes approach; within 30 seconds it advances, defers the destination, or records a specific wait.</li><li>A safe partial route remains eligible while it advances a route or waypoint within a bounded route budget.</li><li>Repeated no-progress defers a destination by map, instance, and geometry revision for a bounded period and allows another useful action.</li><li>Unknown coverage stays distinct from a verified blocked route and reports the missing imported coverage evidence.</li><li>Death, full bags, absent targets, an unreachable giver, a controlled enemy, and a broken prerequisite each end in recovery or an explained finite stop.</li><li>Recovery remains active for companions and uses follow distance, leader movement, and casting position as its progress evidence.</li><li>Restarting the fixture preserves the bounded failure memory that prevents immediate reselection of the same failed target.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-6-astra, high effort. Repositories: Official Package Collection travel and recovery behavior, LyraCore Module navigation evidence, Durable blocked-route and stalled-work scenarios.</p></div></details><small>Parent: S3</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-004">PB-004</a>, <a href="#work-PB-007">PB-007</a></td><td>Pending</td></tr><tr id="work-S4" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S4</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Commands, Transfer, and restart</summary><div><p>Commands, Transfer, and restart</p></div></details><small>Parent: PB</small></td><td>0/2 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-009" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S4"><td><code>PB-009</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Honor durable follow, stay, assist, and target orders</summary><div><p>Complete the companion command contract through the existing command transport. Persist follow, stay, assist, and designated-target orders, apply them with party authority, and resume valid solo work when human-led control ends.</p><h3>Acceptance criteria</h3><ul><li>A human party leader can issue follow, stay, assist, and designated-target orders through the existing command transport.</li><li>Each accepted order persists as typed control state and produces an explanation entry with Actor, target where relevant, and outcome.</li><li>Follow tracks the leader, stay holds the commanded location within movement tolerances, and assist limits initiation to the chosen fight.</li><li>A designated target participates in candidate identity and cannot be replaced by another proposal&#x27;s target when scores change.</li><li>Controlled enemies remain ineligible while assist or target orders are active unless an explicit higher-priority survival decision records why control was broken.</li><li>Joining a human-led party suspends autonomous travel and opportunistic grouping without deleting the solo objective.</li><li>Leaving the party invalidates companion actions, rechecks the retained solo objective, and resumes it only when it is still eligible.</li><li>Role and command state survive companion death and remain consistent after regrouping.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-5.6-sol, high effort. Repositories: Official Package Collection commands and control state, LyraCore Gateway command transport and Module party reads, Durable join and leave scenarios.</p></div></details><small>Parent: S4</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-004">PB-004</a></td><td>Pending</td></tr><tr id="work-PB-010" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S4"><td><code>PB-010</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Preserve one controller through restart and Transfer</summary><div><p>Define and prove the lifecycle of every new bot row across Character deletion, Module restart, Gateway restart, party changes, and Transfer. Suspend local actions while Transfer is pending, rebuild transient observations on arrival, and prevent stale work from acting.</p><h3>Acceptance criteria</h3><ul><li>Each durable Package row has an explicit keep, move, rebuild, or delete rule for Character deletion and Transfer.</li><li>A pending Transfer suspends local actions and relies on authoritative Transfer state rather than timeout to create another executor.</li><li>The retained quest or party objective, control mode, role, deadlines, deferred destinations, and bounded failure memory survive their defined restart and Transfer cases.</li><li>Transient targets and route segments do not Transfer; arrival rebuilds them against the destination&#x27;s content and geometry revisions.</li><li>Pending work carries controller generation and location, and an old completion cannot advance a new action after restart or arrival.</li><li>Restart fixtures interrupt active movement, cast, provisioning, quest reward, and Transfer stages without duplicating a Character, item, supply grant, reward, or active controller.</li><li>A transferred companion retains the correct party and role on arrival, and a transferred autonomous bot resumes or invalidates its objective for a recorded reason.</li><li>One instance entry and exit through the real routing path preserves companion orders and produces arrival evidence.</li></ul><p>Verified criteria: 0/8.</p><p>Execution model: gpt-6-astra, high effort. Repositories: Official Package Collection bot row lifecycle, LyraCore Module, Gateway, Realm-core, Transfer, and Group Intent integration, Durable restart and Transfer scenarios.</p></div></details><small>Parent: S4</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-008">PB-008</a>, <a href="#work-PB-009">PB-009</a></td><td>Pending</td></tr><tr id="work-S5" class="parent-row" data-work-status="planned" data-work-kind="Workstream" data-parent="PB"><td><code>S5</code><br>Workstream</td><td style="padding-left:20px"><details><summary>Release evidence and retirement</summary><div><p>Release evidence and retirement</p></div></details><small>Parent: PB</small></td><td>0/2 complete</td><td>Orchestrator</td><td>None</td><td>Pending</td></tr><tr id="work-PB-011" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S5"><td><code>PB-011</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Pass autonomous, companion, and load acceptance</summary><div><p>Run the complete automated release suites on the pinned core, Package, imported content, and geometry. Prove seeded autonomous work, the fixed human-led companion route, restart and Transfer behavior, bounded recovery, scheduler fairness, and measured 10, 25, and 100 bot load.</p><h3>Acceptance criteria</h3><ul><li>Run ten seeds per starter class through the supported Northshire and Elwynn catalog. All ten runs per class must finish each supported scenario without Operator help: nine of ten is below the 95 percent requirement. Every failed run must record an explained outcome and fails the release gate.</li><li>Autonomous acceptance includes kill, collect, talk-only chains, supported simple GameObject use, travel beyond the former home leash, turn-in, death, combat interruption, full bags, absent targets, an unreachable giver, and unsupported objective admission.</li><li>One human-controlled Character and four bots complete the fixed repeated-pull route with explicit roles, follow and stay, assist and designated target, wounded allies and missing buffs between fights, loss of line of sight, controlled enemies, death, regrouping, and one instance entry and exit.</li><li>The companion fixtures produce no unrequested pull, unexplained role abandonment, repeated cast start, or attack against an obsolete target.</li><li>Every supported action covers success, waiting, Refusal, cancellation, and expiry through the highest suitable behavior seam.</li><li>Restart and Transfer acceptance shows no duplicate Character, equipment, supply grant, quest reward, or controller and no stale action at the old location.</li><li>Named disposable load runs execute 10, 25, and 100 bots and record decision time, movement time, scheduler lag, route expansions, row reads, row writes, and slowest due bot.</li><li>The load report sets a measured deployment capacity, records fixture resources and revisions, and accounts for every deferred due bot without silent loss.</li><li>All relevant repository checks and both specification and standards reviews pass at the pinned revisions.</li></ul><p>Verified criteria: 0/9.</p><p>Execution model: gpt-6-astra, xhigh effort. Repositories: LyraCore and Official Package Collection acceptance suites, Headless Client protocol and world-transition scenarios, Disposable imported-world load fixture and measurement report.</p></div></details><small>Parent: S5</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-005">PB-005</a>, <a href="#work-PB-007">PB-007</a>, <a href="#work-PB-008">PB-008</a>, <a href="#work-PB-010">PB-010</a></td><td>Pending</td></tr><tr id="work-PB-012" class="ticket-row" data-work-status="planned" data-work-kind="Ticket" data-parent="S5"><td><code>PB-012</code><br>Ticket</td><td style="padding-left:28px"><details><summary>Cut over, observe, and retire the old behavior</summary><div><p>Complete the additive state cutover with one durable controller selector, compare record-only decisions, activate a small cohort, gather imported-world and attended client evidence, then delete the displaced behavior source, obsolete tests, and active old state path. Leave old table retirement as its separately reviewed migration when required by repository rules.</p><h3>Acceptance criteria</h3><ul><li>The additive state migration defines defaults and backfill, and exactly one durable selector makes one runner eligible to control each bot.</li><li>Record-only comparison on fixed facts issues no gameplay actions and reports deterministic policy disagreements before cohort activation.</li><li>A small active cohort can freeze without a second controller and can resume after the failure reason is recorded.</li><li>Both automated release suites from PB-011 pass again with the new runner selected and no old runner actions.</li><li>A one-hour imported-world observation runs 25 bots and records no unexplained stall, repeated Refusal spam, visible clipping, or idle injured healer.</li><li>An attended session in a real unmodified 1.12.1 client exercises the companion route and signs off follow, stay, assist, target choice, crowd-control respect, real casts, death, regrouping, and instance entry and exit.</li><li>If the implementation environment cannot run the real client, the exact observation script, fixture revisions, capture format, and diagnostic reads are ready, and this acceptance item remains explicitly pending human evidence.</li><li>The displaced behavior source, obsolete helper-shape tests, broad internal exports, active old controller path, and unused old state access are deleted after acceptance.</li><li>Repository checks prove the deleted behavior source cannot regain control and no production code reads or writes obsolete active state.</li><li>Any physical old-table removal has its own reviewed migration plan and does not weaken the completed single-controller cutover.</li></ul><p>Verified criteria: 0/10.</p><h3>Imported world observation</h3><p>Pending. Required before completion.</p><h3>Attended client observation</h3><p>Pending. Required before completion.</p><p>Execution model: gpt-6-astra, xhigh effort. Repositories: Official Package Collection controller cutover and source retirement, LyraCore additive state migration and architecture checks, Imported-world observation and attended client evidence.</p></div></details><small>Parent: S5</small></td><td>planned</td><td>Unassigned</td><td><a href="#work-PB-011">PB-011</a></td><td>Pending</td></tr></tbody></table></div>
 </section>
 <style>
 .execution-controls{display:flex;align-items:end;flex-wrap:wrap;gap:12px}.execution-controls label{display:grid;gap:4px;font-size:14px}.execution-controls input,.execution-controls select,.execution-controls button{font:inherit;border:1px solid #718a95;background:white;color:#18252d;padding:7px 9px;border-radius:0}.execution-controls input{max-width:100%;width:260px}.execution-table table{min-width:900px}.execution-table td:nth-child(2){min-width:300px;max-width:490px}.execution-table details{border:0;padding:0}.execution-table details h3{font-size:1rem}.execution-table details p,.execution-table details li{font-weight:400}.execution-table .parent-row{background:#edf3f4}.execution-table small{font-weight:400}.execution-table tr[hidden]{display:none}@media print{.execution-controls,#execution-count{display:none}.execution-table table{min-width:0}.execution-table tr[hidden]{display:table-row}}