Level-up saved a feat without its hit points: numbers reviewer does not re-check features' declared facts (Kira trial 3)

[MoonlightByte]

Observed (Kira NPC level-up proof, trial 3, 2026-09-16, real OpenAI, headless)

Scout Kira (Rogue 3 -> 4, Outlander background) was saved with the Tough feat on her sheet and a maximum of 38 hit points. Tough adds 2 hit points per character level, so the saved maximum should have been 46. The sheet on disk is internally inconsistent.

How it got there:

1. The features author (T115) granted Tough as the "restored Outlander Origin feat" and declared it as a rule fact for downstream domains. (Whether a level-up should back-fill a background feat at all is a separate question; owner ruling 2026-09-16 is to leave that behaviour as it runs today.)
2. The numbers author (T119) saw Tough in its packet and included the +8 in its first two drafts, both rejected by the numbers reviewer (T120) for an unrelated proficiency-bonus error (it used +3 at level 4). While fixing that, the third draft dropped the Tough contribution: maximum 38.
3. T120 approved the third draft without noticing the feat was no longer reflected in the hit points.
4. The write committed. Only the report-stage validator (T048) caught it: "Because Tough was saved and increases hit point maximum by 2 per character level, the observed result should include 8 additional hit points at level 4 (maximum 46)". By then the sheet was already saved; the report merely described the discrepancy.

Trial 1 of the same battery granted the same feat and did apply the hit points (32 -> 46). Trial 2 granted no feat. Brim (Outlander, #413 run) got no feat.

Why it matters

A cross-domain fact (a feat with a numeric effect) can be authored by one specialist and silently not applied by the other, and the reviewer of the second domain does not re-check the first domain's declared facts against the numbers. The pre-write review is the last line before the atomic commit; the post-write report cannot undo it.

Possible directions (for later; not started)

• Numbers reviewer: require every declared feat/feature fact with a numeric effect to appear as an operand in the numbers proposal (rejection names the missing fact).
• Or a code-side assembly check that a granted feat with a known fixed HP formula is reflected in maxHitPoints before commit (values compared, not prose).

Evidence: scratchpad capture-kira-3/T115.json, T119.json (3 records), T120.json, T048.json record 2; saved sheet game-kira-3/characters/scout_kira.json (session bdde1eb1).

[MoonlightByte]

Two more instances from the same Kira battery (trials 4 and 5, 2026-09-16, real OpenAI, headless), same class of defect: the numbers domain saved a sheet that does not follow from its own inputs, and the numbers reviewer approved it.

	Trial 4	Trial 5
Dexterity	17 -> 19 (+2 ASI)	17 -> 19 (+2 ASI)
Shortbow attack bonus	stayed +6 (should be +7)	stayed +6 (should be +7)
Initiative	stayed 4 (should be 5)	stayed 4 (should be 5)
Feats	Tough added	Tough added
Max HP	46 (32 + 6 fixed + 8 Tough, consistent)	40 (neither 38 nor 46; inconsistent)
Damage bonus, Stealth, Perception, passive Perception	updated correctly	updated correctly

Trial 1 of the same battery (Dexterity 17 -> 18) did update the attack bonus to +7 and initiative to 5, so the recalculation is known to the author; it is skipped inconsistently and the reviewer does not re-derive dependent fields from the ability change. Trial 5's report narration even states "The saved shortbow attack bonus remains +6" as if that were correct.

Evidence: scratchpad game-kira-4/characters/scout_kira.json, game-kira-5/characters/scout_kira.json, capture-kira-4/T119.json, capture-kira-5/T119.json and the matching T120.json (session bdde1eb1).