semantifold 0.2.0 → 0.3.0

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

@@ -12,8 +12,12 @@ The immutable registry is authoritative for both dispatch and discovery:
 | `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 six records with both frontend and text generation.
+`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
 
@@ -25,6 +29,11 @@ The immutable registry is authoritative for both dispatch and discovery:
 | 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.
 
@@ -35,6 +44,8 @@ Frontend conditional forms remain deliberately bounded:
 - 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.
 
@@ -55,10 +66,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.
 
 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 |
 | --- | --- | --- | --- | --- |
@@ -69,22 +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`.
+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)`. 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.
+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 reject target reserved words for function names, parameter names, local declarations, assignment targets, call targets, and identifier references before emission. Bindings are never renamed. 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; 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 six frontends preserve exact input content and parser-backed semantic token ranges in module provenance. All 36 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_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. `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 uses `MISSING_TYPE` only when a parameter, return, or first-local annotation is absent; a present annotation other than exact `int`, `bool`, or `str` 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 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. 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 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.

package/docs/parser-qualification.md

@@ -27,13 +27,13 @@ All Tree-sitter languages use the official `tree-sitter` Node binding. The langu
 | Owning task | Language | Required upstream route | Qualification state before owner starts |
 | --- | --- | --- | --- |
 | 016 | Python | official [`tree-sitter/tree-sitter-python`](https://github.com/tree-sitter/tree-sitter-python) grammar package | blocked until the exact release record above passes |
-| 017 | C# | official [`tree-sitter/tree-sitter-c-sharp`](https://github.com/tree-sitter/tree-sitter-c-sharp) grammar package | blocked until the exact release record above passes |
-| 018 | C | official [`tree-sitter/tree-sitter-c`](https://github.com/tree-sitter/tree-sitter-c) grammar package | blocked until the exact release record above passes |
-| 019 | C++ | official [`tree-sitter/tree-sitter-cpp`](https://github.com/tree-sitter/tree-sitter-cpp) grammar package | blocked until the exact release record above passes |
+| 017 | C# | official [`tree-sitter/tree-sitter-c-sharp`](https://github.com/tree-sitter/tree-sitter-c-sharp) grammar package | passed for exact `tree-sitter-c-sharp@0.23.5`; see the checked-in record below |
+| 018 | C | official [`tree-sitter/tree-sitter-c`](https://github.com/tree-sitter/tree-sitter-c) grammar package | legacy pair qualified inside the bundled root distribution below; source/target work remains blocked until that packaging correction is reviewed, green, merged, and verified |
+| 019 | C++ | official [`tree-sitter/tree-sitter-cpp`](https://github.com/tree-sitter/tree-sitter-cpp) grammar package | exact 0.23.4 qualified with the existing isolated 0.21.1 runtime; see Task 019 record below |
 | 020 | Rust | official [`tree-sitter/tree-sitter-rust`](https://github.com/tree-sitter/tree-sitter-rust) grammar package | blocked until the exact release record above passes |
 | 022 | Swift | community [`alex-pinkus/tree-sitter-swift`](https://github.com/alex-pinkus/tree-sitter-swift) candidate plus differential `swiftc` checks | candidate only; blocked until exact release and differential record pass |
 | 023 | Kotlin/JVM | community [`fwcd/tree-sitter-kotlin`](https://github.com/fwcd/tree-sitter-kotlin) candidate plus differential `kotlinc` checks | candidate only; blocked until exact release and differential record pass |
-| 024 | Go | official [`tree-sitter/tree-sitter-go`](https://github.com/tree-sitter/tree-sitter-go) grammar package | blocked until the exact release record above passes |
+| 024 | Go | official [`tree-sitter/tree-sitter-go`](https://github.com/tree-sitter/tree-sitter-go) grammar package | passed for exact `tree-sitter-go@0.25.0`; see the checked-in record below |
 | 029 | Dart | candidate selected and qualified by Task 029 | intentionally deferred |
 | 031 | Zig | candidate selected and qualified by Task 031 | intentionally deferred |
 
@@ -68,3 +68,152 @@ npm pack tree-sitter-python@0.25.0 --dry-run --json
 ```
 
 The accepted Python corpus is `spec/fixtures/{program.py,scalars/program.py,locals/program.py,operators/program.py,statements/program.py}` with SHA-256 values, in that order: `045ac897756dde15066878b56e40c84ee1aabdbd6fd32bddb9d0058ad512972a`, `b4acdda8c4c096ef7d76f83aec7dc148e049a0cd33583c55a79fd18ab1d6f6a6`, `123bb06c0833786168722ad7dfdcb47b95d37b502f6240fde4c12cd60f8e6715`, `35dce1aef96e5dc381baa1b2c39b58232d76b9e14350f0e81c4dd296da77df1e`, and `4907b25568006f65ce749f4c57b4b1eb9c7e6f655ad6be6e014d94c84885ada4`. Run `PYTHONPYCACHEPREFIX="$(mktemp -d)" python3 -m py_compile` over those paths so bytecode remains outside the checkout.
+
+## Task 017 C# qualification
+
+Qualification passed in a credential-free empty `/tmp` package on canonical Node `v24.18.1`, npm `11.16.0`, Linux x64, and .NET SDK `10.0.111` (runtime/`Microsoft.NETCore.App` `10.0.11`, RID `ubuntu.26.04-x64`, `Microsoft.NETCore.App.Ref`/`Microsoft.AspNetCore.App.Ref` targeting packs `10.0.11`). Task 017 therefore uses the existing exact `tree-sitter@0.25.1` binding with official registry grammar `tree-sitter-c-sharp@0.23.5`; neither dependency is a Git/archive path or vendored artifact.
+
+| Evidence | Qualified result |
+| --- | --- |
+| npm distribution | `tree-sitter-c-sharp@0.23.5`, resolved from `https://registry.npmjs.org/tree-sitter-c-sharp/-/tree-sitter-c-sharp-0.23.5.tgz` with integrity `sha512-xJGOeXPMmld0nES5+080N/06yY6LQi+KWGWV4LfZaZe6srJPtUtfhIbRSN7EZN6IaauzW28v6W4QHFwmeUW6HQ==`; exact peer `tree-sitter@^0.25.0` is satisfied by `0.25.1`. |
+| upstream identity | Official [`tree-sitter/tree-sitter-c-sharp`](https://github.com/tree-sitter/tree-sitter-c-sharp) annotated tag `v0.23.5` (tag object `173c15453b733ccde654032fec7103705b5ad04f`), peeled commit and npm `gitHead` `cac6d5fb595f5811a076336682d5d595ac1c9e85`. |
+| legal and registry provenance | The grammar declares MIT. In the clean exact installation, `npm audit signatures` verified all four installed-package registry signatures and two attestations. The grammar's registry signature, tag/commit identity, package contents, and lockfile integrity were checked; no credential was exposed or requested. |
+| clean Node 24 install/load | With npm auth/token environment variables removed, exact installation and `npm ls --all` passed with zero vulnerabilities. The package has no Node engine declaration, so compatibility was proven empirically: its explicit Node binding import loaded, `Parser#setLanguage` succeeded, and all fixtures parsed through the native binding. |
+| ABI, typing, lifecycle, and package inputs | The grammar declares ABI `15`; `tree-sitter@0.25.1` supports ABI `13`–`15`. The grammar ships typed `bindings/node/index.d.ts`, Linux x64/arm64 prebuilds, grammar C source fallback, and only `install: node-gyp-build`; no runtime downloader is declared. Dry-run packs showed normal registry package contents. No tarball, parser source copy, prebuild, `node_modules`, NuGet cache, `bin`, or `obj` entered the repository. |
+| coordinates and recovery | `child(index)` traversal covered every named, anonymous, comment, nullable directive, error, and missing node. The Node binding exposes UTF-16 code-unit indexes for JavaScript strings despite Tree-sitter's byte-oriented native contract; astral text before an identifier and CRLF probes separated UTF-16 and UTF-8 offsets. The adapter rejects lone surrogates and verifies every boundary through the shared UTF-8-byte-to-UTF-16 converter. Malformed braces, operands, and missing semicolons produced explicit or propagated `hasError`/`isError`/`isMissing`; propagated ancestor error state is rejected even where no distinct `ERROR` child exists. |
+| Tasks 001–004 grammar shapes | The five fixtures proved exact shapes for `preproc_nullable`, file-scoped namespace, class/modifiers, methods/parameters/types, blocks, declarations, carrier comments, assignments, calls/arguments, print member access, checked expressions, all scalar literals/operators, returns, and `if`/`else if`/`else`. Adapter specs retain field and token ranges and reject every unmodeled present child. |
+| official compiler comparison | All five fixture projects restored without external packages, built under .NET 10/C# 14 with warnings as errors and no warning output, and executed with exact expected stdout. Restore, build, and execution were separate; the isolated `NUGET_PACKAGES` path was resolved to an absolute path because the SDK rejects a relative global packages folder. The official grammar needs no community-grammar differential exception. |
+
+Reproduce the registry qualification in an empty temporary directory with:
+
+```sh
+npm init -y
+env -u NODE_AUTH_TOKEN -u NPM_TOKEN -u npm_config__auth -u npm_config_token \
+  npm install --save-exact tree-sitter@0.25.1 tree-sitter-c-sharp@0.23.5
+npm audit signatures
+npm ls --all
+npm pack tree-sitter@0.25.1 --dry-run --json
+npm pack tree-sitter-c-sharp@0.23.5 --dry-run --json
+```
+
+The accepted C# corpus is `spec/fixtures/{Program.cs,scalars/Program.cs,locals/Program.cs,operators/Program.cs,statements/Program.cs}` with SHA-256 values, in that order: `5ca661d09dff2d775094df99b40e5c5604796c9bff4c32c1da11fa1b4c564a00`, `9cefd6d01c5855480629829489945f2f43338b84879c7a26043963151a8439da`, `ee775fea59ee812212ce325152e4e4cb79c20e699aba081bf39cc698b324444d`, `7137f4acc88dbdc1d0bafd6bb8eb57bed9386daf3e6b11c6fbae3831abceae18`, and `ba63cb72490605437e1efaa7d69ce0abdbfbb07c076aec787bc025e7a277468f`.
+
+## Task 018 legacy C parser boundary qualification
+
+The C grammar's compatible published runtime line cannot share Semantifold's root Tree-sitter instance. The one root `semantifold@0.2.0` distribution therefore explicitly bundles root `tree-sitter@0.25.1` for its modern grammars and a private internal package with an isolated exact `tree-sitter@0.21.1` plus `tree-sitter-c@0.23.2` subtree, whose peer range and grammar ABI agree. The renamed private workspace owns source checking and declaration generation but has no export, publication metadata, or release gate. A separately tested `tree-sitter@0.22.4` plus `tree-sitter-c@0.24.1` install was rejected because `Parser#setLanguage` failed with an undefined `nodeTypeNamesById`; an installable graph alone is not qualification.
+
+| Evidence | Qualified boundary result |
+| --- | --- |
+| npm distribution | `tree-sitter@0.21.1`, integrity `sha512-7dxoA6kYvtgWw80265MyqJlkRl4yawIjO7S5MigytjELkX43fV2WsAXzsNfO7sBpPPCF5Gp0+XzHk0DwLCq3xQ==`; `tree-sitter-c@0.23.2`, integrity `sha512-9kADOx31AF94DHcrsMGW0zM/2LS6v7wFkPHPVm7RQU+vYVVZMKZ2FJ9e99pm5feqsAcjUzB9CarqDLgRT1Fe/w==`. npm's supported `file:` dependency plus repository-local `install-links=true` materializes the private internal package, and root `bundleDependencies` includes both that package and modern `tree-sitter`. Root `acceptDependencies` accepts only the exact private `0.1.0` payload already in the bundle, so consumers use ordinary `install-links=false`. No alias, override, forced peer, archive dependency, copied binding, or custom materialization stage is used. |
+| upstream identity | Official [`tree-sitter/node-tree-sitter`](https://github.com/tree-sitter/node-tree-sitter) tag/commit `v0.21.1` / `bbdba663dc0b8487f1212524a83a7c39e8a5c3ca`; official [`tree-sitter/tree-sitter-c`](https://github.com/tree-sitter/tree-sitter-c) tag/commit and npm `gitHead` `v0.23.2` / `6a4ae2e08916fd08e5739250bb64a14392b01c99`. |
+| legal and registry provenance | Both upstream packages declare MIT and publish registry signatures. Their exact registry URLs and integrities are recorded in `package-lock.json`; the repository gate verifies installed-package signatures and audits the ordinary dependency graph. The private internal package uses ISC and has no public registry identity. All three dependency licenses remain in the root tarball. |
+| ABI and API | `tree-sitter-c@0.23.2` declares language ABI 14; `tree-sitter@0.21.1` accepts ABI 13–14 and the grammar's peer is `^0.21.1`. The legacy binding provides `child(index)` and `fieldNameForChild(index)` but not the newer `fieldNameForNamedChild` convenience API. The adapter therefore traverses every ordered named and anonymous child and copies field names without exposing binding types. |
+| runtime isolation | A real root tarball installed into a credential-free consumer with a fresh npm cache resolves modern `tree-sitter@0.25.1` at the root and legacy `tree-sitter@0.21.1` plus `tree-sitter-c@0.23.2` below the private internal package at distinct paths. No workspace is present in the consumer and no registry publication of the internal name is required. One Node `v24.18.1` Linux x64 process parses modern Go and legacy C without a native-module collision. Ordinary npm install and peer resolution are mandatory. |
+| private boundary | The internal `parseCst(source)` returns only a recursively frozen `semantifold.parser-cst` version 1 envelope and is absent from Semantifold's public exports. Nodes contain plain scalar state, UTF-16 indices/row-column positions, and ordered frozen `{field, node}` edges. Parser, tree, syntax-node, language, method, function, parent, circular, and source-text values do not cross the boundary. The caller retains source ownership and can slice it by the normalized offsets. |
+| recovery and coordinates | Astral text before a later definition plus CRLF separates UTF-8 bytes from UTF-16 code units; the snapshot retains exact UTF-16 indices and row/column positions. Comments remain visible as extra nodes. A missing closing brace propagates `hasError` and preserves the missing node rather than recovering through source text. |
+| lifecycle and package inputs | The native dependencies use only `install: node-gyp-build` and have no runtime downloader. The root tarball retains licenses, `binding.gyp`, and native source fallback for both Tree-sitter bindings plus the C grammar's `binding.gyp` and generated parser source. Modern `tree-sitter@0.25.1` includes Darwin, Linux, and Windows x64/arm64 prebuilds; legacy `tree-sitter@0.21.1` includes Darwin arm64/x64, Linux x64, and Windows x64 prebuilds; `tree-sitter-c@0.23.2` includes Darwin, Linux, and Windows x64/arm64 prebuilds. Only Linux x64 native loading and execution were tested. Other listed platforms rely on upstream prebuild selection or source compilation and are packaging-presence claims, not execution claims. Source fallback additionally requires a compatible compiler toolchain and consumer npm policy permitting the upstream `node-gyp-build` install scripts; fallback compilation was not executed here. Accidental `build/Debug` or `build/Release` output is rejected from the pack proof. |
+| task boundary | This record qualifies only the runtime/package boundary. It does not implement or claim the Task 018 C frontend, semantic normalization, backend, registry, toolchain, compiler comparison, or Tasks 001–004 C corpus. That prerequisite was completed through https://github.com/kaspernj/semantifold/pull/19 at `9184660a21820b429138f0632c89df956a2e350f`; Task 018 implementation and native acceptance are recorded separately below. No package publication is part of that prerequisite. |
+
+Reproduce the repository-owned proof on Node 24 with:
+
+```sh
+npm ci
+npx velocious-test spec/tree-sitter-legacy-adapter.spec.js
+npx velocious-test spec/tree-sitter-legacy-packed-consumer.spec.js
+npm ls --all
+npm pack --dry-run --json
+```
+
+The packed-consumer spec creates the root tarball, fresh cache, and consumer only under unique temporary directories. It removes all inherited npm configuration and token variables case-insensitively, uses empty user/global npm config files and explicit `https://registry.npmjs.org/`, and asserts default `install-links=false` even when supplied synthetic alternate configuration. Before packing, the source/installed consistency gate rejects stale local-package copies; normal root `npm ci` is the recovery after shipped source edits. The spec compares bundled internal files with source and runs default `npm install` followed by default `npm ci`. After each it checks the complete installed lock/tree and real runtime paths, compiles a root API type consumer, and executes both parsers in one process. Cache inspection rejects internal or retired registry lookups; `finally` removes the fixture. Publication is intentionally excluded from this qualification.
+
+The dependency declaration follows npm's implemented [acceptDependencies contract](https://github.com/npm/rfcs/blob/main/implemented/0023-acceptDependencies.md): an already-present exact package can satisfy the edge, but new resolution uses only `dependencies`, here the local `file:` source. It does not relax either native runtime or grammar version and is not an override. With npm 11.16.0, a direct private-workspace fixture packed the legacy bindings under `packages/internal/node_modules` while placing the workspace payload under `node_modules`, leaving the installed boundary unresolved. The materialized local dependency instead packs the complete subtree under its real module directory; the source-byte gate and default-consumer proof protect both halves of that contract.
+
+## Task 024 Go qualification
+
+Qualification passed in a credential-free empty `/tmp` package on canonical Node `v24.18.1`, npm `11.16.0`, Linux x64, and Go `go1.26.0 linux/amd64` with GOROOT `/usr/lib/go-1.26`. Task 024 therefore uses the existing exact `tree-sitter@0.25.1` binding with official registry grammar `tree-sitter-go@0.25.0`; neither dependency is a Git/archive path or vendored artifact.
+
+| Evidence | Qualified result |
+| --- | --- |
+| npm distribution | `tree-sitter-go@0.25.0`, resolved from `https://registry.npmjs.org/tree-sitter-go/-/tree-sitter-go-0.25.0.tgz` with integrity `sha512-APBc/Dq3xz/e35Xpkhb1blu5UgW+2E3RyGWawZSCNcbGwa7jhSQPS8KsUupuzBla8PCo8+lz9W/JDJjmfRa2tw==`; peer `tree-sitter@^0.25.0` is satisfied by exact `tree-sitter@0.25.1` with integrity `sha512-mrcEdkYtHfrK1A6fs3O6FxkBo0Qig5XUXqHhxUOQu0bmPo00QF4XaSx4edpazdHwxnSCjlGKGgIqWdaN4dvTLA==`. |
+| upstream identity | Official [`tree-sitter/tree-sitter-go`](https://github.com/tree-sitter/tree-sitter-go) annotated tag `v0.25.0` (tag object `6048bfc6e5238eaf062c2221bd934489c39fbb61`), peeled commit and npm `gitHead` `1547678a9da59885853f5f5cc8a99cc203fa2e2c`. The binding is official tag `v0.25.1`, npm `gitHead` `75a0eccfedc491e26843bd744bb6806f8a8bfff4`. |
+| legal and registry provenance | Both packages declare MIT. `npm audit signatures` verified all four installed-package registry signatures and two attestations with no invalid or missing signature. The binding publishes npm SLSA provenance; the grammar has a verified registry signature but did not advertise an npm attestation, so tag/commit identity and registry integrity were checked independently. |
+| clean install/load | With npm auth/token environment variables removed, `npm install --save-exact tree-sitter@0.25.1 tree-sitter-go@0.25.0` succeeded from the registry in a fresh package with zero vulnerabilities. `npm ls --all` resolved only `node-addon-api@8.9.2`, `node-gyp-build@4.8.4`, the exact binding, and the exact grammar. The explicit ESM import loaded on Node 24, `Parser#setLanguage` succeeded, and typed `nodeTypeInfo` exposed 188 grammar entries. |
+| ABI, typing, lifecycle, and package inputs | The shipped grammar declares ABI `15`; `tree-sitter@0.25.1` accepts ABI `13` through `15`. The grammar declaration exposes its language handle and `NodeInfo[]` metadata. Both packages use only `install: node-gyp-build`, with no downloader URL or extra lifecycle dependency. Dry-run packs contained 80 binding files (1,594,590-byte archive) and 25 grammar files (558,540-byte archive), including declarations, licenses, platform prebuilds, and source fallback. No archive, prebuild, generated parser, native binary, `node_modules`, or qualification output entered Semantifold. |
+| coordinates, comments, and recovery | The Node binding exposed UTF-16 code-unit indexes: after astral text and CRLF, one literal occupied indexes 61–65 while raw UTF-8 byte boundaries were 63–69; both round-tripped through `utf8ByteOffsetToUtf16Offset()`. Lone surrogates were rejected before parsing. Ordinary and `//go:`, `// +build`, and `//line` directive comments remained visible nodes. Malformed package clauses, parameter lists, missing operands, braces, semicolons, and incomplete strings all exposed `hasError`, `isError`, or `isMissing`. |
+| Tasks 001–004 tree corpus | Exhaustive `child(index)` traversal covered every named and anonymous child, token, comment, and `fieldNameForChild` edge in all five fixtures. Observed shapes include the exact package/import/function/parameter/type/result/block scaffold; variable declarations/specs; assignment/expression lists; returns, calls, arguments, and selectors; parentheses; every accepted scalar/operator node; and nested `if`/`else if`/`else`. No source scan supplied missing structure. |
+| official-tool differential | Matching `/usr/lib/go-1.26/bin/gofmt -d` produced no diff for all five fixtures. In separate dependency-free modules with fixed `go.mod`, every fixture passed offline/local, cgo-disabled `go build`, mandatory `go vet`, and `go run` with exact output. A no-import sample passed `go tool compile`. All six malformed samples were rejected by both `gofmt` and `go tool compile`. A slice/range/short-declaration sample parsed, formatted, built, vetted, and ran under official Go, establishing the intentional valid-but-`UNSUPPORTED_SYNTAX` differential boundary. No `go.sum`, `go.work`, vendor tree, or source mutation appeared. |
+| toolchain isolation | Every Go process used `GOTOOLCHAIN=local`, `GOPROXY=off`, `GOSUMDB=off`, `GOVCS=off`, `CGO_ENABLED=0`, `GOENV=off`, `GOWORK=off`, `GOOS=linux`, `GOARCH=amd64`, and separate absolute cache/module/GOPATH/temp/home paths. `/usr/bin/gofmt` resolved to `/usr/lib/go-1.26/bin/gofmt`, the same verified GOROOT as `go`. |
+
+Reproduce the registry qualification in a fresh empty temporary directory with:
+
+```sh
+npm init -y
+env -u NODE_AUTH_TOKEN -u NPM_TOKEN -u npm_config__auth -u npm_config_token \
+  npm install --save-exact tree-sitter@0.25.1 tree-sitter-go@0.25.0
+npm audit signatures
+npm ls --all
+npm pack tree-sitter@0.25.1 --dry-run --json
+npm pack tree-sitter-go@0.25.0 --dry-run --json
+```
+
+The accepted Go corpus is `spec/fixtures/{program.go,scalars/program.go,locals/program.go,operators/program.go,statements/program.go}` with SHA-256 values, in that order: `5f4ad40a233d8728c90ca885d4bfe6f018f1d7a5e6f2e2cfb97b4b9db4887f1c`, `6d4251def8b1bccdff177df901bf9fe109a8a01ae1514cb8d5aaf364298669b9`, `a7b6eb2f5eae0a20d7cd4982e4d26cc6653760ad03e8b21ff5c360239861dd6f`, `4a263413830a41a59b6d8326a78067826853e3491e65d52559e5acea0d9cf56c`, and `d64f083d70697d25d2ea7f5c7a44cada0ab13a878640fd10bc547df185fa7bba`.
+
+## Task 018 C integration
+
+The C frontend consumes the unchanged frozen parser-neutral legacy boundary qualified above. It adds no native dependency, archive, copied parser, workspace identity, consumer flag or override. Complete C child/field/token traversal, recovery rejection, exact generated-region reconstruction and full canonical-CST comparison are covered by `spec/c-frontend-validation.spec.js` and `spec/c-ordered-expressions.spec.js`. The five checked-in `program.c` fixture profiles pass generated-source round trips and original-five bidirectional execution. Unicode/NUL, every operation/consumer, eager/short-circuit effects and arena/fatal paths run through real separate Clang compile/link/native execution at O0/O2, ordinary and sanitized. The ordinary packed-root consumer now additionally exercises public C parse/generate/reparse and C API typing after both default install and clean npm ci; it preserves the existing credential-free configuration and cache proof. This is implementation regression coverage, not another packaging review. See [C semantics and scaffolds](c.md), [toolchain qualification](testing.md) and [the delivery record](../todo/018-c-source-and-target.md).
+
+## Task 019 C++ grammar qualification — 2026-09-08
+
+This record precedes the dependency manifest change. The official C++ grammar is selected explicitly inside the existing private runtime; the C grammar is not a C++ parser. The root distribution and both existing Tree-sitter versions remain unchanged.
+
+| Evidence | Qualified result |
+| --- | --- |
+| Official npm release | `tree-sitter-cpp@0.23.4`, registry URL `https://registry.npmjs.org/tree-sitter-cpp/-/tree-sitter-cpp-0.23.4.tgz`, integrity `sha512-qR5qUDyhZ5jJ6V8/umiBxokRbe89bCGmcq/dk94wI4kN86qfdV8k0GHIUEKaqWgcu42wKal5E97LKpLeVW8sKw==`. Latest registry tag at qualification was 0.23.4. |
+| Upstream identity and license | Official [tree-sitter/tree-sitter-cpp](https://github.com/tree-sitter/tree-sitter-cpp/tree/v0.23.4), tag `v0.23.4` and npm gitHead both `f41e1a044c8a84ea9fa8577fdd2eab92ec96de02`; MIT license present in the registry package. `git ls-remote` verified the tag. |
+| Ordinary peer graph | Optional peer `tree-sitter@^0.21.1`, grammar ABI 14; exact existing binding 0.21.1 accepts ABI 13–14. Grammar dependency `tree-sitter-c@^0.23.1` dedupes to the existing exact 0.23.2. Clean install and `npm ls --all` resolved these three packages plus node-addon-api 8.9.2 and node-gyp-build 4.8.4, without overrides, force, peer bypass, aliases or a third runtime. |
+| Node and supply chain | Node v24.18.1, npm 11.16.0, Linux x64 as UID1000. Fresh run-local package/cache, empty user/global npm configuration, explicit public registry, inherited npm configuration/token variables removed. Ordinary exact installation succeeded with zero vulnerabilities. `npm audit signatures` verified five registry signatures and one attestation. |
+| Native and typed API | Actual ESM import, `new Parser()`, `setLanguage(CPP)`, parse and exhaustive `child(index)` / `fieldNameForChild(index)` traversal passed beside C in the same process. The declaration's `setLanguage` returns void and fields are nullable; a strict NodeNext typed consumer passed without casts or skipLibCheck, using the repository's Node types. The grammar includes typed `nodeTypeInfo`. |
+| Corpus and coordinates | Five source probes traversed 390 named/anonymous/comment nodes, including qualified scalar types, initialized const/mutable locals, assignment, returns, calls, literals, typed operators, nested/fallthrough branches and main. CPP uses `condition_clause`, independently of C's shape. Astral comment plus CRLF put the next definition at UTF-16 index 10 / UTF-8 byte 12, row 1 column 0. Comments remain explicit extras. |
+| Malformed input and limits | Missing brace and operand produce missing nodes; malformed parameters/string produce ERROR nodes; all four propagate hasError. CPP rejects the same source through the C grammar while CPP accepts it. The binding accepts 32767 UTF-16 units and throws at 32768; adapters must preflight this limit. |
+| Lifecycle and packaged inputs | Only install lifecycle is `node-gyp-build`; no runtime network downloader. Dry-run registry pack reports 27 files, 3,208,986 compressed / 42,392,814 unpacked bytes, including MIT license, declarations, grammar source, native source fallback, Darwin/Linux/Windows x64/arm64 prebuilds and upstream WASM. Only Linux x64 native loading was executed. No archive, vendored grammar/binary or additional publication identity is added to this repository. |
+
+Reproduce in an empty temporary package using Node24 and credential-free public npm configuration:
+
+```sh
+npm init -y
+npm install --save-exact tree-sitter@0.21.1 tree-sitter-c@0.23.2 tree-sitter-cpp@0.23.4
+npm ls --all
+npm audit signatures
+npm pack tree-sitter-cpp@0.23.4 --dry-run --json
+node --input-type=module - <<'JS'
+import Parser from 'tree-sitter'
+import CPP from 'tree-sitter-cpp'
+const parser = new Parser()
+parser.setLanguage(CPP)
+const source = '/* 😀 */\r\nstd::string copy(std::string a, std::string b) { return a; }\n'
+const root = parser.parse(source).rootNode
+function visit(node) {
+  if (node.hasError || node.isError || node.isMissing) throw new Error(node.type)
+  for (let i = 0; i < node.childCount; i++) {
+    console.log(node.fieldNameForChild(i), node.child(i).type)
+    visit(node.child(i))
+  }
+}
+visit(root)
+console.log(root.namedChildren[1].startIndex, root.namedChildren[1].startPosition)
+JS
+```
+
+The complete initial corpus, source SHA-256 values, typed consumer, tree/ABI/package inventory and command logs are retained in the Task019 implementation run's `qualification/` and `evidence/` directories. The repository's private-boundary and CPP behavior specs retain executable regression coverage. Grammar qualification does not claim frontend/backend acceptance, packed-consumer success or CI completion.
+
+The initial qualification corpus is now retained verbatim in the repository (these hashes were recorded before dependency edits):
+
+| Corpus path | SHA-256 |
+| --- | --- |
+| `spec/fixtures/cpp-qualification/corpus-1.cpp` | `6e5763ff158809f0c750011765421c688978e755598cf1c738bd6e9863ccb6e5` |
+| `spec/fixtures/cpp-qualification/corpus-2.cpp` | `0a57ddb7fa84e7f1522452f520898d8e3d99ced6857e85b00d4e6dd327c15835` |
+| `spec/fixtures/cpp-qualification/corpus-3.cpp` | `b9be8da90243dbd9bdcebe3ee9569f2933ba24ddae38b342220183f6c72cf3e7` |
+| `spec/fixtures/cpp-qualification/corpus-4.cpp` | `ec88c7a47a7167b0ad4d2d07744e8d71404551b91a9db927c8d476f6de23a110` |
+| `spec/fixtures/cpp-qualification/corpus-5.cpp` | `a7524580af4881083d2fbf95f9a7b9f940320c2d2c35d3b188094598cca27f59` |
+
+Reproduce exhaustive frozen-edge traversal, coordinate and recovery checks with `npx velocious-test spec/cpp-parser-qualification.spec.js`. The generated Tasks001–004 fixtures are independently accepted by `spec/cpp-cross-language-acceptance.spec.js`; the small grammar probes above qualify CST coverage, not semantic acceptance or native compilation of a complete supported program.

package/docs/plans/2026-09-05-standard-library-portability.md

@@ -0,0 +1,46 @@
+# Standard-library portability implementation plan
+
+Date: 2026-09-05
+
+Status: dependency-ordered future plan; no implementation is claimed.
+
+## Goal and architecture reference
+
+Deliver the first bounded proof of the [standard-library portability architecture](../standard-library-portability.md): language compatibility stdlib/facades and target host providers/native bindings meet only through versioned canonical Semantifold stdlib contracts/capabilities. Pair-specific adapters and direct behavior-changing rewrites are excluded.
+
+## Why semantic prerequisites come first
+
+The current `semantifold@0.2.0` IR cannot express imports, general signatures, receiver calls, classes, loops, optional EOF, typed failures, resource identities, ownership, or close effects. Encoding a socket facade before those meanings exist would push language behavior into parser adapters, emitters, or handwritten source-to-target bridges. That would make evaluation order, EOF, failure, and lifetime accidental and prevent other facades/providers from sharing the work.
+
+The sequence therefore establishes general language semantics first, then defines capability/provider infrastructure, and only then adds a facade and concrete network slice. Numerical task order records this dependency flow; it is not a promise that the work is complete or immediately scheduled.
+
+## Dependency-ordered sequence
+
+1. Complete existing prerequisites [Task 004](../../todo/004-statement-sequencing-and-conditionals.md) and [Task 005](../../todo/005-general-function-signatures-and-calls.md), then add [Task 032 — condition-controlled loops and break/continue](../../todo/032-condition-controlled-loops-and-break.md). This supplies a general strict-Boolean loop model without recognizing stdlib-specific read-loop idioms.
+2. Complete [Task 009](../../todo/009-closed-records-and-member-access.md), then add [Task 033 — reference classes, methods, and constructors](../../todo/033-reference-classes-methods-and-constructors.md). Executable facades need bounded nominal reference identity, private state, construction, and receiver calls; immutable records alone are insufficient.
+3. Build on optionals, typed failures, and reference classes with [Task 034 — effectful capabilities and resource lifetime](../../todo/034-effectful-capabilities-and-resource-lifetime.md). It defines explicit host effects, resource ownership, deterministic close, and typed failure boundaries without claiming async, concurrency, `finally`, or RAII.
+4. Build project/module and effect foundations into [Task 035 — versioned standard-library contracts and provider linking](../../todo/035-versioned-standard-library-contracts-and-provider-linking.md). This owns canonical capability modules, provider registry/negotiation, protected native bindings, transactional linking, and tree-shaking.
+5. Add [Task 036 — language compatibility stdlib/facades](../../todo/036-language-compatibility-stdlib-facades.md). It owns proved stdlib identity, executable source-language facades, collision-safe target names, and same-language recursion isolation.
+6. Combine the loop and facade branches in [Task 037 — blocking TCP client stdlib vertical slice](../../todo/037-blocking-tcp-client-stdlib-vertical-slice.md). This is the first concrete proof, not a general networking or all-language milestone.
+
+The direct dependency chain is also recorded in the [roadmap graph and task index](../../todo/README.md). Phase S stays non-blocking until its prerequisite tasks are delivered; it must not distort the existing language/platform lanes.
+
+## First end-to-end proof
+
+Task 037 provides only these initial integrations:
+
+- canonical versioned blocking `SocketClient`, text-stream line-read, output, and resource-close capabilities;
+- Ruby language compatibility stdlib/facades preserving the supported `TCPSocket.new(host, port)`, `gets`, and `close` shape plus bounded one-string `puts(string)`/`Kernel.puts(string)`;
+- a canonical output operation that writes the string once and appends LF only when it does not already end in LF;
+- a PHP target host provider/native binding implemented with genuine `fsockopen`, `fgets`, and `fclose` for socket operations plus native stdout output without a duplicate LF; and
+- generated PHP that can retain `TCPSocket` and the bounded `puts` function in a collision-safe compatibility namespace/import alias while they call canonical provider operations.
+
+Acceptance starts a real local ephemeral TCP server controlled by the test. Generated PHP runs with the real PHP CLI and must prove exact output, retained input newlines, one appended LF for a final unterminated string, no duplicate LF, an absent result only at clean EOF, normalized connection error before a usable resource escapes, deterministic successful close, the specified repeated-close result, and a typed use-after-close failure. The server and client tests use bounded timeouts so blocking behavior cannot hang the lane.
+
+Negative acceptance covers unresolved or shadowed `TCPSocket` or `puts`, monkey-patching/reopening, dynamic require/lookup, unsupported APIs/options, excluded multi-argument/array/coercive/custom-separator `puts` behavior, missing provider capabilities, namespace collisions, version mismatch, and late provider/link failure. Every failure occurs before partial artifact exposure.
+
+## Delivery discipline for future implementation
+
+Each behavior task must add focused specs, exact public contracts, documentation, and a changelog fragment. Runtime-generation coverage must invoke the real required tools and a real local socket; source snapshots are insufficient. Implementations must validate and return deterministic complete artifact sets, retain semantic/synthetic provenance, and fail if a required tool is unavailable.
+
+This planning change itself adds no compiler/runtime behavior, dependency, generated output, spec, or changelog fragment. It does not trigger release, CI topology, external task mutation, or implementation of the listed tasks.

package/docs/source-maps.md

@@ -1,12 +1,14 @@
 # Source provenance and mappings
 
+C `program.c` uses the same rich/v3 contracts. Original operator, callee, literal, binding and final-consumer tokens retain their parser origins, including after exact ordered-region reconstruction. Generated temporary declarations/names, short-circuit control, markers, prototypes, unused-binding uses and cleanup are synthetic with related semantic origins. Shared semantic objects have separate occurrence paths and temporaries. `semantifold_runtime.h` is a synthetic support artifact related to the module root. C accepts no source-map directive or alternate map filename; use `generateArtifactSet()` and its mapped entry provenance. See the [C profile](c.md).
+
 Semantifold keeps one authoritative, language-neutral provenance chain:
 
 ```text
 generated UTF-16 range -> semantic node/symbol -> original UTF-16 range
 ```
 
-This works for PHP, Ruby, JavaScript, TypeScript, and Java inputs and outputs. It is not limited to JavaScript `sourceMappingURL` comments. `SemantifoldMapping` v1 is the authoritative range model; every generated artifact also includes an ECMA-426/Source Map v3 projection for existing tooling.
+This works for PHP, Ruby, JavaScript, TypeScript, Java, Python, C#, and Go inputs and mapped text outputs. It is not limited to JavaScript `sourceMappingURL` comments. `SemantifoldMapping` v1 is the authoritative range model; every generated program artifact also includes an ECMA-426/Source Map v3 projection for existing tooling.
 
 ## Parsing and semantic provenance
 
@@ -66,7 +68,7 @@ artifact.sourceMap     // encoded Source Map v3 object
 artifact.sourceMapFilename
 ```
 
-Default filenames are `program.php`, `program.rb`, `program.js`, `program.ts`, `Main.java`, and `program.py`. Defaults apply only when `filename` or `sourceMapFilename` is omitted (`undefined`); an explicitly supplied `null` remains invalid. Java artifacts may include directories but must retain the basename `Main.java`, matching the generated public class and making the returned filename directly compilable; any other basename is a located `UNSUPPORTED_CAPABILITY` diagnostic for the Java backend. Python artifacts likewise may include directories but retain the deterministic basename `program.py`; Python adds no package, environment, requirements, or dependency metadata. `sources` may supply exact content for legacy or caller-assembled multi-source IR:
+Default filenames for single-text targets are `program.php`, `program.rb`, `program.js`, `program.ts`, `Main.java`, and `program.py`. Defaults apply only when `filename` or `sourceMapFilename` is omitted (`undefined`); an explicitly supplied `null` remains invalid. Java artifacts may include directories but must retain the basename `Main.java`, matching the generated public class and making the returned filename directly compilable; any other basename is a located `UNSUPPORTED_CAPABILITY` diagnostic for the Java backend. Python artifacts likewise may include directories but retain the deterministic basename `program.py`; Python adds no package, environment, requirements, or dependency metadata. C# is available only through `generateArtifactSet()`: `filename` must be omitted or exact `Program.cs`, and `mapDirective`/`sourceMapFilename` must be omitted. It returns mapped `Program.cs` first and a fixed synthetic `Semantifold.csproj` manifest second. Go also requires `generateArtifactSet()`: `filename` must be omitted or exact `main.go`, mapping options must be omitted, and generation returns fixed synthetic `go.mod` first followed by mapped `main.go`. `sources` may supply exact content for legacy or caller-assembled multi-source IR:
 
 ```js
 generateArtifact({
@@ -79,7 +81,7 @@ generateArtifact({
 })
 ```
 
-`generateArtifactSet()` wraps this exact result for original-five single-text targets and supplies one generated entry artifact, plus the referenced serialized mapping artifact when an external JavaScript-family directive is requested. `createGeneratedArtifactSet()` validates other single-module target shapes without introducing Task 010's source-project semantics. Its dense artifact array preserves caller/backend order and requires unique safe relative POSIX paths without file/directory prefix collisions, non-empty text or bytes, media types, one of `entry`/`source`/`manifest`/`support`/`mapping`/`resource`/`loader`, generated ownership, provenance, and exactly one entry. Binary storage remains private and every `content` read returns a detached `Uint8Array`, so mutations cannot alter the validated artifact or drift from byte provenance. Backends return no iterable or partial files: the complete set is validated before it becomes observable. Generation and set construction never write files.
+`generateArtifactSet()` wraps this exact result for the six single-text targets and supplies one generated entry artifact, plus the referenced serialized mapping artifact when an external JavaScript-family directive is requested. For C#, it transactionally returns exactly `Program.cs` (role `entry`, `text/x-csharp`, rich/v3 text provenance) and `Semantifold.csproj` (role `manifest`, `application/xml`, synthetic provenance with the module's canonical root origin as a related origin). For Go it transactionally returns `go.mod` (role `manifest`, `text/plain`) before `main.go` (role `entry`, `text/x-go`, rich/v3 text provenance). The manifest is the exact LF-terminated module `example.com/semantifold/generated` with `go 1.26.0`; its source-free configuration provenance relates back to the module root, and the dependency-free module needs and produces no `go.sum`. `createGeneratedArtifactSet()` validates these and other single-module target shapes without introducing Task 010's source-project semantics. Its dense artifact array preserves caller/backend order and requires unique safe relative POSIX paths without file/directory prefix collisions, non-empty text or bytes, media types, one of `entry`/`source`/`manifest`/`support`/`mapping`/`resource`/`loader`, generated ownership, provenance, and exactly one entry. Binary storage remains private and every `content` read returns a detached `Uint8Array`, so mutations cannot alter the validated artifact or drift from byte provenance. Backends return no iterable or partial files: the complete set is validated before it becomes observable. Generation and set construction never write files.
 
 All outputs have deterministic LF newlines. Returned rich mappings are detached from caller-owned semantic locations and provenance before they are deeply frozen and internally indexed after trust-boundary validation. Freezing an artifact mapping therefore never freezes the mutable semantic module used to generate it. The rich map's `generated.content` is the exact returned code and its ordered, non-empty spans cover every UTF-16 code unit without gaps or overlaps:
 
@@ -118,7 +120,7 @@ Text artifact provenance embeds the validated rich mapping and Source Map v3 pro
 
 ## Source Map v3 and directives
 
-`artifact.sourceMap` exists for all six text targets and is generated with `@jridgewell/gen-mapping`; lookup, import, and artifact-set validation use `@jridgewell/trace-mapping`. Semantifold does not hand-code VLQ or tracing. Artifact-set validation requires dense `sources`, `names`, and optional `sourcesContent` arrays, decodes and canonically re-encodes the mapping payload, requires standard one-, four-, or five-field segments, rejects source or name indices outside their declared arrays, and requires the complete v3 value to equal the existing `toSourceMapV3()` projection of the accepted rich mapping. That projection comparison covers generated and original positions, source and name indexes, content, and the documented trailing unmapped directive span without a second encoder. The v3 map contains deterministic `file`, `sources`, `sourcesContent`, `names`, and `mappings` fields.
+`artifact.sourceMap` exists for all six single-text target artifacts, C#'s `Program.cs`, and Go's `main.go`; it is generated with `@jridgewell/gen-mapping`. Lookup, import, and artifact-set validation use `@jridgewell/trace-mapping`. Semantifold does not hand-code VLQ or tracing. Artifact-set validation requires dense `sources`, `names`, and optional `sourcesContent` arrays, decodes and canonically re-encodes the mapping payload, requires standard one-, four-, or five-field segments, rejects source or name indices outside their declared arrays, and requires the complete v3 value to equal the existing `toSourceMapV3()` projection of the accepted rich mapping. That projection comparison covers generated and original positions, source and name indexes, content, and the documented trailing unmapped directive span without a second encoder. The v3 map contains deterministic `file`, `sources`, `sourcesContent`, `names`, and `mappings` fields.
 
 Directives are opt-in and only valid for JavaScript and TypeScript:
 
@@ -127,7 +129,7 @@ generateArtifact({language: "javascript", module, mapDirective: "external"})
 generateArtifact({language: "typescript", module, mapDirective: "inline"})
 ```
 
-`external` appends `//# sourceMappingURL=<relative-map-url>`. `artifact.sourceMapFilename` remains the map artifact's literal logical filename, while the directive is relative to `artifact.filename`'s directory and URL-encodes each filesystem path segment without encoding structural slashes. Both logical paths resolve against one synthetic artifact root before relativization, so mixed leading-parent depths do not become false common segments; for example, generated `../../dist/out.js` and map `../maps/out.js.map` emit `../maps/out.js.map`. `dist/program.js` still advertises `dist/program.js.map` and emits `sourceMappingURL=program.js.map`; a literal `#` or `?` in the sidecar filename is emitted as `%23` or `%3F`. Names containing any ECMAScript line terminator—LF, CR, U+2028, or U+2029—are rejected before emission. `generateArtifactSet()` makes that reference materializable by adding the LF-terminated deterministic JSON serialization of `artifact.sourceMap` at the advertised safe path with role `mapping`; `generateArtifact()` retains its existing sidecar-object contract. `inline` appends a UTF-8 base64 data URL. The default is `none`. PHP, Ruby, and Java still receive sidecar map objects but never receive non-native map comments. Native Java debugger mapping such as JSR-45 would require class-file/toolchain integration and is not part of v1.
+`external` appends `//# sourceMappingURL=<relative-map-url>`. `artifact.sourceMapFilename` remains the map artifact's literal logical filename, while the directive is relative to `artifact.filename`'s directory and URL-encodes each filesystem path segment without encoding structural slashes. Both logical paths resolve against one synthetic artifact root before relativization, so mixed leading-parent depths do not become false common segments; for example, generated `../../dist/out.js` and map `../maps/out.js.map` emit `../maps/out.js.map`. `dist/program.js` still advertises `dist/program.js.map` and emits `sourceMappingURL=program.js.map`; a literal `#` or `?` in the sidecar filename is emitted as `%23` or `%3F`. Names containing any ECMAScript line terminator—LF, CR, U+2028, or U+2029—are rejected before emission. `generateArtifactSet()` makes that reference materializable by adding the LF-terminated deterministic JSON serialization of `artifact.sourceMap` at the advertised safe path with role `mapping`; `generateArtifact()` retains its existing sidecar-object contract. `inline` appends a UTF-8 base64 data URL. The default is `none`. PHP, Ruby, Java, and Python still receive sidecar map objects but never receive non-native map comments. C# and Go reject even an explicitly supplied `none`, because multi-backend options must not be silently consumed and their fixed multi-artifact projects have no source-map directive contract. Native Java debugger mapping, C# portable-PDB integration, and Go compiler source-map integration would require compiler-artifact integration and are not part of v1.
 
 The directive itself is an unmapped synthetic rich-map span. `artifact.sourceMap` is computed for the program before that self-referential comment is appended; this is required for a stable inline data URL and is the conventional v3 behavior. Use the rich mapping when the directive span itself matters. Rich registries may distinguish same-named sources by `sourceId`; Source Map v3 identifies sources by filename, so callers should use unique filenames when exporting such an assembled registry to v3.
 
@@ -159,3 +161,7 @@ Validation constructs source line starts once, verifies ranges in linear passes,
 The feature is source-compatible and additive: `generate()` bytes are characterized for both existing fixture profiles, legacy semantic modules remain valid, and existing `location` fields are unchanged. Parsed modules now serialize an additional enumerable `provenance` property, so consumers that compare or persist entire module JSON should consciously include or omit it.
 
 Semantifold is pre-1.0. The recommended release is a minor bump from `0.1.x` to `0.2.0`, with no npm publication as part of this implementation. A future incompatible provenance or mapping representation must use a new schema version rather than reinterpret version 1.
+
+## CPP text provenance
+
+The `cpp` lane emits one `program.cpp` with deterministic rich and Source Map v3 data. Original CPP operator/callee/type/consumer tokens remain mapped through exact ordered-region reconstruction. Inline runtime support, prototypes, temporary declarations/uses, discards, paired markers and short-circuit control are synthetic ranges related to original semantic occurrences. The six-digit occurrence namespace is shared with C’s planning algorithm; CPP marker language and CST validation are independent. No header or map artifact is added. See [CPP semantics and bounds](cpp.md).