acdream/docs/plans/2026-08-26-mosstank-parity-campaign.md

30 KiB
Raw Blame History

MossTank — VTank parity campaign

Date: 2026-08-26 Status: ACTIVE — MT1 USER-PASSED; MTUIMT9 functional/API scope complete; connected shelf/shell, accessibility, reconnect, bidirectional peer-expression and two-member fellowship gates passed; #451 root fixed and 30-minute dual-client activation soak passed; hostile/collision gates remain

Research baseline: docs/research/2026-08-26-mosstank-vtank-utilitybelt-research.md

Product definition

MossTank will provide the complete automation capability associated with Virindi Tank, implemented as a first-class acdream plugin over a stable, BCL-only plugin API. UtilityBelt's typed expression dialect is the scripting baseline. Native file formats may differ; behavior and extensibility may not. The finished surface is a visually verbatim VTank reproduction: every VTank tab and function is present and every enabled control invokes real behavior.

Non-negotiable boundaries

  • modern code, behavior matched to documented VTank/retail behavior;
  • one Runtime owner for every state/action; plugin API is a borrowed projection;
  • policy engines remain in MossTank, not App or Runtime;
  • plugin UI only through IUiRegistry;
  • every API addition works in graphical and no-window hosts, with explicit unavailable behavior until the host can genuinely supply it;
  • no fake success and no silent expression-function omission.

Slice ledger

MT0 — research and campaign design

  • Reconcile existing VTank audit with current Runtime ownership.
  • Audit current UtilityBelt grammar and all 260 expression declarations.
  • Define complete capability ledger and staged architecture.

MT1 — autocombat foundation (current stop gate)

  • Add target/combat views and attempt commands to the plugin API.
  • Project canonical hostile, selection, mode, power and spell state.
  • Implement target lock and range/angle/hybrid selection.
  • Implement melee/missile charge-release and direct offensive magic.
  • Deliver the polished combat dashboard and settings.
  • Focused, App/Runtime and complete solution gates.
  • Connected user gate: user confirmed autocombat works in the plugin.

MT1 intentionally does not pretend later features exist. It is “autocombat ported,” not “all combat policy ported.”

MTUI — generic plugin-window and VTank shell foundation

  • Add manifest-authenticated, stable plugin panel descriptors without breaking API-v1 hosts/plugins.
  • Register plugin panels with the common retained window manager so geometry and visibility persist.
  • Add the shared right-edge plugin shelf and window minimize/restore; hidden panels leave the plugin session and automation running.
  • Add reusable nested groups, tabs, lamp toggles and sliders to retained plugin markup.
  • Replace MossTank's dashboard/settings pair with one VTank-shaped shell using the exact Options, Profiles, Vitals, Monsters, Items, Consumables, Buffs, Route, Meta tab order.
  • Bind all currently enabled controls to real MT1/buff behavior and leave unimplemented tabs visibly disabled.
  • Enable the Items/Consumables pages against durable, manifest-scoped exact-name profiles; selection and Add/Add-no-buffs/Add-All-Peas controls all mutate the policy consumed by combat.
  • Connected visual gate: shelf placement, minimize/restore persistence, and first VTank-shell comparison in the live client.

MT2 — complete monster/weapon/debuff combat policy

  • ordered DEFAULT + first-match monster rules;
  • priorities -1..4 and complete action-flag matrix;
  • damage/weapon/offhand selection, swap state machine and auto power, including the official GameInfoDB exact-name overrides, ordered creature- species preferences, and VTank's final elemental fallback;
  • debuff groups, skill/level choice, receipt-gated reapply and explicit wand switching policy;
  • ring/arc/bolt density/range logic, streaks, Void, harm/martyr, grenades, lenses, cast-on-strike and pets; (carried phials are complete; crafting a missing phial belongs to MT4's generalized craft transaction);
  • blacklist and both ghost-monster detectors, including canonical App entity teardown for a detected client ghost.

MT2 checkpoint 2026-08-27: the BCL API now projects complete learned-combat spell metadata, server cast and physical-attack receipts, health-update revision/age, canonical equipment snapshots/commands, and exact-incarnation ghost deletion. MossTank owns the complete Monsters expression/action model, debuff tracker, elemental/shape spell catalog, range/density selection, weapon/offhand policy, temporary blacklist, and both VTank ghost algorithms. Focused evidence at this checkpoint: 104 MossTank tests, 20 Runtime action/ target tests, and an isolated Release App build all pass with zero failures or warnings. MT2 remains open for automatic physical power and the four item- backed combat families.

MT2 checkpoint 2 (2026-08-27): the official VTank assembly and live GameInfoDB feed were inspected directly. Item appraisal SpellBooks are now retained; plugins receive ordered combat chat and exact item UseDone receipts; the source planner implements dz.b.CompareTo for SpellLevel/Skill preference; the 72 official phials, lenses, cast-on-strike weapons and pets are executable and profile-gated; proc success waits for the actual You cast ... on ... line. hi.cs automatic attack power, including Recklessness clamping, is ported verbatim. Items/Consumables profiles are atomically persisted through a new per-manifest plugin-storage contract. Focused evidence: 131 MossTank tests, the storage/chat/App tests, and an isolated Release App build pass. MT2 remains open only for target-database Auto damage selection and the connected gate; missing-grenade crafting is deliberately MT4 transaction scope.

MT2 automated closeout (2026-08-27): Auto now consumes the official 59-name override and 103-species preference tables. The ordered element decision outranks spell shape/tier, drives profiled physical weapon selection, and feeds automatic attack power and vulnerability policy. Unknown targets preserve VTank's final Pierce→Bludgeon→Slash→Acid→Lightning→Cold→Fire fallback. Focused evidence after the closeout and named-profile foundation: 146 MossTank tests; isolated Release App build 0 warnings / 0 errors. The connected MT2 combat matrix remains part of the later combined user gate.

MT3 — buff, heal and resource parity

  • named macro profiles, buff exclusions/item buffs/top-off foundation;
  • all three vital threshold tiers and canonical fellowship vitals;
  • profiled kits/consumables and worn-item mana recharge;
  • VTank ManaStone/ManaTank acquisition and exact-receipt fill behavior;
  • conversions, self/item/fellow dispel response, and critical/normal/idle component plus six-category consumable upkeep.

MT4 — inventory, craft and transactions

  • AutoStack/AutoCram and the official 757-row VTank craft database;
  • generalized use/apply/give/move/split/stack/drop transaction API with receipts and busy arbitration;
  • retail 0x027D salvage and authoritative current-vendor sale paths;
  • same-input authoritative split crafting, all three split priorities and exact VTank door/lockpick policy.

MT5 — looting and extensible rule engine

  • corpse lifecycle/ID waits, exact 30-attempt/200-second open blacklist, 60-minute cache, 100-second public ownership, fellow Share Loot and rare-only policy;
  • ordered first-match raw/projected-property expressions plus Keep, KeepUpTo, Read, Salvage, Sell, ManaStone, ManaTank and User1User5;
  • canonical appraisal/pickup/salvage/vendor seams, unknown-scroll fallback, and exact VTank salvage workmanship bands with 40-attempt abandonment;
  • independent By-char and named native loot profile documents;
  • exact VTClassic .utl v0/v1 importer/exporter, every structured requirement, forward-compatible length blocks, and profile-owned salvage ranges/value modes;
  • external loot-classifier plugin capability.

MT5 functional closeout (2026-08-27): the graphical host now exposes corpse discovery, raw item properties, canonical appraisal/pickup, learned-spell membership, fellowship Share Loot, retail salvage (0x027D), and current-vendor sale through additive BCL-only interfaces. MossTank owns all policy and waits for authoritative receipts/object removal; no action reports success at dispatch. The official VTank corpse timers, rare/fellow ownership branches, unknown-scroll difficulty check, mana-stone pairing, salvage-bag workmanship bands, and bugged-bag retry ceiling were ported from the official decompiled source. Focused evidence: 184 MossTank tests, 21 inventory-wire/session tests, 134 App automation/item/UI tests, and an isolated Release App build with zero warnings/errors. File interoperability remains an MT9 compatibility tail, not a reason to hold Route/Navigation.

MT6 — navigation

  • canonical move/follow/turn/charged-jump/checkpoint host primitives;
  • circular, linear, once and Target/follow routes, including VTank's endpoint reversal, destructive Once traversal and follow-around-corners;
  • every decoded nav node (0..9), closed-door/lockpick policy, vendor and repeated NPC use, portal re-entry protection and combat/nav priority;
  • independent By-char and named native route profiles;
  • exact uTank2 NAV 1.2 importer/exporter.

MT6 functional closeout (2026-08-27): the additive navigation API projects VTank coordinates, live and server-accepted player position, object reacquisition, door state, portal state, and typed movement levels through the one Runtime command interpreter. MossTank owns the exact four route modes and ten node types. Steering ports fd.cs's 4° turn threshold, far 45° and near 15° forward cones; checkpoints use gr.cs's accepted-position gate and 15-second nudge; Target mode ports gl.cs breadcrumb pruning; doors port b7.cs's defaults (disabled, 20 m ID, 4 m open, 50 lockpick threshold). Portal2/UseNPC reacquire exact-name objects near the saved point, NPC use waits for tell/give chat, jumps align to their stored heading before charge/release, and Once removes completed rows exactly like VTank. Evidence: 204 MossTank tests, focused App navigation projection tests, and isolated Release App build with zero warnings/errors. Legacy file interop remains an MT9 compatibility tail and does not hold the expression engine.

MT7 — expressions

  • immutable AST, typed values, budgets and diagnostics;
  • UtilityBelt grammar semantics including lists/dicts/slices;
  • implement/alias/explicitly disposition the 260-function audit ledger;
  • VTank option/expression command diagnostics;
  • parser, evaluator, persistence and capability-security gates.

MT8 — meta engine and runtime views

  • complete condition/action vocabulary, nested composition, once-per-entry, call/return and watchdog;
  • chat capture variables and option access;
  • plugin-authored runtime views over the retained markup contract;
  • native meta profile;
  • exact VTank CondAct .met importer/exporter, including recursive rules, embedded NAV and the historical CreateView record quirk.

MT9 — fellowship, profiles, commands and polish

  • tell-driven recruitment, waiting-list, status/location commands, and two-minute kick/ban/giveleader/setopen voting over canonical fellowship commands;
  • helper healing, fellowship corpse permissions and shared target views;
  • macro-profile foundation: true per-character By char documents, named create/copy/clear/select, mine-only filtering, hot loading, atomic manifest- scoped storage, and complete current combat/buff/vitals/monster/item state;
  • independent navigation/loot/meta profile documents remain with MT5/MT6/MT8;
  • exact 137-name typed VTank option catalog/defaults and durable /vt opt setinall across every indexed named/character macro profile;
  • all documented /vt command names are locally registered and handled;
  • exact .nav, .met, and .utl dumps/import-export;
  • privileged debug-operation semantics (clearlocks, clearbusy, fakeimp) use canonical owners and authoritative lifetime cleanup;
  • first-run guidance, native/VTank profile migration and corrupt-profile recovery with append-only raw-data preservation;
  • accessibility and scaling polish;
  • performance soak, reconnect/lifecycle and multi-client gates.

MT1 execution order

  1. Add BCL-only combat records/interfaces with inert defaults.
  2. Extend Runtime hostile query with exact position/heading snapshots.
  3. Bind App's automation surface to the canonical action/spell owners.
  4. Implement/test MossTank's deterministic combat controller.
  5. Replace the small panel with dashboard/settings markup and generic markup affordances needed by the design.
  6. Run narrow tests, Release build, broad tests; record exact evidence here.

Closeout evidence

MT1 code-complete 2026-08-26 and user-passed 2026-08-27. The additive BCL-only contract is CombatAutomation.cs; older API-v1 implementations retain inert default members. AppAutomationSurface borrows the canonical Runtime owners and projects hostile captures, combat state, physical press/release attempts, targeted casting and learned direct offensive spells. MossTank's CombatController owns priority, target lock, range/angle/both selection, mode entry, power-bar timing and magic choice. The dashboard/settings markup uses the retained plugin registry; generic markup now supports bound child visibility/enabled state and button colors.

Automated evidence:

  • focused MossTank: 54 passed / 0 failed;
  • complete Runtime: 1,854 passed / 0 failed;
  • repository-owned hermetic Release gate: 15,775 passed / 0 skipped / 0 failed across 14 assemblies;
  • Release build: 0 warnings / 0 errors;
  • the original MossTank XML documents parsed successfully before the gate.

MTUI code-complete 2026-08-27. PluginPanelDescriptor and authenticated PluginUiOwner carry presentation metadata through Core's transactional plugin lifetime; App mounts the stable panel as a RetailWindowHandle and the generic PluginSidePanel owns only hide/restore UI. The one-window MossTank shell uses real retained tabs/toggles/sliders. Focused evidence: 18 App/plugin tests and 56 MossTank tests passed; isolated Release App build passed with 0 warnings / 0 errors. Broader hermetic evidence: Core 4,720/4,720 and Runtime 1,854/1,854 passed; App passed 6,441/6,442 with the sole failure in the unrelated pre-existing landblock recenter assertion OriginRecenter_RetryPreservesLiveIdentityAndDoesNotRescueReusedGuid. Its connected visual gate remains open.

MT3/MT4 resource closeout 2026-08-27: crafting now runs through VTank's three ordered tiers: critical component/consumable recovery, normal component and general profile crafting, then no-target idle component and six-category kit/food stock targets. Same-input recipes wait for both the authoritative split receipt and publication of two distinct stacks before applying. The official IdleCraftCount_* underscore names, 4/20/20 component defaults, and 2/2/2 kit plus 15/15/15 food targets persist in named/By-char profiles. Self-cast and item dispels port c8.cs/cx.cs; fellowship Awakener selection ports af.cs, including exact training, Arcane Lore, 5 m, spell-3179 and summed-vulnerability-quality gates. The additive shared duration-spell ledger matches VTank's confirmed local/external LogSpellCast model and clears on session detach. Evidence: 277/277 MossTank tests, 12/12 focused App automation tests, and isolated Release App build with zero warnings/errors.

MT7MT9 checkpoint 2026-08-27: MossTank registers all 260 audited UtilityBelt public expression names over the typed evaluator, and the Meta runtime/editor, dynamic views, embedded routes, command execution and durable variable scopes are integrated. The host now provides an unload-safe generic plugin-command registry; /vt follows the same local command route from typed chat, launcher login commands and no-window clients. The exact official four-line command catalog and 137-row typed option database are present; setinall rewrites every indexed named/character profile. Run Macro is now a master lifecycle distinct from Enable Combat, and command jumps align before charging. The additive fellowship API projects the canonical retail commands; MossTank owns VTank's tell commands, wait list, spam limit, near-player recruitment, leader transition cleanup and two-minute voting. Evidence at this checkpoint: 261/261 MossTank tests, 18/18 runnable focused App/plugin tests, and isolated Release App build with zero warnings/errors. Four additional GraphicalPluginSession tests could not locate the repository when deliberately run from an isolated OutputPath; this is test-harness path behavior, not a product failure. Connected shelf/UI/fellowship and combined automation gates remain open.

Legacy-profile checkpoint 2026-08-27: native JSON remains MossTank's durable working format, while every save also emits a genuine VTank compatibility file. uTank2 NAV 1.2 routes and CondAct .met files round-trip exactly; the Meta writer was independently accepted and canonicalized byte-identically by the public metaf reference compiler. VTClassic .utl v0/v1 now retains length-delimited unknown requirements/blocks, executes all 31 published requirement types (including the DAT-resolved ordered-palette color family), and applies per-material salvage ranges/value modes to the real 0x027D combine planner. Native-only text rules export disabled rather than becoming VTClassic's dangerous empty-requirement match-all. Evidence: 290/290 MossTank tests, 13/13 focused App/plugin tests, and isolated Release App build with zero warnings/errors.

External-loot checkpoint 2026-08-27: the BCL-only host now owns an unload-safe classifier registry. Classifier ids are namespaced to the registering plugin, all registrations are disposed transactionally with that plugin's session, and exceptions are isolated at the registry boundary. MossTank exposes the available engines in Profiles, persists the selection with the macro profile, and runs Keep/KeepUpTo/Read/Salvage/Sell/User1User5 decisions through its existing authoritative corpse executor. An unavailable engine never silently changes policy by falling back to VTClassic. Evidence: 2 focused Core registry tests, 55 focused MossTank loot/panel/markup tests, and isolated Release App build with zero warnings/errors.

Options/debug checkpoint 2026-08-27: the VTank Options page now uses the verbatim four-column control arrangement. Normal automatic rebuff, the separate idle top-off window, Attack→Approach distance navigation, and final Idle Peace fallback were ported from fz.cs, cLogic.cs, g8.cs, eb.cs and cm.cs; Force Buff and Cancel Force Buff remain distinct actions. The Advanced Options button opens the full ordered 137-setting table. /vt clearbusy decrements exactly one Runtime-owned inventory busy reference, clearlocks clears only MossTank's transient policy locks, and fakeimp records VTank's local 3,000-second Gossamer Flesh debug marker without forging a server cast. External classifiers now receive authoritative OnLooted and OnItemRemoved lifecycle callbacks after inventory publication. Evidence: 298/298 MossTank tests and an isolated Release App build with zero warnings and zero errors.

Final automated API/options checkpoint 2026-08-27: every one of the 137 official advanced-option names has an explicit writable live-policy mapping; the full catalog, official defaults, case-insensitive lookup and durable profile propagation are covered. The Monsters page now exposes the three distinct official cycles for Damage type, Ex. Vuln and PetDmg rather than one shared internal enum. Prismatic remains an ammunition policy while preserving automatic magic-element selection; Fists uses Tusker Fists only while its enchantment is active. DoJiggle now ports VTank's PreviousSelection followed by alternating NextPlayer/PreviousPlayer at 131 ms and no longer moves the character. ShowCollisionDebug publishes bounded projectile samples through the BCL-only API and renders transient red/green markers in the retained UI. WhoYouGonnaCall is intentionally stored but inert, matching the official source's explicit No Function disposition.

The plugin API now projects combat, magic, equipment/items, looting, fellowship, enchantments, navigation, world objects/time, login, network peer state, recovery, projectile diagnostics and selection through canonical Runtime/App owners. Startup peer tags are parsed once by RuntimeOptions, portable data paths come from ApplicationPathSet, and both graphical and headless plugin hosts load fixtures correctly from isolated output graphs. Latest hermetic evidence: App 6,592 passed / 94 environment-dependent skips; Runtime 1,863/1,863; Core 4,911/4,911; Core.Net 1,042/1,042; Headless 171/171; UI abstractions 880/880; MossTank 320/320 — 15,779 passed, zero failed across the selected automated lanes. The Release App build completed with zero warnings and zero errors. Excluded gates are explicit: manual/live lanes, Linux-only tests on this Windows host, the machine-local stale bake-tool 4 PAK test, and one registered pre-existing tower-ascent known failure. The generic shelf, VTank shell, minimization-while-running, reconnect, live combat, multi-client peer expressions, and collision-marker appearance remain owed in the combined connected user gate.

Connected shelf/shell gate 2026-08-27: the first isolated Release launch found that App's plugin-copy target still assumed each plugin's conventional bin directory when a custom OutputPath was active. That caused the packaged MossTank DLL/markup to be stale even though the root build outputs were current. Build and publish now resolve both first-party plugin targets through MSBuild's GetTargetPath; MossTank markup copies directly from its source. The rebuilt package's MossTank DLL and XML matched their build/source SHA-256 hashes and the boundary regression passed 5/5.

The next live launch exposed a retained-markup contract mismatch: one field reused an Action button binding where onsubmit requires Action<string>, preventing the complete plugin window from mounting. MossTank now has a typed submit action and its markup contract test validates every interactive binding's delegate shape. A later visual pass also caught three unsupported inline label bindings on Meta; all are now whole-value properties, and the contract rejects future inline interpolation. Focused MossTank evidence is 321/321; isolated Release build app-release22 is zero-warning/zero-error with exact packaged artifact hashes.

The connected app-release22 gate then passed: all nine tabs mounted and were visually inspected; Meta rendered State: Default, N: 0, and N2: 0; the right-edge MT shelf button was fully reachable; minimize hid only the window; while hidden the live buff pass advanced from 91/97 to 77/97; restore showed Stop Macro and the changed live status; the macro stopped normally. Logs show 92 server-confirmed UseDone err=0 casts and no plugin/UI exception. Shift+Esc completed the full logout presentation and returned to character selection. This supersedes the earlier statement that the shelf, shell, minimization, and basic reconnect/lifecycle presentation were wholly unproven. At that checkpoint, still owed were the accessibility/scale closeout, longer performance/reconnect soak, live hostile combat matrix, two-client peer expressions/fellowship, and collision- marker appearance.

Accessibility/reconnect/peer checkpoint 2026-08-27: textless and terse controls now carry runtime-bound retained tooltips, and the common window owner clamps plugin panels to the current viewport (including the 800x600 oversize case). Focused evidence is 325/325 MossTank tests, 16/16 retained-UI tooltip/geometry tests, and isolated Release app-release23 with zero warnings/errors. The live client displayed the Monster Range help text, completed a same-character logout/re-entry, restarted the macro, and completed another 92 server-confirmed casts. Working/private memory stayed approximately 1.59/1.84 GiB across the combined soak rather than climbing with casts or reconnect.

The local peer API also passed real two-process expressions in both directions: the secondary +Horan evaluated dictgetitem[listgetitem[netclients['mosstank-guard-primary'],0],'Name'] and received +Acdream, while the earlier reciprocal gate returned +Horan to the primary; both heartbeat documents contained the expected names, tags, vitals and positions.

That broader gate exposed separate client defect #451. First-chance cdb proof located it in GLFW's Win32 event pump: temporary cross-process input-queue attachment let GetActiveWindow return the other acdream process's HWND; GLFW's shared L"GLFW" property then returned the other process's private _GLFWwindow*, which the caller dereferenced. app-release24 installs the current-process HWND guard at GLFW's own import slot before glfwInit; its four focused tests pass. Two rebuilt graphical clients then entered world, survived 100 rapid forced activation switches—the exact old trigger—and remained responsive through a 30-minute combined soak with no native error. Issue #451 remains in-progress only until both sessions complete a graceful-exit gate.

The secondary-owned fellowship gate also passed: +Acdream created mosstankgate, +Horan joined, both canonical rosters contained both members, and the secondary evaluated getfellowshipcount[] as 2.

Still owed here: the hostile combat matrix and collision-marker appearance.

Final local validation checkpoint 2026-08-27: the complete Release solution build passed with zero warnings and zero errors. Focused MossTank passed 325/325 and the App plugin/API/UI/GLFW set passed 35/35. The conservative Windows hermetic filter passed 15,083 non-network tests; Core.Net then passed 1,042/1,042 in its isolated lane, for 16,125 passing selected tests. The first max-parallel combined invocation made Core.Net's timing-sensitive two-percent packet-loss soak exhaust its wall-clock headroom; the same case and complete Core.Net lane passed immediately when isolated. No MossTank, plugin API, plugin UI, Runtime-owner, or #451 guard test failed.

Live hostile discovery checkpoint 2026-08-27: the first surrounded-monster gate exposed two coupled compatibility defects. Retail's classic * Lure vulnerability names were absent from the debuff classifier, so an attack-only profile could misclassify Piercing Lure's "piercing damage" description as a direct attack. The classifier now recognizes all seven classic elemental Lure families (while excluding the distinct Lure Blade item spell), and the attack catalog defensively rejects every host-authored debuff. Target evaluation also now ports official dz::a's previous-target tie-break after priority and manual TargetLock: a valid chosen monster remains selected while the character turns, instead of angle rescans alternating between surrounding monsters. The new Lure/attack and target-stability regressions bring the focused MossTank lane to 337/337. Connected re-test remains part of the hostile combat gate.

Requirement-level completion audit (2026-08-27)

Completion is deliberately not claimed while live evidence remains missing. The authoritative requirement/evidence map is:

Objective requirement Current evidence Audit result
Functionally complete VTank behavior MT2MT9 implementation ledger; 337 MossTank behavior/format/expression tests; connected MT1 autocombat acceptance Proven for implemented policy and formats; the combined hostile physical/magic matrix remains live-unproven
Visually verbatim nine-tab VTank surface mosstank.xml contains the exact Options, Profiles, Vitals, Monsters, Items, Consumables, Buffs, Route, Meta order; all nine tabs mounted in app-release22 Proven for shell/tab presence and first comparison; projectile debug-marker appearance remains live-unproven
Every visible control has real behavior 190 interactive controls expose 202 bindings (191 unique); MossTankMarkupContractTests resolves every binding, verifies delegate shape, and rejects handlerless controls; 137/137 advanced options have explicit writable mappings Proven statically and by focused controller tests. WhoYouGonnaCall intentionally stores its value but performs no action because the official VTank source labels it No Function
Generic plugin sidepanel; minimizing must not stop plugins retained PluginSidePanel/window-manager tests plus connected hide/restore gate where the hidden buff pass advanced from 91/97 to 77/97 Proven
Modern acdream plugin APIs over canonical owners additive BCL-only combat, magic, equipment, item, loot, fellowship, enchantment, navigation, object, world-time, login, network, recovery, projectile, selection, storage, command and classifier contracts; 35 focused App/API/UI tests and 16,125 selected Release tests Proven for the graphical live host; older/no-window implementations explicitly report unavailable and never fabricate success
UtilityBelt-compatible expression superset immutable evaluator tests; all 260 audited public names registered; host-action, object, fellowship, time, login/network, UI, persistence, collection and meta tests Proven by catalog and semantic family tests; bidirectional two-client network expressions passed live
Lifecycle, reconnect, multi-client stability same-character reconnect and hidden execution passed; peer expressions and two-member fellowship passed; #451 exact trigger survived 100 focus switches and a 30-minute dual-client soak Proven through soak; #451 cannot close until both current sessions exit gracefully

Open completion gates: (1) hostile physical and offensive-magic behavior against a live target at valid configured range; (2) visible green/red projectile collision markers with ShowCollisionDebug; (3) graceful exit of both current soak clients with no native or managed failure. These are evidence gaps, not redefined-away acceptance criteria.