Polish combat scene validation

docs/internal/dnd.md

@@ -142,10 +142,55 @@ guidance. It does not assess titles, summaries, non-combat subtype, or scene
 boundaries; deferred boundary-coherence review remains separate. It is opt-in;
 [Configuration](../config.md) owns selection and retry/failure behavior.
 
-Before proposing default-chain inclusion, run a deliberate provider evaluation
-against the synthetic corpus and record false acceptance, false rejection,
-producer-correction success, added calls, latency, and token use. Default tests
-remain offline and do not measure provider quality.
+### Combat-semantics provider evaluation
+
+The human-reviewed corpus at
+`internal/modules/dnd/validate/scenedescriptions/combat_semantics/testdata/evaluation_cases.json`
+owns the proposed kind, expected verdict, and reviewer rationale for each
+synthetic case. Its package test validates the fixture contract only. Provider
+evaluation remains an explicit maintainer operation and must not be added to
+the default offline test suite.
+
+Use the following protocol before proposing default-chain inclusion:
+
+1. Record the Notarius commit, prompt and schema fingerprints, provider, model,
+   profile settings, reasoning effort, structural-repair setting, number of
+   repetitions, and evaluation date before collecting results. Do not revise
+   expected verdicts merely to agree with provider output; a substantive corpus
+   correction requires independent human review.
+2. Exercise the production validator construction and prompt assets from an
+   explicitly invoked, disposable evaluation driver or test in the validator
+   package. For each corpus case, construct transcript source units from the
+   listed IDs and text, assign matching per-unit source references, and use
+   `source.MaterializeChunkPlan` with one range spanning those units. Construct
+   exactly one scene whose ID and source range match that chunk and whose kind
+   is the case's `proposed_kind`; title and summary may use fixed placeholders
+   because the validator neither receives nor evaluates them. Invoke the typed
+   validator at extract stage through the production registry and scheduled LLM
+   client. Do not commit provider credentials, generated source material, or an
+   always-on live test.
+3. Compare the resulting approval or reason code with `expected_verdict`.
+   Record an unexpected approval of an expected rejection as a false
+   acceptance, an unexpected rejection of an expected approval as a false
+   rejection, the opposite rejection direction separately, and any validator
+   execution failure separately from semantic accuracy. Retain per-case results
+   so repeated trials and systematic failure modes remain visible.
+4. Evaluate producer correction separately with representative complete
+   scene-description runs configured as shown in
+   [Configuration](../config.md#production-validator-keys-and-default-chains).
+   For every initial semantic rejection, record whether the next producer
+   attempt returns the requested combat status and is approved. Do not count a
+   PromptKit structural repair as a producer-correction attempt.
+5. Run the correction evaluation with debug capture enabled and without reused
+   extraction checkpoints. Record added validator and producer calls, elapsed
+   latency, and cumulative prompt, completion, cached, and total token usage
+   from the debug attempt records. Compare these values with an otherwise
+   identical run whose scene-description chain omits the semantic validator.
+
+The default-chain review must consider false acceptance, false rejection,
+wrong-direction rejection, execution failure, producer-correction success,
+added calls, latency, and token use together. A structurally successful
+provider run alone is not evidence that the validator should become a default.
 
 Every D&D rejection describes the correction in transcript-grounded domain
 terms, using contextual names, artifact fields, and source segment ranges when