Conformance evidence policy

import SpecPageHeader from '@beskid/beskid-ui/platform-spec/SpecPageHeader.astro';

<SpecPageHeader status="Standard" ownerName="Piotr Mikstacki" ownerEmail="pmikstacki@cybernomad.it" submitterName="Piotr Mikstacki" submitterEmail="pmikstacki@cybernomad.it" />

This feature hub defines the normative contract for conformance evidence policy and links newcomer-oriented reference articles.

Implementation anchors

• compiler/crates/beskid_tests/src/analysis/diagnostics.rs provides semantic conformance evidence.
• compiler/crates/beskid_tests/src/doc_tests.rs validates docs-facing conformance examples.
• compiler/crates/beskid_e2e_tests/src/tests/runtime_cases.rs provides executable behavior evidence.

Compiler mods evidence (required when feature ships)

Conformance for Mod projects must include, at minimum:

1. Manifest goldens — Valid and invalid Project.proj / Workspace.proj pairs with stable diagnostic codes for type = Mod, mod settings, and capability violations.
2. Pipeline ordering — A test PipelineObserver recording parse, mod.load, mod.collect, mod.generate, semantic gate, mod.analyze, mod.rewrite, and lowering in documented order.
3. Incremental replay — Fixtures performing edits with identical keys that assert stable generator outputs.
4. Analyzer coverage — Fixtures showing analyzers run over host and generated code.
5. LSP parity — Snapshot tests ensuring mod diagnostics round-trip through beskid_lsp with the same codes as CLI analysis.

Fixture layout for manifest/mod work must follow names documented in Project manifest contract / verification.

Decisions

No open decisions. Closed choices are normative ADRs under adr/ (D-COMP-CONF-0001 … D-COMP-CONF-0003); use the reader ADRs tab for expandable detail.

• Design model
• Flow and algorithm
• Contracts and edge cases
• Examples
• Verification and traceability
• FAQ and troubleshooting