Dependency-Aware Content Health

What This System Is

Content Health turns the existing catalog checks, semantic dependency graph, Scenario Sandbox, Combat Balance Lab, Party Composition Simulator, and Campaign Journey Simulator into one affected-content validation action. It selects registered fixtures reachable from a content-chain root, executes them in a stable order, and emits one report for the editor or CI.

How Authors Use It

Open Simulation & Debug.
Enter a quest, world event, dialogue sequence, or encounter under Content chain root.
Optionally enter comma-separated changed content IDs or asset paths under Changed IDs/files.
Select Validate Affected Content.
Scrub the unified health report or select Copy Health JSON for review and CI artifacts.

The root may be omitted when a changed content ID identifies a valid graph root. Otherwise the graph's deterministic default root is used.

Rules And Invariants

Every plan contains:

the requested and resolved roots;
normalized changed-input hints;
the selected validator kind and target ID;
a reason explaining why each target was scheduled;
a deterministic input fingerprint;
the number of registered targets skipped as unaffected.

The current plan runs game-data catalog loading and dependency validation first. It then selects registered scenario fixtures whose roots are reachable, combat and party fixtures whose encounters are reachable, and campaign journeys that consume any reachable scenario or encounter. A directly referenced changed input may select a fixture even when it is outside the forward-reachable chain.

Fingerprints And Cache

Fingerprints combine authored-workspace lane fingerprints, world-event and enemy catalogs, ability/status/passive catalogs, build and party strategies, encounter mechanics, difficulty and mutator definitions, reward profiles, loot tables, validator identity, target ID, and fixture JSON. Results are cached in a bounded in-process cache. Repeating an unchanged validation reuses deterministic results; any relevant authored input change produces a new fingerprint and reruns the target.

Reports And CI

The unified report distinguishes passes, warnings, and failures and retains per-validator details. Dependency warnings remain non-fatal; catalog load errors, missing planned fixtures, failed scenario assertions, combat regressions, and journey regressions fail the health run.

Run it headlessly with:

cargo run --bin aether-content-health -- --root world_event.slime_infestation
cargo run --bin aether-content-health -- --changed forge_slime_halberd --json

The CLI exits with code 0 for a healthy plan, 1 for validation failures, and 2 for invalid CLI usage or report serialization errors. JSON output is suitable for CI artifacts and external dashboards.

Current Boundaries

Changed asset paths are hints rather than a source-control diff parser. Exact semantic impact comes from graph IDs and fixture references. The cache is process-local and intentionally bounded; persistent cross-process caching can be layered on the same fingerprints later.

Examples

Use cargo run --bin aether-content-health -- --root world_event.slime_infestation after changing a world event chain. Use --changed forge_slime_halberd --json when an item change should rerun only affected catalog, scenario, party, combat, and journey checks.

Validation And Debugging

cargo test -p aether content_health --lib
cargo check -p aether --bin aether-content-health