5.7 KiB
BUG-000021: field-confirmed visibility mechanism and analysis review
Date: 2026-10-25. Evidence: final revision-2 generation-123 case package reviewed previously, followed by operator-supplied SQL outputs, screenshots and in-game experiments. No model calls, DB writes or code changes were executed by the assistant for this review. The earlier completion and usage reports remain unchanged.
Confirmed operator experiments
- Furien exists as creature 35286, spawn 367807. GM visibility and NPC inspection confirmed the original live spawn.
- The original PhaseId is 169. The inspected Vcore source defines DEFAULT_PHASE as 169; InitDbPhaseShift treats it as Unphased. Both the NPC and the player's reported ordinary phase state had Flags 8. This contradicts the automatic diagnosis's unverified premise that 169 is a nondefault inaccessible phase.
- creature_addon is empty for this spawn. creature_template_addon has StandState 7 and aura 49414; the live aura list identifies Generic Quest Invisibility 1, aura type 18.
- Removing 49414 from the NPC makes him visible without GM mode. Keeping the original NPC aura and adding detection aura 49416 to the player also makes him visible.
- There was no matching spell_area rule for area 405/2404 or the Horde breadcrumb quest. Existing uses of 49416 were confined to other area/quest conditions.
- Operator inserted spell_area (spell=49416, area=405, quest_start=0, quest_end=0, aura_spell=0, racemask=946, gender=2, flags=3, quest_start_status=0, quest_end_status=0), reloaded spell_area, removed the manually applied player aura and left/reentered Desolace. Operator reports automatic Horde visibility, and invisibility to an Alliance character.
- This supports the proposed zone-wide Horde detection rule for the tested scenario. Original retail conditions, all quest-progress states, aura removal on exit and the entire downstream quest chain were not all separately reported as tested. It is not proof that this is the only correct rule.
- Jankie (36410) and mount templates have no static creature rows; an Alliance field test did not find her even in GM mode. No fix applied. This is reserved for a subsequent independent BugAnalysis field test.
What BugAnalysis did correctly
Intake, project binding, read-only DB tools, actor-audited technical release, bounded name-assessment repair, case continuation, early diagnosis and differentiated coding/human handoff worked. Furien's identity and existing spawn were found correctly. H1 missing-spawn was rejected using actual complete query evidence. H2 appropriately included visibility as a candidate mechanism. Placeholders and human verification prevented a fabricated target PhaseId from becoming an executable hardcoded instruction.
What failed
The automatic workflow never identified the invisibility aura. Original archive members include an empty creature_addon result but no direct creature_template_addon result for 35286. Numeric 49414 strings exist in historical SQL-reference ID lists; these are not captured evidence of Furien's aura. The relationship tool projects template/script, spawn and event-link information, not template addon/auras or effective visibility. This is a coverage gap, not a reason to treat omitted fields as absent; the read-only DB tool could retrieve them.
The H2 initial brief labels the mere existence of phase-related schema columns as supporting causal evidence. Later the model explicitly calls PhaseId 169 nondefault without checking its core semantics. The next brief presents exclusion of the test player as a fact although no phase-membership measurement was obtained. The root-cause claim thus grew from a real column value through an unverified interpretation into an alleged runtime observation.
Early review used the same spawn records to reject H1 and countercheck H2. Showing that a spawn exists is not a discriminating test of whether phase state or a separate invisibility aura hides it. Neither the source DEFAULT_PHASE definition nor the target's aura state was examined. Final diagnosis repeated the unsupported player-phase assertion and accepted the early conclusion. Contract-valid evidence references establish provenance of the row, not entailment of every causal clause attached to it.
The coding request correctly uses {{TARGET_PHASE_ID}}, but already mandates changing the NPC phase and prohibits changes to other spawn fields. The human task asks which phase is intended; it does not adequately question the unsupported repair mechanism itself. A placeholder does not repair an incorrect causal diagnosis.
Generalizable improvement candidates, not implemented here
Distinguish captured values, interpreted mechanisms and unverified runtime prerequisites; do not promote schema-only results to causal support. Verify numeric field semantics in the actual source before classifying values as abnormal. Expand visibility research to relevant effective addon/aura sources, keeping spawn-specific versus template precedence explicit. Require a countercheck that probes the selected mechanism rather than only eliminating another hypothesis. Have final review test causal prerequisites and allow a focused tool/human follow-up when they are missing. Review whether the chosen intervention follows from the evidence, separately from whether parameters are known. These measures do not require excluding every alternative, exhausting budgets or disabling early completion.
The run is an infrastructure success and a useful partially correct investigation, but not a successful automatic root-cause diagnosis or repair recommendation. The visibility fix was derived by subsequent human-guided investigation. No claim is made that a single example establishes overall accuracy or that the system should memorize Furien/169/49416 as a special case.