semantifold 0.3.0 → 0.4.0

package/docs/language-support.md

@@ -4,20 +4,197 @@
 
 The immutable registry is authoritative for both dispatch and discovery:
 
-| ID | Frontend | Text backend | Binary backend | Application backend | Interoperability | Artifacts | Round trip | Mapping | Acceptance |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `php` | yes | yes | no | no | no | single | yes | rich + v3 | parse, generate, execute (`php`) |
-| `ruby` | yes | yes | no | no | no | single | yes | rich + v3 | parse, generate, execute (`ruby`) |
-| `javascript` | yes | yes | no | no | no | single | yes | rich + v3 | parse, generate, execute (`node`) |
-| `typescript` | yes | yes | no | no | no | single | yes | rich + v3 | parse, generate, compile, execute (`tsc`, `node`) |
-| `java` | yes | yes | no | no | no | single | yes | rich + v3 | parse, generate, compile, execute (`javac`, `java`) |
-| `python` | yes | yes | no | no | no | single | yes | rich + v3 | parse, generate, compile, execute (`python3`) |
-| `csharp` | yes | yes | no | no | no | multiple | yes | rich + v3 | parse, generate, restore, compile, execute (`dotnet`) |
-| `go` | yes | yes | no | no | no | multiple | yes | rich + v3 | parse, generate, compile, validate, execute (`go`) |
-| `cpp` | yes | yes | no | no | no | single | yes | rich + v3 | parse, generate, compile, link, execute (`clangpp`, native executable) |
-| `c` | yes | yes | no | no | no | multiple | yes | rich + v3 | parse, generate, compile, link, execute (`clang`, native executable) |
-
-`languageCapabilities` exposes this information as frozen data. A role is not inferred from the presence of another role: a future browser binary target need not have a frontend, and a future interoperability bridge need not be a general backend. `supportedLanguages` is the derived list of all ten records with both frontend and text generation. C#, Go, and C are two-artifact text backends, so callers use `generateArtifactSet()`; the legacy single-artifact APIs reject them with `UNSUPPORTED_ROLE`.
+| ID | Frontend | Text backend | Binary backend | Application backend | Interoperability | General functions/calls | Immutable collections | Optional values | Ordered list iteration | Ordered map iteration | Condition-controlled loops | Reference classes | Effects/resources | Closed records | Typed errors | Type parameters/generics | Artifacts | Round trip | Mapping | Acceptance |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `php` | yes | yes | no | no | no | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | single | yes | rich + v3 | parse, generate, execute (`php`) |
+| `ruby` | yes | yes | no | no | no | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | single | yes | rich + v3 | parse, generate, execute (`ruby`) |
+| `javascript` | yes | yes | no | no | no | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | single | yes | rich + v3 | parse, generate, execute (`node`) |
+| `typescript` | yes | yes | no | no | no | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | single | yes | rich + v3 | parse, generate, compile, execute (`tsc`, `node`) |
+| `java` | yes | yes | no | no | no | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | single | yes | rich + v3 | parse, generate, compile, execute (`javac`, `java`) |
+| `kotlin` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | single | yes | rich + v3 | parse, generate, compile, execute (`kotlinc`, `java25`) |
+| `python` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | single | yes | rich + v3 | parse, generate, compile, execute (`python3`) |
+| `csharp` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | multiple | yes | rich + v3 | parse, generate, restore, compile, execute (`dotnet`) |
+| `go` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | multiple | yes | rich + v3 | parse, generate, compile, validate, execute (`go`) |
+| `cpp` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | single | yes | rich + v3 | parse, generate, compile, link, execute (`clangpp`, native executable) |
+| `c` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | multiple | yes | rich + v3 | parse, generate, compile, link, execute (`clang`, native executable) |
+| `rust` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | multiple | yes | rich + v3 | parse, generate, compile, validate, execute (`rustc`, `cargo`) |
+| `swift` | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | no | no | single | yes | rich + v3 | parse, generate, compile, execute (`swiftc`) |
+| `dart` | yes | yes | no | no | no | yes | no | no | no | no | no | no | no | no | no | no | multiple | yes | rich + v3 | parse, generate, restore, compile, validate, execute (`dart`) |
+| `wasm` | no | no | yes | yes | no | no | no | no | no | no | no | no | no | no | no | no | multiple | no | rich text + v3 + byte ranges | generate, validate, instantiate, execute (`wasm-validate`, `node`, `chromium`) |
+| `ios` | no | no | no | yes | no | no | no | no | no | no | no | no | no | no | no | no | multiple | no | rich text + v3 + byte ranges | generate (Apple acceptance deferred) |
+
+`languageCapabilities` exposes all sixteen records as frozen data, including `features.generalFunctionsAndCalls`, `features.immutableCollections`, `features.optionalValues`, `features.orderedListIteration`, `features.orderedMapIteration`, `features.conditionControlledLoops`, `features.referenceClasses`, `features.effectfulCapabilitiesAndResources`, `features.closedRecords`, `features.typedErrors`, and `features.typeParametersAndGenerics`. A role or semantic feature is not inferred from another role: browser Wasm has binary/application backends without a frontend or text backend, and the `ios` record has only its application backend. Neither has a source round trip, any semantic-feature flag, or general interoperability role. `supportedLanguages` is the derived list of fourteen records with both frontend and text generation. C#, Go, and C return two text artifacts; Rust and Dart return three; Wasm returns one binary and three text artifacts; iOS returns a deterministic multi-artifact SwiftUI/Xcode project model. Their callers use `generateArtifactSet()`; the legacy single-artifact APIs reject unavailable roles with `UNSUPPORTED_ROLE`.
+
+## Task 026 iOS application generation
+
+The `ios` registry row means implemented deterministic generation/provenance; materialization and Apple acceptance deferred. It consumes a caller-owned Task 010 project or a normalized single module and accepts exactly the semantics supported by the Task 022 Tasks 001–004 Swift backend. It has no iOS source syntax, text/binary shortcut, provider, interoperability, runtime-translation, or source-discovery role. `role: "application"` is explicit; omitting it preserves default text behavior for ordinary languages.
+
+Generation validates the whole semantic graph and closed application configuration before returning deterministic captured Swift, a synthetic SwiftUI shell, unsigned project/configuration/test files, exact caller assets, and a versioned ownership/provenance manifest. Output/resource paths use a closed portable ASCII alphabet without restricting Unicode semantic source or generated text. No public materializer is shipped; the atomic no-replace and descriptor-relative no-follow contract requires a separately authorized native boundary. Linux proves Ruby-to-generated-Swift output and packed generator behavior; macOS/Xcode/Apple SDK/XCTest/XCUIAutomation/iOS Simulator behavior is not yet qualified. The complete contract and exclusions are in [iOS application target](ios.md).
+
+## Task 025 core expanded-language acceptance
+
+Python, C#, C, C++, Rust, Swift, Kotlin/JVM, and Go share one data-driven Tasks 001–004 acceptance gate. Their five base/scalar/local/operator/statement fixtures normalize to the same location-neutral semantic corpus; the pre-existing `select`/`choose` spelling difference is treated as a reserved-word adaptation only, not different behavior. Each backend generates, reparses, and runs the complete operator profile through its real registered toolchain. Python and Swift emit one source file; C++ emits one source file; C# and C emit two-file projects; Rust emits `Cargo.toml`, `Cargo.lock`, and `src/main.rs`; Kotlin emits mapped `Program.kt` with runnable-JAR metadata; and Go emits `go.mod` plus `main.go`.
+
+The bounded crossing set is deliberately eleven paths: Python statements to Rust, C# operators to C++, C locals to Kotlin, then PHP to Python, Ruby to C#, JavaScript to C, TypeScript to C++, Java to Rust, PHP to Swift, Ruby to Kotlin, and JavaScript to Go. This proves dynamic-to-native, managed-to-native, native-to-managed, and every original-five-to-expanded-backend route without promising an all-pairs matrix. It is separate from Task 013, which remains the historical original-five acceptance gate for later Tasks 005–008.
+
+Repeated artifact generation checks ordered paths, byte identity, rich mappings, Source Map v3, exact/synthetic spans, and source-filename provenance. Boundary safe integers, Unicode and NUL strings, and permitted non-ASCII identifiers are included. A nested marker program proves eager operands evaluate left before right and Boolean operators short-circuit on all eight backends. C and C++ additionally require their exact versioned ordered-expression regions and real Clang O0/O2 runs both with and without ASan/UBSan/leak instrumentation; Rust runs debug/release and Swift runs debug/`-O`.
+
+The shared negative corpus covers parser recovery, missing types, truthiness, mixed numeric/Boolean equality, unsafe literals, dynamic calls, reflection, exceptions, concurrency, illegal target names, malformed caller IR, later-arity IR, bounded-target overflow, unsupported roles, and unknown languages. Diagnostics retain code, language, filename, and parser-backed range, and artifact generation remains transactional. Task 025 adds no semantic nodes or capabilities: Wasm, application platforms, Objective-C, Dart/Flutter, Zig, Tasks 005+, compiler installation, benchmarks, and quadratic crossings remain outside the gate.
+
+## Task 005 general functions and calls
+
+PHP, Ruby, JavaScript with JSDoc, TypeScript, Java, and Dart accept any number of required positional parameters, including zero. The module resolver collects every unique function signature before validating bodies, assigns declarations deterministic `function:N` identities, and binds each direct call to that identity plus its ordered parameter and return types. This permits forward calls, nested calls, direct recursion, and unambiguous mutual recursion without overload or dynamic dispatch. Arity and every positional scalar type must match exactly.
+
+Function returns are `integer`, `boolean`, `string`, or `void`. A non-void function has an expression on every reachable return and returns on every reachable path. A void function may fall through or use a bare return, and its call is legal only as an `ExpressionStatement`. Void is never a value: it cannot type a parameter or local, initialize or assign a binding, become an argument or operand, be printed, or be returned as a value. Generation revalidates declaration identities and complete resolved signatures in externally supplied IR. Function names, parameters, return annotations, callees, arguments, and resolution references retain deterministic parser-backed provenance and mappings.
+
+The source profiles remain deliberately exact:
+
+- Ruby accepts only required positional parameters with one immediately adjacent `# @param name [Type]` per parameter and exactly one `# @return [Type]`, where `[void]` is the only void spelling. Optional, rest, post, keyword, keyword-rest, block parameters, singleton methods, receiver/dynamic calls, blocks, and implicit value returns are rejected. The built-in print spelling `puts` is reserved from semantic function declarations and Ruby target emission.
+- JavaScript accepts only declarations spelled `function name(...)` with a JSDoc annotation for every identifier parameter and an explicit scalar or `void` return annotation. TypeScript requires the corresponding explicit keyword annotations. Both reject optional/default/rest/destructured parameters, overloads, async/generators, arrows/function expressions, methods, callbacks and higher-order callees, optional/receiver/spread calls, and general TypeScript assertions. Task 012 adds only its exact generic declaration/application profile; Task 006 has one type-only exception for the exact independently validated `Map#get(...)!` round-trip form.
+- PHP accepts simple typed by-value required parameters, an explicit scalar or `void` return, and unqualified direct calls. Defaults, variadics, named/unpacked/by-reference arguments, by-reference parameters or returns, methods, dynamic/qualified calls, implicit nullability, and missing types are rejected; Task 007 adds only its exact explicit nullable profile.
+- Java accepts the established private-static semantic method profile with explicit supported parameter and scalar-or-void result types inside `public final class Main`, plus receiver-free direct calls and the exact entry method. Generated zero-parameter signatures named `getClass`, `hashCode`, `clone`, `toString`, `notify`, `notifyAll`, `wait`, or `finalize` conflict with inherited `java.lang.Object` instance methods and are rejected before emission; nonconflicting scalar-parameter overloads of those names remain available. Overload sets, instance/receiver/qualified/static-import ambiguity, varargs, bounded/defaulted/wildcard/raw generics, constructors, throws clauses, and non-static semantic methods are rejected.
+- Dart accepts synchronous top-level functions with exact explicit `int`, `bool`, `String`, or `void` returns, explicitly typed required positional parameters, initialized typed locals, direct calls, and exact `void main()`/`print`. Inference, `var`, inferred `final`, optional/named/default arguments, methods/classes, generics, imports, dynamic/nullability, collections, exceptions, async, and isolates are rejected. Generated Dart alone may contain formatter-added trailing commas and the complete canonical private runtime prefix; neither grants those forms to ordinary source. See [Dart source and target](dart.md).
+
+Python, C#, C, C++, Rust, Swift, Kotlin/JVM, Go, and browser Wasm remain on their Task 025 Tasks 001–004 profile. Their registry feature flag is false, their existing exact-two/scalar-return behavior is unchanged, and a Task-005-only arity, void return, or void call statement is a located `UNSUPPORTED_CAPABILITY` before source, bytes, or a partial artifact set is exposed. This boundary does not broaden the future Task 013 aggregate acceptance.
+
+## Task 006 immutable lists and maps
+
+PHP, Ruby, JavaScript with JSDoc, TypeScript, and Java add finite homogeneous immutable collection values. `ListType {elementType}` and `MapType {keyType, valueType}` are distinct recursive semantic types; map keys are exactly semantic strings and initial keys must be nonnumeric string literals. `ListLiteral` preserves zero-based source order and duplicate values. `MapLiteral` retains source entry order only for initializer evaluation, provenance, and diagnostics: portable map iteration and observable map order are not modeled.
+
+The accepted Task 006 operations are list indexing, total map lookup, and collection size. A read is admitted only when literal propagation proves its index/key present or the exact source operation fails on absence, such as Ruby `Hash#fetch` and Java `List#get`. Known out-of-bounds indices and absent literal keys are rejected. When the explicit element or value type is `Optional<T>`, the admitted access preserves that optional result; an unchecked missing-key read is still not converted into optional absence. Collection mutation, sets, tuples, object/record maps, sparse arrays, spreads, arbitrary keys, map iteration, ranges/slices, comprehensions, sorting, and deep-freezing claims remain outside this capability. Task 008 separately adds exact ordered list iteration. Semantic immutability is guaranteed by the accepted operation profile: generated runtime containers need not be recursively frozen because no alias-visible mutation operation can enter or be emitted.
+
+The exact source and target profiles are:
+
+- Ruby uses adjacent `[Array[T]]` and `[Hash[String,T]]` metadata, bracket list literals/indexing, string-rocket hashes, `fetch`, and `size`. Hash defaults, symbol/numeric keys, splats, bracket map lookup, and mutation are rejected.
+- JavaScript/JSDoc uses `ReadonlyArray<T>`, `ReadonlyMap<string, T>`, dense array literals, and exact `new Map([[key, value]])`; TypeScript additionally accepts `readonly T[]`. Plain objects, tuples, mutable array types/APIs, weak collections, spreads, general assertions, and unproven `Map#get` are rejected. Generation uses read-only annotations and the same array/`Map` values; TypeScript adds a type-only non-null assertion to semantically proven map reads so their emitted type remains `T`. The frontend accepts that exact wrapper only around a `Map#get` result and still proves lookup totality independently, so `!` cannot admit a missing read.
+- PHP uses exact PHPDoc `list<T>` versus `array<string,T>` while native function signatures use `array`. Empty `[]` inherits only an explicit declaration, return, previously declared binding, or direct-call parameter collection type. Implicit list entries cannot mix with explicit map entries; references, unpacking, coercive/numeric-string keys, duplicates, mutation, and absent bracket reads are rejected. Generation reproduces PHPDoc so the distinction reparses.
+- Java uses only fully qualified `java.util.List<T>`/`java.util.Map<String,T>` with boxed recursive arguments and `java.util.List.of`/`java.util.Map.of`. Arrays, raw or mutable implementations, null factory members, duplicate keys, and more than ten `Map.of` entries are rejected. Task 010 admits only explicit supplied-project imports under its separate canonical module profile.
+
+These spellings are parser-backed profiles for the closed Task 006 semantic nodes, not a general standard-library-call translation mechanism. Backends render target collection representations from validated IR without mapping source API names to target API names or adding facade, canonical-capability, or provider integrations. Tasks 035–037 implement the separate hub-and-spoke standard-library route; collection spellings do not enter or broaden it.
+
+Recursive type arguments, list elements, map entries and their key/value children, accesses, sizes, call-signature identities, provenance, and generated mappings have deterministic identities and parser-owned locations. All other registered frontends retain their prior source subset, and all registered non-cohort targets reject collection IR with `UNSUPPORTED_CAPABILITY` before returning any source, bytes, or partial artifact set. Task 013 remains the original-five aggregate boundary.
+
+## Task 007 optional values and presence narrowing
+
+The original-five cohort adds recursive `OptionalType {valueType}` plus `OptionalNone`, `OptionalSome {value}`, `OptionalIsPresent`, and guarded `OptionalUnwrap`. Absence is not a universal literal: it is valid only where an explicit optional declaration, parameter, return, assignment, collection element/value, or call argument supplies `Optional<T>`. Optional types compose as recursive list elements and map values, literal children inherit that declared context, and admitted collection access preserves an already-optional result. Presence contains exactly `T`; void, direct `Optional<Optional<T>>`, cyclic optionals, and arbitrary unions are rejected.
+
+Narrowing is deliberately conservative. One exact presence test on one identifier proves that same binding present only in the corresponding branch. A direct negation moves the proof to the alternate branch. Reassignment invalidates it, nested scopes cannot manufacture it, and shadowing remains forbidden by the shared lexical model. Every unchecked or invalidated unwrap fails with `UNCHECKED_OPTIONAL_UNWRAP`; backends revalidate the same flow before emitting an artifact.
+
+The exact parser-backed profiles are:
+
+- Ruby uses adjacent RBS-style `T?`, `nil`, exact `value.nil?`, and guarded `if` or `unless`. Optional truthiness, safe navigation, `||` defaults, nonoptional `nil`, and union spellings are rejected.
+- JavaScript/JSDoc uses exact `{T|null}`, `null`, and `value !== null`. `undefined`/`void` absence, omitted or optional parameters/properties, loose checks, optional chaining, `??`, and wider unions are rejected.
+- TypeScript uses exact `T | null` with `null` and `value !== null`; real acceptance compiles with `--strict`. `undefined`, optional/default parameters or properties, non-null assertions, optional chaining, `??`, wider unions, and `@ts-nocheck` are rejected.
+- PHP uses canonical native `?T`, paired with exact PHPDoc where a recursive collection constituent needs it, plus `null` and `$value !== null`. Omitted nullability, union spellings, loose checks, nullsafe access, and `??` are rejected.
+- Java uses parser-identified `java.util.Optional<T>` or `Optional<T>`, `Optional.empty`/`Optional.of`, `isPresent`, and guarded `get`. Generation retains fully qualified `java.util.Optional` names. Bare nullable references, `null` inside `Optional`, unchecked `get`, nested optionals, third-party nullable annotations, and `ofNullable` are rejected.
+
+Backends emit only target-native `nil`, `null`, or `java.util.Optional` representations from these semantic nodes. Type constituents, collection-contained presence/absence, preserved accesses, and every construction/test/unwrap keep deterministic source provenance and generated mappings. Backend preflight rejects recursive expression cycles with located `UNSUPPORTED_CAPABILITY` while allowing shared acyclic subexpressions, before a writer or partial artifact is exposed. Python, C#, Go, C, C++, Rust, Swift, Kotlin/JVM, and browser Wasm advertise `optionalValues: false` and reject optional IR with located `UNSUPPORTED_CAPABILITY` before exposing source, bytes, or partial artifact sets. This core value feature does not add standard-library facade/provider linking, pairwise adapters, missing-key-to-optional lookup, result/error types, patterns, or general method semantics.
+
+## Task 008 ordered list iteration
+
+The original-five cohort adds `ForEachStatement {list, valueBinding, body, location}`, immutable typed `ValueBinding`, and nearest-loop `BreakStatement`/`ContinueStatement`. A loop evaluates its list expression exactly once before iteration, visits elements in list order, and exposes the element binding only inside its lexical body. The binding type must exactly equal the list element type, assignment to it is illegal, and the shared duplicate/no-shadowing policy applies. A presence-narrowed `Optional<List<T>>` operand in the original-five source profiles normalizes to the existing canonical `OptionalUnwrap` expression before iteration; semantic validation still requires the exact Task 007 guard, so an unguarded optional list remains invalid. A loop may execute zero or repeatedly many times, so every outer mutable binding assigned on any nested body path loses its known-value and optional-presence facts both while validating the body and after loop exit; abrupt assignment paths cannot hide those effects, while bindings the body cannot assign retain their stable facts. A return in the body never by itself completes a non-void function. `break` and `continue` are legal only in a loop and affect the nearest enclosing loop.
+
+The exact parser-backed source and target profiles are:
+
+- Ruby accepts only resolved-list `items.each do |item| ... end` with one required block parameter. Ruby `for`, braces, arbitrary blocks, Hash iteration, nonlocal return, redo/retry, parameters of other arities, and mutation are rejected. Because a semantic return inside the loop would lower to a nonlocal Ruby block return that the source profile excludes, the Ruby target rejects that IR before exposing any artifact.
+- JavaScript/JSDoc and TypeScript accept only a block-bodied `for (const item of list)`. The collection supplies the element type, which TypeScript may annotate only compatibly. `await`, destructuring, `let`/`var`, Map/custom iterator iteration, `for...in`, classic loops, labels, generators, and mutation are rejected.
+- PHP accepts only block-form `foreach ($list as $item)`. Key bindings, references, destructuring, alternate syntax, maps or ambiguous arrays, and mutation are rejected.
+- Java accepts only enhanced `for (T item : list)` where the resolved operand is `java.util.List<T>`/`List<T>` and `T` is exact. Parser-owned recursive type inference follows canonical `List#get`/`Map#get` receivers, explicit `Optional#get`, and structurally valid parentheses, so enhanced loops over generated nested-list access, guarded optional lists, or parenthesized supported expressions retain their exact element type and ordinary Task 006/007 validation. Maps/`entrySet`, arrays, basic loops, streams/lambdas, raw or incompatible types, labels, and mutation are rejected.
+
+Backends emit native Ruby `.each`, JavaScript/TypeScript `for...of`, PHP `foreach`, and Java enhanced-for syntax from the canonical IR. Generated source reparses to equivalent loop/control nodes. Loop, list expression, binding, body, and abrupt controls retain deterministic source provenance and generated mappings; each of those loop-owned locations must be a complete ordered UTF-16 range. Missing, null, or malformed loop-owned ranges, malformed/cyclic caller IR, and every unsupported target fail with a safely located `UNSUPPORTED_CAPABILITY` before source, bytes, or a partial artifact set is exposed. `orderedListIteration` is true only for the original five; the other eight source languages and browser Wasm advertise false. Task 014 owns the separate ordered-map capability. Task 008 adds structured list control flow only: it does not add pairwise translation, source-call substitution, compatibility facades, canonical stdlib contracts, or host providers.
+
+## Task 014 ordered map iteration
+
+PHP, Ruby, JavaScript with JSDoc, TypeScript, and Java expose `orderedMapIteration: true`. The canonical `OrderedMapType {keyType, valueType, order: "insertion"}` and `OrderedMapLiteral` are distinct from Task 006's unordered `MapType`/`MapLiteral`; an ordinary map is still valid for construction, lookup, and size but can never be iterated or promoted after the fact. Ordered-map keys are homogeneous semantic strings, must be unique nonnumeric literals, and preserve first-insertion order. Values have one exact homogeneous recursive type. Literal keys and values evaluate left-to-right in source order, and `ForEachMapStatement {map, keyBinding, valueBinding, body, location}` evaluates its operand once before visiting each pair once. Both bindings are immutable and exist only in the body; nearest-loop `break` and `continue` retain their existing meaning.
+
+Each frontend accepts only a parser-proven native ordered profile: typed frozen Ruby `Hash` literals with two-parameter `each`; native JavaScript/TypeScript `Map` literals whose constructor identifier resolves to the unshadowed intrinsic, with `const` two-identifier `for...of`; explicitly documented PHP string-key arrays with key/value `foreach`; and a bounded Java sequence consisting of a fresh insertion-mode `LinkedHashMap`, ordered `put` calls, immediate `Collections.unmodifiableSequencedMap` sealing as `SequencedMap`, and `sequencedEntrySet()` iteration with exact key/value extraction. A Java `SequencedMap` annotation alone remains ordinary `MapType` evidence because its encounter order need not be first-insertion order; source names consumed for the Java backing and entry helper remain reserved in their lexical scopes. Aliases, mutation, duplicate or coercible keys, shadowed JavaScript/TypeScript `Map` constructors, Java helper-name collisions, key-only/value-only binding, structural or custom iterables, sorted/access-ordered/concurrent maps, all Java `Map.of` families, and escaped Java backings fail loudly with located diagnostics.
+
+Backends preserve the same native boundaries: Ruby `Hash`, JavaScript/TypeScript `Map`, PHP's safe string-key associative-array profile, and Java's non-escaping mutable backing behind an unmodifiable `SequencedMap`. Shared target preflight admits an ordered-map local only as an immutable declaration with a direct `OrderedMapLiteral` initializer, rejecting aliases and mutable declarations transactionally before source emission. Java allocates collision-safe hidden names and permits ordered-literal lowering only as a safe local initializer; it rejects expression positions where statement insertion could change evaluation order. Every other registered target advertises false and rejects Task 014 IR before returning an artifact. This remains a canonical semantic capability between independent source and target adapters, not a pairwise/name-only rewrite or a standard-library facade/provider shortcut.
+
+## Task 032 condition-controlled loops and resolved control
+
+PHP, Ruby, JavaScript with JSDoc, TypeScript, and Java expose `conditionControlledLoops: true`. The canonical `WhileStatement {id, condition, body, location}` evaluates its condition before every iteration, requires an exact semantic Boolean, introduces a nested body scope, and conservatively remains a possible zero-iteration fallthrough path. Mutations reachable from the body invalidate outer known-value and optional-presence facts before the repeatedly evaluated condition and after loop exit. No loop body alone proves a non-void function complete.
+
+Every list, ordered-map, and condition-controlled loop receives a deterministic module-local `loop:N` identity. `BreakStatement` and `ContinueStatement` carry the resolved `targetLoopId` of the nearest enclosing loop. Semantic and backend validation reject missing or duplicate loop identities, a non-nearest target, and a target owned by another function; an abrupt control also makes following statements in its block unreachable. `continue` reaches the next condition evaluation and `break` exits exactly its resolved loop, including in mixed nested loop kinds.
+
+The parser-backed source profile accepts only ordinary precondition block forms: braced `while (condition) { ... }` in PHP, JavaScript/TypeScript, and Java, plus Ruby `while condition ... end`. Post-condition `do` loops, PHP alternate syntax, Ruby `until` and modifier loops, unbraced bodies, labels, numeric levels, valued controls, loop `else`, implicit truthiness, basic/range/async loops, and termination proofs remain excluded. The five backends emit the matching native `while`, `break`, and `continue` constructs directly from validated semantic nodes. All other registered targets advertise false and reject the capability transactionally before returning source, bytes, or partial artifact sets. Task 032 adds no stdlib-specific read-loop recognition, canonical stdlib contract, facade, provider, or pairwise rewrite.
+
+## Task 033 reference classes, methods, and constructors
+
+PHP, Ruby, JavaScript with JSDoc, TypeScript, and Java expose `referenceClasses: true`. The canonical model consists of nominal `ClassDeclaration` values with stable identities, ordered private typed fields, exactly one `ConstructorDeclaration`, and a closed ordered method set. `ReferenceType` is bound to the exact class identity. `ReferenceConstruction` carries an exact resolved constructor signature, and `MethodCallExpression` carries an exact nominal method resolution. `ReceiverExpression`, `PrivateFieldRead`, and `PrivateFieldWriteStatement` are valid only inside the declaring class. Each construction produces a fresh stable identity; copying a reference through an immutable local, parameter, or return preserves aliasing rather than copying state.
+
+Construction arguments evaluate left to right and all fields must be initialized exactly once, in field declaration order, before the new reference can escape. A receiver call evaluates its receiver before its left-to-right arguments. Method and constructor bodies use the ordinary statement/type/flow rules, including void calls, returns, branches, and the delivered loop forms. JavaScript and TypeScript predeclare every class field, constructor signature, and method signature before converting any class body, so canonical forward construction and receiver calls resolve without exposing incomplete declarations. Validation registers all class identities before resolving field, parameter, return, construction, and call types; it rejects duplicate declarations, members and IDs, missing or repeated initialization, private access without the declaring receiver, unknown or mismatched receiver/member/signature/arity/type information, malformed caller-owned resolutions, and target name/layout collisions before writer allocation.
+
+The source profiles are intentionally exact. TypeScript uses non-exported classes with explicit `private` fields, one unmodified constructor, and ordinary typed instance methods. JavaScript uses native `#private` fields with adjacent complete JSDoc on fields, constructor parameters, method parameters/returns, and reference-typed bindings. PHP uses `final class`, explicit private typed properties, one public `__construct`, and public typed instance methods. Ruby uses a closed class body with one documented `initialize`; its ordered required parameters initialize the correspondingly named instance variables, and every ordinary method has complete adjacent type comments. Ruby target preflight rejects setter-style method names ending in `=` because native setter invocation returns the assigned argument independently of the method body. Java uses a package-private `final class` with explicit private mutable fields, one package-private constructor, package-private ordinary typed methods, and a separate canonical public `Main`; when a reference method calls a semantic function, generated package-visible static `Main` methods and explicit `Main.method(...)` calls preserve access and evaluation order. All five generated forms reparse to the same semantic class/member identities and execute through the real registered toolchains.
+
+Inheritance, interfaces, traits/mixins, class reopening or monkey-patching, prototypes, decorators/annotations, static/singleton members, computed or dynamic sends, overloads, virtual/duck dispatch, arbitrary host construction, reflection and host lifecycle/protocol hooks, public mutable fields, private access from outside the declaring receiver, identity equality/hashing/ordering, cloning, serialization, finalizers, generic or async methods/classes, and concurrency remain excluded. Constructors and methods may catch Task 011 errors internally but cannot expose an unchecked-error effect through a receiver call; that cross-feature effect contract is not invented by Task 033. Kotlin, Python, C#, Go, C, C++, Rust, Swift, and browser Wasm advertise `referenceClasses: false` and reject class-bearing modules transactionally. Task 033 is single-module: `parseProgram` and `generateProgramArtifactSet` reject class-bearing Task 010 modules before resolution or artifact allocation. It adds no Task 034 resource/effect model and no standard-library contract, facade, provider, or pairwise rewrite.
+
+## Task 034 effectful capabilities and owned resource lifetime
+
+PHP, Ruby, JavaScript/JSDoc, TypeScript, and Java expose `effectfulCapabilitiesAndResources: true`. A caller must supply an explicit frozen `SemantifoldCapabilityAuthority` schema-version-1 value to `parse`; source spelling alone never grants authority, and an ordinary same-named function remains ordinary. The resulting module records deterministic capability, resource, failure, operation, and `effect:N` identities plus exact ordered parameter/return types, host effects, declared failure identities, and resource flow. The schema version applies only to this authority payload and is not the versioned canonical contract/provider negotiation owned by Task 035.
+
+The bounded conformance authority is `semantifold.task034.resource-probe`. Its acquisition returns one open `ProbeResource` or raises `ProbeAcquireFailure` without creating an owner; reads use an immediate shared borrow and distinguish clean optional absence from `ProbeReadFailure`; close uses an immediate exclusive borrow, is explicit and deterministic, and becomes terminal on both success and `ProbeCloseFailure`. A later read or close raises the declared `ProbeResourceClosed` before another native operation. `OwnedResourceType` and resource-owning `OwnedReferenceType` are linear and separate from immutable values and ordinary Task 033 aliasable references. Fresh owned locals, parameters, constructors, and returns require explicit moves, while private resource fields remain encapsulated. Path-sensitive analysis preserves state across exact typed catches and requires every branch, loop edge, abrupt exit, and scope exit to close or transfer each owner; it rejects aliases, escaping or invalid borrows, state joins, leaks, use after move/close, and mismatched resource types.
+
+Effect expressions evaluate receiver first and arguments left to right, exactly once. A target-neutral backend plan materializes nested effect sites inside their current statement and failure boundary before emitting the enclosing eager expression. Backend preflight revalidates the complete authority, effect/failure ordering, ownership graph, target support, and protected helper needs before allocating a writer. The five adopted backends use fixed target-private conformance support over PHP file functions, Ruby `File`, Node `fs`, or Java `FileChannel`; host exceptions, messages, codes, and handles never enter semantic IR. Generated code is deterministic, reparses only with the same explicit authority, and is compiled/executed by the real `php`, `ruby`, `node`, `tsc`, `javac`, and `java` tools in focused acceptance.
+
+Kotlin, Python, C#, Go, C, C++, Rust, Swift, and browser Wasm expose the feature as false and reject Task 034 IR transactionally. `parseProgram` and program generation reject it because Task 034 remains single-module. Effectful short-circuit Boolean `&&`/`||` and effectful `while` conditions are outside the initial lowering profile. Async, concurrency, cancellation, `finally`/`ensure`/`defer`, destructors/finalizers/RAII/GC cleanup, retry, effect polymorphism, unsafe native pointers or descriptors, shared mutable resources, distributed transactions, specific public file/socket APIs, provider registries, negotiation, linking, facades, and pairwise or name-only rewrites remain excluded.
+
+## Task 009 closed records and member access
+
+The original-five cohort implements nominal, closed, immutable product records. `RecordDeclaration` owns ordered unique `RecordField` values and deterministic `record:N`/`record:N:field:N` identities. `RecordType` refers to a declaration identity; `RecordConstruction` requires exactly one correctly typed argument per field in declaration order; `MemberRead` resolves a nominal receiver and stable field identity. A record declaration name is reserved from lexical parameters, locals, and iteration bindings so every constructor lookup retains its nominal declaration ownership. After an optional record binding is proven present, frontend dispatch uses its unwrapped nominal value type: fields named `length` or `size` remain `MemberRead` rather than collection-size operations. Record fields compose with supported scalars, records, lists, maps, and optionals. Direct value-recursive cycles fail deterministically; recursion mediated by an explicit optional or container is representable and is compiled and executed in all five targets. Structural lookalikes never satisfy a record type.
+
+The one parser-backed source profile per language is intentionally narrow:
+
+- PHP requires the canonical `php82` toolchain profile (PHP 8.2 or newer), `final readonly class`, exactly one public constructor, and only public promoted parameters. The profile uses the ordinary `php` command and `SEMANTIFOLD_PHP` override; generic non-record PHP qualification remains PHP 8.x. Native scalar/record/nullable types pair with exact PHPDoc for recursive collection constituents.
+- Ruby requires one typed `attr_reader` per field followed by one typed `initialize`, matching required parameters and instance-variable assignments in order, ending in `freeze`. Generated Ruby binds the root-owned `Kernel#freeze` implementation so a same-named semantic function cannot intercept record immutability.
+- JavaScript/JSDoc requires one class constructor with a `@param` for every field, one immediately annotated `@readonly` `this.field = field` assignment per parameter, and final `Object.freeze(this)`. Generated JavaScript uses the exact identifier-free `({}).constructor.freeze(this)` provider scaffold so constructor parameters cannot capture the native operation.
+- TypeScript requires exactly one empty-body constructor whose parameters are plain `readonly name: Type` parameter properties, with no accessibility or other parameter-property modifiers.
+- Java requires a package-private `final class` with private-final fields, one package-private constructor assigning each field once, and one package-private canonical `field()` accessor per field. A zero-argument `equals()` on a known record receiver remains a nominal field read; one-argument `.equals(...)` retains the canonical string-equality path and diagnostics. The pinned `@lezer/java@1.1.3` grammar does not faithfully model Java record declarations, so Java `record` syntax is explicitly rejected from its parser recovery tree.
+
+Every backend emits the corresponding native declaration, construction, and read rather than erasing a record into a map or object. Preflight validates the complete record/type graph, identities, locations, target identifiers, reserved names, declaration/field collisions, recursive value edges, and Java `Main.java` constraint before writer allocation. PHP rejects a deterministic case-insensitive PHP 8.2+ core/date/SPL/JSON type baseline, and Ruby rejects its deterministic built-in type baseline; generation never queries ambient runtime state or mangles nominal identities. For legacy external IR, an omitted or `undefined` `records` member means no records, but explicit `null` is rejected as malformed before artifact exposure. Python, C#, Go, C, C++, Rust, Swift, Kotlin/JVM, and browser Wasm advertise `closedRecords: false` and reject record IR transactionally. Task 033 reference classes are a distinct mutable-identity capability; Task 009 records remain immutable values. Inheritance/interfaces/traits/mixins, methods beyond the Java canonical record accessors and constructor, mutation, equality/hashing, destructuring/copy/update, dynamic/computed access, reflection, decorators/annotations, prototypes/open objects, and magic methods remain outside the record capability. PR #34 delivered Task 009 after green TensorBuzz CI. This follow-up hardens JavaScript/Ruby record freezing and Java `equals()` member dispatch; its review and merge remain coordinator-owned.
+
+## Task 010 multi-file modules and names
+
+The original five additionally accept a complete explicit source set through `parseProgram`. The shared `SemanticProgram` owns dependency-first logical modules, one selected executable entry, a caller-order source registry, stable module-qualified declaration identities, and explicit resolved import/export bindings. All cycles, mixed source-language profiles, missing/private/wrong-kind declarations, duplicate modules/exports/import bindings, unsafe relative resolution, and empty or unknown entry selection fail before a program is returned. Parser ASTs, native filenames, package names, and generated paths never become semantic resolution keys.
+
+Each parser adapter recognizes only its canonical native module form: named relative ESM for JavaScript/TypeScript, literal `require_relative` plus one Ruby module, one PHP namespace with explicit `use` and matching literal `require_once __DIR__`, or one Java package/final-class file with direct imports. Type-only TypeScript imports are visible only to semantic type positions and type-only exports are rejected. Duplicate Java native class identities and Ruby cross-file module reopening are rejected before resolution. Package managers, networks, load paths, Composer/autoload, classpath/module-path discovery, CommonJS, default/star/dynamic imports, re-exports, Ruby mixins, PHP namespace fallback, Java static/wildcard imports and JPMS are not resolution mechanisms and are rejected. Import/export declaration, path and name roles retain parser-owned UTF-16 provenance, including exact aliased exported-name mappings.
+
+`generateProgramArtifactSet` accepts only PHP, Ruby, JavaScript, TypeScript, and Java. It plans paths and validates the full graph, source-owned module/header/node locations, a dense non-empty selected entry, target names/collisions, backend semantics, visibility, and public-file constraints before writer allocation, then returns one immutable mapped artifact set in dependency order. ESM projects include a synthetic module manifest; Ruby uses module wrappers, relative requires, and native private markers; PHP uses collision-checked generated namespaces, imports, and relative requires but rejects unexported declarations that its top-level namespace cannot hide; Java uses package directories with public exported and target-private unexported declarations. It never reads or writes source/output files and never exposes a partial set. See [multi-file modules and names](multi-file-modules.md) for the complete public, layout, rejection, and migration contract.
+
+## Task 011 typed errors and handling
+
+The original-five cohort implements one nominal unchecked-error model: `ErrorDeclaration`, identity-bound `ErrorType`, `ErrorConstruction` with exactly one semantic string message, abrupt `RaiseStatement`, and `TryStatement` with one exact `catchType`, one immutable block-local `CatchBinding`, and one `catchBody`. `ErrorMessageRead` is the only portable member operation. A handler removes only its exact nominal identity from the protected block's escaping errors; unmatched errors and errors raised by the handler continue outward. Catch entry discards known-value and optional-presence facts for every outer mutable binding assignable anywhere in the protected body, because a raise may transfer control after any preceding assignment. Internal fixed-point analysis follows direct calls so a catch around a helper call is reachable without adding checked exception declarations or public effect lists. Raise, return, break, and continue remain abrupt for reachability and return-completeness analysis.
+
+The accepted parser-backed forms are deliberately exact:
+
+- Ruby uses an empty `class E < StandardError`, `raise E, message`, and `begin` with one explicit `rescue E => error`. Default/broad or multiple rescue, rescue modifiers, bare raise/re-raise, retry, else, ensure, and fatal/system classes are rejected.
+- JavaScript/JSDoc and TypeScript use an empty `class E extends Error`, `throw new E(message)`, and one catch whose first statement is the exact `if (!(error instanceof E)) { throw error }` unmatched-value guard. An imported error alias resolves as a constructor only when no parameter, local, iteration, or catch binding shadows that spelling. Unguarded catches, alternate narrowing/assertions, arbitrary thrown values, `AggregateError`, causes, and `finally` are rejected. The guard is target syntax only and reparses back into the single semantic handler.
+- PHP uses `final class E extends RuntimeException`, exact construction/throw, and one `catch (E $error)`. Multi-catch, `Throwable`/`Exception`/`Error`, previous exceptions, throw expressions in value contexts, and `finally` are rejected. Generated namespaced projects qualify the native `\RuntimeException` base explicitly.
+- Java uses a final unchecked `RuntimeException` subclass with exactly one `String message` constructor forwarding to `super(message)`, exact construction/throw, and one typed catch. Checked exceptions, `throws`, multi-catch, resources, broad catches, suppressed/cause behavior, and `finally` are rejected.
+
+Error declaration/type/construction, raise, try/body, catch type/binding/body, and message-read nodes participate in deterministic source provenance, symbols, rich mappings, and Source Map v3. Task 010 programs preserve module-qualified `module#error:N` identities through imports, generation, and reparse. All backend graph, location, target-name, handler-shape, binding, payload, and effect validation completes before writer allocation. Kotlin, Python, C#, Go, C, C++, Rust, Swift, and browser Wasm advertise `typedErrors: false` and reject any Task 011 IR with located `UNSUPPORTED_CAPABILITY`; there is no C status-code, Rust `Result`, Wasm trap, or other substitute.
+
+This feature does not model arbitrary error values, multiple/union/broad handlers, checked effects, error result types, stack traces, causes, suppression, fatal/process errors, asynchronous rejection, `finally`/`ensure`, general classes/methods, or standard-library portability. It adds no pairwise rewrite and does not expand Task 013's historical Tasks 001–008 cohort.
+
+## Task 012 type parameters and generic declarations
+
+PHP, Ruby, JavaScript/JSDoc, TypeScript, and Java support invariant unbounded type parameters owned by function and closed-record declarations. Each parameter receives a stable `record:N:type:N` or `function:N:type:N` identity, and each use is a scoped `TypeVariableReference`; Task 010 prefixes both identities with the logical module ID. A generic record use is always a closed `RecordType` with exactly the declaration's ordered argument count. Raw, free, unknown, sparse, cyclic, and wrong-arity applications fail during semantic validation.
+
+Generic direct calls have no explicit type-argument syntax in the accepted profile. The validator performs deterministic first-order unification from argument types alone, recursing through records, lists, maps, and optionals. A concrete present argument for `Optional<T>` supplies evidence for `T`; an optional binding passed directly to `T` instead infers the whole `Optional` type and is not converted into an unchecked unwrap. Empty collections and absent optionals cannot manufacture evidence, including when nested in list/map literals, but their contextual validation is deferred while evidence-bearing nested values and sibling arguments resolve the variables; the result is independent of argument order. Every declared variable must receive one consistent non-recursive substitution. The complete substitution is recorded as a dense `ResolvedFunctionSignature.typeArguments` array and applied recursively to parameter checks, return types, constructed record fields, and member reads; caller-authored sparse arrays, including nested generic-record identity arguments, reject before emission. Frontend-known call results use parser-known arguments only to distinguish modeled syntax such as record fields named `length` or `size`; unknown arguments remain unknown and the semantic validator performs authoritative inference. An expected return type never participates. Conflicts, failure, and occurs-check recursion use `GENERIC_INFERENCE_CONFLICT`, `GENERIC_INFERENCE_FAILURE`, and `GENERIC_INFERENCE_RECURSION`.
+
+TypeScript emits and parses native `function f<T>`/`class Box<T>` syntax; Java uses native `<T>` methods/classes and boxed scalar arguments inside generic applications. Java generic constructors must carry explicit type arguments; a parameterized local cannot close a raw `new Box(...)`. JavaScript requires exact adjacent JSDoc `@template T`, Ruby requires exact adjacent `# @template T`, and PHP requires exact PHPDoc `@template T`; all three dynamic targets emit complete parameter, return, field, local, and application documentation so generated source reparses without semantic erasure. Their optional type-variable spellings (`T|null`, `T?`, and `?T`) and optional applied-record spellings (`Box<T>|null`, `Box[T]?`, and `?Box<T>`) remain exact inside recursive lists and maps. PHP derives the contextual closed type for an erased generic constructor from parser-known sibling call arguments, including the contained type of a present scalar passed to `Optional<T>`, while any variable that remains open must be owned by the exact enclosing lexical declaration; a callee's parameter cannot leak into an entry point or unrelated generic scope. An optional actual passed to nonoptional `T` remains whole evidence and is not unwrapped. PHP retains native scalar, record, and `array` carriers where faithful, but emits no native hint for `Optional<T>` because the variable itself has no faithful native carrier; both the native type and nullable marker must be absent for that carrier-free profile. Fixed optional scalar, record, list, and map documentation requires the exact matching native carrier with `?`, while nonoptional documentation rejects `?`; scalar comparison reuses the canonical PHP source-type mapping. Its generic records use private promoted storage plus exact documented public getters, preserving external immutability even when a direct type variable has no native PHP spelling. Only the field-named zero-argument getter on that exact generic record receiver normalizes to a member read; a presence-proven optional receiver produces the existing explicit semantic unwrap, while ordinary property access and unrelated same-named methods are rejected. Runtime erasure in those languages never removes the canonical semantic type.
+
+Declaration parameters, variable references, applications, inferred call resolutions, and generated spellings participate in deterministic provenance, symbol references, rich mappings, and Source Map v3. Generic record construction arguments inherit recursively substituted closed field types before expression conversion. Backend preflight validates parameter shape, IDs, target identifiers, reserved words, declaration/value-name collisions, every recursive application, the required absence of `arguments` on non-generic records, and complete call substitution before writer allocation. Kotlin, Python, C#, Go, C, C++, Rust, Swift, and browser Wasm advertise `typeParametersAndGenerics: false` and reject generic modules with located `UNSUPPORTED_CAPABILITY` before an artifact is exposed.
+
+Bounds/constraints/defaults, variance/wildcards/capture, higher-kinded or associated types, conditional/mapped/indexed/keyof/infer/intersection types, overload-driven or bidirectional inference, explicit generic function instantiation, specialization/reification, reflection/runtime type tests, generic arrays/varargs, casts, wrappers, raw applications, and `any`/`mixed`/`Object`/untyped fallbacks are outside Task 012. No standard-library contract, compatibility facade, host provider, pairwise adapter, or behavior-changing rewrite is added.
+
+## Task 013 original-five acceptance
+
+Task 013, delivered through PR 32 with the packed-consumer lifecycle correction in PR 33 on current `master`, freezes the combined Tasks 001–008 contract without adding capability. One substantial idiomatic fixture per original language covers scalar values, mutable/immutable locals, all selected expression families, nested multi-statement flow, zero/one/many-argument calls, direct recursion, void calls, recursive lists/maps with total lookup and size, present/absent optionals, and ordered list iteration with `continue`/`break`. No fixture iterates a map. A spec-only structural comparator removes source locations, provenance, and regenerated `function:N` links while preserving all other modeled semantic fields.
+
+Every one of the five source-derived modules generates all five targets. The 25 artifacts validate before emission, reparse to the complete same meaning, and collapse to one byte-identical artifact per target before execution is deduplicated. Real `php`, `ruby`, `node`, local `tsc` then `node`, and `javac` then `java` runs require exact output for branches, presence/absence, nested map/list lookup and sizes, and list-order-sensitive control flow. The older two-integer fixtures remain unchanged as backward-compatibility coverage. The compact rejection corpus crosses all five languages with parser failure, unsupported form, missing type, semantic resolution/type/flow failure, malformed external IR, target names, Java integer range, and PHP key rules. PHP and Babel parser failures now retain their native parser position as a normalized filename-bearing UTF-16 location; opaque failures fall back deterministically to the module range.
+
+This acceptance remains original-five-only and does not itself expand to the later Task 009 record, Task 010 project, Task 011 typed-error, Task 012 generic, or Task 014 ordered-map profiles. Task 014 is delivered separately and does not change the historical Task 013 fixture or its ordinary-map semantics. The Task 025 expanded cohort, browser Wasm, mobile/application lanes, Dart/Flutter, Zig, and all standard-library facade/provider work remain separate.
 
 ## Implemented subset
 
@@ -28,24 +205,30 @@ The immutable registry is authoritative for both dispatch and discovery:
 | JavaScript | JSDoc `number`, `boolean`, and `string` on synchronous, non-generator functions and locals | `console.log(…)` |
 | TypeScript | exact `number`, `boolean`, and `string` keyword annotations on synchronous, non-generator functions and locals | `console.log(…)` |
 | Java | primitive `int`/`boolean` and exact `String` or `java.lang.String` declarations, plus a sequenced `public static void main` | `System.out.println(…)` in `Main` |
+| Kotlin/JVM | exact `Long`, `Boolean`, and `String`; explicitly typed `val`/`var` | `println(…)` in final zero-argument `fun main()` in `Program.kt` |
 | Python | exact `int`/`bool`/`str` annotations on every parameter, return, and initialized local | direct top-level `print(…)` in `program.py` |
 | C# | exact `long`/`System.Int64`, `bool`/`System.Boolean`, and non-null `string`/`System.String` declarations | `System.Console.WriteLine(…)` in zero-argument `private static void Main()` |
 | Go | exact `int64`, `bool`, and `string` declarations on every parameter, result, and initialized local | `fmt.Println(…)` in final zero-argument `func main()` |
 | C | exact `int64_t`, `bool`, and immutable UTF-8 `SemantifoldString`; local `const` means immutable | scalar print helpers in canonical `int main(void)` with arena cleanup |
+| C++ | exact `std::int64_t`, `bool`, and owned `std::string` | checked scalar print helpers in `int main()` |
+| Rust | exact `i64`, `bool`, owned `String`; typed `let`/`let mut`, canonical safe decimal `i64` literal suffix | exact scalar print helpers in `fn main()` |
+| Swift | exact `Int64`, `Bool`, and `String`; explicitly typed `let`/`var` | direct top-level `print(…)` in `program.swift` |
 
 C uses the unchanged private root-bundled legacy CST boundary and the [complete C17 profile](c.md). It generates deterministic `program.c` plus `semantifold_runtime.h`, checks signed integer arithmetic and arena sizes, and sequences every call and nontrivial expression through exact versioned regions. Caller-authored nested calls with unspecified C order are rejected. Generated regions reparse only after whole-CST comparison verifies types, numbering, uses, order, consumers, prototypes and cleanup. No user pointer, ownership, preprocessing, general FFI or C++ behavior enters semantic IR. Real Clang O0/O2 execution and ASan/UBSan/leak checks are mandatory on the qualified Linux lane.
 
-Across every language, a module contains at least one function with exactly two required parameters and a scalar return. Function bodies, entry points, and conditional branches are ordered lexical blocks. They may contain supported local declarations, plain assignments, nested conditionals, explicit returns, and prints in source order. Conditions require semantic `boolean`. An alternate is optional, and source `else if`/`elsif`/`elseif` normalizes to one nested conditional inside the alternate block. Non-void functions must explicitly return on every reachable path; an optional alternate is therefore accepted only when a later statement completes the fallthrough path. A statement following an unconditional return or an exhaustive returning conditional in the same block is unreachable and rejected. Entry points cannot return values.
+Every module contains at least one function. The Task 005 cohort uses general required signatures and scalar-or-void returns; the remaining languages retain exactly two required parameters and a scalar return. Function bodies, entry points, and conditional branches are ordered lexical blocks. They may contain supported local declarations, plain assignments, nested conditionals, explicit returns, and prints in source order; the Task 005 cohort additionally permits direct void calls as statements. Conditions require semantic `boolean`. An alternate is optional, and source `else if`/`elsif`/`elseif` normalizes to one nested conditional inside the alternate block. Non-void functions must explicitly return on every reachable path; an optional alternate is therefore accepted only when a later statement completes the fallthrough path. A statement following an unconditional return or an exhaustive returning conditional in the same block is unreachable and rejected. Entry points cannot return.
 
 Frontend conditional forms remain deliberately bounded:
 
 - JavaScript and TypeScript accept `if` with a block or one supported statement and normalize either to `Block`; directives, switch, labels, conditional expressions, and unmodeled executable/type-only statements are rejected.
 - PHP accepts braced `if`/`elseif`/`else`; alternative colon syntax, `switch`, `match`, inline HTML, and truthy conditions are rejected.
-- Ruby accepts ordinary `if`/`elsif`/`else` with explicit `return`; modifier conditionals, `unless`, `case`, implicit method returns, and truthy conditions are rejected.
+- Ruby accepts ordinary `if`/`elsif`/`else` with explicit `return`; Task 007 additionally accepts exact `if`/`unless` optional-presence guards. Modifier conditionals, other `unless` conditions, `case`, implicit method returns, and truthy conditions are rejected.
 - Java requires braced ordinary branches while accepting a direct `else if`; switch forms, labels, assertions, synchronized blocks, local classes, and recovered grammar nodes are rejected.
+- Kotlin requires top-level semantic functions before exactly one final `fun main()`, two explicitly typed ordinary parameters, explicit scalar returns, braced branches, and direct one-argument `println`. Packages, imports, annotations, type inference, nullable/platform types, nominal declarations, extensions, overloads, generics, lambdas, exceptions, coroutines, qualified calls, arbitrary APIs, string templates, and recovered grammar nodes are rejected.
 - Python accepts ordinary indented `if`/`elif`/`else`, with `pass` only as the source/backend representation of an otherwise empty semantic block. Truthiness, match, loops, exceptions, context managers, async/generators, nested declarations, and recovered grammar nodes are rejected.
 - C# requires braced ordinary branches and accepts a direct `else if`. Its file must have exact `#nullable enable`, file-scoped `namespace Semantifold.Generated;`, and `internal static class Program`; semantic methods are ordered synchronous `private static` methods and `Main` is the final member. Attributes, using directives, fields, properties, constructors, nested types, extra members, nullable context changes, loops, exceptions, patterns, and recovered grammar are rejected.
 - Go requires `package main`, zero or one exact unaliased `import "fmt"`, one or more ordinary top-level semantic functions, and a final zero-argument `func main()`. It accepts braced branches and direct `else if`; build directives, `init`, methods, top-level data/type declarations, user imports, loops, switches, concurrency, panic/recover, and recovered grammar nodes are rejected.
+- Swift requires synchronous top-level functions before entry statements, exactly two unlabeled explicitly typed parameters, explicit scalar returns, direct one-argument `print`, backend-representable NFC caller identifiers, and integer/Boolean equality. Ordinary String `==`/`!=` are rejected in favor of fully validated generated scalar-equality helpers. Imports, attributes, type inference, optionals, nominal declarations, generics, errors, concurrency, macros, Apple frameworks, arbitrary standard-library calls, and recovered grammar nodes are rejected. The independent review completed with this bounded correction; exact-head CI, merge, and post-merge verification remain separate delivery gates.
 
 Every local is an explicitly typed simple identifier with an initializer. Parameters are immutable. Initializers are checked before their new binding becomes visible; assignment right-hand expressions are checked before the target update. Exact scalar types are preserved. Lexical function, branch, and entry scopes reject duplicate declarations, use before declaration, unresolved reads/writes, assignment to immutable bindings, type mismatch, and all shadowing or repeated local spellings in this initial capability. Module function names participate in the same no-shadowing contract, so no parameter or local may capture a callable name. Destructuring, multiple/uninitialized declarations, inferred types, arbitrary lvalues, compound/update assignment, globals/fields/constants, and parameter reassignment are unsupported.
 
@@ -68,10 +251,12 @@ $name = "value";
 - Python requires `name: int|bool|str = expression`. Locals default to mutable; an immutable declaration has the exact immediately preceding, equally indented `# @semantifold-immutable` carrier.
 - C# requires one initialized scalar local declarator with an explicit accepted type. Locals default to mutable; an immutable declaration has exactly one immediately adjacent `// @semantifold-immutable` carrier. `const`, `var`, multiple/uninitialized declarations, and other comment carriers are rejected.
 - Go requires `var name int64|bool|string = expression`. A local is mutable only when the accepted syntax contains an assignment occurrence to that binding; otherwise it is immutable and generated Go carries the exact adjacent `// @semantifold-immutable` marker. Short declarations, inferred/uninitialized/multiple declarations, `const`, and malformed marker placement are rejected.
+- Swift requires `let|var name: Int64|Bool|String = expression`. `let` is immutable and `var` mutable under the shared assignment rules; inferred, uninitialized, tuple-pattern, property-wrapper, and multiple declarations are rejected.
+- Kotlin requires `val|var name: Long|Boolean|String = expression`. `val` is immutable and `var` mutable under the shared assignment rules; inferred, uninitialized, destructured, delegated, nullable/platform, and multiple declarations are rejected.
 
 The Ruby/PHP tags are Semantifold source-profile metadata, not native runtime immutability. Their adapters validate the exact tag shape, semantic validation rejects later writes, and generators reproduce the metadata so mutability round-trips.
 
-Expressions contain parameter/local identifiers, scalar literals, two-argument unqualified calls, and the following typed operations. Every operation node records its result type, and identifier/call operands are resolved before an operation is selected. C# generation escapes NEL (`U+0085`) as well as the other Unicode source line terminators so every semantic string remains one compilable regular string-literal token.
+Expressions contain parameter/local identifiers, scalar literals, direct unqualified calls, and the following typed operations. Task 005 calls have arbitrary positional arity in the required cohort; other languages retain two arguments. Every operation node records its result type, and identifier/call operands are resolved before an operation is selected. C# generation escapes NEL (`U+0085`) as well as the other Unicode source line terminators so every semantic string remains one compilable regular string-literal token.
 
 | Meaning | Ruby | JavaScript / TypeScript | PHP | Java |
 | --- | --- | --- | --- | --- |
@@ -82,28 +267,48 @@ Expressions contain parameter/local identifiers, scalar literals, two-argument u
 | Integer ordering | `<`, `<=`, `>`, `>=` | `<`, `<=`, `>`, `>=` | `<`, `<=`, `>`, `>=` | `<`, `<=`, `>`, `>=` |
 | String concatenation | `+` | `+` | `.` | `+` |
 
-Python uses `+`, `-`, `*`, unary `-`, `not`, `and`, `or`, `==`, `!=`, and integer ordering with explicit generated parentheses. The same-type semantic checker distinguishes Boolean from integer even though CPython makes `bool` a runtime subclass of `int`. C# uses the ordinary scalar operators, including value `==`/`!=` for all three supported scalar types, but requires exactly one `checked(...)` wrapper around every integer add, subtract, multiply, and negate. Go uses its ordinary `int64`/Boolean/string operators with explicit generated parentheses except where `gofmt` removes a redundant condition wrapper. Division, remainder, bitwise, shifts, conversions, indexing, and updates remain unsupported.
+Python uses `+`, `-`, `*`, unary `-`, `not`, `and`, `or`, `==`, `!=`, and integer ordering with explicit generated parentheses. The same-type semantic checker distinguishes Boolean from integer even though CPython makes `bool` a runtime subclass of `int`. C# uses the ordinary scalar operators, including value `==`/`!=` for all three supported scalar types, but requires exactly one `checked(...)` wrapper around every integer add, subtract, multiply, and negate. Go uses its ordinary `int64`/Boolean/string operators with explicit generated parentheses except where `gofmt` removes a redundant condition wrapper. Kotlin uses ordinary Boolean, ordering, string, and equality operators; generated integer arithmetic calls exact private checked helpers. Swift uses ordinary checked `Int64` arithmetic and Boolean operations; generated string equality uses exact `unicodeScalars.elementsEqual` helpers because native `String.==` applies canonical equivalence. Division, remainder, bitwise, shifts, conversions, indexing, and updates remain unsupported.
 
 Operands evaluate left to right, and Boolean and/or short-circuit. Conditions require semantic `boolean`; Ruby, PHP, and JavaScript truthiness is not normalized. Equality is scalar value equality only, requires matching operand types, and never coerces. Java reference `==`/`!=` on strings is rejected; generated Java uses `.equals`. Return values, call arguments, initializers, assignments, and explicit operation result types must exactly match their declared scalar types. Generated operations are parenthesized so reparsing preserves the expression tree rather than relying on coincident target precedence.
 
-Integer literals are restricted to JavaScript's safe integer range, `Number.MIN_SAFE_INTEGER` through `Number.MAX_SAFE_INTEGER`, and semantic integers have one unsigned mathematical zero. JavaScript and TypeScript can form IEEE-754 `-0` through negation or multiplication, so generated modules containing either operation stringify their scalar print argument to render both zero signs as `0`; the parser recognizes and removes only this exact entry-point scaffold during reparse. Supported operations cannot otherwise observe a zero sign, and the semantic expression tree is neither rewritten nor folded. Java generation additionally requires primitive-`int` literals and rejects compile-time-known add/subtract/multiply/negate results outside `-2147483648` through `2147483647`. C# source requires canonical decimal `long` literals with `L`; generation rejects known integer operation trees outside signed 64-bit and emits checked arithmetic. Go source uses canonical decimal `int64`-representable literals; generation rejects compile-time-known operation trees outside signed 64-bit. These checks use exact arithmetic without replacing the semantic expression tree. Runtime arithmetic overflow for non-literal expressions is not a portable result guarantee: C# raises its native checked failure, while Go retains native `int64` wrap behavior.
+Integer literals are restricted to JavaScript's safe integer range, `Number.MIN_SAFE_INTEGER` through `Number.MAX_SAFE_INTEGER`, and semantic integers have one unsigned mathematical zero. JavaScript and TypeScript can form IEEE-754 `-0` through negation or multiplication, so generated modules containing either operation stringify their scalar print argument to render both zero signs as `0`; the parser recognizes and removes only this exact entry-point scaffold during reparse. Supported operations cannot otherwise observe a zero sign, and the semantic expression tree is neither rewritten nor folded. Java generation additionally requires primitive-`int` literals and rejects compile-time-known add/subtract/multiply/negate results outside `-2147483648` through `2147483647`. Kotlin emits uppercase-`L` literals, rejects statically known results outside the semantic safe range, and checks dynamic integer arithmetic through `Math.*Exact` plus the safe bound. C# source requires canonical decimal `long` literals with `L`; generation rejects known integer operation trees outside signed 64-bit and emits checked arithmetic. Go source uses canonical decimal `int64`-representable literals; generation rejects compile-time-known operation trees outside signed 64-bit. These checks use exact arithmetic without replacing the semantic expression tree. Runtime arithmetic outside the portable range fails in Kotlin/C# and retains native wrap behavior only in Go.
 
 String literals normalize to their parser-decoded Unicode scalar value. Original quotes and escapes are not retained. PHP and Ruby interpolation, JavaScript/TypeScript template substitution, Java text blocks, PHP heredoc/nowdoc, invalid source encodings, and lone surrogate values are rejected. Backends use target-specific escaping for quotes, backslashes, controls, Unicode, and interpolation introducers. Generated source reparses to the same value.
 
-Ruby accepts exactly two required positional parameters. Optional, rest, post, keyword, keyword-rest, and block parameters remain unsupported. Its three annotation comments must form the contiguous block immediately before their function. PHP rejects every `declare` form other than one optional exact `declare(strict_types=1)`. Python rejects default, positional-only, keyword-only, variadic, keyword, and starred parameters/calls, quoted or compound annotations, bytes/f-strings/raw/triple/implicitly concatenated strings, decorators, imports, classes, comprehensions, lambdas, attributes, subscripts, and every other dynamic form. Java calls remain unqualified and `main` may not contain ignored statements. C# rejects ref/out/in/scoped/params/default parameters, named/ref arguments, generics, overloads, instance/qualified calls, lambdas/delegates, async/iterators, unsafe code, casts, interpolation/raw/verbatim strings, boxing, `dynamic`, LINQ, and every form outside the exact direct two-argument call and recognized print scaffold. Go rejects variadics, named/multiple/missing results, generic parameters, methods/receivers, qualified or non-two-argument calls, closures, raw/rune/imaginary/float literals, arrays/slices/maps/structs/interfaces/channels/pointers, `defer`, `go`, `select`, conversions, assertions, selectors, indexing, reflection, cgo, and `unsafe`.
+Ruby accepts zero or more required positional parameters. Optional, rest, post, keyword, keyword-rest, and block parameters remain unsupported. Its parameter annotations followed by one return annotation must form the contiguous block immediately before their function. PHP rejects every `declare` form other than one optional exact `declare(strict_types=1)`. Python rejects default, positional-only, keyword-only, variadic, keyword, and starred parameters/calls, quoted or compound annotations, bytes/f-strings/raw/triple/implicitly concatenated strings, decorators, imports, classes, comprehensions, lambdas, attributes, subscripts, and every other dynamic form. Java calls remain unqualified and `main` may not contain ignored statements. C# rejects ref/out/in/scoped/params/default parameters, named/ref arguments, generics, overloads, instance/qualified calls, lambdas/delegates, async/iterators, unsafe code, casts, interpolation/raw/verbatim strings, boxing, `dynamic`, LINQ, and every form outside the exact direct two-argument call and recognized print scaffold. Go rejects variadics, named/multiple/missing results, generic parameters, methods/receivers, qualified or non-two-argument calls, closures, raw/rune/imaginary/float literals, arrays/slices/maps/structs/interfaces/channels/pointers, `defer`, `go`, `select`, conversions, assertions, selectors, indexing, reflection, cgo, and `unsafe`.
 
-Backends reject target reserved words for function names, parameter names, local declarations, assignment targets, call targets, and identifier references before emission. Bindings are never renamed. C# uses a conservative ASCII identifier profile, rejects all C# 14 reserved/contextual words (including the intrinsic `__arglist`, `__makeref`, `__reftype`, and `__refvalue` spellings) and verbatim/normalization-sensitive spellings, reserves semantic method names `Main`, `Program`, and `System`, and forbids parameter/local capture of `System`; ordinary `args` remains legal outside the fixed zero-argument entry scaffold. `System` is also a method collision because the native compiler resolves generated `System.Console` against that member and reports CS0119. C# semantic function names also cannot hide inherited `object` members: `Equals`, `Finalize`, `GetHashCode`, `GetType`, `MemberwiseClone`, `ReferenceEquals`, and `ToString` are rejected before warnings-as-errors compilation. This inherited-member restriction is function-specific, so those spellings remain valid for parameters and locals. Go uses a conservative ASCII identifier profile, rejects all Go keywords plus `_`, and reserves `main`, `fmt`, `int64`, `bool`, `string`, and `true`/`false` where generated scaffolding or predeclared identities would be captured. Python accepts Unicode XID spelling but rejects hard/soft keywords and the annotation/entry capture hazards `_`, `match`, `case`, `type`, `int`, `bool`, `str`, and `print`. TypeScript rejects `arguments` and `eval` for function, parameter, local-declaration, and assignment-target bindings because generated modules are strict mode. PHP rejects exact `GLOBALS`, `_SERVER`, `_GET`, `_POST`, `_FILES`, `_COOKIE`, `_SESSION`, `_REQUEST`, `_ENV`, and `this` parameter bindings; only exact `GLOBALS` and `this` are also rejected for local declarations and assignment targets. PHP function/call names, lowercase near-collisions, assignable non-`GLOBALS` superglobals, and ordinary predefined variables retain their legal roles. Ruby rejects exact `_1` through `_9` function, parameter, local-declaration, and assignment-target bindings while retaining `_10`; references and callees keep their general target identifier policy. JavaScript and other targets retain their own identifier policies. Names owned by generated scaffolding are role-specific: entry locals cannot be `console` in JavaScript/TypeScript or `args`/`System` in Java; function parameters and locals cannot be the generated print receiver `console` in JavaScript/TypeScript or `System` in Java/C#; and module functions cannot be `console` in JavaScript/TypeScript, `puts` in Ruby, `main`/`fmt` in Go, or the C# method/scaffolding collisions listed above. Ruby locals named `puts` and PHP locals named `PHP_EOL` remain valid because the generated print forms do not resolve them as local bindings. Java method names and PHP function names occupy namespaces that do not capture their entry scaffolding. PHP and C# Boolean printing are target-native; cross-language assertions therefore use integer/string results rather than claiming portable Boolean display formatting.
+Backends reject target reserved words for function names, parameter names, local declarations, assignment targets, call targets, and identifier references before emission. Bindings are never renamed. C# uses a conservative ASCII identifier profile, rejects all C# 14 reserved/contextual words (including the intrinsic `__arglist`, `__makeref`, `__reftype`, and `__refvalue` spellings) and verbatim/normalization-sensitive spellings, reserves semantic method names `Main`, `Program`, and `System`, and forbids parameter/local capture of `System`; ordinary `args` remains legal outside the fixed zero-argument entry scaffold. `System` is also a method collision because the native compiler resolves generated `System.Console` against that member and reports CS0119. C# semantic function names also cannot hide inherited `object` members: `Equals`, `Finalize`, `GetHashCode`, `GetType`, `MemberwiseClone`, `ReferenceEquals`, and `ToString` are rejected before warnings-as-errors compilation. This inherited-member restriction is function-specific, so those spellings remain valid for parameters and locals. Go uses a conservative ASCII identifier profile, rejects all Go keywords plus `_`, and reserves `main`, `fmt`, `int64`, `bool`, `string`, and `true`/`false` where generated scaffolding or predeclared identities would be captured. Python accepts Unicode XID spelling but rejects hard/soft keywords and the annotation/entry capture hazards `_`, `match`, `case`, `type`, `int`, `bool`, `str`, and `print`. TypeScript rejects `arguments` and `eval` for function, parameter, local-declaration, and assignment-target bindings because generated modules are strict mode. PHP rejects exact `GLOBALS`, `_SERVER`, `_GET`, `_POST`, `_FILES`, `_COOKIE`, `_SESSION`, `_REQUEST`, `_ENV`, and `this` parameter bindings; only exact `GLOBALS` and `this` are also rejected for local declarations, assignment targets, and catch bindings. PHP function/call names, lowercase near-collisions, assignable non-`GLOBALS` superglobals, and ordinary predefined variables retain their legal roles. Ruby rejects exact `_1` through `_9` function, parameter, local-declaration, and assignment-target bindings while retaining `_10`; references and callees keep their general target identifier policy. JavaScript and other targets retain their own identifier policies. Names owned by generated scaffolding are role-specific: entry locals cannot be `console` in JavaScript/TypeScript or `args`/`System` in Java; function parameters and locals cannot be the generated print receiver `console` in JavaScript/TypeScript or `System` in Java/C#; and module functions cannot be `console` in JavaScript/TypeScript, `puts` in Ruby, `main`/`fmt` in Go, or the C# method/scaffolding collisions listed above. A Java parameter or local named `java` is also rejected when a collection literal in its lexical scope—including the local's own initializer—requires `java.util.List.of` or `java.util.Map.of`. Ruby locals named `puts` and PHP locals named `PHP_EOL` remain valid because the generated print forms do not resolve them as local bindings. Java method names and PHP function names occupy namespaces that do not capture their entry scaffolding. PHP and C# Boolean printing are target-native; cross-language assertions therefore use integer/string results rather than claiming portable Boolean display formatting.
+
+## Browser WebAssembly target
+
+Wasm consumes the same validated Tasks 001–004 modules but is not an implemented source-language row in the frontend table. It lowers semantic integers to checked signed `i64`, Booleans to canonical i32 zero/one, and strings to immutable UTF-8 pointer/length pairs in one fixed exported memory. Dynamic concatenation uses a checked private 1,048,576-byte scratch arena. Generation bounds malformed caller graphs before recursion, rejects compile-time-known i64 overflow module-wide, and separately rejects entry-reachable unknown or excessive scratch demand and any path that can exceed 64 active semantic calls before returning bytes. Valid JavaScript/TypeScript `$` identifiers remain valid Wasm semantic names.
+
+Binary/application generation returns `program.wasm`, `program.wasm.map`, `semantifold-loader.mjs`, and sole entry `index.html`. The versioned `semantifold.browser.v1` ABI imports only three scalar print functions and exports exactly `memory` and zero-parameter `run`. The loader has no DOM import, allocator import, WASI, memory growth, or semantic JavaScript fallback. See the [complete Browser WebAssembly target contract](webassembly.md).
 
 ## Diagnostics and limitations
 
-### Current standard-library limitation and future direction
+### Bounded standard-library portability
+
+The registered language roles cover only the semantic subset documented above. `semantifold@0.3.0` has no standard-library symbol identities, compatibility facade, or host-provider linking. The current source tree adds Task 032 condition-controlled loops, Task 033 bounded reference classes, Task 034's effect/resource foundation, Task 035's delivered versioned canonical contract/provider-linking hub from PR #45, and Task 036's delivered neutral facade qualification layer from PR #46. The published release lacks all of these additions.
+
+Task 037 adds exactly one concrete lane: Ruby source targeting PHP. The Ruby frontend accepts only literal `require "socket"`, genuine `TCPSocket.new(host, port)`, zero-argument receiver `gets` and `close`, and exactly one string argument to unqualified `puts` or `Kernel.puts`. The output builtin is resolved only inside that same parser-proved socket profile, preserving legacy Ruby program-mode `puts` elsewhere. User-defined/shadowed/reopened/monkey-patched identities, dynamic require/send, blocks, other members, extra arguments, coercive or multi-value output, and timeout or socket options fail at their parser-backed locations.
 
-The registered language roles cover only the semantic subset documented above. `semantifold@0.2.0` does not resolve imports or map any language's native standard library; it also lacks the classes/methods, loops, optionals, typed errors, resources, and host operations required for that work. Planned portability uses a language compatibility stdlib/facade, canonical Semantifold stdlib contract/capability, and target host provider/native binding rather than pairwise library rewrites. See the [standard-library portability design](standard-library-portability.md) and [dependency-ordered implementation plan](plans/2026-09-05-standard-library-portability.md).
+The two executable compiler-owned Ruby facades compile through ordinary semantic IR and call only canonical `semantifold.socket-client@1.0.0`, `semantifold.text-stream@1.0.0`, `semantifold.output@1.0.0`, and `semantifold.resource@1.0.0` operations. Generated PHP requires the canonical `php82` runtime profile and core streams. Only provider artifacts may invoke native `fsockopen`, `fgets`, `feof`, `fclose`, and stdout; application and facade source cannot resolve those protected names or inherit canonical authority. Only reachable facade/provider modules are emitted, with facade support artifacts under `semantifold/facade/ruby/` and provider artifacts under `providers/php/semantifold/`.
 
-All ten frontends preserve exact input content and parser-backed semantic token ranges in module provenance. The original-six 36-combination matrix remains byte-characterized; Tasks 017–019 and 024 add their own native/managed and original-five crossing coverage. Go's `main.go` has complete range-based rich/v3 mappings; manifest-first `go.mod` has synthetic configuration provenance related to the module root. CPP's `program.cpp` maps original occurrences and synthetic inline support/ordered regions. Output text uses LF deterministically. Only JavaScript and TypeScript may opt into inline or external `sourceMappingURL` directives; C#, Go, C and CPP reject unsupported mapping directive/filename options instead of silently dropping them. Mapping does not imply lossless formatting or support for syntax outside the semantic subset. See [source provenance and mappings](source-maps.md).
+Line reads block without a configurable timeout, decode incremental UTF-8, retain LF and CRLF, return the final unterminated line once, and use absence only for clean EOF. Output adds LF only when missing. Connect/read/decode/write/close failures remain typed, and either outcome of the first close attempt makes the resource terminal. TCP servers, TLS, UDP, Unix sockets, nonblocking or async I/O, cancellation, arbitrary encodings/framing, other Ruby APIs/output forms, other source facades, and other target providers remain unsupported. See the [standard-library portability design](standard-library-portability.md) and [dependency-ordered implementation plan](plans/2026-09-05-standard-library-portability.md).
 
-`UNSUPPORTED_LANGUAGE` is exclusive to unknown or misspelled IDs. `UNSUPPORTED_ROLE` reports a known ID without the requested frontend, text/binary/application backend, artifact, or interoperability role, including C#, Go, and C through a legacy single-artifact API. `UNSUPPORTED_CAPABILITY` reports a role that exists but cannot represent the requested semantic module or target feature. `UNSUPPORTED_SYNTAX` reports parsed constructs outside the subset with the best parser-provided source location. Python, C#, and Go use `MISSING_TYPE` for well-formed missing/inferred explicit types; a present unsupported type is `UNSUPPORTED_SYNTAX` at that annotation. Parser failures use `PARSE_ERROR`. Semantic resolution/type failures use `DUPLICATE_BINDING`, `UNRESOLVED_BINDING`, `USE_BEFORE_DECLARATION`, `IMMUTABLE_ASSIGNMENT`, and `TYPE_MISMATCH`; flow failures use `NON_BOOLEAN_CONDITION`, `MISSING_RETURN`, `UNREACHABLE_STATEMENT`, `ILLEGAL_RETURN_CONTEXT`, and `UNSUPPORTED_STATEMENT`. Backends validate complete recursive block shape, flow, scalar payloads, binding/type agreement, mutability, identifiers, target bounds, and fixed artifact contracts before emission. Missing or structurally invalid caller IR reports located `UNSUPPORTED_CAPABILITY` rather than leaking a native error or producing partial source. A non-`Main.java` Java basename, non-`Program.cs` C# filename, non-`main.go` Go filename, or non-`program.c` C filename uses that same contract. Artifact-set generation requires a non-empty string language/target ID and accepts only the explicit `text`, `binary`, and `application` backend-role strings; malformed IDs or roles report `INVALID_ARTIFACT_SET` without coercing caller input, while an unknown string ID reports `UNSUPPORTED_LANGUAGE` and a valid role absent from a known registry record reports `UNSUPPORTED_ROLE`. Optional registry roles and backend metadata may be omitted with `undefined`; present malformed values, including `null`, report `INVALID_REGISTRY`. Invalid registry, artifact-set, byte-map, discovery, and runner inputs have their own normalized diagnostics rather than leaking native type or subprocess errors.
+All fourteen frontends preserve exact input content and parser-backed semantic token ranges in module provenance. The original-six 36-combination matrix remains byte-characterized; Tasks 017–020 and 022–024 add their own native/managed and original-five crossing coverage. Go's `main.go` has complete range-based rich/v3 mappings; manifest-first `go.mod` has synthetic configuration provenance related to the module root. CPP, Rust, Swift, Kotlin, and Dart map original occurrences and synthetic target support. Output text uses LF deterministically. Only JavaScript and TypeScript may opt into inline or external `sourceMappingURL` directives; C#, Go, C, CPP, Rust, Swift, Kotlin, and Dart reject unsupported mapping directive/filename options instead of silently dropping them. Mapping does not imply lossless formatting or support for syntax outside the semantic subset. See [source provenance and mappings](source-maps.md).
 
-Boxed or coercive types, inferred public types, TypeScript literal/enum/`any`/`unknown`/union types, PHP aliases/nullable declarations, Ruby `boolish`, Java `Boolean`/`char`, null values, floating point, decimal, bigint, symbols, regex values, byte strings, and interpolation are unsupported. Division, remainder, exponentiation, bitwise/shift/update/compound operations, Ruby/PHP `and`/`or`, loose equality, ternary/nullish forms, optional/safe navigation, ranges, casts/assertions, collection/object equality, operator overloading, implicit coercion, and constant folding are also excluded. There is no truthiness, implicit-return or statement-value model, void call statement (roadmap task 005), optional-value model, async/generator model, qualified calls other than Java string `.equals`, classes in the semantic representation, imports, loops, switches, exceptions, overloads, generics, packages, or source-format preservation. Ruby type comments remain a bounded RBS-style convention rather than a full signature parser, and Java generation retains the fixed `Main.java` contract.
+`UNSUPPORTED_LANGUAGE` is exclusive to unknown or misspelled IDs. `UNSUPPORTED_ROLE` reports a known ID without the requested frontend, text/binary/application backend, artifact, or interoperability role, including C#, Go, C, Rust, and Dart through a legacy single-artifact API. `UNSUPPORTED_CAPABILITY` reports a role that exists but cannot represent the requested semantic module or target feature. `UNSUPPORTED_SYNTAX` reports parsed constructs outside the subset with the best parser-provided source location. Missing public annotations use `MISSING_TYPE`; a present unsupported type is `UNSUPPORTED_SYNTAX` at that annotation. Parser failures use `PARSE_ERROR`. Semantic resolution/type failures use `DUPLICATE_BINDING`, `UNRESOLVED_BINDING`, `USE_BEFORE_DECLARATION`, `IMMUTABLE_ASSIGNMENT`, and `TYPE_MISMATCH`; Task 005 additionally uses `VOID_AS_VALUE`, `VOID_RETURN_VALUE`, and `MISSING_RETURN_VALUE`. Task 033 adds `DUPLICATE_CLASS`, `DUPLICATE_PRIVATE_FIELD`, `DUPLICATE_CONSTRUCTOR`, `DUPLICATE_METHOD`, `INCOMPLETE_INITIALIZATION`, `ILLEGAL_PRIVATE_ACCESS`, `UNKNOWN_CLASS`, `INVALID_METHOD_RECEIVER`, `UNKNOWN_METHOD`, `CONSTRUCTOR_ARITY_MISMATCH`, and `METHOD_ARITY_MISMATCH`. Task 034 adds `MISSING_CAPABILITY_AUTHORITY`, `INVALID_CAPABILITY_AUTHORITY`, `UNDECLARED_EFFECT`, `UNDECLARED_FAILURE`, `INVALID_EFFECT_ORDER`, `RESOURCE_TYPE_MISMATCH`, `RESOURCE_MOVE_REQUIRED`, `INVALID_RESOURCE_TRANSFER`, `RESOURCE_ALIAS`, `INVALID_RESOURCE_BORROW`, `BORROW_ESCAPE`, `USE_AFTER_MOVE`, `USE_AFTER_CLOSE`, `RESOURCE_STATE_MISMATCH`, `LEAKED_RESOURCE`, and `FAILURE_ABSENCE_CONFLATION`; a repeated close in the bounded probe uses its declared terminal failure rather than `DOUBLE_CLOSE`. Task 035 adds `STDLIB_CONTRACT_INVALID`, `STDLIB_MODULE_UNKNOWN`, `STDLIB_OPERATION_UNDECLARED`, `STDLIB_VERSION_INCOMPATIBLE`, `STDLIB_VERSION_MALFORMED`, `STDLIB_PROVIDER_INVALID`, `STDLIB_PROVIDER_MISSING`, `STDLIB_PROVIDER_AMBIGUOUS`, `STDLIB_PROVIDER_DEPENDENCY_MISSING`, `STDLIB_PROVIDER_CYCLE`, `STDLIB_LINK_FAILURE`, and `STDLIB_NAME_COLLISION`. Task 036 adds `STDLIB_FACADE_INVALID`, `STDLIB_FACADE_IDENTITY_UNPROVED`, `STDLIB_FACADE_MEMBER_UNSUPPORTED`, `STDLIB_FACADE_VERSION_MALFORMED`, `STDLIB_FACADE_VERSION_INCOMPATIBLE`, `STDLIB_FACADE_DYNAMIC_REFERENCE`, `STDLIB_FACADE_REFLECTION_UNSUPPORTED`, `STDLIB_FACADE_NATIVE_EXTENSION_UNSUPPORTED`, `STDLIB_FACADE_SHADOWED`, `STDLIB_FACADE_REOPENED`, `STDLIB_FACADE_AUTHORITY_FORGED`, `STDLIB_FACADE_NAME_COLLISION`, `STDLIB_FACADE_DECLARATION_MISMATCH`, and `STDLIB_FACADE_DESCRIPTOR_INVALID`; Task 037 additionally uses `STDLIB_PROTECTED_BINDING_ACCESS` for portable attempts to reach canonical operations directly. Resolution failures retain parser locations, while descriptor/link failures are transactional. Flow failures use `NON_BOOLEAN_CONDITION`, `MISSING_RETURN`, `UNREACHABLE_STATEMENT`, `ILLEGAL_RETURN_CONTEXT`, `ILLEGAL_BREAK_CONTEXT`, `ILLEGAL_CONTINUE_CONTEXT`, `INVALID_LOOP_TARGET`, `CROSS_FUNCTION_LOOP_TARGET`, and `UNSUPPORTED_STATEMENT`. Backends validate complete recursive block shape, flow, scalar payloads, binding/type agreement, call resolutions, mutability, loop context, identifiers, target bounds, and fixed artifact contracts before emission. Missing or structurally invalid caller IR reports located `UNSUPPORTED_CAPABILITY` rather than leaking a native error or producing partial source. A non-`Main.java` Java basename, non-`Program.cs` C# filename, non-`main.go` Go filename, non-`program.c` C filename, or non-`src/main.rs` Rust filename, non-`bin/program.dart` Dart filename uses that same contract. Artifact-set generation requires a non-empty string language/target ID and accepts only the explicit `text`, `binary`, and `application` backend-role strings; malformed IDs or roles report `INVALID_ARTIFACT_SET` without coercing caller input, while an unknown string ID reports `UNSUPPORTED_LANGUAGE` and a valid role absent from a known registry record reports `UNSUPPORTED_ROLE`. Optional registry roles and backend metadata may be omitted with `undefined`; present malformed values, including `null`, report `INVALID_REGISTRY`. Invalid registry, artifact-set, byte-map, discovery, and runner inputs have their own normalized diagnostics rather than leaking native type or subprocess errors.
+
+Boxed or coercive types, inferred public types, TypeScript literal/enum/`any`/`unknown`/arbitrary-union types, PHP aliases or implicit nullable declarations, Ruby `boolish`, Java `Boolean`/`char`, universal null values, floating point, decimal, bigint, symbols, regex values, byte strings, and interpolation are unsupported. Division, remainder, exponentiation, bitwise/shift/update/compound operations, Ruby/PHP `and`/`or`, loose equality, ternary/nullish forms, optional/safe navigation, ranges, general casts/assertions, collection/object equality, operator overloading, implicit coercion, and constant folding are also excluded; the sole assertion exception is Task 006's exact TypeScript `Map#get(...)!` wrapper, whose lookup must be independently total. Task 007 supplies only the exact explicit optional model, Task 008 only exact ordered list loops, Task 010 only explicit supplied source projects, Task 011 only the exact nominal unchecked-error model above, Task 012 only the exact unbounded invariant generic profile above, Task 014 only the exact ordered-map pair loop above, Task 032 only the exact strict-Boolean precondition loop above, Task 033 only the exact closed reference-class profile above, and Task 034 only the explicit single-module probe effect/resource profile above. There is no truthiness, implicit-return or general statement-value model, async/generator model, open/inherited/virtual class model, implicit import discovery, post-condition/basic/range loops, arbitrary or ordinary-map iteration, switches, exception behavior beyond Task 011 and declared Task 034 failures, overloads, advanced generic/effect type systems, implicit resource cleanup, unsafe native handles, package-manager resolution, or source-format preservation. The sole value-free expression statements are resolved void function and method calls in the original-five cohort. Ruby type comments remain a bounded RBS-style convention rather than a full signature parser, and single-module Java generation retains the fixed `Main.java` contract.
 
 CPP uses its own [C++20 scalar and scaffold profile](cpp.md), official CPP grammar, one `program.cpp`, by-value owned strings and checked arithmetic. The shared native occurrence planner is backend-only; CPP owns its exact marker and CST recognizer. Native O0/O2 and ASan/UBSan/leak execution are mandatory.
+
+## Rust edition 2021
+
+Rust uses the existing private frozen CST schema with official grammar 0.23.1 and Tree-sitter 0.21.1. A dedicated frontend consumes every named, anonymous, extra, attribute and macro child. Only complete validated helper definitions authorize print/overflow calls; marker comments never do. User references, raw pointers, lifetimes, patterns, inference, tail returns, generics, user types, modules/use/impl/traits, unsafe/extern, closures/async, const/static, loops/match/ranges/casts/indexing, custom dispatch, turbofish, arbitrary macros/attributes, Result/Option/question-mark and panic/assert/unwrap/expect/catch_unwind are rejected.
+
+Owned strings retain value semantics. Explicit source clones and concat borrows collapse without adding IR nodes, while a separate flow analysis rejects later use of moved values and moves during overlapping implicit comparison borrows. Branches join only continuing paths. Generated storage/call/print copy boundaries clone strings, comparisons and concat operands borrow internally, and terminal returns transfer owned results. Compiler rejection of generated ownership is a backend defect.
+
+The artifact-set API emits `Cargo.toml`, format-4 `Cargo.lock`, then rich/V3 mapped `src/main.rs`. The manifest is dependency-free, fixed to edition 2021 with a tested minimum and exact discovered pair of Rust/Cargo 1.98.1. Dev/release use identical overflow checks and aborting panics. Checked add/subtract/multiply/negate exit 70 with `semantifold: integer overflow\n`; statically known out-of-range integer and string-size results reject before emission. The frontend and backend enforce the qualified 32767 UTF-16 input bound and 512-level CST bound, including generated borrow/scalar syntax. See [Rust](rust.md) for exact source spelling, tool identities, host-failure limits and Cargo commands.

package/docs/multi-file-modules.md

@@ -0,0 +1,52 @@
+# Multi-file modules and names
+
+Task 010 adds an explicit original-five project boundary without filesystem or package discovery. `parseProgram({entryModule, sources})` receives every PHP, Ruby, JavaScript/JSDoc, TypeScript, or Java source as `{id, filename, language, source}`. All sources in one request use the same language profile. Logical IDs are stable parser-neutral identities; filenames and native module/package spellings are resolution metadata, not semantic meaning.
+
+```js
+import {generateProgramArtifactSet, parseProgram} from "semantifold"
+
+const program = parseProgram({
+  entryModule: "main",
+  sources: [{
+    id: "main",
+    filename: "main.ts",
+    language: "typescript",
+    source: `import {label} from "./labels.js"
+console.log(label("Ada"))
+`
+  }, {
+    id: "labels",
+    filename: "labels.ts",
+    language: "typescript",
+    source: `export function label(value: string): string { return value }
+`
+  }]
+})
+
+const artifacts = generateProgramArtifactSet({language: "java", program})
+```
+
+The returned `SemanticProgram` contains dependency-first `modules`, the selected `entryModule`, and the complete caller-order source registry. Each program module has its logical `id`, `sourceFilename`, stable module-qualified declaration IDs such as `labels#function:0`, explicit resolved `imports` and `exports`, and an entry point only when selected. Identity rebasing changes only declaration/reference identity fields; equal literal, name, and filename strings remain source data. Imports retain the remote declaration identity separately from their source-local binding name. Record types, calls, and member reads continue to resolve by semantic declaration identity. Import/export nodes and generated artifacts retain filename-bearing rich and Source Map v3 provenance; aliased ESM exported names map to the exact `SemanticExport` `exportedName` token.
+
+Source-profile qualifiers such as Ruby `Labels.label` or Java `Labels.label` remain source spelling and provenance, not target bindings. When emitting an unqualified-import target, generation chooses the imported declaration name by identity; genuine ESM/PHP local aliases remain explicit bindings and are preserved where the target can represent them.
+
+`generateProgramArtifactSet` validates the complete graph, dense non-empty selected entry body, source-owned canonical module/header/node locations, declaration visibility, and every target layout before it allocates a writer. It returns the existing immutable `GeneratedArtifactSet` envelope in deterministic dependency order with exactly one entry artifact and never writes files. JavaScript and TypeScript include a synthetic `package.json` declaring ESM, followed by one `.js` or `.ts` artifact per semantic module. Ruby emits one `.rb` file per module with literal `require_relative`, one module wrapper, the canonical module-function profile, and explicit private method/constant markers for unexported declarations. PHP emits one `.php` file per namespace with explicit `use`/`use function` bindings and matching literal `require_once __DIR__` edges; because top-level namespace declarations have no module-private visibility, a module containing an unexported declaration is rejected. Java emits package-directory `.java` files with a selected public `Main`, public exported classes/methods, package-private unexported record classes, and private-static unexported functions.
+
+The accepted source profiles are deliberately narrow:
+
+- JavaScript and TypeScript use relative named ESM imports/exports. Type-only imports may name records only in semantic type positions; a declaration available only through type-only imports cannot be constructed, while a separate value import remains valid for construction. Type-only exports are explicitly outside this profile. Default, star, dynamic, side-effect-only, bare-package, attributed and CommonJS forms, re-exports, namespaces, ambient modules, export assignment, and path aliases are rejected.
+- Ruby uses literal `require_relative`, exactly one simple module, explicit qualified record/function references, and `module_function`; generated exact `private_class_method`/`private_constant` markers preserve unexported declarations on reparse. Gems, load paths, dynamic require, autoload, mixins, cross-file module reopening, and top-level constant fallback are rejected.
+- PHP uses one unbracketed namespace, explicit ungrouped class/function imports, and literal `require_once __DIR__` paths. Include paths, Composer/autoload, dynamic or other include/require forms, grouped uses, namespace fallback, and multiple namespace blocks are rejected.
+- Java uses one package, direct non-static non-wildcard imports, and one matching final class/file; exported/entry classes are public while an unexported record class may be package-private. Duplicate fully qualified native class identities are rejected before import resolution. JPMS, classpath discovery, unnamed-package mixing, split or mismatched packages, annotations, and multiple public classes are rejected.
+
+Module IDs, export names, import bindings, visibility and kinds must be unique and resolved. Exactly one supplied module is selected as a non-empty entry. All dependency cycles are rejected. Target-reserved module/declaration names, case-folded PHP collisions, unsafe or colliding paths, and unavailable Java public-file layouts fail with a located diagnostic. ESM export aliases, including aliases beside a same-name direct export, are preserved by JavaScript/TypeScript; targets without an equivalent public alias reject them instead of changing behavior.
+
+This API never reads source files, searches load paths/classpaths, resolves packages or networks, invokes a package manager, writes output, flattens modules, or returns a partial artifact set. Package/provider and standard-library work remains outside Task 010. Existing `parse`, `generate`, `generateArtifact`, and single-module `generateArtifactSet` behavior is unchanged; callers opt into projects only by using the two new APIs.
+
+## Compiler-owned standard-library modules
+
+Tasks 036–037 extend the explicit program boundary without changing Task 010 source discovery. Parser-proved stdlib identities select immutable registry definitions; the compiler supplies only their dependency-first reachable facade source and compiles it through the ordinary frontend, semantic validation, and target backend. Caller sources cannot use a compiler-owned module ID or artifact path, forge the facade descriptor, provide capability authority to application modules, import a protected provider, or inherit authority by importing or calling a facade.
+
+Task 037's Ruby profile recognizes only exact literal `require "socket"` and the genuine bounded `TCPSocket`/`puts` bindings. The selected application binding and the exact compiler-owned socket class are the only reference-class exception admitted in a semantic program; ordinary caller-owned Task 010 class modules remain rejected. The two generated facade support paths are `semantifold/facade/ruby/socket.php` and `semantifold/facade/ruby/output.php`. Reachable canonical requirements select distinct provider paths under `providers/php/semantifold/`: `socket-client.php`, `text-stream.php`, `output.php`, and `resource.php` as required. Provider artifacts have protected synthetic provenance; application and facade artifacts retain their separate mapped sources.
+
+Artifact planning validates the complete source/facade/contract/provider/runtime/path/namespace/provenance/mapping graph before exposing the immutable set. Repeated generation compares every path, byte, mapping, provenance record, role, and metadata value. Missing or incompatible capabilities, forged descriptors, protected access, provider-path collisions, duplicate paths, or any late validation failure return no partial artifact set.