2 validation provider registry and strict preflight
forgejo-actions edited this page 2026-07-15 12:43:13 +00:00

Validation Provider Registry And Strict Preflight

Purpose

Use this page when adding a validator, changing validation severity, or debugging why strict preflight blocks pack export even though normal editor validation only warns.

Steps

Register the provider, define its input signature, emit a shared validation report, include repair metadata when safe, and decide whether the finding blocks strict preflight. Add tests that cover both normal validation and strict export behavior.

Every provider has a stable aether.validator.* registration ID. The shipped extension manifest claims exactly one owner for every ID. Full validation and strict content gates run the complete native provider registry. The interactive editor instead derives an AuthoringValidatorSelection from enabled extensions and gives that immutable selection to its background authored-workspace job. The provider runner filters before computing signatures or collecting reports, so disabled providers do no background work.

The selected ID set is sorted and deduplicated before it enters the authored-workspace cache key. A change in extension lifecycle therefore rebuilds diagnostics even if scene and catalog signatures are unchanged. The editor first replaces the previous projection with an empty safe workspace, then schedules the new selection; a job captured under an older selection may finish, but cannot install its results after the desired selection changes. Per-provider incremental entries remain available, so re-enabling a provider can reuse its reports when its own version and input signatures still match.

Expected Outputs

Validation should produce stable domains, target references, severities, blocking status, repair ids, source spans, and jump targets. Strict preflight should explain exactly which provider blocked export and which asset needs repair. Editor diagnostics should contain only providers owned by currently enabled extensions, while non-editor gates continue to use the full registry.

Common Mistakes

Do not emit plain strings without target refs. Do not treat every warning as pack-blocking. Do not attach a repair action unless it can be safely previewed. Do not add a validator that cannot be run from content gates. Do not filter reports after running all providers: pass the lifecycle selection into the registry so disabled work is never scheduled. Do not key the authored workspace only by content signatures, because that reuses diagnostics produced under a different extension state.

Recovery Paths

Inspect the provider report, fix the source asset, rerun targeted validation, then rerun bake or pack export. If a strict-only error seems wrong, compare provider input signatures and pack-export asset catalog contracts.