semantifold 0.1.1 → 0.3.0

package/docs/architecture.md

@@ -2,11 +2,25 @@
 
 Semantifold has three explicit layers.
 
-1. Frontend adapters in `src/frontends/` invoke mature language parsers and translate only recognized syntax. Babel owns JavaScript and TypeScript parsing, `php-parser` owns PHP, Prism owns Ruby, and Lezer owns Java. Their AST/CST objects never appear in the public API. Adapters enumerate supported children and reject every other parser node; filtering syntax away is not a normalization strategy. Prism node offsets and comment byte ranges are converted from UTF-8 to JavaScript UTF-16 offsets before semantic location construction and metadata source slicing.
+Task 018's C path follows these layers through the unchanged root-bundled private legacy CST boundary. `src/frontends/c.js` owns all C trees and exhaustive profile validation. `src/backends/native-validation.js` checks native graph/location limits and `c-validation.js` checks C memory limits; `ordered-expressions.js` plans occurrence-specific evaluation without modifying IR; `c.js` emits mapped `program.c`; and `c-runtime.js` supplies the synthetic immutable-slice/arena header. The C frontend reconstructs candidates only from complete CST regions, resolves them with the existing semantic validator, and compares the original whole CST against the re-parsed canonical backend plan before returning a module. This same-language validation keeps target generation free of parser objects. See the [C profile](c.md).
+
+1. Frontend adapters in `src/frontends/` invoke mature language parsers and translate only recognized syntax. Babel owns JavaScript and TypeScript parsing, `php-parser` owns PHP, Prism owns Ruby, Lezer owns Java, and the exact official `tree-sitter` binding with the official Python, C#, or Go grammar owns those languages. Their AST/CST objects never appear in the public API. Adapters enumerate supported children and reject every other parser node; filtering syntax away is not a normalization strategy. Prism node offsets and comment byte ranges are converted from UTF-8 to JavaScript UTF-16 offsets before semantic location construction and metadata source slicing. The Node Tree-sitter binding feeds strings as UTF-16LE and exposes code-unit indexes; its adapters reject lone surrogates, exhaustively traverse named/anonymous/comment/directive/error/missing children, and verify boundaries through the shared UTF-8-byte-to-UTF-16 converter. The Go adapter additionally collapses only exact `package main`, optional `fmt`, ordered semantic functions, and a final zero-argument `func main()` into the shared module/entry shape; assignment occurrences, not Go's uniformly mutable `var` syntax, determine semantic local mutability.
 2. `src/semantic/` defines the shared JSDoc-typed discriminated representation and one-based, filename-bearing UTF-16 source locations. `provenance.js` indexes exact source content, deterministic semantic paths/node IDs, resolved symbol IDs, parser-token subranges, and closed source/derived/synthetic origins without exposing parser objects. Scalar types are exact `integer`, `boolean`, or `string` references. Literal nodes carry JavaScript-safe integer, primitive boolean, or parser-decoded Unicode scalar values. Unary and binary expressions carry a closed semantic `operation` and explicit result `type`, never a source operator symbol. Every function, entry point, consequent, and alternate owns a located `Block` containing ordered `Statement` nodes. Statements are local declarations, assignments, conditionals, explicit returns, or prints; an `IfStatement` has a Boolean condition, a consequent block, and an optional alternate block. Source-spelled `else if`, `elsif`, and `elseif` normalize to an alternate block containing one nested conditional.
-3. Source backends in `src/backends/` validate their semantic capabilities before emitting target syntax. Shared validation owns recursive block shape, reachability and all-path return analysis, recursively complete expressions, exhaustive operation/type signatures, function signatures, lexical binding scopes, mutability, declaration-before-use, and strict condition/return/argument/initializer/assignment types. Target-specific validation adds identifier rules, entry-scaffolding name collisions, Java's signed 32-bit `int` literal and compile-time-known arithmetic range, and target string escaping. Every emitter recursively writes blocks and statements through `SourceWriter`; semantic tokens, target anchors, and synthetic layout are mapped as they are emitted. A backend either returns a complete executable program or raises `UNSUPPORTED_CAPABILITY`; it never silently drops nodes or lets an emitter discover malformed shape through a `TypeError`.
+3. Source backends in `src/backends/` validate their semantic capabilities before emitting target syntax. Shared validation owns recursive block shape, reachability and all-path return analysis, recursively complete expressions, exhaustive operation/type signatures, function signatures, lexical binding scopes, mutability, declaration-before-use, and strict condition/return/argument/initializer/assignment types. Target-specific validation adds identifier rules, entry-scaffolding name collisions, Java's signed 32-bit `int` range, C#'s checked signed-64-bit operation range, Go's known signed-64-bit range and round-trip mutability rule, and target string escaping. Every emitter recursively writes blocks and statements through `SourceWriter`; semantic tokens, target anchors, and synthetic layout are mapped as they are emitted. The C# backend validates the complete module and all filename/map options first, writes mapped `Program.cs`, constructs fixed source-free `Semantifold.csproj`, and submits one ordered candidate set for transactional validation. The Go backend likewise validates before writing, then returns fixed synthetic `go.mod` followed by mapped, gofmt-stable `main.go`; manifest-first ordering lets native setup inspect configuration before source without exposing either artifact early. A backend either returns a complete executable program/project or raises `UNSUPPORTED_CAPABILITY`; it never silently drops nodes, exposes a partial artifact, or lets an emitter discover malformed shape through a `TypeError`.
+
+`src/language-registry.js` is the sole ordered dispatch and discovery source. Its deeply frozen records bind implementations to independent frontend, text-backend, binary-backend, application-backend, and interoperability roles. Public descriptors derive role booleans, artifact multiplicity, round-trip support, rich/v3/byte mapping forms, and acceptance stages/toolchains from those records; `supportedLanguages` is the derived compatibility view containing IDs with both a frontend and text backend. Duplicate IDs, unknown record fields, malformed capabilities, and unordered acceptance stages fail as `INVALID_REGISTRY`.
+
+`index.js` is the public boundary. `parse({language, filename, source})` resolves only the frontend role. `generate({language, module})` and `generateArtifact(...)` resolve a single-text backend, validate the full module, and preserve the compatibility source/artifact contracts; they intentionally reject the multiple-artifact C#, Go, and C backends. `generateArtifactSet(...)` is additive and is required for C#, Go, C, and other multi-artifact, binary, and application targets. It forwards filename and mapping options to a multi backend so unsupported options cannot disappear. An unknown ID is `UNSUPPORTED_LANGUAGE`; a known ID without the requested role is `UNSUPPORTED_ROLE`; `UNSUPPORTED_CAPABILITY` remains a backend-with-role rejection of the requested semantic content. `src/artifacts.js` owns transactional generated-file validation, `src/binary-mapping.js` owns byte provenance, and `src/mapping.js` owns text lookup, serialization, import/composition, and diagnostic remapping.
+
+`src/toolchains.js` resolves configured absolute overrides or one unambiguous canonical PATH executable, runs a bounded version command, and returns its exact real path and captured version. The `dotnet` contract accepts SDK major 10 through `SEMANTIFOLD_DOTNET` or canonical `dotnet`; the `go` contract accepts only Go 1.26.x on Linux/amd64 through `SEMANTIFOLD_GO` or canonical `go`, with `gofmt` taken from the same GOROOT. `src/acceptance.js` validates all artifacts and ordered stages—including the distinct `restore` stage between generation and compilation—before filesystem mutation, materializes only safe generated paths in a unique temporary directory, invokes exact executable/argument arrays without a shell, fixes `LANG`, `LC_ALL`, and `TZ`, captures output, distinguishes discovery/version/launch/timeout/nonzero failures, records the precise failed stage, and removes the directory. Go acceptance uses isolated caches with downloads, cgo, workspaces, and automatic toolchain selection disabled. The runner performs no network discovery, installation, or runtime download.
+
+## Future standard-library portability
 
-`index.js` is the public boundary. `parse({language, filename, source})` dispatches to an adapter. `generate({language, module})` validates and returns the compatibility source string. `generateArtifact(...)` uses the same emission path and returns code plus rich and v3 mappings. `src/mapping.js` owns validated lookup, deterministic serialization, mapping import/composition, and diagnostic remapping.
+Standard-library portability is a planned extension of these layers, not current behavior. A frontend will substitute a source-language **language compatibility stdlib/facade** only after parser-backed module resolution proves the native library and symbol identity. The facade is portable executable source that enters the same frontend and semantic layers as application code. It calls a versioned **canonical Semantifold stdlib contract/capability**, never a target API or pair-specific bridge.
+
+Artifact generation will compile the application and only its used compatibility modules, then link only the required **target host provider/native binding** modules. Providers implement canonical capabilities with the target's genuine native stdlib behind a protected host-native boundary unavailable to ordinary application and facade code; that isolation also prevents same-language generation from recursively selecting its own compatibility facade. Contract and target validation must finish before any artifact is exposed. Unsupported source identity, source APIs, target capabilities, or semantic mismatches produce located diagnostics rather than partial output.
+
+Generated target code may preserve source API class or function names in a collision-safe compatibility namespace or import alias while using valid target syntax. A later backend may replace a facade/provider path with direct idiomatic lowering only when equivalence is proven; it is never the correctness baseline. Linking, tree-shaking, contract precision, namespace rules, and the full compile flow are defined in the [authoritative standard-library portability design](standard-library-portability.md).
 
 ## Round trips
 
@@ -24,7 +38,7 @@ Frontend source capabilities and backend target capabilities are intentionally s
 
 Binary operands evaluate left to right. `BooleanAnd` and `BooleanOr` are short-circuit operations. Equality accepts only two operands of the same supported scalar type and means scalar value equality. Semantic integers are mathematical integers with one unsigned zero; IEEE-754 signed zero is not a distinct semantic value. Backends map meaning rather than copying syntax: PHP concatenation is `.`, Java string equality is `.equals`, JavaScript/TypeScript/PHP equality is strict, and other operations use their target's matching native construct. Because supported operations cannot otherwise distinguish signed zero, JavaScript and TypeScript canonically stringify observable scalar output when a module contains integer negation or multiplication. Their frontends unwrap that exact parser-native output scaffold during generated-source reparse, retaining the original operation tree without constant folding. Every emitted operation is conservatively parenthesized; generated-source reparsing reconstructs the same semantic tree.
 
-A source-valid semantic name can be rejected for a target reserved word, and a safe semantic integer can be rejected by Java's narrower `int` range. Java validates literal-only integer operation trees with exact mathematical integers without folding the IR, rejecting known results outside signed 32-bit `int`; unknown runtime overflow remains outside the portable guarantee.
+A source-valid semantic name can be rejected for a target reserved word, and a safe semantic integer can be rejected by Java's narrower `int` range. Java validates literal-only integer operation trees with exact mathematical integers without folding the IR, rejecting known results outside signed 32-bit `int`. C# performs the same proof against signed 64-bit and emits an exact `checked(...)` wrapper for every integer arithmetic/negate operation while the project also enables overflow checking. Go performs the signed-64-bit proof without folding, but non-literal runtime overflow retains native `int64` wrap behavior and remains outside the portable result guarantee.
 
 ## Blocks, flow, and bindings
 
@@ -34,6 +48,10 @@ Binding identity is resolver-owned and exposed as deterministic module-local str
 
 ## Provenance and generated mappings
 
-Frontend offsets remain parser-owned. Babel token positions, php-parser nodes/tokens, Prism byte locations/comment carriers, and Lezer syntax nodes provide exact function, parameter, local, type, assignment, literal, call, and operator ranges. The JavaScript/TypeScript adapter indexes Babel tokens once by start offset, using direct identifier lookup and bounded binary-search token lookup instead of rescanning the full token stream per semantic node. Source normalization converts only coordinates; it never normalizes source content. CRLF and lone CR count as line breaks and Ruby byte offsets become UTF-16 offsets.
+Frontend offsets remain parser-owned. Babel token positions, php-parser nodes/tokens, Prism byte locations/comment carriers, Lezer syntax nodes, and Tree-sitter Python/C#/Go/C/CPP named and anonymous nodes provide exact function, parameter, local, type, assignment, literal, call, branch, and operator ranges. Every Tree-sitter adapter traverses every child, rejects propagated error/missing recovery, and never substitutes source-text parsing after a rejected tree node. The JavaScript/TypeScript adapter indexes Babel tokens once by start offset, using direct identifier lookup and bounded binary-search token lookup instead of rescanning the full token stream per semantic node. Source normalization converts only coordinates; it never normalizes source content. CRLF and lone CR count as line breaks and parser coordinates become verified UTF-16 offsets.
 
 Each semantic node carries a JSON-safe source-provenance association through reorder, insertion, deletion, cloning, and serialization. Generation rebuilds canonical paths and node/symbol identities from current traversal and validates any serialized caller provenance before use; aggregate path/kind coincidence is never used to associate a different node. Shared caller objects receive deterministic occurrence records keyed by current JSON Pointer, so reused parameters, types, expressions, and valid statements do not collapse distinct emitted locations. Malformed caller registries, including empty source filenames, are discarded before canonical source fallback. This permits legacy and multi-source caller IR while preventing duplicate/stale IDs, mismatched source ownership, or out-of-bounds ranges from becoming semantic authority. The source-aware writer makes all output spans explicit, retains every contextual origin range across composition boundaries, and leaves no coarse legacy emitter path. Rich maps are frozen and indexed after validation; generated, original, node, and symbol queries include contextual related provenance without duplicate spans. See [source provenance and mappings](source-maps.md).
+
+## Task019 CPP integration
+
+`src/frontends/cpp.js` independently consumes official CPP snapshots and validates exact qualified types, condition clauses, inline support and CPP ordered regions. `src/backends/cpp.js` emits one mapped `program.cpp`; `cpp-runtime.js` owns fixed C++20 libstdc++ support and `cpp-validation.js` proves known owned-value sizes. C and CPP reuse `ordered-expressions.js` for occurrence planning/signatures and `native-validation.js` for bounded graphs, with the owning language preserved in diagnostics. The CPP frontend compares complete CPP CST structure against its canonical CPP output; it never calls the C frontend. The private runtime explicitly selects its official grammar and exports only frozen parser-neutral values. No semantic IR, standalone package identity, parser export, artifact contract or standard-library architecture is expanded. See the [CPP profile](cpp.md).

package/docs/c.md

@@ -0,0 +1,60 @@
+# C source and native target profile
+
+Task 018 implements the existing Tasks 001–004 semantic subset as independent language `c`. Use `parse({language: "c", filename, source})` and `generateArtifactSet({language: "c", module})`. Generation returns mapped `program.c` first and synthetic support artifact `semantifold_runtime.h` second, with deterministic LF content. Only an omitted filename or exact `program.c` is accepted. Mapping filename/directive options are rejected. Single-artifact generation reports `UNSUPPORTED_ROLE`; C has no binary-backend, interoperability, project-graph, or FFI role.
+
+## Scalars, arithmetic and lifetime
+
+| Semantic value | Exact C representation | Rules |
+| --- | --- | --- |
+| `integer` | `int64_t` | Safe nonnegative decimal literal payloads; negative values are unary negation. Generated literals use `INT64_C`. |
+| `boolean` | `bool` | Exact `true`/`false`; no integer conversion or truthiness. |
+| `string` | `SemantifoldString` | Immutable `const unsigned char *data` plus `size_t length`, containing valid UTF-8 bytes including embedded NUL. |
+
+The qualified ABI is Linux x86-64: eight-bit bytes, 64-bit `int64_t` and `size_t`, `PTRDIFF_MAX == INT64_MAX`, and eight bytes of arena metadata per allocation. Header static assertions enforce these assumptions at compilation. Caller identifiers begin with an ASCII letter and continue with ASCII letters, digits or underscores. C keywords, imported standard-header names/types/macros, implementation-reserved names, and the `semantifold_`, `SEMANTIFOLD_` and `Semantifold` namespaces are protected in both directions; generation never renames a collision.
+
+Boolean literals must have exact lowercase `true`/`false` spelling. The frozen grammar also classifies `TRUE`/`FALSE` expression tokens as Booleans, so those uppercase spellings are rejected as both expressions and caller identifiers, including parameters, locals and functions. They are not aliases or implicit constants. The imported `<limits.h>` macro `MB_LEN_MAX` is also reserved in both directions; a target collision receives a located `UNSUPPORTED_CAPABILITY` before any artifact is returned.
+
+Every add, subtract, multiply and negate uses a checked helper. Clang overflow builtins detect signed-64-bit overflow without evaluating undefined signed arithmetic; negation is checked subtraction from zero. Known literal arithmetic outside signed 64-bit is rejected with `UNSUPPORTED_CAPABILITY` before generation. Dynamic overflow cleans the arena, writes exactly `semantifold: integer overflow\n` to stderr and exits with status 70. This is a target failure boundary outside semantic user control; it does not add exceptions or wider portable integer guarantees to the IR. `INT64_MIN` prints correctly using unsigned magnitude conversion. A negative or negative-zero `IntegerLiteral` payload is rejected; unary negation remains a supported operation.
+
+`SEMANTIFOLD_STRING("...")` borrows a static C string-literal array, excluding its terminating byte by `sizeof(literal) - 1`. The strict C17 profile limits each decoded literal to 4095 UTF-8 bytes; larger literal objects fail before artifacts. Runtime concatenations can exceed that literal translation limit. Generated tokens encode each UTF-8 byte with three-digit octal escapes, avoiding locale changes, escape munching and embedded-NUL truncation. The frontend decodes only parser-owned ordinary string content and valid simple/octal/hex byte escapes, then verifies complete UTF-8. Copies, parameter passing and returns copy only the descriptor. They do not allocate, mutate, transfer ownership, or end the underlying lifetime.
+
+A hexadecimal escape must end at the same boundary in C and the parser. The frozen grammar consumes at most four hex digits per escape node, while C consumes every following hex digit. An escape followed immediately by a parser-owned content node starting with another hex digit is therefore rejected with located `UNSUPPORTED_SYNTAX`, even if its numeric value would fit in a byte. For example, `"\x000041"` is rejected rather than decoded as NUL plus `41`; native C produces `A`. Bounded byte escapes such as `"\x41"`, `"\x0041"` and `"\x43G"`, separate escaped UTF-8 bytes, octal escapes and embedded NUL remain supported. No source reparsing or dependency modification repairs a split escape.
+
+Each concatenation allocates one arena node, including empty concatenations. The requested object contains the metadata plus exactly the two explicit byte lengths; it does not require a string terminator. Before allocation, the header checks each length, their sum, metadata addition and cumulative arena accounting against `PTRDIFF_MAX`. It then checks `malloc`, links the owned node and copies nonempty byte ranges. Known literal/local length growth and known allocation lower bounds receive corresponding preflight checks without rewriting the semantic IR. Unknown lengths remain checked at runtime. Size failure writes `semantifold: allocation size\n`; allocation failure writes `semantifold: allocation failure\n`. Both clean existing allocations and exit 70.
+
+Canonical `main` calls `semantifold_cleanup()` once after semantic entry statements and returns zero. Cleanup frees each owned node and clears the arena. Returned slices and branch-local descriptor copies therefore remain valid until entry completion. The same cleanup runs before every generated fatal exit. No allocation hook, pointer operation, free, lifetime choice or ownership state is exposed to portable code. Printing uses `fwrite` with explicit lengths, canonical ASCII integer/boolean formatting and one LF. Output failure follows the same fatal policy with `semantifold: output failure\n`; stdout is flushed after each print.
+
+## Accepted source and complete CST validation
+
+The unchanged root-bundled private legacy boundary supplies recursively frozen C CST data from exact `tree-sitter@0.21.1` and `tree-sitter-c@0.23.2`. `src/frontends/c-parser.js` describes that private plain-data boundary; native handles and parser-specific objects never enter semantic values. Every child, field, anonymous token, extra, error, missing node and recovery flag is traversed before meaning is returned. Coordinates and token origins refer to the original UTF-16 source, including astral characters and CRLF. There is no parser-source scan, compiler-based interpretation, preprocessing fallback or source-text recovery.
+
+Ordinary source contains the exact support-header include, at least one `static` semantic function with two named explicitly typed parameters, and final `int main(void)`. Functions return exact scalars. Bodies admit initialized single scalar locals, plain assignment, prints through the matching scalar helper, explicit returns and braced conditionals, including `else if`. `const` locals are immutable; other locals are mutable, and parameters are immutable. Main ends with the exact cleanup call and `return 0`. Raw calls must refer to a preceding or current function definition. Caller-authored forward calls requiring implicit C declarations are rejected; canonical generated prototypes support forward calls and recursion.
+
+Only direct semantic calls and the exact scalar/literal/print helpers are recognized. Caller-authored calls nested in an operator operand or another call's argument are rejected because ordinary C does not establish the required semantic evaluation order. Trigraph preprocessing in parser-backed comments or string content is rejected. No user preprocessing, typedef substitution, global data, complex/multiple declarator, qualifier beyond local `const`, array, struct, union, enum, pointer, function pointer, cast, address/dereference, member access, ownership call, `sizeof`, comma/ternary, loop, switch, goto, update, compound operator, conversion or arbitrary external call is accepted.
+
+The nested-call restriction includes every scalar helper: checked integer add/subtract/multiply/negate and string concat/equal/not-equal. Helper syntax does not prove ordering; allocation and checked-operation failures are observable. Only the exact `INT64_C` and `SEMANTIFOLD_STRING` literal macros are exempt. A helper can remain the root expression of an initializer, assignment, return, print or condition, with call-free operands or literal macros. Caller code must sequence helper results into locals before passing them to another helper/callee or using them inside unary/binary expressions. For example, `return semantifold_integer_add(left, right) + right;` is rejected at the helper call; `int64_t sum = semantifold_integer_add(left, right); return sum + right;` is supported.
+
+Generated ordered regions remain supported because the backend emits each helper as a separate temporary initializer with already-sequenced operands. The frontend reconstructs nesting from those temporary references, then still validates the complete canonical CST. A marker does not exempt an actual nested helper call from the rejection boundary. This correction and its focused RED/GREEN evidence are recorded for [PR 20](https://github.com/kaspernj/semantifold/pull/20) in the [Task 018 delivery record](../todo/018-c-source-and-target.md).
+
+Before discarding any parser-backed comment, the frontend rejects backslash-line-ending splices and line comments containing content after a lone CR. The pinned parser can otherwise hide text that native C executes, including a statement following `// comment` plus a bare CR or a block-comment terminator split by backslash-newline. This validation precedes semantic extraction and generated-region comparison. Ordinary line/block comments, exact generated markers, and normal CRLF remain supported and execute under the same strict compiler profile. A split comment opener that the grammar already rejects remains a located `PARSE_ERROR`; compiler output is never used to recover source meaning.
+
+## Ordered expressions and exact reparse
+
+After complete semantic/target validation and before creating a writer, the C backend plans each expression occurrence in semantic left-to-right order. It treats every call as potentially observable. Each call and enclosing nontrivial operation gets its exact scalar type and a consecutive six-digit name such as `semantifold_ordered_000001`. Eager left preludes precede right preludes. Short-circuit results receive a temporary initialized from the left value, an exact conditional RHS prelude and one final result write using the original `&&` or `||` operator. That token retains the original operator mapping; the generated conditional and temporary names are synthetic. The pure result then feeds the original local initializer, assignment, return, print or conditional test. Branches recursively contain their own regions. The public IR is never rewritten.
+
+Every semantic statement is surrounded by exact paired comments:
+
+```c
+/* semantifold:ordered-expression:c:v1 begin 000001 <64 lowercase hex digits> */
+/* semantifold:ordered-expression:c:v1 end 000001 <same digest> */
+```
+
+The digest is SHA-256 over the closed consumer/expression signature implemented in `ordered-expressions.js`, excluding locations. It detects changed operators/consumers; it is not an authentication mechanism or a substitute for tree validation. Generated files start with exact `/* semantifold:program:c:v1 */`, followed by the include, matching ordered prototypes, semantic definitions and main. Exact generated `(void)name;` uses prevent warnings for unused functions, parameters and locals; they are accepted only at their canonical positions.
+
+The frontend first reconstructs a private candidate from complete region child lists and direct temporary references, requiring each temporary to be consumed exactly once and rejecting duplicate declarations, extra reads and dead values before shared validation. The candidate must also meet the C graph/occurrence bounds. It then resolves semantic types, regenerates the canonical plan, parses that candidate C through the same CST boundary and compares the **entire original CST** against the canonical CST. Every significant node type, child count, field, token, marker, temporary type/number, initializer, dependency, conditional RHS, write, consumer, prototype and discard position must agree. Only ordinary comments and whitespace are ignored. No candidate module escapes before this comparison. Generated programs must use the complete canonical profile; isolated marker fragments or mixed ordinary/generated statements are rejected.
+
+Missing, duplicated, reordered, forged or wrong-version markers; extra/dead/escaping temporaries; wrong types/operators/consumers; altered scaffold casts/prototypes; and malformed semantic content inside a generated region all report located `UNSUPPORTED_SYNTAX`. Parser recovery remains `PARSE_ERROR`. Backend malformed IR, collisions, invalid required locations, cycles, target bounds and unsupported options report `UNSUPPORTED_CAPABILITY`. The unchanged legacy parser accepts at most 32,767 UTF-16 code units per source input; a direct real-parser boundary test proves success at 32,767 and its native failure at 32,768. The C frontend gives a located size diagnostic, and the backend performs an exact output-length preflight before constructing the provenance writer or exposing artifacts. It rejects generated programs above that same limit. No buffer override, parser-payload change or source trimming bypasses this boundary. The bounded C plan also rejects semantic graph depth above 512 or more than 999,999 expanded graph occurrences before recursive validation/emission; occurrence names and statement IDs never widen or wrap.
+
+Rich mappings and Source Map v3 retain original operator, call, literal, binding and final-consumer origins. All generated declarations/names/markers, prototypes, unused-binding uses, short-circuit control and cleanup are synthetic with related semantic origins. Shared IR objects receive distinct occurrence paths, temporary names and map records. The header is a synthetic artifact related to the module root.
+
+See [testing](testing.md) for package pins, portable qualification commands, strict C17 flags, mandatory O0/O2 sanitizer execution, ownership instrumentation and original-five crossings. These changes neither publish a package nor extend the standard-library portability contract.

package/docs/cpp.md

@@ -0,0 +1,61 @@
+# C++ source and target profile
+
+`cpp` is an independent frontend and single-text native backend for Tasks 001–004. The official `tree-sitter-cpp@0.23.4` grammar runs inside the existing private, root-bundled Tree-sitter 0.21.1 boundary. C uses its own grammar and profile. No compiler, preprocessor, source-mode guess or source-text recovery supplies semantic meaning.
+
+## Toolchain and artifacts
+
+Generation returns exactly `program.cpp`, including fixed inline scalar support. `generate`, `generateArtifact` and `generateArtifactSet` all support CPP. Rich and Source Map v3 data accompany the artifact; no map directive, alternate map filename, header, build file, dependency project or additional semantic module is emitted. The filename must be exactly `program.cpp`; map metadata uses `program.cpp.map` and the directive is `none`.
+
+The selected profile is C++20, Ubuntu Clang 21.1.8, Linux x86-64 (`x86_64-pc-linux-gnu`), eight-bit bytes, 64-bit int64/size/ptrdiff, and libstdc++ with its C++11 owned-string ABI (`_GLIBCXX_USE_CXX11_ABI == 1`). The canonical development lane supplies libstdc++-15-dev 15.2.0-16ubuntu1. The Noble CI lane explicitly installs g++-13 and its libstdc++-13 headers and records the installed version. These are the two image-owned library builds of the same selected standard-library/ABI profile; libc++ and the old libstdc++ string ABI are excluded. Static assertions reject incompatible native byte/ABI settings. Local execution qualifies the development build; exact-head TensorBuzz must qualify the checked-in Noble lane.
+
+Discovery ID `clangpp` uses canonical `clang++` or the absolute `SEMANTIFOLD_CLANGPP` override. In the development container use `/usr/bin/clang++-21`; the C lane retains `SEMANTIFOLD_CLANG=/usr/bin/clang-21`. Discovery resolves real paths, so compile and link both explicitly pass `--driver-mode=g++`; this preserves C++ driver semantics when clang++ is a symlink to clang. Discovery never installs or substitutes a tool.
+
+Compile flags, in addition to `-O0` or `-O2`, are:
+
+```text
+--no-default-config --driver-mode=g++ -std=c++20 -stdlib=libstdc++
+-Wall -Wextra -Werror -pedantic-errors -Wconversion -Wsign-conversion -Wshadow -Wformat=2
+-fno-exceptions -fno-rtti -ftrapv -finput-charset=UTF-8 -fexec-charset=UTF-8 -fno-color-diagnostics
+```
+
+Compilation (`-c program.cpp -o program.o`), linking (`--no-default-config --driver-mode=g++ -stdlib=libstdc++ -O0 program.o -o program`) and execution are separate stages. All stages run in a fresh directory with fixed `LANG=C.UTF-8`, `LC_ALL=C.UTF-8`, `TZ=UTC`, captured output and bounded execution. Both optimizations also run with `-g -fsanitize=address,undefined -fno-sanitize-recover=all -fno-omit-frame-pointer` at compile and link, plus `ASAN_OPTIONS=detect_leaks=1:halt_on_error=1:allocator_may_return_null=1` and `UBSAN_OPTIONS=halt_on_error=1`. Missing compilers, runtime libraries, sanitizer support, failed stages and failed cleanup are failures.
+
+## Scalar values and errors
+
+| Semantic value | Exact CPP form | Behavior |
+| --- | --- | --- |
+| integer | `std::int64_t` | JavaScript-safe nonnegative literal magnitude, explicit semantic negation, checked signed-64 arithmetic |
+| boolean | `bool` | Exact true/false, strict typed conditions, Boolean short circuit |
+| string | owned `std::string` | UTF-8 bytes, by-value locals/arguments/returns, scalar value equality |
+
+Integer literals use exact `std::int64_t(123)` construction. Bare native integers, suffixes, deduction and arbitrary casts are rejected, so a source expression cannot silently perform narrower `int` arithmetic. String literals use exact `std::string("bytes", byteCount)` construction: an ordinary parser-owned literal and a matching canonical decimal UTF-8 byte count. Raw UTF-8, supported simple byte escapes and bounded octal/hex byte escapes are decoded strictly; concatenated/prefixed/raw literals, universal escapes, invalid UTF-8 and parser-split hexadecimal escapes are rejected. Generated literals use three-digit octal bytes, preserving Unicode and embedded NUL independently of source encoding or locale. The byte count belongs only to the exact literal scaffold, not to semantic user size/pointer operations.
+
+Raw CR or LF inside an ordinary literal is rejected at its parser-owned content node, including the bare CR that the official grammar accepts as `string_content`. Clang treats that CR as a source line break. Escaped `\r`/`\n`, Unicode/NUL values, LF/CRLF source lines and CR whitespace between declarations retain their supported behavior.
+
+Add, subtract, multiply and negate use checked helpers. Known literal-only results outside signed int64 fail before artifacts; dynamic overflow writes exactly `semantifold: integer overflow\n` to stderr and exits 70. No generated arithmetic relies on signed-overflow undefined behavior. `-ftrapv` additionally protects raw caller arithmetic in the selected compiler profile; caller code needing the generated status-70 policy uses the exact checked helper forms. There is no promise to normalize native traps from arbitrary raw source execution into semantic exceptions.
+
+Strings are owned values: copying, concatenating, assigning, passing and returning them cannot expose alias identity, moved-from state, references or lifetime effects. No explicit move/borrow is generated. Fixed helpers receive by-value scalars; compiler copy elision/moves are permitted only by normal as-if semantics. String concatenation checks its native maximum size; known impossible object lengths reject before generation. Byte-counted `std::fwrite` output preserves NUL and UTF-8. Integer formatting uses unsigned magnitude and ASCII digits, including both signed extrema; Boolean output is ASCII `true`/`false`, followed by one newline. Output failure and checked string-size failure exit 70 with the corresponding fixed diagnostic.
+
+The support contains no `throw`, `try` or `catch`. Exceptions and RTTI are disabled. Library allocation exhaustion, failed allocation during value copying, stack exhaustion, library termination and external process termination are host-resource failures; they do not become portable user exceptions or semantic RAII cleanup effects. Normal successful scope exit destroys native string storage. Fatal process termination is not an unwinding contract. ASan/UBSan/leak executions cover long strings, copies, reassignment, concatenation, returns and all arithmetic fatal paths.
+
+## Accepted source and exact scaffolds
+
+A source translation unit contains the exact generated inline support, followed by namespace-scope semantic functions and one canonical final `int main() { ... return 0; }`. Each semantic function has a unique non-overloaded name, exactly two required by-value scalar parameters, explicit scalar result type and explicit returns on every path. Locals are initialized with an explicit scalar type; `const` records semantic immutability. Plain assignment, supported typed operators, exact print helper calls, braced nested/empty/fallthrough branches and `else if` normalization are supported. Caller functions must be defined before calls, apart from self-recursion. Generated exact prototypes support forward calls and mutual recursion. Namespace-scope function-address discards are unnecessary in CPP and are not emitted; unused parameters/locals use exact inert generated discards.
+
+The frontend traverses every named, anonymous, comment and field-bearing child and rejects error, missing and recovered nodes. Only complete CPP child shapes collapse: qualified `std::int64_t`/`std::string`, the precise include/support prefix, literal construction, print helpers, generated prototypes, main and ordered regions. Qualified names are resolved through CPP `scope`/`name` edges and `::`; conditions use CPP `condition_clause` nodes. Ordinary comments/whitespace may vary, but preprocessing-sensitive comments and unrecognized scaffold comments reject.
+
+The shared backend-only occurrence planner leaves semantic IR unchanged. It plans every initializer, assignment, return, print argument, call argument and condition; eager operands and arguments execute left to right. Each nontrivial occurrence gets a six-digit `semantifold_ordered_` name with exact `std::int64_t`, `bool` or owned `std::string` type. Short-circuit RHS steps stay in the corresponding conditional block.
+
+Each statement has paired `semantifold:ordered-expression:cpp:v1` comments with a deterministic statement number and semantic signature. The CPP frontend reconstructs candidate expressions, requires linear temporary consumption and exact conditional/final-consumer shapes, resolves semantic types, then compares every significant original CPP node, field and token against a newly parsed canonical CPP plan. The digest supplements this structural proof. Partial, forged, reordered, duplicate, wrong-type, wrong-number, wrong-dependency, wrong-consumer, escaping, colliding and C-tagged regions reject. Caller-authored semantic or scalar-helper calls nested in operands/arguments remain rejected; ordinary CPP syntax does not establish the portable evaluation order. Literal construction alone is pure and may nest.
+
+No templates/concepts, deduction/auto, user overloads/operators/conversions, references, pointers, arrays, classes/records/enums, constructors/destructors, inheritance/virtuals, namespaces/using outside exact support, exceptions/specifications, RTTI, casts outside exact literal/support scaffolds, initializer lists, lambdas, coroutines, ranges, user literals, macros, general standard-library calls, C compatibility mode or user build system enters semantic IR. The protected `semantifold_` namespace, implementation-reserved names/double underscores, CPP keywords and included C library names/macros are unavailable to user declarations. Standard implementation internals in exact support are not portable code or an extension of the planned stdlib architecture.
+
+CPP additionally reserves `WEOF` and `wint_t`, introduced by the qualified libstdc++ `<string>` include chain as a macro and global typedef. Functions, parameters and locals with these exact names fail target validation before any artifact is returned. This protection belongs to CPP's header environment; C keeps its existing identifier contract, and ordinary CPP names such as `WEOFValue` and `wint_type` remain valid.
+
+## Bounds, diagnostics and provenance
+
+The qualified binding accepts at most 32,767 UTF-16 code units, including all inline support, comments and whitespace. Frontend input and an exact private backend size preflight enforce that limit. Semantic graph cycles, depth above 512 and expanded occurrence counts above 999,999 reject before recursive validation/provenance; CPP CST depth is also bounded at 512. Native parser failures retain a source-file range when no finer node exists. Statically known owned string sizes above the qualified signed-64 object limit reject; native `std::string::max_size()` remains checked for runtime concatenation. This lane does not inherit C17's 4,095-byte literal limit.
+
+Malformed IR, unsupported target options/identifiers/types and unrepresentable integer/string/source bounds use `UNSUPPORTED_CAPABILITY` before any artifact. Unsupported source forms use located frontend diagnostics; malformed generated regions normalize semantic/capability failures to `UNSUPPORTED_SYNTAX`. Parser recovery uses `PARSE_ERROR`.
+
+Original operators, call targets, types and statement consumers retain rich/v3 provenance. Runtime code, prototypes, discards, marker comments, temporary declarations/uses and short-circuit control have explicit synthetic origins related to semantic occurrences. Generation/reparse is deterministic, including shared semantic objects, Unicode/CRLF source positions, serialized maps and stale-provenance rebuilding. Tests use the complete C distinguishable-call matrix, five CPP fixture profiles, original-five crossings and real native execution; expanded language-cohort matrices remain Task025 work.

package/docs/goals.md

@@ -2,6 +2,8 @@
 
 Semantifold's long-term goal is a language-neutral toolkit for understanding, transforming, generating, and eventually executing programs through a shared high-level semantic representation. The representation should make types, control flow, calls, declarations, diagnostics, and source provenance understandable without exposing a language parser's private tree.
 
-The current release candidate proves one minimal vertical slice across PHP, Ruby, JavaScript, TypeScript, and Java. It includes versioned source provenance, deterministic semantic node/symbol identity, range-based generated mappings, Source Map v3 interop, composition, and diagnostic remapping across that slice. It does not yet provide a general analyzer, transformation API, interpreter, optimizer, project graph, debugger integration, coverage remapping, or lossless formatter.
+The current source tree proves one minimal Tasks 001–004 vertical slice across nine registered languages: PHP, Ruby, JavaScript, TypeScript, Java, strictly annotated Python, canonical C#, bounded Go, and C17. It includes versioned source provenance, deterministic semantic node/symbol identity, range-based generated mappings, Source Map v3 interop, composition, and diagnostic remapping across that slice. The published `semantifold@0.2.0` release predates the C#, Go, and C additions. Neither the source tree nor that release provides a general analyzer, transformation API, interpreter, optimizer, project graph, debugger integration, coverage remapping, or lossless formatter.
 
-Roadmap candidates include a versioned full semantic schema, more scalar and compound types, expressions and statements, user-authored transformations, richer backend capability negotiation, multi-file modules, cross-language stack/coverage presentation, and a semantic interpreter. LLVM, Wasm, JVM bytecode, package publication automation, and production TensorBuzz changes are explicitly outside this candidate.
+The long-term product direction includes bounded standard-library portability through [language compatibility stdlib/facades, canonical Semantifold stdlib contracts/capabilities, and target host providers/native bindings](standard-library-portability.md). That direction is incremental and versioned; it does not promise arbitrary standard-library coverage or arbitrary-application translation. The `0.2.0` release has no imports, classes or methods, loops, optional values, typed errors, resources, host APIs, or stdlib portability.
+
+Other roadmap candidates include a versioned fuller semantic schema, more scalar and compound types, expressions and statements, user-authored transformations, richer backend capability negotiation, multi-file modules, cross-language stack/coverage presentation, and a semantic interpreter. LLVM, Wasm, JVM bytecode, package publication automation, and production TensorBuzz changes remain outside the current release.

package/docs/language-support.md

@@ -1,5 +1,24 @@
 # Language support
 
+## Registered roles
+
+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`.
+
 ## Implemented subset
 
 | Language | Exact frontend scalar types | Generated entry point |
@@ -9,6 +28,12 @@
 | 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` |
+| 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 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.
 
@@ -18,6 +43,9 @@ Frontend conditional forms remain deliberately bounded:
 - 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.
 - 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.
+- 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.
 
 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.
 
@@ -37,9 +65,13 @@ Local source profiles are exact:
 $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.
+
 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.
+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.
 
 | Meaning | Ruby | JavaScript / TypeScript | PHP | Java |
 | --- | --- | --- | --- | --- |
@@ -50,20 +82,28 @@ 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.
+
 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`. This validation uses exact arithmetic without replacing the semantic expression tree. Runtime arithmetic overflow for non-literal expressions is not a portable guarantee.
+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.
 
 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)`. Java calls remain unqualified and `main` may not contain ignored statements.
+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`.
 
-Backends retain narrow ASCII identifier rules and reject target reserved words for function names, parameter names, local declarations, assignment targets, call targets, and identifier references before emission. Bindings are never renamed. 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; and module functions cannot be `console` in JavaScript/TypeScript or `puts` in Ruby. 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 boolean printing differs from the other targets; the cross-language execution contract therefore compares a string result 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 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.
 
 ## Diagnostics and limitations
 
-All five frontends preserve exact input content and parser-backed semantic token ranges in module provenance. All 25 input-to-output combinations produce range-based rich maps and Source Map v3 sidecars with UTF-16 coordinates and symbol names. Output code uses LF deterministically. Only JavaScript and TypeScript may opt into inline or external `sourceMappingURL` directives; other targets consume sidecars through Semantifold APIs. Mapping does not imply lossless formatting or support for syntax outside the semantic subset. See [source provenance and mappings](source-maps.md).
+### Current standard-library limitation and future direction
+
+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).
 
-`UNSUPPORTED_SYNTAX` reports parsed constructs outside the subset with the best parser-provided source location. `MISSING_TYPE` reports missing or unsupported atomic annotations and identifies integer, boolean, and string as the supported scalar set. 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 Java's fixed `Main.java` artifact basename before emission. Missing or structurally invalid blocks, statement arrays/elements, declaration names, mutability, type references, initializers, assignment targets/names, assigned expressions, conditional branches, and call-expression fields in caller-supplied IR use their nearest owning node location and report `UNSUPPORTED_CAPABILITY` rather than leaking a native error or producing partial source. A non-`Main.java` Java basename uses the same located capability diagnostic contract.
+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).
+
+`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.
 
 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.
+
+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.