v0.14.0 Final Design Review

Status: complete and requalified (2026-08-23).

This review is performed after implementation qualification and before release preparation. It does not define language behavior, change release identity, or authorize packaging or publication. The v0.14.0 qualification remains the baseline unless review remediation changes production behavior or architecture, in which case qualification must be run again.

Primary Rule

Each responsibility knows only the contracts supplied by other responsibilities, never their internal implementation.

A Rust trait is not required at every boundary. An immutable program, closed algebraic IR, exact identity, validated snapshot, or typed error is a contract when all of these conditions hold:

• its owning responsibility and meaning are explicit;
• it is complete and immutable before a consumer receives it;
• its invariants are validated by its owner;
• it exposes semantic facts rather than construction artifacts;
• consumers cannot mutate it or recover omitted facts from source text, names, ranges, ordering, or another side channel;
• its internal construction can change without changing consumers that use the same contract.

Making a type pub does not by itself make that type a valid contract. Builders, temporary indexes, partially resolved nodes, mutable pipeline state, and presentation strings are internal unless the review proves otherwise.

Review Scope

The review covers every production crate in development/compiler/Cargo.toml, the authored standard library, compiler test support, and the composition boundaries used by public examples. It evaluates both the vertical compiler pipeline and horizontal services:

SourceProgram
  -> SyntaxProgram
  -> DeclarationProgram
  -> CheckedProgram
  -> TargetProgram
  -> ExecutableProgram
  -> MirProgram
  -> MachineProgram
  -> Arm64Program
  -> MachOImage

Horizontal boundaries include source projection, diagnostics, package resolution and mutation, filesystem overlays, command orchestration, compiler sessions, semantic analysis, LSP protocol projection, installation, formatting, standard semantic roles, and test fixtures.

Boundary Inventory

Each responsibility receives one inventory row containing:

The inventory is complete only when every direct production dependency is justified by at least one input contract. A dependency used only to reach through another owner, recreate a decision, or name an internal helper is a finding.

Audit Questions

Contract purity

• Can the provider change its internal representation without changing a contract-only consumer?
• Does a consumer pattern-match a deliberate closed IR, or an incidental construction shape?
• Does production code import another responsibility's builder, mutable table, recovery scratch state, or syntax helper?
• Is a test helper bypassing a production facade and thereby proving a different composition?

One-way lowering and single authority

• Does a later phase revisit source or an earlier program to reconstruct a decision?
• Are resolution, normalization, dispatch, ownership, provenance, cleanup, specialization, layout, ABI, source selection, and package identity each decided exactly once?
• Does a later phase receive every fact it needs, or infer a missing fact from a spelling, range, arena position, filesystem path, diagnostic message, or standard-library name?
• Can two authorities disagree while local tests still pass?

Completeness, mutation, and failure

• Does the owner freeze and validate a complete output before publication?
• Are authored failures, environment failures, and compiler invariant failures distinct?
• Can an empty value, Option, fallback, stale snapshot, or best-effort branch hide corruption?
• Does one owner control each mutation, transaction, document generation, artifact, and cleanup?
• Are partial source, lock, package, or binary effects impossible on failure?

Determinism and backend closure

• Can package, module, source, declaration, hash insertion, discovery, or traversal order select a semantic or machine result?
• Does code generation consume only machine contracts, without source, syntax, resolver state, standard names, or runtime-name lookup?
• Do layout, ABI, linkage, allocation, frame construction, fixups, and final bytes retain one owner each?

Tooling and standard library

• Do editor adapters perform only protocol and coordinate projection?
• Do all semantic editor features select the same compiler-owned identity and presentation facts?
• Does a failed generation ever reuse a stale successful program or fabricate partial semantics?
• Are built-ins restricted to behavior that cannot be expressed by ordinary source contracts?
• Do authored standard APIs use the ordinary construction, conformance, instance, coercion, operator, ownership, provenance, and primitive-role mechanisms?

Cost and maintainability

• Are complete programs, source graphs, or type stores cloned or rebuilt unnecessarily?
• Do hot paths repeat global scans, normalization, specialization, or standard-library checking?
• Do tests duplicate assertions without protecting a distinct contract or boundary?
• Do temporary build, package, formatter, test, and editor artifacts have bounded ownership and cleanup?

Finding Classes

• Release blocker: observable miscompilation, specification disagreement, unsafe external-input handling, non-atomic public effect, or a boundary that can produce contradictory accepted output.
• Architectural debt: duplicate authority, reverse dependency, leaked internal representation, or a contract omission that forces another responsibility to reconstruct facts.
• Robustness defect: order dependence, hidden fallback, incomplete validation, stale state, ambiguous error ownership, or unclosed failure cleanup.
• Maintenance issue: unjustified public API, avoidable coupling, repeated expensive work, redundant tests, misleading naming, or documentation that obscures the actual owner.

Every finding must cite a concrete producer, consumer, leaked fact, and failure mode. A preference without such evidence is not a finding.

Work Order

1. 1. Freeze these criteria before inspecting implementation details for findings.
2. Build the complete responsibility and direct-dependency inventory without modifying production code.
3. Audit each pipeline and horizontal boundary, recording findings but applying no local fixes.
4. Group findings by root cause and design complete authority replacements, deletion sets, migration order, and conformance evidence.
5. Ask for a user decision only when the specification permits materially different observable behavior or two boundary designs impose materially different long-term language constraints.
6. Implement one coherent responsibility replacement at a time; delete the superseded path in the same change.
7. Perform an adversarial second review that assumes the first review missed duplicate and fallback paths.
8. Repeat incremental and external-target clean qualification before release preparation.

Completion Gate

The review completes only when every production dependency has a contract justification, every finding is resolved or explicitly accepted by the user, every superseded authority is deleted, and the second review finds no remaining instance of internal-representation knowledge crossing a responsibility boundary. Passing tests alone cannot close this review.

Adversarial Second Review

The second review repeated the dependency and reach-through search after all first-pass findings were fixed. It treated convenience imports, test composition, optional recovery, and public getters as potential alternate authority paths rather than assuming the first inventory was complete.

The review established these concrete boundaries:

• machine has no production dependency on target program and cannot recover an executable or checked program from MIR;
• executable target storage is unavailable outside target-program production code; MIR receives only named semantic queries, then consumes the executable into the closed runtime environment;
• runtime representation tables have no mutation API after construction;
• declaration, compile-input, runtime, and model contracts are imported from their actual owners, including in shared fixtures;
• target, MIR, machine, and ARM64 production code contain no source-path lookup for semantic roles;
• editor-only incomplete-syntax recovery remains explicitly optional and cannot produce a checked target, while production compilation continues to return typed failures.

The second review found one additional maintenance issue, F6, and removed it. No unresolved contract, duplicate-authority, fallback, determinism, or backend-closure finding remains. The incremental and external-target clean qualification matrix then passed in full; the exact evidence is recorded in the implementation qualification.

Review Records

• Boundary inventory
• Findings and remediation order