Specification

The spec remains important, but in the current repo it should be read as one layer of truth rather than the whole truth. Comprehensive docs need to explain how to use the spec together with artifacts, tests, and source layout instead of treating it as a complete description of present-tense behavior.

How to use the spec correctly

• Use the spec to understand the intended language model and terminology.
• Use souc check, fixtures, and status artifacts to understand what the currently recommended artifact actually enforces.
• Use source directories such as self-hosted/check/, self-hosted/parser/, and self-hosted/native/ to understand how implementation work is structured today.

What the spec is especially good for

• Cross-cutting concepts such as effects, epistemic types, units, and refinements.
• Long-range design intent that spans more than one backend or subsystem.
• Vocabulary and formal framing that help make sense of the more implementation-focused repo docs.

What the spec does not replace

• Current artifact status from souc info.
• Fixture-backed proof from tests/run-pass/, tests/compile-fail/, and tests/stdlib/.
• Machine-readable status artifacts under artifacts/stdlib/.