Nocter v0.3.0 Release Record

Purpose

v0.3.0 makes allocation convenient by default without weakening Nocter's ownership guarantees. The release builds typed literals, sequence construction, and productive standard-library APIs on a compiler-owned region and provenance model rather than on a process-global allocator or syntax-specific exceptions.

Development is divided into ordered phases. Phase 0: Region and Allocation Context, Phase 1: Typed Literal Core, Phase 2: Explicit Iteration and Collection Access, and Phase 3: Owned String Interpolation and Formatting, Phase 4: Public Provenance Contracts and Generic Interface Bounds, Phase 5: Nested Outcomes and Executable Process Context, and Phase 6: First-Class Outcome Values, Phase 7: Protocol-Driven Collection Iteration, and Phase 8: Explicit Sequence Spread and Composable Element Packs, Phase 9: Composable Iterators and Collection Builders, and Phase 10: Callable Values and Interface Default Methods, v0.3.0 Stabilization, body-bearing impl Interface for Type { ... } declarations, and type-owned construction surfaces are complete. The previously qualified structural-conformance source tree is retained only as a historical checkpoint.

The released baseline is v0.3.0 on arm64-darwin. The previous release remains recorded in v0.2.0. Public language rules live in the specification, and the user-visible summary lives in the v0.3.0 release notes.

Completed Gate: v0.3.0 Stabilization

Stabilization freezes the v0.3.0 feature set and proves that the completed phase contracts form one coherent release. Work in this gate fixes unsoundness, miscompilation, crashes, valid-program rejection, specification drift, editor inconsistency, and structural debt that directly creates those failures. Body-bearing interface implementations are the only admitted language-surface change. Unrelated language features and standard-library expansion remain outside the gate.

The gate is complete only when all of the following are true:

• every source form accepted by typecheck and buildability lowers and validates without exposing IR or backend implementation diagnostics
• optional and fallible outcome identity remains explicit from semantic analysis through IR, cleanup, ABI validation, code generation, stored values, and editor presentation
• ownership, partial initialization, outcome storage, closures, iterators, allocation failure, and every region exit drop each live value exactly once and release each allocation context once
• repository-home and packaged-home execution agree for the completed Phase 0 through Phase 10 acceptance surfaces
• malformed and incomplete source produces source-backed diagnostics or editor recovery rather than a panic, stale identity, or invented semantic fact
• hover, completion, definition, references, signature help, and semantic tokens agree with the same compiler-owned declaration, type, ownership, provenance, and allocation facts
• required interface methods are implemented only by members of the exact impl Interface for Type { ... } declaration; inherent methods never establish or override conformance
• user-facing diagnostics and documentation name exact milestones or capabilities and contain no bare v0 compatibility boundary
• responsibility hotspots have been reviewed; refactoring is required only where mixed ownership, duplicated semantic decisions, or broad suppression can cause correctness drift
• the full verification suite, Clippy, documentation build, distributed runtime tests, and clean release packaging pass from a clean worktree

Requalification Outcome

The previous stabilization pass completed the full compiler verification suite, Clippy with warnings denied, the public documentation build, local distribution build, installed-home doctor, and archive-content inspection. The distributed runtime suite included all 199 Phase 0 through Phase 10 integration cases.

That qualification was reopened before release because structural conformance forced interface implementations into unrelated inherent blocks and gave one method declaration two responsibilities. The replacement contract in Body-Bearing Interface Implementations is implemented and requalified. The full compiler suite, warnings-denied Clippy, generated public documentation, local optimized distribution, installed-home doctor, packaged-home runtime suite, and archive inspection pass.

Release Qualification

The v0.3.0 release preparation updated the Cargo package, installed VERSION, distribution manifest, archive name, CLI/LSP version reporting, public documentation, and release notes as one versioned unit. Qualification passed on 2026-08-05 against that exact metadata:

• 2,161 library tests
• 296 CLI build tests, 6 formatter tests, and 15 LSP protocol tests
• 449 native run tests and 199 distributed-home tests
• 6 example-corpus tests
• formatter and Clippy with warnings denied
• a 50-page public documentation build
• optimized arm64-darwin packaging, installed-home doctor, archive inspection, and packaged compiler check/run smoke tests

The installed compiler reports Nocter 0.3.0, and the qualified archive is nocter-v0.3.0-arm64-darwin.tar.gz with one .nocter/ root. The release commit qualifies the source tree and local artifact; Git tagging and remote publication remain separate release operations.

Stabilization Work Order

1. 1. Replace structural conformance with body-bearing interface implementations and preserve each implementation member's declaration identity through compiler and editor layers.
2. Record the release gate and establish cross-phase acceptance tests that require every buildable checked program to lower and validate.
3. Preserve optional versus fallible outcome layers in IR instead of recovering that distinction from source types during individual lowering paths.
4. Audit ownership, drop, allocation, stored outcomes, closures, iterators, and region cleanup over normal and early exits with native observations.
5. Audit editor queries by binding and declaration kind, including incomplete edits and exact UTF-16 ranges, with paired analysis and JSON-RPC tests.
6. Audit malformed-input resilience, internal-diagnostic leakage, obsolete version wording, dead paths, broad lint suppression, and responsibility hotspots.
7. Run the completed phase matrices against repository and packaged homes, rebuild public documentation, and qualify the release candidate.

Each correction starts with a reproducer or invariant test. Structural refactoring and behavior promotion remain separate commits when practical. Passing unit tests alone does not close a gate whose contract requires native, packaged, or protocol-visible behavior.

Stabilization Priorities

• P0: unsoundness, miscompilation, double drop, missing cleanup, use-after-move, compiler panic
• P1: valid-program rejection, invalid-program acceptance, specification mismatch, wrong editor identity or type
• P2: semantic conflation, duplicated phase decisions, or mixed responsibilities that are a direct source of P0 or P1 failures
• P3: diagnostic wording, formatting, and non-blocking presentation polish

Stabilization Non-goals

• new syntax other than body-bearing interface implementations, new interfaces, collection families, allocator policies, or native targets
• compatibility shims for unpublished behavior or removed repository layouts
• mechanical file splitting, blanket unwrap removal, or abstraction changes without a concrete invariant they protect
• source-level lifetime parameters, runtime interface dispatch, async execution, or concurrency

Phase 0 Outcome

Phase 0 is complete when the compiler and distributed standard library provide one coherent model for lexical regions, borrow origins, allocator origins, allocation failure policy, and cleanup.

At the gate, all of the following are true:

• ordinary allocating operations use a statically propagated current allocation context
• the root context uses the aborting system allocator and has program lifetime
• TryAllocator provides an explicit recoverable path without duplicating allocation algorithms
• region name using allocator { ... } creates a child allocation region and makes it current for the lexical body
• values, views, allocator capabilities, and aggregates derived from a child region cannot escape it
• returned borrow-like values keep their exact input origins through calls and remain active until their last source-level use
• normal exit, return, break, continue, and ? drop live values before releasing a region
• compiler analysis and LSP expose the same region, allocation-effect, and provenance facts

Phase 0 must not recognize Allocator, TryAllocator, String, Vec, alloc, or method spellings as semantic magic. Trusted declarations and compiler-owned summaries connect ordinary standard- library APIs to allocation effects.

Phase 0 Completion Status

Phase 0 passed its implementation and verification gates on 2026-08-02. The compiler, packaged standard library, native runtime, and LSP now share the model specified below.

• allocation effects propagate the current context through source and trusted call graphs
• owned and borrowed provenance survives moves, helpers, aggregates, optional and fallible channels
• lexical region escape checks reject direct and indirect storage escape
• all supported exiting edges drop live values before releasing the child runtime region
• normal allocation aborts without unwinding; explicit try_* APIs retain recoverable, failure-atomic behavior over the shared core
• native tests observe region-backed mappings while live and their release at region exit
• incomplete region edits retain cursor identity and expose established compiler facts through LSP

There are no required Phase 0 items in development/TODO.md. Git owns the chronological implementation record; this document remains the design and acceptance record.

Allocation Policy

The standard path aborts on allocation failure. It is intended for normal application and library code, where continuing after exhaustion of the process allocator is rarely reliable.

The recoverable path is explicit:

• TryAllocator operations return the built-in error payload
• standard containers expose try_* construction and growth operations
• aborting operations adapt the fallible core and terminate on failure
• RawBuffer, String, and Vec<T> retain backend identity and storage provenance, not duplicated allocator implementations
• out-of-memory termination performs no allocation and does not unwind Nocter scopes

The ambient context accepts only the aborting Allocator capability during Phase 0. A TryAllocator is used through named try_* APIs. This prevents an expression's type from changing between T and T! merely because a different ambient allocator was selected.

Capacity overflow and invalid layout follow the same split: aborting APIs terminate with a stable reason, while try_* APIs return stable std.mem.* errors and preserve the old value.

Region and Provenance Model

The implementation introduces compiler-owned identities and summaries instead of extending the return checker with more special cases.

Storage origins

Every storage-dependent value resolves to one or more origins:

• static: program-lifetime storage and the root allocation context
• scope: stack storage owned by a lexical scope
• input: storage reached through a borrow-like parameter or receiver
• region: storage allocated through a lexical region context
• unknown: storage for which safe escape cannot be proved

The representation is compile-time only and does not alter public pointer or view ABI layouts.

Value provenance

Provenance follows both borrowed and owned storage-dependent values. It is preserved through named fields, fixed-array elements, enum payloads, optionals, fallible success/error channels, aliases, branches, and calls. A pure copy value that contains no storage dependency is region-independent.

Callable summaries

Every callable with a storage-dependent result or allocation effect has a compiler-owned summary. A summary records:

• whether a result is static, comes from the receiver, or comes from one or more parameters
• field-, element-, success-, and error-specific origins when those distinctions are known
• whether the callable needs the current allocation context
• which allocator input determines newly owned result storage

Concrete source bodies infer summaries to a fixed point. Trusted bodyless declarations require explicit compiler metadata. An untrusted bodyless declaration whose return origin is ambiguous is rejected.

The same summaries are consumed by return checking, non-lexical borrow checking, region escape checking, lowering, compiler analysis, and LSP presentation.

Source-Language Boundary

Phase 0 implements:

region temp using arena {
    let text = String.copy("temporary")
    consume(text.view())
}

The using operand is an established allocator/context place, not an arbitrary effectful expression. The parent is resolved before the child region is entered. The named region handle is immutable, cannot escape, and identifies the child context for diagnostics and explicit low-level APIs.

No source-level lifetime parameters or Rust-style lifetime annotations are added. Phase 0 uses origin inference and these elision rules:

• a borrow-like result with one borrow-like input is tied to that input
• a method result may be tied to its borrowed receiver when that is the only declared origin
• a concrete body may infer a result tied to multiple inputs; callers then satisfy every required origin
• an ambiguous bodyless declaration is rejected rather than guessed

Typed literals and per-literal using syntax are implemented by the completed Phase 1 gate. They consume the allocation-context and provenance APIs supplied by Phase 0.

Compiler Responsibilities

New responsibilities receive focused modules:

Return validation no longer owns a private provenance model. IR and backend code consume typed facts and do not recover origins from AST or standard-library names.

Completed Work Order

1. 1. Extract the existing borrow-return provenance into a general value-provenance model without changing accepted programs.
2. Give callable summaries stable parameter/receiver identities and use them at call sites.
3. Connect borrow-like call results to NLL so source loans remain active through the result's last use.
4. Add storage-origin constraints, aggregate propagation, lexical outlives relations, and escape diagnostics.
5. Add the allocation-effect summary and statically thread the root allocation context through allocating calls.
6. Implement the shared fallible allocator core, aborting Allocator adapter, TryAllocator, and paired normal/try_* collection operations.
7. Add region AST, resolution, typechecking, and incomplete-source recovery.
8. Lower region entry and every exiting control-flow edge to ordered value cleanup followed by region release.
9. Add the child-region runtime allocator and propagate its identity through RawBuffer, String, Vec<T>, and user aggregates.
10. Expose allocation effect and region identity through compiler analysis and LSP.
11. Pass the Phase 0 acceptance matrix from a packaged Nocter home.

The order remains documented because later phases depend on these boundaries, not as an active checklist.

Acceptance Matrix

Tests must observe runtime release, error identity, exit status, and post-operation state. Backend instruction snapshots alone do not satisfy the gate.

Phase 0 Non-goals

• typed literal declarations or expressions
• sequence spread, rest capture, variadic calls, or struct embedding
• collection for lowering or a general iterator protocol
• source-level lifetime or region parameters
• ambient TryAllocator contexts or a fallible region statement
• runtime allocator interface dispatch or user-defined allocator plugins
• thread-local allocator selection or concurrency semantics
• implicit fallback from an invalid region context to the root allocator
• native targets other than arm64-darwin
• v1 compatibility guarantees

Phase 1: Typed Literal Core

Phase 1 promotes user-defined sequence and string literal definitions, typed literal expressions, literal-owned ephemeral element packs, and explicit per-literal allocation selection:

let values = Vec [1, 2, 3]
let values = Vec [1, 2, 3] using arena

region temp using arena {
    let values = Vec [1, 2, 3]
    let text = String "hello"
}

Sequence spread and iteration follow only after their move, borrow, drain, partial-initialization, and cleanup rules use the Phase 0 provenance model. Workspace indexing and broader LSP refactoring features remain post-v0.3.0 work.

The source definition forms are:

construct Vec<T> {
    pub default literal [](...items: T): Self { ... }
}

construct String {
    pub default literal ""(text: &str): Self { ... }
}

The empty delimiters are shape markers. The construction-surface stabilization now requires each definition to be an explicitly public member of the nominal target's construct declaration. Definitions are keyed by nominal declaration identity and shape, with no overload within a key. ...items: T is a literal-only ephemeral owned pack, not a slice, allocated collection, normal ABI parameter, or general variadic feature. The detailed design belongs to Typed Literal Core.

Phase 1 Outcome

Phase 1 is complete when all of the following are true:

• sequence and string definitions are ordinary same-module declarations with explicit visibility
• expressions resolve definitions by target declaration identity and shape, never standard-library names
• generic sequence element types infer from expected result and element expressions
• literal elements evaluate once from left to right and retain recursive drop obligations
• literal pack iteration consumes each element once and drops every unconsumed element exactly once
• default, lexical-region, and explicit using contexts use the Phase 0 allocation/provenance model
• Vec [..] and String ".." are defined in distributed std without compiler representation access
• parser recovery, formatter, AST JSON, analysis, and LSP understand definitions and expressions
• packaged-home native tests observe content, cleanup, context selection, and region escape behavior

Phase 1 Completion Status

Phase 1 passed its implementation and verification gates on 2026-08-02. The compiler, distributed standard library, packaged home, native runtime, analysis layer, and LSP share the literal model specified below.

• sequence and string definitions resolve by nominal declaration identity and shape
• literal bodies participate in the same allocation-effect and provenance-summary fixed point as functions and methods
• sequence elements use literal-owned ephemeral packs with left-to-right evaluation, consuming iteration, and reverse-order cleanup of every unconsumed element
• default, lexical-region, and explicit using construction preserve Phase 0 context identity
• distributed Vec<T> and String define their literal surfaces in ordinary Nocter source
• editor queries expose specialized hover, signature help, definition, completion, and incomplete-edit recovery from compiler analysis facts
• native packaged-home tests observe ordered content, move-only cleanup, stable allocation-abort status, child-origin escape rejection, and final release of Vec literal storage

There are no required Phase 1 items in development/TODO.md. A later phase must receive its own scope and completion gate before implementation begins.

Completed Phase 1 Work Order

1. 1. Freeze sequence/string shape syntax, pack semantics, diagnostics, and non-goals.
2. Add focused AST, lexer, parser, JSON, formatter, and incomplete-source recovery responsibilities.
3. Add literal declaration identity, same-module attachment, visibility, and shape-key uniqueness.
4. Typecheck target specialization, empty-literal context, string input, pack operations, and established aborting using places.
5. Connect literal results and elements to Phase 0 allocation effects, provenance, ownership, and escape checking.
6. Lower element evaluation, recursive prefix obligations, pack consumption, context override, result publication, and every cleanup edge.
7. Define distributed Vec<T> and String literal bodies over existing public construction APIs.
8. Expose literal definition/expression facts and incomplete-edit recovery through analysis and LSP.
9. Pass the Phase 1 acceptance matrix from a packaged Nocter home.

Phase 1 Acceptance Matrix

Tests must observe native content, drop order, release, allocation failure status, and region escape. Parser snapshots or desugaring-only tests do not satisfy the gate.

Phase 1 Non-goals

• sequence spread expressions such as Vec [...other]
• normal variadic functions or methods
• mapping, named, tuple, numeric, or byte literal definitions
• required leading sequence parameters before a capture
• general collection for or an iterator protocol
• embedding or embedded initializers
• string interpolation lowering
• fallible literals or ambient TryAllocator
• runtime literal dispatch or literal definitions for foreign nominal types
• native targets other than arm64-darwin

Phase 1 Verification Gate

Phase 1 passed all of:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
git diff --check

Focused parser, resolver, typecheck, ownership, IR, native runtime, distributed-home, analysis, formatter, AST JSON, and JSON-RPC tests cover the acceptance matrix. No required Phase 1 item remains in development/TODO.md.

Phase 0 Verification Gate

Phase 0 passed all of:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
git diff --check

Focused parser, resolver, typecheck, IR, native runtime, distributed-home, analysis, and JSON-RPC tests cover the acceptance matrix. No required Phase 0 item remains in development/TODO.md.

Phase 2: Explicit Iteration and Collection Access

Phase 2 makes existing views, Vec<T>, and String useful in ordinary algorithms without adding compiler-recognized iterator names or collection for syntax. The public iterator types and methods are ordinary standard-library declarations. Compiler work is limited to the general borrowed-element projection, ownership, optional-return, generic-specialization, and lowering capabilities those declarations require.

The canonical surface is:

var borrowed = values.iter()
loop {
    let item = borrowed.next() otherwise { break }
    inspect(item)
}

var owned = (move values).into_iter()
loop {
    let item = owned.next() otherwise { break }
    consume(move item)
}

ViewIter<T> retains a readonly view and returns &T?. VecIntoIter<T> owns the vector storage, returns each T in source order exactly once, drops every unconsumed element in reverse order, and releases the storage exactly once.

The detailed implementation design belongs to Explicit Iteration and Collection Access.

Phase 2 Outcome

Phase 2 is complete when all of the following are true:

• ViewIter<T> can be constructed from &[T], Vec<T>, and String byte views without allocation
• every borrow returned by ViewIter.next() retains the source view's exact storage origin
• mutation or move of a source is rejected while a live iterator-derived borrow still requires it
• VecIntoIter<T> consumes a vector in source order and supports copy and move-only elements
• normal exhaustion, early drop, return, break, and ? drop unconsumed owned elements exactly once in reverse order and release storage once
• Vec<T> provides provenance-safe get and get_mut, plus ownership-safe insert and remove
• fallible insertion performs allocation before element shifting and leaves the old vector unchanged when allocation fails
• String exposes byte iteration without claiming Unicode scalar or grapheme semantics
• compiler analysis and LSP expose specialized iterator method signatures, optional result types, receiver capability, and result provenance
• packaged-home native tests observe order, mutation visibility, move-only cleanup, failure state, region escape rejection, and final storage release

Phase 2 Completion Status

Phase 2 passed its implementation and verification gates on 2026-08-02. The distributed standard library now provides allocation-free readonly byte/element cursors, consuming vector cursors, and checked vector access and mutation without compiler-recognized collection names.

• optional element borrows retain their source loan through aliases, control-flow wrappers, and ordinary callable summaries
• consuming iteration transfers the initialized range and raw storage obligation from Vec<T> to VecIntoIter<T> exactly once
• exhaustion and every tested early exit drop only the still-owned suffix in reverse order
• try_insert completes bounds and allocation work before opening a non-fallible transient hole; deterministic growth failure leaves pointer, length, capacity, content, and origin unchanged
• LSP hover, completion, and signature help use specialized compiler facts for readonly and owned iterators; zero-argument incomplete calls recover without iterator-specific parsing
• packaged-home native tests cover scalar and move-only order, exact element addresses, UTF-8 byte order, mutation visibility, region escape, failure atomicity, and cleanup

There are no required Phase 2 items in development/TODO.md. Git owns the chronological implementation record; this document remains the design and acceptance record.

Phase 2 Completed Work Order

1. 1. Correct the released/future iterator specification boundary and freeze API, ownership modes, transient-hole invariants, diagnostics, and non-goals.
2. Promote general borrowed element projection through views, aggregates, optionals, callable summaries, IR, ABI, and backend lowering.
3. Define ViewIter<T> and its constructors and forwarding methods in distributed std.
4. Define VecIntoIter<T>, ownership transfer from Vec<T>, ordered extraction, remaining-range cleanup, and single storage release.
5. Add Vec<T>.get, get_mut, insert, try_insert, and remove over checked bounds and the initialized-prefix model.
6. Expose iterator facts through analysis and LSP hover, completion, signature help, diagnostics, and incomplete member/call recovery.
7. Pass the Phase 2 acceptance matrix from a packaged Nocter home.

Phase 2 Acceptance Matrix

Tests must observe native order, drop order, release, failure identity, post-operation state, and region escape. Type labels or backend instruction snapshots alone do not satisfy the gate.

Phase 2 Non-goals

• for item in collection syntax or compiler lowering by iter/next spelling
• a general Iterator interface, generic bounds, adapters such as map, or dynamic dispatch
• mutable slice iteration, reverse iteration, or custom stepping
• sequence spread, normal variadic functions, or required literal parameters
• Unicode scalar, grapheme, normalization, or character indexing APIs
• string interpolation lowering, filesystem expansion, or path types
• workspace rename, code actions, formatting requests, inlay hints, or package indexing
• native targets other than arm64-darwin

Phase 2 Verification Gate

Phase 2 passed all of:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
git diff --check

Focused provenance, ownership, optional-return, generic method, IR, native runtime, distributed-home, analysis, and JSON-RPC tests cover the acceptance matrix. No required Phase 2 item remains in development/TODO.md.

Phase 3: Owned String Interpolation and Formatting

Phase 3 promotes interpolated strings from check-only syntax to buildable owned String values. It completes the ordinary aborting formatting surface, preserves allocation-context provenance, and connects parser, typecheck, ownership, IR, native execution, analysis, and LSP through one validated runtime capability. The detailed implementation design belongs to Owned String Interpolation and Formatting.

Phase 3 Outcome

Phase 3 is complete when all of the following are true:

• an interpolated string has type String, not String!, and a bare string literal remains &str
• interpolation obtains storage from the current aborting allocation context and carries its exact result provenance
• trusted runtime declarations are validated by module, declaration identity, and complete shape; lowering does not recognize public names
• decoded text, &str, borrowed or temporary String, bool, and the executable scalar integer types i32, u8, and usize format through ordinary standard-library operations
• text and expressions evaluate once in source order, and an existing owned String is not consumed
• partial results and expression temporaries drop exactly once on every recoverable exiting edge
• std/fmt exposes paired normal and try_* operations over one fallible implementation core
• region-backed interpolation cannot escape its lexical region directly or indirectly
• analysis and LSP expose the owned result, allocation effect, provenance, diagnostics, and stable incomplete-expression behavior
• packaged-home native tests observe content, boundary integer formatting, order, cleanup, allocation context, and region release

Phase 3 Work Order

1. 1. Freeze public formatting policy, runtime capability shape, evaluation modes, diagnostics, cleanup, LSP behavior, and non-goals.
2. Add an atomic trusted interpolation runtime capability keyed by validated declaration identity.
3. Rebuild std/fmt around paired aborting and recoverable operations covering i32, u8, and usize.
4. Produce interpolation semantic plans with result type, allocation effect, provenance, append target, input type, and evaluation mode.
5. Lower construction, ordered append, expression temporaries, result publication, and every recoverable cleanup edge through the semantic plan.
6. Expose interpolation facts and incomplete-edit recovery through analysis and LSP.
7. Pass the Phase 3 acceptance matrix from a packaged Nocter home.

All seven items are complete. The compiler validates the trusted runtime bundle before typecheck, typecheck emits a semantic interpolation plan, IR consumes only that plan, and editor queries use the dedicated analysis/interpolation boundary. The distributed standard library supplies paired aborting and recoverable formatting operations over one checked core.

Phase 3 Acceptance Matrix

Tests must observe native bytes, side-effect order, storage origin, drop/release behavior, and exit status. Type labels or IR snapshots alone do not satisfy the gate.

Phase 3 Non-goals

• user-defined formatting interfaces, implicit conversion, or to_string lookup
• width, precision, radix, locale, debug, or custom formatting options
• optional, fallible, collection, pointer, enum, or arbitrary nominal formatting
• recoverable interpolation syntax or ambient TryAllocator
• sequence spread, normal variadic functions, collection for, or iterator adapters
• Unicode scalar, grapheme, normalization, or character indexing APIs
• filesystem expansion, path types, or environment retrieval
• native targets other than arm64-darwin

Phase 3 Verification Gate

Phase 3 passed:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
git diff --check

Focused lexer/parser, runtime-capability, typecheck, allocation, provenance, ownership, IR, native runtime, distributed-home, analysis, and JSON-RPC tests cover the acceptance matrix. Packaged-home execution verifies the repository and distributed standard library together. No required Phase 3 item remains in development/TODO.md.

Phase 4: Public Provenance Contracts and Generic Interface Bounds

Phase 4 turns compiler-inferred result provenance into an explicit contract where implementation inference is unavailable or an API author wants to stabilize the relationship. It then permits a generic parameter bound by an interface to call that interface's methods through deterministic static specialization. The detailed design belongs to Public Provenance Contracts and Generic Interface Bounds.

The canonical surface is:

pub interface Lookup<K, V> {
    pub method &self.get(key: &K): &V? from self
}

func find<M: Lookup<K, V>, K, V>(map: &M, key: &K): &V? from map {
    return map.get(key)
}

from names storage origins, not lifetimes. Origin names resolve to receiver and parameter declaration identities. A concrete body is checked against its declared contract. A bodyless interface method uses the contract as its callable provenance summary. Allocation effects remain compiler-inferred and have no Phase 4 source annotation.

Phase 4 Outcome

Phase 4 is complete when all of the following are true:

• callable signatures accept from self, from parameter, from left | right, from static, and from current
• origin names resolve by declaration identity and produce source-backed duplicate, unknown, ineligible-origin, and contract-mismatch diagnostics
• a concrete body may be more independent than its contract but cannot return storage outside the declared origin set
• an ambiguous bodyless interface method with a storage-dependent result requires a from clause
• from current contributes the current allocation-context origin and therefore implies the existing inferred allocation effect; no separate effect syntax is introduced
• generic bounds use T: Interface<...> and validate interface kind, arity, visibility, duplicate parameters, and bound cycles
• a method call on a generic receiver searches only its declared interface bound and reports deterministic missing or ambiguous candidates
• explicit conformance remains required, and each concrete specialization resolves to a matching conformance member without dynamic dispatch
• provenance, ownership, buildability, IR lowering, and allocation-context propagation consume the resolved bound-call fact rather than recognizing interface or method names
• formatter, AST JSON, hover, completion, signature help, definition, references, semantic tokens, and incomplete-source recovery share compiler-owned bound and provenance facts
• a small distributed standard-library interface proves readonly borrowed-result abstraction from repository and packaged Nocter homes

Phase 4 Work Order

1. 1. Freeze clause grammar, origin eligibility, contract variance, bound lookup, static dispatch, diagnostics, editor behavior, and non-goals.
2. Add dedicated AST and resolver models for provenance contracts and generic bounds.
3. Seed callable summaries from bodyless contracts and validate concrete inferred summaries.
4. Resolve bound methods on generic receivers and record the interface declaration target.
5. Re-specialize bound calls through explicit concrete conformance for buildability and lowering.
6. Connect ownership, allocation propagation, formatter, AST JSON, and analysis/LSP facts.
7. Add the standard-library proof interface and pass the packaged-home acceptance matrix.

All seven items are complete. Source clauses resolve to declaration identities before summary validation, generic calls resolve against one canonical interface contract, and reachable concrete specializations lower to public inherent implementations without a runtime dispatch layer. Import qualification preserves generic bounds and explicit conformance across module boundaries.

Phase 4 Completion Status

Phase 4 passed its implementation and verification gates on 2026-08-03.

• from clauses are represented independently in the AST, resolver, semantic contracts, formatter, and JSON output
• concrete bodies validate declared upper bounds while bodyless interface methods seed callable summaries from explicit contracts
• bound calls retain interface declaration identity for analysis and are redirected to a unique concrete implementation only after specialization
• ownership, allocation propagation, buildability, and IR consume the same bound-call and provenance facts
• hover, completion, signature help, definition, references, semantic tokens, and incomplete-edit recovery use compiler analysis rather than protocol-side parsing
• distributed std/sequence.Sequence<T> and first prove readonly result provenance through Vec<T> from both repository and packaged homes
• native execution observes the specialized Vec<T>.get result, and JSON-RPC tests verify exact hover and definition ranges

There are no required Phase 4 items in development/TODO.md. A later phase must be explicitly adopted before additional v0.3.0 feature work begins.

Phase 4 Acceptance Matrix

Tests must observe source-loan retention, region escape, concrete dispatch, native result behavior, drop/release behavior, and JSON-RPC source ranges. Type labels or IR snapshots alone do not satisfy the gate.

Phase 4 Non-goals

• Rust-style lifetime names or source-level region parameters
• region-parameterized stored types or higher-ranked relationships
• dynamic interface objects or runtime dispatch
• associated types, default methods, interface inheritance, blanket impls, or specialization
• multiple bounds on one parameter, where clauses, or negative bounds
• collection for, a general iterator protocol, iterator adapters, or closures
• explicit allocation-effect syntax or a general effect system
• separate-compilation or stable public ABI guarantees
• native targets other than arm64-darwin

Phase 4 Verification Gate

Phase 4 passed:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
git diff --check

Focused parser, resolver, provenance, interface-bound call, ownership, buildability, IR, native, distributed-home, formatter, AST JSON, analysis, and JSON-RPC tests cover the acceptance matrix.

Phase 5: Nested Outcomes and Executable Process Context

Status: complete.

Phase 5 removes the remaining check-only process API by making composed optional/fallible callable results executable through a general outcome boundary. It then aligns std/process with the ambient allocation policy established by Phase 0. The detailed compiler and runtime design belongs to Nested Outcomes and Executable Process Context.

The target public surface is:

pub func args(): Vec<&str>! from current | static
pub func env(name: &str): &str?! from static
pub func cwd(): String! from current
pub func try_cwd(allocator: &+TryAllocator): String! from allocator

The callable ABI models each optional and fallible layer independently. A successful present value, successful absence, and failure are distinct outcomes; the compiler must not infer those states from a standard-library module or declaration name. Immediate ?, otherwise, catch, and return lowering consume this shared model.

Phase 5 Outcome

Phase 5 is complete when all of the following are true:

• resolved callable return shapes retain ordered optional and fallible layers instead of collapsing both constructors into one failure bit
• native lowering distinguishes present success, successful absence, and failure for T?!, with the same machinery available to ordinary user functions, methods, associated functions, and generic specializations
• ?, otherwise, catch, explicit return, and scope cleanup compose without losing a channel or dropping an acquired value more than once
• result provenance remains path-sensitive through the present payload, absence, and error channel
• std/process.env executes on arm64-darwin, returns none for an absent name, returns a process-lifetime UTF-8 view for a present name, and returns std.process.invalid_encoding for an invalid name or value
• std/process.cwd() uses the current aborting allocation context while try_cwd retains explicit recoverable allocation and stable OS/encoding error identities
• every buildability exception that identifies std/process.env by module or declaration spelling is removed
• compiler analysis and LSP present the normalized nested result and exact from contract without protocol-side reconstruction
• repository-home and packaged-home tests observe the same process behavior and native ABI

Phase 5 Work Order

1. 1. Freeze the recursive outcome shape, ABI word order, propagation, cleanup, provenance, process storage, diagnostics, editor behavior, and non-goals.
2. Add a dedicated compiler outcome model shared by buildability, IR lowering, and backend ABI classification.
3. Lower composed callable returns and immediate consumers through explicit outer-failure and inner-absence branches.
4. Preserve cleanup obligations and path-specific provenance across every composed outcome edge.
5. Expose target process environment entries through a narrow trusted primitive and implement env in ordinary standard-library source.
6. Split cwd into ambient aborting and explicit recoverable allocation surfaces over one fallible implementation core.
7. Remove the check-only exception, integrate analysis/LSP, and pass repository plus packaged-home acceptance tests.

Phase 5 Acceptance Matrix

Tests must observe native exit status, bytes, error identity, branch selection, cleanup order, and storage lifetime. Type labels, check-only acceptance, or IR snapshots alone do not satisfy the gate.

The completed implementation exercises all three T?! leaves, propagation followed by optional fallback, failure-only catch, exact-once cleanup, and specialized method dispatch through the same structural call instruction. Packaged-home tests execute argument, environment, ambient cwd, and recoverable cwd APIs. Provenance tests reject an ambient cwd result escaping its active region, and JSON-RPC tests consume the compiler-normalized nested return and from static contract.

Phase 5 Non-goals

• storing arbitrary optional or fallible values in first-class local or aggregate slots
• unbounded recursive outcome nesting beyond the adopted optional/fallible composition surface
• a user-visible Result or Option nominal type
• multiple interface bounds, where clauses, associated types, or dynamic dispatch
• generalized ... spread, ordinary variadic callables, or struct embedding
• package manifests, workspace indexing, rename, code actions, or formatting requests
• process-environment mutation or owned environment snapshots
• native targets other than arm64-darwin

Phase 5 Verification Gate

Phase 5 must pass:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
cargo clippy --manifest-path development/compiler/Cargo.toml --all-targets -- -D warnings
node docs/build-docs.js
git diff --check

Focused outcome-shape, buildability, IR, backend, ownership, provenance, process-runtime, packaged- home, analysis, and JSON-RPC tests must cover the acceptance matrix.

Phase 6: First-Class Outcome Values

Status: complete.

Phase 6 promotes the executable outcome channels completed in Phase 5 into ordinary stored values. The detailed compiler design belongs to First-Class Outcome Values.

Phase 6 Outcome

Phase 6 is complete when all of the following are true:

• T?, T!, T?!, and T!? values may be bound, moved, copied when eligible, assigned, passed, returned, and stored in every supported sized aggregate or fixed-array position
• one compiler-owned storage layout derives recursive tag, union, payload, and error offsets from the existing normalized OutcomeShape
• callable ABI and stored memory layout use explicit structural pack/unpack operations instead of assuming identical register and frame representations
• ?, !, otherwise, and catch consume arbitrary places and expressions rather than only recognized call forms
• initialization, replacement, move, branch join, early exit, and scope cleanup drop exactly the active owned payload once and never inspect inactive storage
• presence/success, absence, and failure provenance remain distinct across storage and later consumption
• generic specialization, methods, associated functions, imports, and aliases use the same stored outcome machinery as plain functions
• buildability rejects only outcome shapes beyond the adopted depth; every diagnostic that rejects stored optional or fallible values by expression category is removed
• formatter, AST JSON, hover, completion, signature help, semantic tokens, and incomplete-source recovery continue to present normalized outcome types without protocol-side reconstruction
• repository-home and packaged-home native tests observe identical tags, payloads, cleanup, and provenance behavior

Phase 6 Completion Status

Phase 6 passed its implementation and verification gates on 2026-08-03.

• OutcomeShape derives one recursive stored layout for optional, fallible, and supported composed values; frame, IR, backend, aggregate, and drop code consume that model
• explicit stored-call and stored-return operations bridge scalar/view, direct aggregate, and indirect aggregate callable channels without equating register order with memory layout
• bindings, copies, explicit moves, replacements, parameters, returns, struct fields, and fixed arrays preserve tags and active payloads
• tag-guarded cleanup drops only the active owned payload, including nested aggregate cleanup and replacement after the new value has been evaluated
• ?, !, otherwise, and catch consume saved outcomes, including both supported composed orders, in ordinary value positions
• aliases, imports, methods, associated functions, and generic specializations resolve through the same structural outcome model
• buildability no longer rejects supported stored outcomes by expression category; unsupported repeated or deeper shapes remain rejected by the shared capability boundary
• analysis and JSON-RPC hover/completion preserve normalized composed types, while repository-home and packaged-home native tests exercise stored round trips

There are no required Phase 6 items in development/TODO.md. Git owns the chronological implementation record; this document remains the design and acceptance record.

Phase 6 Work Order

1. 1. Freeze stored layout, callable bridging, active-payload ownership, provenance, diagnostics, editor behavior, and non-goals.
2. Add a dedicated recursive outcome-storage model under the existing compiler outcome boundary.
3. Add generic IR frame operations for outcome construction, copying, moving, assignment, and active-branch extraction.
4. Bridge scalar/view, direct aggregate, indirect aggregate, and error call channels to stored outcome slots.
5. Extend ownership and drop lowering to use tag-guarded active payload cleanup.
6. Generalize ?, !, otherwise, and catch from call-specific lowering to stored expression lowering.
7. Extend parameters, aggregate fields, fixed arrays, generic specialization, provenance, and analysis/LSP facts.
8. Remove obsolete buildability restrictions and pass repository plus packaged-home acceptance tests.

All eight items are complete. Stored layout construction remains separate from callable ABI construction, and consumers, ownership cleanup, provenance, and editor presentation use shared compiler facts rather than spelling- or protocol-specific reconstruction.

Phase 6 Acceptance Matrix

Phase 6 Non-goals

• repeated optional/fallible layers or deeper recursive outcome trees
• user-defined outcome constructors or nominal Option / Result types
• exceptions, stack unwinding, implicit error conversion, or multiple failure payload types
• pattern matching directly on built-in outcome tags
• sequence spread, variadic callables, embedding, or collection for
• workspace indexing, rename, code actions, or inlay hints
• native targets other than arm64-darwin

Phase 6 Verification Gate

Phase 6 passed:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
cargo clippy --manifest-path development/compiler/Cargo.toml --all-targets -- -D warnings
node docs/build-docs.js
git diff --check

Focused layout, buildability, IR, backend, ownership, drop, provenance, generic, aggregate, fixed-array, analysis, JSON-RPC, and packaged-home tests cover the acceptance matrix.

Phase 7: Protocol-Driven Collection Iteration

Status: complete.

Phase 7 connects explicit readonly and consuming collection syntax to ordinary standard-library interfaces. The detailed compiler design belongs to Protocol-Driven Collection Iteration.

Phase 7 Outcome

Phase 7 is complete when all of the following are true:

• for item in &collection selects a validated readonly conversion and yields source-tied borrows
• for item in move collection transfers the collection and yields owned elements
• a bare iterator expression may be used directly, while a bare collection value is rejected as ownership-ambiguous
• trusted Iterator, readonly-conversion, and owned-conversion roles resolve once to declaration identities after their complete interface shapes are validated
• user types participate through explicit ordinary interface conformance; parser, typecheck, IR, and LSP never select methods by iter, into_iter, or next spelling
• the source evaluates once and a compiler-owned semantic plan records conversion, iterator type, step target, item type, provenance, and ownership mode
• exhaustion, normal completion, continue, break, return, propagation, and nested loops drop each initialized item and iterator obligation exactly once
• readonly iteration retains the source loan; consuming iteration transfers and drops only the unconsumed suffix before releasing storage once
• generic collection and iterator specializations use the same conformance and static-dispatch machinery as ordinary bound calls
• hover, completion, semantic tokens, diagnostics, and incomplete-header recovery expose the exact loop item and source mode through compiler analysis
• repository-home and packaged-home native tests agree for readonly, move-only, generic, nested, early-exit, region, and failure-propagation paths

Phase 7 Completion Status

Phase 7 passed its implementation and verification gates on 2026-08-03.

• trusted iterator, readonly-conversion, and owned-conversion declarations are validated once and consumed by declaration identity
• Vec<T>, ViewIter<T>, VecIntoIter<T>, and user conformances use the ordinary interface and generic-specialization machinery
• readonly, consuming, and direct-iterator loops share one typecheck plan and one focused IR lowering path
• source loans, source transfers, item moves, implicit allocation effects, and region escape checks remain part of the existing ownership, effect, and provenance systems
• exhaustion, continue, break, return, propagation, and nested iteration execute ordered, exactly-once item and iterator cleanup in native tests
• hover reports the concrete source mode, iterator, item, conversion, and step; completion and semantic tokens recover incomplete headers without inventing a protocol identity
• repository and packaged-home checks cover standard and user-defined conformances

There are no required Phase 7 items in development/TODO.md. Git owns the chronological implementation record; this document remains the design and acceptance record.

Phase 7 Work Order

1. 1. Freeze ownership modes, trusted interface shapes, semantic-plan fields, cleanup order, diagnostics, editor behavior, and non-goals.
2. Generalize trusted runtime declaration facts with validated iteration protocol roles.
3. Add standard-library protocol interfaces and conform ViewIter<T>, VecIntoIter<T>, and Vec<T> without compiler name recognition.
4. Add a dedicated collection-for AST source and cursor-preserving parser recovery.
5. Resolve conversions and iterator steps by conformance identity; record item type, provenance, ownership, and concrete call targets in typecheck facts.
6. Extend ownership, region, return, and buildability traversal over the shared semantic plan.
7. Lower iterator construction, optional step consumption, item scope, loop control, and ordered cleanup through existing call, outcome, and drop operations.
8. Expose loop facts through analysis/LSP and pass repository plus packaged-home acceptance tests.

Phase 7 Acceptance Matrix

Phase 7 Non-goals

• mutable collection iteration through &+collection
• implicit readonly or consuming selection for a bare collection value
• associated types, multiple interface bounds, or dynamic iterator dispatch
• iterator adapters requiring closures, asynchronous iteration, or generators
• reverse iteration, custom stepping, destructuring loop patterns, or loop values
• generalized ... spread, variadic callables, embedding, or collection comprehensions
• native targets other than arm64-darwin

Phase 7 Verification Gate

Phase 7 passed:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
cargo clippy --manifest-path development/compiler/Cargo.toml --all-targets -- -D warnings
node docs/build-docs.js
git diff --check

Focused trusted-role, parser, resolver, typecheck, ownership, provenance, IR, backend, native, analysis, JSON-RPC, and packaged-home tests must cover the acceptance matrix.

Phase 8: Explicit Sequence Spread and Composable Element Packs

Status: complete as of 2026-08-04.

Phase 8 extends the Phase 1 literal-only element pack with statically planned value and iterator segments. It reuses Phase 7 declaration-identity iteration rather than recognizing standard-library type or method names. The public language contract belongs to Literal Definitions and Sequence Spread.

Phase 8 Outcome

Phase 8 is complete when all of the following are true:

• typed sequence literals accept ...source, ...&source, and ...move source with fixed copy, readonly-reference, and ownership-transfer meanings
• the source evaluates once at its source position and the typechecker records one immutable pack segment plan containing concrete conversion, iterator, item, projection, exact-count, and step targets
• collection loops and spread segments consume one shared iteration plan and lowering substrate
• spread iterators provide an exact remaining count through validated ExactSizeIterator<T> conformance; unknown-size input is rejected without hidden materialization
• literal specialization keys and hidden ABI describe the compile-time segment signature rather than the runtime element count
• items.len() returns the checked sum of fixed values and exact spread counts, while pack consumption streams spread items in source order
• copy spread rejects non-Copy elements, readonly spread propagates source provenance, and move spread makes the source unavailable through the ordinary ownership model
• preparation failure, exhaustion, return, and propagation drop every initialized value, iterator suffix, and allocation exactly once in specified order
• hover, completion, signature help, semantic tokens, formatter output, diagnostics, and incomplete spread recovery consume the same semantic segment facts
• repository-home and packaged-home native tests agree for empty, mixed, borrowed, copy, move-only, generic, failure, cleanup, region, and allocator-context scenarios

Phase 8 Completion Status

Phase 8 passed its implementation and verification gates on 2026-08-04. The compiler and editor now consume one declaration-identity segment plan for every spread. Hidden literal entry computes and caches one checked exact pack length, while item stepping remains streaming and allocation-free.

• parser and formatter reserve ... for typed sequence elements and preserve the three canonical ownership spellings
• trusted ExactSizeIterator<T> validation extends the Phase 7 iteration runtime without nominal type or method-name recognition
• deterministic segment signatures drive literal specialization and hidden iterator ABI
• copy, readonly-reference, and move projections share ordinary ownership, provenance, effect, and cleanup analyses
• standard readonly and owning vector iterators provide exact remaining counts
• hover, completion ranking, signature help, semantic tokens, and incomplete-source recovery use the resolved segment facts
• packaged native tests observe mixed and repeated segments, direct owning iterators, cached length, region rejection, and exactly-once suffix cleanup

There are no required Phase 8 items in development/TODO.md. Git owns the chronological implementation record; this document remains the design and acceptance record.

Phase 8 Work Order

1. 1. Freeze syntax, ownership modes, exact-count contract, segment plan, evaluation order, cleanup, diagnostics, editor behavior, and non-goals.
2. Add contextual spread AST nodes and parser/formatter recovery without enabling ... in arrays, calls, aggregates, declarations, or patterns.
3. Extract a reusable iteration semantic plan from collection-for facts and add exact-size trusted conformance resolution.
4. Replace element-count literal specializations with deterministic segment-signature specializations and lower segment preparation in source order.
5. Replace the flat literal-pack lowering context with fixed-value and iterator segments; share iterator materialization and optional-step lowering with collection for.
6. Integrate ownership, provenance, implicit effects, recursive cleanup, and buildability checks.
7. Conform standard readonly and owning iterators to ExactSizeIterator<T> and prove native behavior from repository and packaged homes.
8. Expose segment facts through analysis/LSP and pass the full verification gate.

Phase 8 Acceptance Matrix

Phase 8 Non-goals

• ordinary variadic parameters or call arguments
• spread in fixed arrays, mapping literals, struct initializers, patterns, or embedding declarations
• unknown-size spread through implicit buffering, iterator collection, or hidden heap allocation
• mutable spread, draining a borrowed collection, iterator adapters, generators, or async streams
• associated types, multiple interface bounds, or dynamic iterator dispatch
• native targets other than arm64-darwin

Phase 8 Verification Gate

Phase 8 passed:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
cargo clippy --manifest-path development/compiler/Cargo.toml --all-targets -- -D warnings
node docs/build-docs.js
git diff --check

Focused parser, formatter, trusted-role, typecheck-plan, ownership, provenance, effect, IR, backend, native, analysis, JSON-RPC, and packaged-home tests must cover the acceptance matrix.

Phase 9: Composable Iterators and Collection Builders

Status: complete as of 2026-08-04.

Phase 9 turns the Phase 7 and Phase 8 iteration protocols into a practical, allocation-transparent standard-library layer. Its compiler foundation is a declaration-identity capability set and conditional conformance model, not adapter-name recognition. The detailed design belongs to Composable Iterators and Collection Builders.

Phase 9 Outcome

Phase 9 is complete when all of the following are true:

• generic parameters accept canonical interface sets such as I: Iterator<T> + ExactSizeIterator<T>
• duplicate, malformed, cyclic, unsatisfied, missing-method, and ambiguous-method cases produce deterministic source-backed diagnostics
• conformance declarations retain their generic bounds and apply only when every specialized condition is satisfied
• conformance lookup, generic calls, iteration plans, buildability, IR, analysis, and LSP use one declaration-identity conditional-conformance query
• distributed std provides empty, once, take, skip, chain, enumerate, count, and last without hidden collection allocation or runtime dispatch
• exact-size adapters expose a correct remaining count only under proven input capabilities
• Vec.from_iter consumes unknown-size iterators through explicit checked growth, while Vec.from_exact_iter performs one exact initial reservation
• adapter and builder ownership transfers each item once and drops current state, unconsumed suffixes, partial vectors, and storage exactly once on every supported exit
• allocation effects and region provenance flow through builders while allocation-free adapters remain effect-free
• hover, completion, signature help, definition, semantic tokens, diagnostics, and incomplete-bound recovery present the same specialized capability and conformance facts
• repository-home and packaged-home native tests agree for empty, scalar, move-only, generic, exact-size, early-exit, region, and allocation-context scenarios

Phase 9 Work Order

1. 1. Freeze capability-set grammar, conditional-conformance matching, coherence, adapter APIs, ownership, exact-size rules, diagnostics, editor behavior, and non-goals.
2. Replace the optional single-bound AST and signatures with ordered bound lists while exposing a declaration-identity set to semantic consumers.
3. Add conditional conformance signatures and one recursive, cycle-safe specialization query.
4. Redirect generic call checking, bound method lookup, iteration resolution, buildability, IR, analysis, and LSP to the shared query.
5. Implement allocation-free adapter state machines and exact-size preservation in focused standard-library modules.
6. Implement unknown-size and exact-size Vec builders over the existing initialized-prefix, allocation-context, and cleanup foundations.
7. Pass the Phase 9 acceptance matrix from repository and packaged Nocter homes.

Phase 9 Acceptance Matrix

Phase 9 Non-goals

• closures, first-class callable values, map, filter, callback fold, or comparator APIs
• associated types, interface inheritance, where clauses, negative bounds, or runtime dispatch
• overlapping conformance specialization, blanket impls, or orphan/coherence policy beyond exact normalized duplicate rejection
• hidden buffering, implicit collection during adaptation, or unchecked trust in exact counts
• recoverable collection from an iterator before partial-consumption semantics are specified
• asynchronous iteration, generators, parallel iteration, or native targets beyond arm64-darwin

Phase 9 Verification Gate

Phase 9 must pass:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
cargo clippy --manifest-path development/compiler/Cargo.toml --all-targets -- -D warnings
node docs/build-docs.js
git diff --check

Focused parser, formatter, resolver, generic-bound, conformance, ownership, provenance, effect, IR, backend, native, analysis, JSON-RPC, and packaged-home tests must cover the acceptance matrix.

Phase 10: Callable Values and Interface Default Methods

Status: complete as of 2026-08-04.

Phase 10 makes the Phase 9 iterator layer ergonomic by allowing reusable behavior derived from an interface's required capability. It adds interface default methods, owned closure values, and a chainable standard iterator surface. The detailed design belongs to Callable Values and Interface Default Methods.

Phase 10 Outcome

Phase 10 is complete when all of the following are true:

• methods may declare generic parameters whose scope follows the enclosing declaration and whose bounds use the existing declaration-identity capability set
• interface methods without bodies remain conformance requirements; body-bearing methods are reusable defaults that add no fields, layout, implicit conformance, or runtime dispatch
• concrete lookup treats inherent and conformance methods as peer candidates, diagnoses competing declarations, and records one specialized callable target; generic lookup searches only its explicit bound set
• (parameters) { body } creates an anonymous concrete closure value and contextually infers its callable signature
• &name, &+name, and move name capture lists produce exact readonly, readwrite, and owned environment fields; unlisted outer bindings are rejected
• closure construction, movement, invocation, and destruction reuse aggregate ownership, loan, provenance, allocation-effect, and cleanup machinery
• closure calls use built-in &func, &+func, and func generic contracts and dedicated static callable specializations without a standard-library protocol, heap box, erased environment, vtable, or runtime interface dispatch
• standard iterator defaults provide lazy map and filter, the Phase 9 adapters and terminals as methods, callback terminals, and explicit consuming to_vec
• exact-size capability is preserved only for mathematically exact adapter compositions
• hover, completion, signature help, definition, references, semantic tokens, diagnostics, and incomplete closure/default-body recovery consume compiler-owned semantic facts
• repository-home and packaged-home native tests agree for scalar, move-only, captured, generic, exact-size, early-exit, region, and allocation-context scenarios

Phase 10 Work Order

1. 1. Freeze default-method and closure grammar, capture modes, callable capabilities, method lookup, ownership, provenance, effects, diagnostics, editor behavior, iterator APIs, and non-goals.
2. Add method-level generic parameters and carry their declaration identities through resolver, typecheck, specialization, formatter, AST JSON, and analysis.
3. Preserve required/default method identity through imports and add deterministic override, applicability, ambiguity, and static call-target facts.
4. Add focused closure AST and contextual signature inference, then materialize anonymous capture aggregates and generated call targets.
5. Connect capture places and generated calls to ordinary ownership, provenance, allocation, buildability, IR, ABI, and cleanup paths.
6. Implement chainable map/filter adapters, existing adapter forwarding, callback terminals, and to_vec with explicit standard-library ownership boundaries.
7. Expose default-method and closure facts through analysis/LSP and pass the acceptance matrix from repository and packaged Nocter homes.

Phase 10 Acceptance Matrix

Phase 10 Non-goals

• interface inheritance, associated types, where clauses, or implicit conformance
• extension declarations, interface fields, properties, drop members, or associated functions
• import-order or declaration-order method selection
• erased callable types, heap-boxed environments, code-pointer closure ABI, or runtime dispatch
• implicit capture, asynchronous closures, generators, parallel iterators, or comparator sorting
• generic collection collect, recoverable partial iterator collection, or hidden buffering
• native targets other than arm64-darwin

Phase 10 Verification Gate

Phase 10 must pass:

./development/compiler/scripts/verify.sh
cargo fmt --manifest-path development/compiler/Cargo.toml --check
cargo clippy --manifest-path development/compiler/Cargo.toml --all-targets -- -D warnings
node docs/build-docs.js
git diff --check

Focused lexer, parser, formatter, resolver, default-method, closure, generic, ownership, provenance, effect, buildability, IR, backend, native, analysis, JSON-RPC, and packaged-home tests must cover the acceptance matrix.

Phase 10 Completion Status

The completed implementation includes method-local generics, deterministic interface-default selection, explicit-capture closure aggregates, built-in structural callable contracts, dedicated direct-call specialization, lazy iterator defaults, exact-size conditional conformance, recursive drop-dependency discovery, consuming callable ownership transfer, callback provenance and allocation propagation, shared incomplete-body recovery, and compiler-backed LSP presentation. Repository and packaged-home native tests cover scalar and move-only chains, early termination, owned and borrowed captures, lexical regions, and current-context allocation.