semantifold 0.8.0 → 0.10.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (171) hide show
  1. package/README.md +11 -5
  2. package/bin/semantifold.js +6 -0
  3. package/build/bin/semantifold.d.ts +3 -0
  4. package/build/bin/semantifold.d.ts.map +1 -0
  5. package/build/bin/semantifold.js +5 -0
  6. package/build/index.d.ts +9 -0
  7. package/build/index.d.ts.map +1 -1
  8. package/build/index.js +10 -1
  9. package/build/src/artifact-path.d.ts +16 -0
  10. package/build/src/artifact-path.d.ts.map +1 -1
  11. package/build/src/artifact-path.js +29 -3
  12. package/build/src/backends/c-check.d.ts +7 -0
  13. package/build/src/backends/c-check.d.ts.map +1 -0
  14. package/build/src/backends/c-check.js +65 -0
  15. package/build/src/backends/check-plan.d.ts +96 -0
  16. package/build/src/backends/check-plan.d.ts.map +1 -0
  17. package/build/src/backends/check-plan.js +135 -0
  18. package/build/src/backends/cpp-check.d.ts +7 -0
  19. package/build/src/backends/cpp-check.d.ts.map +1 -0
  20. package/build/src/backends/cpp-check.js +59 -0
  21. package/build/src/backends/csharp-check.d.ts +7 -0
  22. package/build/src/backends/csharp-check.d.ts.map +1 -0
  23. package/build/src/backends/csharp-check.js +125 -0
  24. package/build/src/backends/csharp.d.ts +1 -0
  25. package/build/src/backends/csharp.d.ts.map +1 -1
  26. package/build/src/backends/csharp.js +5 -4
  27. package/build/src/backends/dart-check.d.ts +7 -0
  28. package/build/src/backends/dart-check.d.ts.map +1 -0
  29. package/build/src/backends/dart-check.js +103 -0
  30. package/build/src/backends/dart.d.ts +2 -0
  31. package/build/src/backends/dart.d.ts.map +1 -1
  32. package/build/src/backends/dart.js +5 -5
  33. package/build/src/backends/go-check.d.ts +7 -0
  34. package/build/src/backends/go-check.d.ts.map +1 -0
  35. package/build/src/backends/go-check.js +77 -0
  36. package/build/src/backends/go.d.ts +1 -0
  37. package/build/src/backends/go.d.ts.map +1 -1
  38. package/build/src/backends/go.js +3 -3
  39. package/build/src/backends/java-check.d.ts +21 -0
  40. package/build/src/backends/java-check.d.ts.map +1 -0
  41. package/build/src/backends/java-check.js +73 -0
  42. package/build/src/backends/javascript-check.d.ts +7 -0
  43. package/build/src/backends/javascript-check.d.ts.map +1 -0
  44. package/build/src/backends/javascript-check.js +29 -0
  45. package/build/src/backends/kotlin-check.d.ts +7 -0
  46. package/build/src/backends/kotlin-check.d.ts.map +1 -0
  47. package/build/src/backends/kotlin-check.js +31 -0
  48. package/build/src/backends/php-check.d.ts +7 -0
  49. package/build/src/backends/php-check.d.ts.map +1 -0
  50. package/build/src/backends/php-check.js +21 -0
  51. package/build/src/backends/program.d.ts +7 -0
  52. package/build/src/backends/program.d.ts.map +1 -1
  53. package/build/src/backends/program.js +16 -1
  54. package/build/src/backends/python-check.d.ts +7 -0
  55. package/build/src/backends/python-check.d.ts.map +1 -0
  56. package/build/src/backends/python-check.js +28 -0
  57. package/build/src/backends/ruby-check.d.ts +7 -0
  58. package/build/src/backends/ruby-check.d.ts.map +1 -0
  59. package/build/src/backends/ruby-check.js +21 -0
  60. package/build/src/backends/rust-check.d.ts +7 -0
  61. package/build/src/backends/rust-check.d.ts.map +1 -0
  62. package/build/src/backends/rust-check.js +65 -0
  63. package/build/src/backends/swift-check.d.ts +7 -0
  64. package/build/src/backends/swift-check.d.ts.map +1 -0
  65. package/build/src/backends/swift-check.js +77 -0
  66. package/build/src/backends/typescript-check.d.ts +7 -0
  67. package/build/src/backends/typescript-check.d.ts.map +1 -0
  68. package/build/src/backends/typescript-check.js +33 -0
  69. package/build/src/backends/zig-check.d.ts +7 -0
  70. package/build/src/backends/zig-check.d.ts.map +1 -0
  71. package/build/src/backends/zig-check.js +70 -0
  72. package/build/src/diagnostic.d.ts +13 -1
  73. package/build/src/diagnostic.d.ts.map +1 -1
  74. package/build/src/diagnostic.js +14 -2
  75. package/build/src/frontends/program.d.ts +6 -0
  76. package/build/src/frontends/program.d.ts.map +1 -1
  77. package/build/src/frontends/program.js +9 -1
  78. package/build/src/language-registry.d.ts +54 -0
  79. package/build/src/language-registry.d.ts.map +1 -1
  80. package/build/src/language-registry.js +107 -5
  81. package/build/src/project-build.d.ts +172 -0
  82. package/build/src/project-build.d.ts.map +1 -0
  83. package/build/src/project-build.js +320 -0
  84. package/build/src/project-cli.d.ts +40 -0
  85. package/build/src/project-cli.d.ts.map +1 -0
  86. package/build/src/project-cli.js +145 -0
  87. package/build/src/project-manifest.d.ts +148 -0
  88. package/build/src/project-manifest.d.ts.map +1 -0
  89. package/build/src/project-manifest.js +432 -0
  90. package/build/src/project-reporter.d.ts +81 -0
  91. package/build/src/project-reporter.d.ts.map +1 -0
  92. package/build/src/project-reporter.js +293 -0
  93. package/build/src/project-snapshot.d.ts +129 -0
  94. package/build/src/project-snapshot.d.ts.map +1 -0
  95. package/build/src/project-snapshot.js +362 -0
  96. package/build/src/project-watch-reporter.d.ts +125 -0
  97. package/build/src/project-watch-reporter.d.ts.map +1 -0
  98. package/build/src/project-watch-reporter.js +280 -0
  99. package/build/src/project-watch.d.ts +133 -0
  100. package/build/src/project-watch.d.ts.map +1 -0
  101. package/build/src/project-watch.js +839 -0
  102. package/build/src/publication.d.ts +218 -0
  103. package/build/src/publication.d.ts.map +1 -0
  104. package/build/src/publication.js +1832 -0
  105. package/build/src/semantic/types.d.ts +613 -0
  106. package/build/src/semantic/types.d.ts.map +1 -1
  107. package/build/src/semantic/types.js +163 -1
  108. package/build/src/subprocess.d.ts +8 -0
  109. package/build/src/subprocess.d.ts.map +1 -1
  110. package/build/src/subprocess.js +50 -9
  111. package/build/src/target-check.d.ts +52 -0
  112. package/build/src/target-check.d.ts.map +1 -0
  113. package/build/src/target-check.js +796 -0
  114. package/build/src/toolchains.d.ts.map +1 -1
  115. package/build/src/toolchains.js +3 -3
  116. package/docs/architecture.md +3 -1
  117. package/docs/c.md +4 -0
  118. package/docs/cpp.md +4 -0
  119. package/docs/dart.md +4 -0
  120. package/docs/generated-artifact-publication.md +98 -0
  121. package/docs/kotlin.md +2 -2
  122. package/docs/language-support.md +29 -3
  123. package/docs/project-build-cli.md +147 -0
  124. package/docs/project-watch.md +60 -0
  125. package/docs/rust.md +4 -0
  126. package/docs/swift.md +2 -0
  127. package/docs/testing.md +70 -3
  128. package/docs/watch-build-pipeline.md +42 -26
  129. package/docs/zig.md +2 -0
  130. package/examples/jsdoc-java-watch/expected-output.txt +3 -0
  131. package/examples/jsdoc-java-watch/semantifold.json +23 -0
  132. package/examples/jsdoc-java-watch/src/main.js +21 -0
  133. package/index.js +9 -0
  134. package/package.json +6 -1
  135. package/src/artifact-path.js +31 -2
  136. package/src/backends/c-check.js +80 -0
  137. package/src/backends/check-plan.js +147 -0
  138. package/src/backends/cpp-check.js +73 -0
  139. package/src/backends/csharp-check.js +139 -0
  140. package/src/backends/csharp.js +4 -3
  141. package/src/backends/dart-check.js +117 -0
  142. package/src/backends/dart.js +4 -4
  143. package/src/backends/go-check.js +89 -0
  144. package/src/backends/go.js +2 -2
  145. package/src/backends/java-check.js +77 -0
  146. package/src/backends/javascript-check.js +33 -0
  147. package/src/backends/kotlin-check.js +41 -0
  148. package/src/backends/php-check.js +23 -0
  149. package/src/backends/program.js +17 -0
  150. package/src/backends/python-check.js +30 -0
  151. package/src/backends/ruby-check.js +23 -0
  152. package/src/backends/rust-check.js +78 -0
  153. package/src/backends/swift-check.js +89 -0
  154. package/src/backends/typescript-check.js +37 -0
  155. package/src/backends/zig-check.js +81 -0
  156. package/src/diagnostic.js +9 -1
  157. package/src/frontends/program.js +9 -0
  158. package/src/language-registry.js +113 -4
  159. package/src/project-build.js +353 -0
  160. package/src/project-cli.js +155 -0
  161. package/src/project-manifest.js +479 -0
  162. package/src/project-reporter.js +320 -0
  163. package/src/project-snapshot.js +403 -0
  164. package/src/project-watch-reporter.js +303 -0
  165. package/src/project-watch.js +870 -0
  166. package/src/publication.js +2071 -0
  167. package/src/semantic/types.js +184 -0
  168. package/src/subprocess.js +49 -8
  169. package/src/target-check.js +844 -0
  170. package/src/toolchains.js +3 -2
  171. package/tsconfig.json +1 -1
@@ -0,0 +1,147 @@
1
+ # Project manifest and one-shot build CLI
2
+
3
+ Task 039 adds a strict filesystem boundary above the existing `parseProgram`, `generateProgramArtifactSet`, and `GeneratedArtifactPublisher` APIs. Tasks 040–042 compose the registered developer-check boundary without moving target behavior into the CLI. A build reads one explicit source graph, parses and links it once, generates every ordered target from that semantic program, and makes the complete immutable generation active with one pointer replacement. Ordinary `build` remains generation-only; `build --check` invokes only target-owned non-executing plans. Neither mode executes generated code.
4
+
5
+ ## `semantifold.json` version 1
6
+
7
+ The manifest is closed JSON: every object rejects unknown fields. The project file's containing directory is the project root.
8
+
9
+ ```json
10
+ {
11
+ "schema": "SemantifoldProject",
12
+ "version": 1,
13
+ "id": "jsdoc-java-example",
14
+ "publicationRoot": ".semantifold",
15
+ "sources": [
16
+ {
17
+ "id": "main",
18
+ "path": "src/main.js",
19
+ "language": "javascript",
20
+ "entry": true
21
+ }
22
+ ],
23
+ "targets": [
24
+ {
25
+ "id": "java-main",
26
+ "language": "java",
27
+ "role": "text",
28
+ "sourceProjection": "targets/java/source",
29
+ "buildProjection": "targets/java/build"
30
+ }
31
+ ]
32
+ }
33
+ ```
34
+
35
+ Root fields are:
36
+
37
+ - `schema`: exactly `SemantifoldProject`.
38
+ - `version`: exactly `1`.
39
+ - `id`: a stable lowercase project ID matching `[a-z][a-z0-9-]*`.
40
+ - `publicationRoot`: one canonical project-relative portable path owned by the publisher.
41
+ - `sources`: a non-empty ordered array of explicit modules.
42
+ - `targets`: a non-empty ordered array of explicit generated targets.
43
+
44
+ Each source has exactly `id`, `path`, `language`, and Boolean `entry`. Module IDs are stable logical Task-010 identities. Paths are project-relative source paths; languages are explicit registered frontends that participate in the complete-program profile. All modules use one source-language compatibility profile, paths and IDs are unique, and exactly one module has `entry: true`. Extensions never select a language.
45
+
46
+ Each target has exactly `id`, `language`, `role`, `sourceProjection`, and optional `buildProjection`. The role is `text`, `binary`, or `application` and must match both the language registry and an implemented complete-program backend. The existing original-five text program backends are supported. A registered single-module target is not automatically a project target; complete-program binary generation is not implemented. Android and Flutter application backends may participate through their default, asset-free requests. iOS requires caller-supplied application identity and deployment configuration that version 1 cannot express, so an iOS application target fails at manifest loading with `UNSUPPORTED_PROJECT_TARGET`; direct public iOS generation with explicit configuration remains supported. This does not define Task 046 watch/check policy.
47
+
48
+ `sourceProjection` is required. `buildProjection` owns checker/compiler output and defaults to `targets/<target-id>/build`. Both are logical paths inside one immutable generation, never separately promoted output roots. A generation-only build leaves the build projection empty. PHP, Ruby, JavaScript, TypeScript, Rust, Dart, and Zig developer checks leave it empty; Dart 3.13.3 embeds the candidate's absolute source URI, while Zig Debug output retains its absolute project root, so those real native check outputs are removed. Java and Kotlin record class files, Python records its explicit checked-hash `.pyc`, C# records only final `bin/`, and Go/C/C++/Swift record their linked or compiled developer executable after transient restore/intermediate/cache/home/object/target state is removed.
49
+
50
+ Version 1 has no globs, extension inference, package resolution, environment expansion, configuration callbacks, plugins, shell hooks, commands, target-specific compiler settings, or independent output roots.
51
+
52
+ ## Paths and ownership
53
+
54
+ Manifest paths use `/`, contain no empty, dot, or dot-dot segment, and are neither absolute nor drive-qualified. Source paths may use valid Unicode scalar filenames, including spaces; their duplicate, prefix, and Unicode case-fold comparisons remain in that source-path domain. Publication and projection paths separately retain the portable ASCII artifact alphabet. Portable source aliases, duplicate module/target IDs, hard-linked source aliases, and colliding or nested projections are rejected.
55
+
56
+ The manifest, every source, and every existing publication-root component must be real nonsymlink paths under the canonical project root. The publication root cannot contain a source or be a source. Source files may live directly in the project root because the publisher protects their exact paths rather than treating the entire parent directory as source-owned. `GeneratedArtifactPublisher` rechecks source/publication separation and symlink ownership before publication.
57
+
58
+ The publisher owns only:
59
+
60
+ ```text
61
+ <publicationRoot>/
62
+ active-generation.json
63
+ generations/<generation-id>/
64
+ manifest.json
65
+ <target source projection>/...
66
+ <target build projection>/...
67
+ ```
68
+
69
+ Readers resolve `active-generation.json` once and retain the returned immutable generation paths for the whole read. They must not combine paths resolved from separate pointer reads.
70
+
71
+ ## Snapshot and build semantics
72
+
73
+ `ProjectSnapshotBuilder` reads the exact manifest and all declared source files in manifest order. Descriptor identity, size, modification state, real paths, and exact bytes are checked, and the complete graph is read twice. One inconsistent graph receives one bounded retry. Continued mutation fails with a project-relative `UNSTABLE_PROJECT_SNAPSHOT`; a changed manifest is never combined with the already-validated project value.
74
+
75
+ The SHA-256 snapshot hash is length-framed over the exact manifest bytes and ordered source IDs, paths, languages, and UTF-8 content. Absolute host paths and wall-clock values are absent. The generation-only ID is `g-<snapshot-hash>`. Each checked invocation uses `g-<snapshot-hash>-checked-<uuid>` for its fresh candidate, so generation-only and compiler-bearing manifests never alias and compiler output produced by one validation run is never mistaken for a later run.
76
+
77
+ `ProjectBuilder` parses and links the frozen sources once. It generates targets in manifest order through the existing program backend dispatch. With `check: true`, each target must advertise an immutable developer-check capability. The builder discovers exactly that capability's toolchains and attaches a publisher validator; the validator constructs the target-owned plan only after generated artifacts exist in the candidate source subtree. The generic `TargetCheckRunner` validates the complete plan before spawning, owns timeout/cancellation and bounded output, and settles on child `close`. The builder propagates the same cancellation authority through publication, where it is rechecked immediately before the atomic pointer replacement. Only after every target succeeds and cancellation remains inactive does the publisher replace `active-generation.json` once. A configuration, read, parse, link, semantic, generation, discovery, plan, check, cancellation, or pre-pointer publication failure leaves the prior active generation authoritative.
78
+
79
+ Java's target-owned plan declares only stage `compile` and toolchain `javac`, even though full acceptance metadata also declares later `java` execution. It passes `-d <candidate-build-root>` followed by every staged `.java` artifact. Task 041 adds target-owned PHP `-n -l`, Ruby `--disable=gems -c`, Node `--check`, TypeScript no-emit, Kotlin/JVM class compilation, isolated checked-hash Python bytecode, and offline-isolated C# restore/build plans. Task 042 adds target-owned Go build/vet, strict C/C++ compile/link, Cargo locked/offline build/check, Swift type-check/compile, Dart offline lock verification/compile/format/analyze, and Zig build/format plans. The generic plan declares every staged input, every argv/environment path owner, optional restore-input SHA-256, nullable output ownership, and candidate source/build transient directories that the runner removes only after children close. It publishes the last declared compiler/linker output even when a later non-producing validator succeeds. No generic builder, runner, reporter, CLI, or watcher branch switches on a language ID.
80
+
81
+ The version-1 project manifest continues to support complete-program text generation only for PHP, Ruby, JavaScript, TypeScript, and Java. Consequently `build --check` can select all five original-language targets immediately; the Task 041–042 Kotlin/Python/C#/Go/C/C++/Rust/Swift/Dart/Zig plans are public and use the same runner for existing generated single-module artifact sets, but do not expand semantic program generation. C# accepts only the exact producer-owned `Semantifold.csproj`, disables ancestor directory-build imports through global properties at restore and compile, and supplies the complete sorted `.cs` set through the manifest's closed compile-item property. Its restore declares a length-framed hash of ordered project/lock content, uses only the staged source root as its package source, and writes packages, HTTP cache, CLI home, user home, temp, and MSBuild intermediates under the candidate build root. Those transient paths are deleted after compile or failure. Dart similarly accepts only its exact dependency-free package/lock, length-frames that restore identity, and removes `.dart_tool`, isolated pub state, and its native check output before publication. Zig removes its root-dependent Debug prefix with the same post-close transient cleanup. An unchanged watch reconciliation admits no cycle, so it cannot perform a restore.
82
+
83
+ Rebuilding identical generation-only inputs uses the same exact candidate comparison as retained-generation reactivation. If the same deterministic generation is retained but another generation is active, the publisher requires its canonical manifest bytes to equal the validator-free candidate exactly and revalidates the complete inventory, hashes, provenance, symlink boundaries, and hard-link identities before one atomic pointer replacement reactivates it. Task 038 intentionally forbids reactivation requests that carry validators, so a retained same-ID candidate with validators fails with `PUBLICATION_UNOWNED_CONFLICT` instead of trusting previously produced compiler output. Checked builds therefore submit a fresh immutable identity on every invocation and actually rerun every target check, including unchanged and reverted snapshots. A mismatched or malformed retained generation is neither overwritten nor removed, and the previous pointer remains authoritative.
84
+
85
+ ## Command and output
86
+
87
+ The public package installs one executable:
88
+
89
+ ```sh
90
+ semantifold build
91
+ semantifold build --check
92
+ semantifold build --project path/to/semantifold.json
93
+ semantifold build --project path/to/semantifold.json --check --ndjson
94
+ ```
95
+
96
+ The default is `./semantifold.json`. `build`, `--project <path>`, `--check`, and `--ndjson` are the complete grammar. Options may appear once. Unknown commands/options, missing option values, duplicate options, and positional extras fail with `INVALID_CLI_ARGUMENTS`. The executable passes argument arrays directly to the importable CLI; it does not spawn a shell.
97
+
98
+ Human mode prints one concise success line only after the active pointer names the committed generation. Failures retain the outer build/publication diagnostic and render each nested Semantifold cause. A check-process failure then prints labeled project/target, tool, stage, exit/signal, duration, and bounded stdout/stderr evidence without repeating its cause line; tool discovery failures instead retain actionable missing, ambiguous, executable, and version details from their nested diagnostics. SIGINT or SIGTERM after a checker closes but before pointer replacement produces one failure terminal record, never a success record. Exit status is `0` only for a committed generation and `1` for the first failure.
99
+
100
+ `--ndjson` writes one `SemantifoldBuildEvent` version-1 JSON object per line. Every record has `cycle: 1`, `project`, and `state`. Successful builds emit these deterministic states in order:
101
+
102
+ ```json
103
+ {"cycle":1,"project":"jsdoc-java-example","schema":"SemantifoldBuildEvent","version":1,"state":"project-loaded"}
104
+ {"cycle":1,"project":"jsdoc-java-example","schema":"SemantifoldBuildEvent","version":1,"snapshotHash":"<sha256>","state":"snapshot-loaded"}
105
+ {"cycle":1,"project":"jsdoc-java-example","schema":"SemantifoldBuildEvent","version":1,"artifactCount":1,"language":"java","role":"text","state":"target-generated","target":"java-main"}
106
+ {"cycle":1,"project":"jsdoc-java-example","schema":"SemantifoldBuildEvent","version":1,"exitCode":0,"generationId":"g-<sha256>","snapshotHash":"<sha256>","state":"succeeded","targets":[{"artifactCount":1,"id":"java-main","language":"java","role":"text"}],"terminal":true}
107
+ ```
108
+
109
+ There is exactly one record with `terminal: true`. Failure records use `state: "failed"`, `exitCode: 1`, and a stable structured diagnostic. Generation-only records remain deterministic; checked-stage records add the observed lifecycle duration required for process reporting.
110
+
111
+ Checked builds insert one `target-checked` record per successful stage after `target-generated`. It contains the exact `argv`, target and language, stage, canonical tool ID/command/executable/source/version, exit code or signal, bounded stdout/stderr, and duration. The terminal record includes `checked: true`. Check failures retain the outer publication context and a nested compiler diagnostic rather than flattening away stage/tool/process evidence.
112
+
113
+ ## JavaScript/JSDoc to Java example
114
+
115
+ Create `src/main.js`:
116
+
117
+ ```js
118
+ /**
119
+ * @param {number} left
120
+ * @param {number} right
121
+ * @returns {number}
122
+ */
123
+ function add(left, right) {
124
+ return left + right
125
+ }
126
+
127
+ console.log(add(2, 3))
128
+ ```
129
+
130
+ Copy the manifest above to `semantifold.json`, then run:
131
+
132
+ ```sh
133
+ npx semantifold build
134
+ npx semantifold build --check
135
+ ```
136
+
137
+ Resolve `.semantifold/active-generation.json` once; the checked generation from this manifest contains Java at `targets/java/source/semantifold/generated/main/Main.java` and compiler output at `targets/java/build/semantifold/generated/main/Main.class`. The two paths belong to the same immutable generation and are never promoted separately. Omitting `buildProjection` instead selects `targets/<target-id>/build`.
138
+
139
+ `build --check` checks or compiles but never runs generated application behavior. Acceptance code may explicitly invoke committed output afterward. Tasks 043–044 compose the same builder through the packed `semantifold watch --check` JavaScript/JSDoc-to-Java workflow; see [deterministic project watch](project-watch.md) and the shipped [`examples/jsdoc-java-watch`](../examples/jsdoc-java-watch/) project. The terminal all-text acceptance matrix remains Task 045. No build or watch mode garbage-collects committed generations or implements hot reload.
140
+
141
+ ## Importable API and diagnostics
142
+
143
+ `ProjectManifestLoader`, `SemantifoldProject`, `ProjectSnapshotBuilder`, `ProjectSnapshot`, `ProjectBuilder`, `ProjectBuildReporter`, `ProjectWatchCoordinator`, `ProjectWatchReporter`, `SemantifoldCli`, `parseSemantifoldCliArguments`, `createTargetCheckPlan`, and `TargetCheckRunner` are public ESM exports. `languageCapabilities[].check` truthfully exposes immutable `supported`, `stages`, and `toolchains` fields without claiming execution. The executable is only a thin wrapper around `SemantifoldCli`.
144
+
145
+ Plan and lifecycle failures use `UNSUPPORTED_TARGET_CHECK`, `INVALID_TARGET_CHECK_PLAN`, `TARGET_CHECK_PREPARATION_FAILURE`, `TARGET_CHECK_LAUNCH_FAILURE`, `TARGET_CHECK_OUTPUT_LIMIT`, `TARGET_CHECK_TIMEOUT`, `TARGET_CHECK_CANCELLED`, `TARGET_CHECK_SIGNAL`, `TARGET_CHECK_NONZERO_EXIT`, `TARGET_CHECK_CLEANUP_FAILURE`, and `TARGET_CHECK_OUTPUT_INVALID`. Restore failures retain stage `restore`; compiler failures retain stage `compile`. Discovery retains `TOOL_NOT_FOUND`, `TOOL_AMBIGUOUS`, and version diagnostics. Publisher validation remains the transaction boundary and preserves the check diagnostic as its structured cause.
146
+
147
+ Manifest/snapshot diagnostics include `INVALID_PROJECT_MANIFEST`, `INVALID_PROJECT_PATH`, `PROJECT_SOURCE_ALIAS`, `PROJECT_SOURCE_PUBLICATION_OVERLAP`, `PROJECT_PROJECTION_COLLISION`, `PROJECT_SYMLINK_TRAVERSAL`, `PROJECT_MANIFEST_READ_FAILED`, `PROJECT_SOURCE_READ_FAILED`, `INVALID_PROJECT_SOURCE_ENCODING`, `UNSUPPORTED_PROJECT_SOURCE`, `UNSUPPORTED_PROJECT_TARGET`, and `UNSTABLE_PROJECT_SNAPSHOT`. Registry, parser, semantic, backend, artifact, and publication diagnostics retain their existing codes and causes. User output uses project-relative locations and does not print unrelated absolute host paths.
@@ -0,0 +1,60 @@
1
+ # Deterministic project watch
2
+
3
+ Task 043 adds one language-neutral, long-lived coordinator above the existing project snapshot, build/check, and transactional publication contracts. Task 044 proves its first packed checked vertical slice from JavaScript/JSDoc through generated Java and real `javac`. The coordinator accepts filesystem events only as hints, re-reads the complete explicit manifest/source graph, serializes complete cycles, and never executes generated programs.
4
+
5
+ ## Commands
6
+
7
+ ```sh
8
+ semantifold watch
9
+ semantifold watch --project config/semantifold.json
10
+ semantifold watch --check
11
+ semantifold watch --check --ndjson
12
+ ```
13
+
14
+ `watch` accepts the same single `--project`, `--check`, and `--ndjson` options as `build`. Generation-only watch works for every target accepted by the version-1 project manifest. `--check` additionally requires every configured target to advertise a target-owned non-executing developer-check plan. PHP, Ruby, JavaScript, TypeScript, and Java are check-capable among the manifest's existing complete-program text targets; the registry also exposes Kotlin/JVM, Python, and C# plans for their existing generated single-module artifact sets. Neither command runs generated application code.
15
+
16
+ The coordinator installs `SIGINT` and `SIGTERM` handlers before loading the initial graph and immediately performs cycle 1. Invalid startup configuration or a failed initial build terminates watch with status 1. Once the initial cycle succeeds, an ordinary source, semantic, generation, discovery, check, or pre-commit publication failure emits a failed cycle and keeps watch alive. The next successful candidate is reported as recovered. Clean signal shutdown returns status 0.
17
+
18
+ ## Events, reconciliation, and cycle ownership
19
+
20
+ The native backend subscribes to every declared source file, the manifest, and their distinct parent directories. Exact parent-event filenames are mapped to declared graph paths, unknown non-publication events conservatively request a complete reconciliation, and writes identified beneath the publisher-owned root are ignored. Parent subscriptions make deletion, recreation, rename, and editor-style atomic replacement observable without relying on recursive Linux watching.
21
+
22
+ If initial subscription, live watching, or topology resubscription fails, the coordinator closes the complete native subscription set, reports the transition, and switches once to bounded polling. A 1,000 ms reconciliation interval also backs native subscriptions so event loss can be detected. It compares mutation-sensitive state only to decide when to re-read the complete graph and never treats timestamps as build identity; after an invalid graph, the first successful recovery probe preserves one existing quiet timer instead of postponing it on every shorter polling interval. A changed hint starts a 50 ms quiet window. The public `ProjectWatchCoordinator` constructor permits bounded `quietPeriodMs` values from 1 through 10,000 and `pollIntervalMs` values from 1 through 60,000 for embedding and focused tests. The CLI uses the defaults.
23
+
24
+ After the quiet window, `ProjectManifestLoader` and `ProjectSnapshotBuilder` re-read the complete graph in stable manifest order. The versioned complete content/configuration hash is authoritative. A touch or event burst whose final hash is unchanged does not admit a cycle. Create, change, delete, rename, and replacement hints never select a partial event filename as the compilation input.
25
+
26
+ Only one cycle and one checker child can be owned at a time. A hint during a cycle sets one dirty marker; it does not terminate a healthy compiler. After every target checker has closed, the builder invokes a complete-snapshot currentness guard at the publisher's pre-pointer boundary. Changed content supersedes and cleans the staged candidate without replacing `active-generation.json`; one immediate follow-up then owns the latest complete state. A hint in the narrow interval after that guard cancels publication before pointer replacement. After a pointer commit, mutation-sensitive state is compared with the pre-cycle polling baseline: a newer state marks the active cycle dirty and is never absorbed as a clean baseline merely because its native event was lost. A committed pointer still selects exactly one immutable generation, and readers continue to resolve it once.
27
+
28
+ In NDJSON mode, the first hint admitted while a cycle remains active emits nonterminal `state: "cycle-dirty"`. This acknowledges that the coordinator owns one latest-state follow-up; it does not claim that an event filename is a complete input or that its bytes have already been snapshotted. Further hints in the same active cycle collapse into that one dirty generation.
29
+
30
+ ## Failure, reporting, and shutdown
31
+
32
+ Human output identifies succeeded, failed, recovered, superseded, and cancelled cycles. NDJSON uses `SemantifoldWatchEvent` version 1. State records carry the project, cycle, complete snapshot hash when available, stable changed paths, ordered target/check evidence, and durations. Every admitted cycle emits exactly one record with `terminal: true` and `terminalScope: "cycle"`; shutdown emits exactly one separate watcher terminal with `terminalScope: "watch"`.
33
+
34
+ Parse or generation failure never starts a checker. Tool/check failure and stale-candidate refusal never switch the active pointer. Failed candidates are removed through the existing publication ownership journal, while all committed generations remain immutable and retention remains an external policy.
35
+
36
+ On `SIGINT`, `SIGTERM`, or `ProjectWatchCoordinator.stop(reason)`, the coordinator stops admitting cycles, closes every subscription and timer, awaits any in-progress startup read before terminal settlement, aborts the exact active build/check authority, waits for the owned child process group to reach `close`, waits for publisher staging cleanup, emits the watcher terminal once, and resolves. Startup rechecks stop ownership after each asynchronous boundary, so it cannot subscribe, schedule, or report after terminal shutdown. Generated programs are not started, hot-reloaded, or stopped because watch never executes them.
37
+
38
+ ## Importable API and boundaries
39
+
40
+ `ProjectWatchCoordinator` and `ProjectWatchReporter` are public ESM exports. The coordinator composes `ProjectManifestLoader`, `ProjectSnapshotBuilder`, `ProjectBuilder`, target-owned check plans, and `GeneratedArtifactPublisher`; it contains no language IDs, parser logic, compiler argument construction, or artifact writes.
41
+
42
+ The coordinator and generic check runner contain no target-language switch. Target-owned modules construct exact PHP, Ruby, Node, TypeScript, Java, Kotlin/JVM, Python, and C# requests; the runner owns their processes and transient candidate state. Native/project text-target plans remain Task 042, their terminal matrix remains Task 045, and binary/application watch policy remains Task 046. Watch adds no globs, ignore language, daemon mode, editor protocol, runtime execution, hot reload, arbitrary hooks, network access, or package installation.
43
+
44
+ ## Copy-ready JavaScript/JSDoc-to-Java watch
45
+
46
+ The npm package includes [`examples/jsdoc-java-watch`](../examples/jsdoc-java-watch/). Copy that directory outside `node_modules`, enter it, and run:
47
+
48
+ ```sh
49
+ npx semantifold watch --check
50
+ ```
51
+
52
+ The example manifest explicitly selects `src/main.js`, JavaScript, one Java text target, `targets/java/source`, and `targets/java/classes`. Its JSDoc-typed functions cover numeric and Boolean/string control behavior, and `expected-output.txt` records the output used by acceptance. Cycle 1 prints a line of this form only after real `javac` has closed successfully and the pointer has switched:
53
+
54
+ ```text
55
+ Watch cycle 1 succeeded: project 'jsdoc-java-watch' published generation 'g-<snapshot-sha256>-checked-<uuid>'.
56
+ ```
57
+
58
+ An unambiguous supported `javac` must be available on `PATH`, or `SEMANTIFOLD_JAVAC` must name its absolute configured executable. Missing `javac` fails the declared check; watch never silently changes to generation-only operation. Real `java` is not required by watch because watch does not execute generated code. The Task 044 acceptance harness separately discovers real `java`, resolves `active-generation.json` once, verifies the selected manifest/source/class hashes, and executes only that committed class snapshot.
59
+
60
+ Saving a valid edit produces a later successful generation. Touching the source without changing content reports no cycle. A located JavaScript/JSDoc parse or semantic error never invokes `javac`; a real compiler error at the generic staged check boundary never switches the pointer. Both failures keep a previously successful watcher alive, and the next valid edit reports recovery. Edits admitted during an active check emit `cycle-dirty` in NDJSON, allow the owned child to close, refuse its stale candidate, and run one latest-state follow-up without overlapping compiler processes. `SIGINT` or `SIGTERM` during idle or checking closes subscriptions and the exact checker process before the sole watcher terminal.
package/docs/rust.md CHANGED
@@ -86,3 +86,7 @@ Tests also execute each built binary directly, distinguish build diagnostics fro
86
86
  Focused product specs cover Tasks001–004 round trips, all 18 operations, strings and ownership, branch/order/divergence behavior, both build modes and every overflow, real rustc E0382/E0505 source rejection, native execution at the generated nesting boundary, malformed IR/helper adversaries, deterministic artifacts and rich/V3 forward/reverse mappings around Unicode. Rust fixtures execute in all original-five native targets, and one original-five source per profile executes in Rust in both modes. Task025 owns the expanded-cohort matrix.
87
87
 
88
88
  The root packed-consumer proof repeats ordinary npm install and clean npm ci with separate fresh caches, empty configuration files, default install-links=false, isolated modern/legacy runtimes, strict TypeScript and native offline Rust in both modes. The local lane still has the complete home mounted: this proves cleaned-environment behavior, not the external source/home/auth-free boundary. Disposable acceptance inputs and exact local evidence are prepared for the coordinator to run across that boundary before delivery. Local testing uses individual focused files sequentially; TensorBuzz owns full/native aggregate acceptance.
89
+
90
+ ## Non-executing developer check
91
+
92
+ The registered Task 042 plan accepts only the exact producer-owned dependency-free `Cargo.toml`, `Cargo.lock`, and Rust sources. It qualifies both canonical Rustc and Cargo 1.98.1, binds `RUSTC` to the exact discovered compiler even when the tools occupy different directories, and runs `cargo build --offline --locked --target-dir <candidate>` followed by `cargo check --offline --locked --target-dir <candidate>`. CARGO_HOME, HOME, TMPDIR, incremental state, and the target tree are isolated below the candidate build root and removed after both children close, so no dependency, cache lock, or executable is published or run. Debug/release execution remains explicit acceptance coverage.
package/docs/swift.md CHANGED
@@ -42,3 +42,5 @@ Discovery uses canonical command `/usr/bin/swiftc` after image construction or a
42
42
  The Dockerfile selects official image `swift:6.3.3-noble@sha256:56ef1be2c1ca36f4c52440357dc1fcdfdb5e113587134fcadeef57c225c71b54`; its Linux/amd64 child manifest is `sha256:4e0fc24f0f93a5cf9a91bfcf182534bbc0571d70d757389c04ff1f616c1c460f`. A source stage probes the identity and copies only Swift executable/resource paths into the unchanged final `ubuntu:26.04@sha256:3131b4cc82a783df6c9df078f86e01819a13594b865c2cad47bd1bca2b7063bb` stage. It does not copy project source or replace the final `/usr` tree wholesale.
43
43
 
44
44
  Real acceptance independently materializes each original parser fixture and regenerated `program.swift` in a fresh directory, runs `swiftc -warnings-as-errors -typecheck`, compiles once without optimization and once with `-O`, executes both binaries, checks exact UTF-8 stdout/stderr/status, verifies source bytes are unchanged, and removes the directory. Its deterministic PATH places the resolved compiler directory first, the canonical host-tool directory `/usr/bin` second, and the isolated caller PATH last with first-occurrence deduplication, so archive Swift selects its own compiler companions while Clang can launch the host linker. The rebuilt canonical image passed this exact Swift 6.3.3 x86_64 contract; `spec/swift-native-execution.spec.js` is 6/6.
45
+
46
+ The registered Task 042 developer plan uses the same explicit driver mode and warnings-as-errors profile for `-typecheck`, then compiles the stable `SemantifoldGenerated` module to a relative object inside a generation-owned transient directory and links generation-owned `semantifold-swift` with the nondeterministic ELF build ID disabled. This avoids the driver's randomized temporary object path entering Swift's module hash, so repeated candidates produce identical executable bytes. The object directory, HOME, XDG cache, and TMPDIR are removed after close. The developer plan never runs the executable; debug and `-O` execution remain explicit acceptance profiles.
package/docs/testing.md CHANGED
@@ -1,5 +1,39 @@
1
1
  # Testing
2
2
 
3
+ ## Task 044 packed JavaScript/JSDoc-to-Java watch slice
4
+
5
+ `jsdoc-java-watch-packed-consumer.spec.js` performs the complete Task 044 proof from a real root tarball after ordinary credential-free install and clean `npm ci`, each with default `install-links=false`, an empty user/global npm configuration, a fresh cache, the public registry, full dependency listing, and strict public API typing. One long-lived packed `watch --check --ndjson` process uses an exact-argv test-owned configured compiler boundary that delegates to canonical real `javac`. Event and process markers—not timing sleeps—drive valid edits, no-op touch suppression, a located frontend failure, one controlled invalid staged-Java compiler failure, recovery, dirty-during-check burst supersession, and idle/active signal shutdown. Every successful cycle resolves the active pointer once, verifies manifest and artifact hashes/provenance, and invokes canonical real `java` only from the acceptance harness. Missing `javac`, overlap, leakage, a changed last-good byte, or a missing tool is a failure, never a skip.
6
+
7
+ Run it as one focused file:
8
+
9
+ ```sh
10
+ npx velocious-test spec/jsdoc-java-watch-packed-consumer.spec.js
11
+ ```
12
+
13
+ ## Task 040 target check plans and Java compiler publication
14
+
15
+ Task 040 uses focused plan, process-lifecycle, real project transaction, CLI, registry/public-API, and packed-consumer specs. `target-check-plan.spec.js` owns immutable capability/plan schema, exact Java argv, target-declared stage/tool validation, generation-only rejection, path ownership, dense immutable arguments/environment, and the developer execution prohibition. `target-check-runner.spec.js` owns launch, non-zero, output-limit, timeout, cancellation, child-signal, late-output, and close-only settlement behavior without timing sleeps. `project-java-check.spec.js` compiles a real two-unit JavaScript/JSDoc → semantic IR → Java project into the generation-scoped build subtree, executes committed classes only in acceptance code, and proves repeated and A→B→A checked builds rerun real `javac`, exact reverted source/class bytes, missing/ambiguous `javac`, invalid Java, pre-pointer failure, exact last-good bytes, cleanup, and recovery. CLI coverage owns strict `--check`, stage/tool/process reporting, nested compiler and tool-discovery diagnostics, the no-execution boundary, and deterministic cancellation after checker close but before pointer replacement with exact last-good source/class preservation. The packed-consumer proof repeats ordinary install and clean `npm ci` with scrubbed credentials/configuration, public declaration use, real package bin/`javac`, committed class resolution, and explicit post-build `java` execution.
16
+
17
+ Real Java proofs require canonical `javac` and `java`; absence is a failure, never a skip. Run these focused files individually with `npx velocious-test <file>`. Broad discovery and the complete toolchain matrix remain TensorBuzz-owned.
18
+
19
+ ## Task 039 project manifest and one-shot build CLI
20
+
21
+ Task 039 uses four focused real-filesystem specs plus the public API and nearby publication regression. Manifest coverage owns the closed schema, registered complete-program roles, identities, entry selection, portable paths, source/publication separation, projection collisions, hard-link aliases, and symlink roots. Snapshot coverage owns deterministic ordered hashing and bounded real-file mutation. Build coverage owns one-file JavaScript/JSDoc-to-Java, Task-010 multi-file/multi-target publication, one parse and pointer commit, project-root source ownership, and late-target atomic failure. CLI coverage owns the original generation-only strict arguments, human/NDJSON terminal truth, and exit status. Task 040 extends rather than replaces these proofs.
22
+
23
+ Run the focused files individually and sequentially:
24
+
25
+ ```sh
26
+ npx velocious-test spec/project-manifest.spec.js
27
+ npx velocious-test spec/project-snapshot.spec.js
28
+ npx velocious-test spec/project-build.spec.js
29
+ npx velocious-test spec/project-cli.spec.js
30
+ npx velocious-test spec/project-cli-packed-consumer.spec.js
31
+ npx velocious-test spec/generated-artifact-publication.spec.js
32
+ npx velocious-test spec/public-api.spec.js
33
+ ```
34
+
35
+ These tests generate and publish source artifacts only. They do not run `javac`, execute generated output, discover packages, or watch files.
36
+
3
37
  ## Task 005 general function signatures and calls
4
38
 
5
39
  Task 005 stays bounded to PHP, Ruby, JavaScript with JSDoc, TypeScript, and Java. `general-function-signatures-and-calls.spec.js` proves equivalent zero-, one-, and three-parameter signatures, complete signature collection, nested calls, terminating recursion, scalar/void returns, and the stable semantic failures. `general-function-frontend-validation.spec.js` owns the excluded parameter, call, method, receiver, dispatch, annotation, overload, generic, and higher-order source forms. `general-function-backend-validation.spec.js` proves generation/reparse, exact external-IR signature revalidation, target conflicts, the public feature flag, and transactional rejection from every deferred Task 025/Wasm target. `general-function-provenance-and-mapping.spec.js` proves deterministic declaration/resolution identities and exact signature/call mappings. `general-function-runtime-execution.spec.js` invokes real PHP, Ruby, Node, local `tsc` followed by Node, `javac`, and `java`, requiring exact `ready\n6\n` output; a missing command fails.
@@ -346,7 +380,40 @@ Task 017 adds the distinct ordered `restore` stage and configured .NET SDK 10 di
346
380
 
347
381
  Task 024 adds configured Go 1.26.x discovery restricted to Linux/amd64; the patch release is read from the discovered toolchain rather than fixed by runtime tests. Acceptance obtains `GOROOT` from that exact `go`, requires the companion `gofmt` beside the configured or discovered executable to resolve to the same `GOROOT/bin/gofmt`, and checks `gofmt -d` before native execution. Each dependency-free generated module is run with `GOTOOLCHAIN=local`, `GOPROXY=off`, `GOSUMDB=off`, `GOVCS=off`, `CGO_ENABLED=0`, `GOENV=off`, `GOWORK=off`, `GOOS=linux`, `GOARCH=amd64`, and isolated HOME/GOPATH/build/module caches. The short-lived discovery fixture also writes exact `off` mode into its isolated Go telemetry directory before invoking the tool, then asserts that the mode file is the only telemetry state: Go 1.26 otherwise starts an unawaited uploader sidecar even in default `local` mode, which can recreate `upload/` while the fixture root is being removed. Cleanup errors remain fatal. Stages run offline `go build`, mandatory `go vet`, and `go run`, while compiler-only differential cases use the matching `go tool compile`. Tests require exact status/stdout, unchanged `go.mod`/`main.go`, no `go.sum`/`go.work`/vendor tree, and byte-identical binaries and output in two fresh directories. Missing, wrong-minor, wrong-architecture, mismatched-gofmt, download, cgo, workspace, vet, formatting, nondeterminism, telemetry leakage, or cleanup evidence fails without a skip.
348
382
 
349
- Task 023 adds exact Kotlin/JVM 2.4.20 discovery on the pinned OpenJDK 25.0.4+7 Ubuntu runtime. Ubuntu26.04 development and Ubuntu24.04 TensorBuzz use their exact `25.0.4+7-1~26.04` and `25.0.4+7-1~24.04` package builds. Bootstrap and discovery accept only their two qualified compiler-reported distribution suffixes, never arbitrary output. Original and generated `Program.kt` files compile with `-language-version 2.4 -api-version 2.4 -jvm-target 25 -Werror -include-runtime` into runnable `Program.jar` files, then execute through the exact `java25` discovery contract. Every process uses a fresh directory and exact status/stderr/UTF-8 stdout assertions; no test downloads a compiler or dependency.
383
+ Task 023 adds exact Kotlin/JVM 2.4.20 discovery on pinned OpenJDK 25 Ubuntu runtimes. Ubuntu26.04 development uses exact `25.0.4.1+1-1~26.04.4`; Ubuntu24.04 TensorBuzz retains exact `25.0.4+7-1~24.04`. Bootstrap and discovery accept only those two qualified compiler-reported package identities, never arbitrary output. Original and generated `Program.kt` files compile with `-language-version 2.4 -api-version 2.4 -jvm-target 25 -Werror -include-runtime` into runnable `Program.jar` files, then execute through the exact `java25` discovery contract. Every process uses a fresh directory and exact status/stderr/UTF-8 stdout assertions; no test downloads a compiler or dependency.
384
+
385
+ Task 041's product checks are separate from runtime acceptance. Run the two focused files sequentially:
386
+
387
+ ```sh
388
+ npx velocious-test spec/managed-target-check-plans.spec.js
389
+ npx velocious-test spec/managed-target-check-real-tools.spec.js
390
+ ```
391
+
392
+ The plan spec proves exact frozen registry descriptors/argv, declared input and path ownership, no execute stage, stable C# project/lock hashing, and source-only changes that do not alter that restore identity. The real-tool spec fails rather than skips when any configured PHP, Ruby, Node, TypeScript, Kotlin, Python, or .NET tool is unavailable. It checks a generated supported fixture twice per target, injects invalid native source at every plan boundary, and requires preserved native output, nonzero structured stage diagnostics, the unchanged last-good pointer/bytes, and no failed candidate/staging residue. A separate malformed C# lockfile produces a real `restore` failure distinct from `compile` failure. The same file exercises all Task 041 targets already admitted by the version-1 complete-program boundary through the unchanged generic CLI.
393
+
394
+ `spec/csharp-target-check-safety.spec.js` is the focused correction gate. With real .NET it proves that altered project bytes are rejected before a safe project-defined write target can run, ancestor `Directory.Build.targets` is not imported, staged source bytes remain unchanged, and an additional invalid `.cs` artifact reaches the compiler through the exact deterministic compile-item list instead of being merely declared as evidence.
395
+
396
+ Product checks never execute the generated marker program. PHP uses configuration-free lint, Ruby disables gems for syntax checking, Node uses parse-only `--check`, and TypeScript uses no emit/incremental state plus candidate-only type roots. Kotlin publishes only `classes/`; Python uses isolated `py_compile` with checked-hash invalidation and publishes one build-root `.pyc`; C# accepts only its canonical generated manifest, disables ancestor customization, compiles every staged source, and lets restore consult only the staged local source. All NuGet/CLI/home/temp/intermediate paths are generation-owned and removed after the compiler closes, leaving only `bin/`. Repeated output inventories must match, source trees remain byte-owned by the publisher, and missing tools are failures.
397
+
398
+ Task 042's native/project checks are covered by two additional focused files, run sequentially:
399
+
400
+ ```sh
401
+ npx velocious-test spec/native-project-target-check-plans.spec.js
402
+ npx velocious-test spec/native-project-target-check-real-tools.spec.js
403
+ ```
404
+
405
+ The plan spec asserts exact frozen registry descriptors, argv arrays, declared inputs, path ownership, non-execution, and isolation for Go, C, C++, Rust, Swift, Dart, and Zig. It proves that Dart's length-framed restore identity contains only the exact producer-owned `pubspec.yaml`/`pubspec.lock` and is stable across source-only changes. The real-tool spec fails rather than skips when any qualified tool is unavailable. For every target it publishes two fresh valid candidates, checks stable source/build inventories and successful native stages, injects invalid staged source, retains native diagnostics and exact target identity, preserves the prior pointer/bytes, and proves the failed candidate plus transient state are gone.
406
+
407
+ The developer profiles are intentionally bounded and non-executing:
408
+
409
+ - Go uses exact local Go 1.26, `CGO_ENABLED=0`, `GOTOOLCHAIN=local`, read-only modules, network/VCS/workspace disablement, trimmed/build-ID-free output, and mandatory vet. Its HOME, GOPATH, GOCACHE, GOMODCACHE, and GOTMPDIR are candidate-owned; the qualified version-specific telemetry child guard prevents an unowned uploader descendant.
410
+ - C uses strict Clang C17 at `-O0`, compiling every `.c` unit while declaring every `.h`, then linking the complete object set. C++ uses Clang C++20/libstdc++, no exceptions/RTTI, and the matching strict warnings/encoding/overflow profile. Their objects and temp state are removed, leaving only the linked developer executable. Existing O0/O2 ordinary plus ASan/UBSan/leak runs remain mandatory explicit acceptance/CI profiles; they are not hidden watcher branches.
411
+ - Rust requires the exact dependency-free edition-2021 manifest and format-4 lock, qualifies both exact Rustc and Cargo identities, binds Cargo to the discovered compiler through an exact `RUSTC` tool environment path, then runs `cargo build --offline --locked` and `cargo check --offline --locked` with isolated CARGO_HOME/HOME/temp/target state and no incremental compilation. All Cargo target/cache/lock/executable state is transient.
412
+ - Swift 6.3.3 explicitly uses `--driver-mode=swiftc`, warnings as errors, `-typecheck`, then a stable named-module object compile and native link with the ELF build ID disabled. The owned relative object path avoids randomized driver-temporary paths in `.swift_modhash`; object/HOME/XDG cache/temp state is removed, and the byte-stable compiled output is published but never run.
413
+ - Dart 3.13.3 performs `pub get --offline --dry-run --enforce-lockfile --no-precompile` against the fixed dependency-free package, compiles the selected native executable, verifies formatting with no writes, and runs fatal analysis. PUB_CACHE/HOME/temp, the candidate package's `.dart_tool`, and the path-dependent native check output are declared transient and removed after close; `PUB_HOSTED_URL` is unreachable.
414
+ - Zig 0.15.2 accepts only `build.zig` plus generated Zig sources, runs the Debug project build with generation-owned local/global caches and prefix, then runs `zig fmt --check`. The root-dependent Debug prefix is transient, so no native executable leaks or is published. Canonical format, `zig build test`, and builds/runs in Debug, ReleaseSafe, and ReleaseFast remain mandatory explicit acceptance/CI coverage and are not repeated on every edit.
415
+
416
+ No Task 042 plan runs a generated executable, fetches a package, consults a user-global dependency home, cross-compiles, or adds a terminal matrix. Native nonzero exit, discovery, invalid plan, restore, compile, link, validation, timeout/cancellation, cleanup, and publication failures retain their distinct existing diagnostics.
350
417
 
351
418
  | Tool ID | Canonical command | Absolute-path override | Accepted canonical version |
352
419
  | --- | --- | --- | --- |
@@ -357,8 +424,8 @@ Task 023 adds exact Kotlin/JVM 2.4.20 discovery on the pinned OpenJDK 25.0.4+7 U
357
424
  | `tsc` | `tsc` | `SEMANTIFOLD_TSC` | TypeScript 7.x |
358
425
  | `javac` | `javac` | `SEMANTIFOLD_JAVAC` | JDK 17–29 |
359
426
  | `java` | `java` | `SEMANTIFOLD_JAVA` | JRE 17–29 |
360
- | `java25` | `java` | `SEMANTIFOLD_JAVA` | exact OpenJDK 25.0.4+7 Ubuntu runtime for JVM25 artifacts |
361
- | `kotlinc` | `kotlinc` | `SEMANTIFOLD_KOTLINC` | exact Kotlin/JVM 2.4.20 on JRE 25.0.4+7 Ubuntu |
427
+ | `java25` | `java` | `SEMANTIFOLD_JAVA` | exact OpenJDK 25.0.4.1+1 development or 25.0.4+7 TensorBuzz runtime for JVM25 artifacts |
428
+ | `kotlinc` | `kotlinc` | `SEMANTIFOLD_KOTLINC` | exact Kotlin/JVM 2.4.20 on the matching qualified OpenJDK 25 Ubuntu package |
362
429
  | `python` | `python3` | `SEMANTIFOLD_PYTHON` | Python 3.x |
363
430
  | `dotnet` | `dotnet` | `SEMANTIFOLD_DOTNET` | .NET SDK 10.x |
364
431
  | `go` | `go` | `SEMANTIFOLD_GO` | Go 1.26.x, Linux/amd64 |
@@ -2,7 +2,7 @@
2
2
 
3
3
  ## Status and verified baseline
4
4
 
5
- This document is a roadmap contract, not an implemented CLI contract.
5
+ Tasks 039–042 implement the strict project manifest, stable one-shot snapshot, deterministic generation orchestration, generic non-executing check-plan contract, Java/`javac`, the interpreted/managed cohort, the native/project cohort, human/NDJSON reporting, and packaged `semantifold build [--check]`. Task 043 implements the language-neutral deterministic watch coordinator and `semantifold watch [--check]`; Task 044 proves its packed JavaScript/JSDoc-to-Java checked vertical slice. Task 045 remains the terminal all-text matrix.
6
6
 
7
7
  The inspected baseline is `semantifold@0.7.0`, annotated tag `v0.7.0`, commit `8cd70c5a6c7de98df2d4a183d6555ad4f3d5ba5a`. At that revision:
8
8
 
@@ -11,31 +11,31 @@ The inspected baseline is `semantifold@0.7.0`, annotated tag `v0.7.0`, commit `8
11
11
  - `discoverCanonicalToolchain` finds the configured `javac` and `java` executables.
12
12
  - `runAcceptanceStages` materializes an artifact set in a temporary directory and runs caller-supplied exact argument arrays with bounded process execution.
13
13
  - A bounded direct proof parsed the 2,648-byte JSDoc fixture `spec/fixtures/compatibility/program.js`, generated `Main.java`, compiled it with `javac 25.0.4`, executed it with Java 25.0.4, and observed the canonical output `compat\nbranch-ok!\npresent\nabsent\n7\n2\n3\n5\n4\n`.
14
- - `package.json` has no `bin` entry. The public API does not persist generated artifacts, load a project manifest, derive compiler arguments from a target, or watch source files.
14
+ - `package.json` had no `bin` entry. The public API did not persist generated artifacts, load a project manifest, derive compiler arguments from a target, or watch source files.
15
15
  - The only repository file-change watcher is a test helper; there is no product watch coordinator, incremental dependency graph, event coalescing policy, or long-lived compiler owner.
16
16
 
17
- The current system therefore already proves **JavaScript/JSDoc → semantic IR → Java → `javac`** as a one-shot composition. The roadmap below turns that composition into a safe project workflow without moving filesystem or process lifecycle concerns into parsers or backends.
17
+ That historical baseline proved **JavaScript/JSDoc → semantic IR → Java → `javac`** as a one-shot composition. Released `semantifold@0.9.0` supplies Task 038's public language-neutral `GeneratedArtifactPublisher`, immutable generation manifests, one atomic active pointer, pointer-once resolution, and journal-bounded recovery. Task 039 adds the package bin, project configuration, and one-shot CLI behavior; Task 040 productizes the generic plan/runner and Java compiler boundary; Task 041 adds PHP, Ruby, JavaScript, TypeScript, Kotlin/JVM, Python, and C# plans; Task 042 adds Go, C, C++, Rust, Swift, Dart, and Zig plans; Task 043 supplies generic watch coordination; and Task 044 supplies the packed credential-free watch proof and public example.
18
18
 
19
19
  ## Product outcome
20
20
 
21
- A project can declare explicit source modules, one or more generated targets, one publisher-owned project publication root, target-relative generated/build projections, and whether each target is checked with its real toolchain. It can then run:
21
+ A project can declare explicit source modules, one or more generated targets, one publisher-owned project publication root, and target-relative generated/build projections. The one-shot CLI selects generation-only or all-target developer checking with `--check`. It can then run:
22
22
 
23
- - a planned one-shot `semantifold build`; or
24
- - a planned long-lived `semantifold watch`.
23
+ - the implemented one-shot `semantifold build`; or
24
+ - the implemented long-lived `semantifold watch`.
25
25
 
26
26
  For the first end-to-end slice, changing a JSDoc-typed JavaScript source regenerates Java and compiles the staged candidate with `javac`. A successful cycle publishes one coherent generated-source/compiler-output generation through one active-generation pointer switch. A parse, semantic, generation, tool-discovery, compiler, or publication failure reports a located diagnostic, keeps the process alive in watch mode, and leaves the previous successful generation usable. A later valid edit recovers without restarting the watcher.
27
27
 
28
- The architecture is target-neutral. Every current text backend eventually supplies one target-owned check plan. Every current source frontend participates through the existing parser/project APIs; the watcher never contains language syntax logic.
28
+ The architecture is target-neutral. All fifteen text targets supply target-owned plans. Every current source frontend participates through the existing parser/project APIs; the watcher never contains language syntax logic.
29
29
 
30
30
  ## Architecture boundaries
31
31
 
32
- ### Project manifest and loader
32
+ ### Project manifest and loader (Task 039 implemented)
33
33
 
34
34
  A versioned, strict manifest declares ordered source modules and target entries. Source language, module identity, entry identity, target language/role, one project publication root, and each target's generated/check subpaths inside an immutable project generation are explicit. These target paths are logical projections, not independently promoted filesystem roots. Version 1 uses explicit file paths rather than introducing a glob language or package-manager resolution.
35
35
 
36
- The loader owns path normalization and rejects unknown fields, duplicate module/target identities, ambiguous target roles, source/publication overlap, publication roots outside the project root, colliding or nested target projections, and symlink/path traversal across the owned publication root. It returns an immutable project request and never parses language syntax.
36
+ The loader owns path normalization and rejects unknown fields, duplicate module/target identities, ambiguous target roles, source/publication overlap, publication roots outside the project root, colliding or nested target projections, symlink/path traversal across the owned publication root, and registered backend capabilities whose required configuration version 1 cannot express. It returns an immutable project request and never parses language syntax.
37
37
 
38
- ### Snapshot builder
38
+ ### Snapshot builder (Task 039 implemented for one-shot builds)
39
39
 
40
40
  Each cycle reads a complete content snapshot of every declared source and the project manifest. File events are hints only. Before parsing, the coordinator re-reads and hashes the declared graph in stable order; it never assumes an event filename is complete or authoritative.
41
41
 
@@ -45,30 +45,44 @@ A snapshot is immutable for the cycle. Edits arriving during parse/generation/ch
45
45
 
46
46
  Frontends, semantic validation, linking, and backends remain pure with respect to the project filesystem. They consume the immutable snapshot and return complete `GeneratedArtifactSet` values. No frontend or backend starts watchers, writes files, spawns a compiler, or reads undeclared project files.
47
47
 
48
- ### Transactional artifact publication
48
+ ### Transactional artifact publication (Task 038 implemented)
49
49
 
50
- A publisher stages one complete project candidate as a new immutable generation beneath the publisher-owned publication root. Every target's generated artifacts, mappings, and optional compiler outputs live in generation-relative subtrees on the same filesystem. The publisher validates paths, mappings, hashes, collisions, ownership, and manifests before touching committed state.
50
+ `GeneratedArtifactPublisher` stages one complete project candidate as a new immutable generation beneath a dedicated publisher-owned publication directory inside the canonical project root. Every target carries an explicit language-neutral role, and its generated artifacts, mappings, and optional validator/compiler outputs live in generation-relative subtrees on the same filesystem. The publisher validates paths, mappings, hashes, hard-link identities, complete generation inventory, collisions, ownership, and manifests before touching committed state. Its public contract and caller obligations are documented in [transactional generated-artifact publication](generated-artifact-publication.md).
51
51
 
52
- When checking is enabled, target checks run against those staged generation subtrees. Only a fully generated and successfully checked project candidate may be published. The generation manifest is the explicit versioned authority for files the publisher created; it never authorizes mutation outside the publication root.
52
+ When checking is enabled, target checks run against those staged generation subtrees. Each checked invocation owns a fresh immutable candidate identity, including for an unchanged or reverted source snapshot, so it cannot reuse retained compiler output instead of executing the declared checks. Generation-only snapshots retain deterministic same-ID verification and reactivation. Only a fully generated and successfully checked project candidate may be published. The generation manifest is the explicit versioned authority for files the publisher created; it never authorizes mutation outside the publication root.
53
53
 
54
54
  Publication commits exactly one small active-generation pointer by writing and syncing a sibling temporary pointer, atomically replacing the prior pointer on the same filesystem, and syncing the parent directory before reporting success. A host filesystem that cannot provide atomic same-directory regular-file replacement is rejected before publication; copying, truncating, or rewriting the live pointer in place is never a fallback. Readers resolve that pointer once and consume all generated/build paths from the referenced immutable generation. Configured generated-source and compiler-output names are logical projections returned from that resolved generation; they are never independent directories, symlinks, or manifests promoted one after another. The same rule covers every target in a multi-target cycle.
55
55
 
56
- An interruption before the pointer replacement leaves the previous generation active; an interruption after it leaves either the old or new complete pointer durably recoverable, never a composite state. A recovery journal may finish cleanup of unpublished candidates and temporary pointer files, but it is not used to claim atomicity across multiple filesystem operations. Publication never removes a committed generation, because a reader may already hold its resolved snapshot; committed-generation retention/garbage collection is a separate explicit policy. A failed candidate is removed without changing the active pointer.
56
+ An interruption before the pointer replacement leaves the previous generation active; an interruption after it leaves either the old or new complete pointer durably recoverable, never a composite state. A recovery journal may finish cleanup of unpublished candidates and temporary pointer files, but it is not used to claim atomicity across multiple filesystem operations. Candidate and temporary-pointer parent directories are synchronized before the proving journal is removed and its directory synchronized. Publication never removes a committed generation, because a reader may already hold its resolved snapshot; committed-generation retention/garbage collection is a separate explicit policy. A failed candidate is removed without changing the active pointer.
57
57
 
58
- ### Target check-plan registry
58
+ ### Target check-plan registry (Tasks 040–042 implemented)
59
59
 
60
- The existing language registry remains authoritative for target identity, roles, declared acceptance stages, and required toolchain IDs. A planned target-check capability derives exact stage requests from a validated staged artifact set and its generation-scoped target build subtree.
60
+ The existing language registry remains authoritative for target identity, roles, declared acceptance stages, and required toolchain IDs. Its explicit immutable `check` capability distinguishes generation-only targets from Java plus PHP, Ruby, JavaScript, TypeScript, Kotlin/JVM, Python, and C# developer checks without claiming execution. The target-owned factory derives exact stage requests from a validated staged artifact set and its generation-scoped target source/build subtrees.
61
61
 
62
- The generic runner owns process lifecycle, locale/timezone normalization, output capture, timeout/cancellation, and close observation. A target check plan owns filenames, exact argv, toolchain IDs, offline/cache policy, and which stages constitute a non-executing developer check. The watcher does not switch on language IDs.
62
+ The generic runner validates immutable dense argv, complete artifact inputs, restore hashes, candidate-path ownership, exact discovered-tool environment bindings, nullable output ownership, and transient candidate directories before spawn. It owns process lifecycle, locale/timezone normalization, bounded output capture, timeout/cancellation, signal forwarding, first failure, close observation, and post-close transient cleanup. A target check plan owns filenames, exact argv, toolchain IDs, offline/cache policy, and which stages constitute a non-executing developer check. The builder and watcher do not switch on language IDs.
63
63
 
64
- The initial check plan is Java/`javac`. Later tasks add current text targets in two cohorts:
64
+ Java/`javac` compiles every staged `.java` artifact together with `-d` directed at the candidate build subtree and never invokes `java`. Task 041 implements the interpreted/managed cohort:
65
65
 
66
- - interpreted/managed: PHP, Ruby, JavaScript, TypeScript, Kotlin/JVM, Python, and C# (Java is supplied by the initial slice);
67
- - native/project: Go, C, C++, Rust, Swift, Dart, and Zig.
66
+ - PHP, Ruby, and JavaScript run real syntax checks once per generated language artifact;
67
+ - TypeScript type-checks the complete set with no emit and isolated type roots;
68
+ - Kotlin/JVM compiles all sources together to candidate-owned classes;
69
+ - Python produces deterministic checked-hash bytecode at an explicit candidate build path and never creates source-adjacent `__pycache__`;
70
+ - C# requires its exact producer-owned project, disables ancestor MSBuild props/targets, passes every staged `.cs` file in deterministic order, hashes project/lock restore inputs, restores from a local-only staged source into candidate-owned state, builds with `--no-restore`, and removes cache/home/intermediate state before publishing only `bin/` outputs.
68
71
 
69
- A watch check validates or compiles but does not execute generated application code by default. Restore/download behavior is never an implicit per-edit action; targets with project metadata use pinned, offline, isolated state and rerun prerequisite stages only when their declared inputs change.
72
+ Task 042 implements the remaining cohort:
70
73
 
71
- ### Watch coordinator
74
+ - Go disables cgo, workspace/toolchain switching, VCS, and network resolution for its build, then vets read-only with isolated HOME/GOPATH/module/build/temp state.
75
+ - C and C++ compile every translation unit and link through the strict Clang C17 or C++20/libstdc++ `-O0` developer profile. Object/temp state is transient; `-O2` and ASan/UBSan remain explicit CI acceptance profiles rather than watcher branches.
76
+ - Rust accepts only the dependency-free generated Cargo manifest/lock, qualifies both Rustc and Cargo, binds Cargo's `RUSTC` to that exact discovered compiler, runs locked offline build/check with isolated Cargo home/target state, and removes that state before publication.
77
+ - Swift type-checks and compiles with exact driver mode and warnings as errors while isolating home/cache/temp state.
78
+ - Dart validates only the producer-owned dependency-free package/lock through an enforced offline dry run, compiles a native executable, verifies format, and analyzes fatally. The restore hash excludes ordinary source edits; `.dart_tool`, pub/home/temp state, and the absolute-source-URI-bearing native check output are transient.
79
+ - Zig accepts only the producer-owned standard-library-only project, builds Debug with isolated local/global caches and an owned transient prefix, then verifies canonical formatting. Multi-mode builds/tests remain explicit acceptance profiles.
80
+
81
+ None of these developer plans executes its generated program. A later validator does not hide an earlier declared compiler/linker output, and all candidate transient state is removed after child close on success, failure, timeout, or cancellation.
82
+
83
+ A watch check validates or compiles but does not execute generated application code by default. A content-identical reconciliation admits no cycle and therefore performs no restore. Every fresh C# candidate uses its declared project/lock hash, generation-specific SDK assets, and local-only package source; it reruns restore without network access because checked generations do not share mutable restore state.
84
+
85
+ ### Watch coordinator (Task 043 implemented)
72
86
 
73
87
  One lifecycle-aware class owns filesystem subscriptions, content snapshots, cycle state, the active checker child, reporting, and shutdown. Its state machine is:
74
88
 
@@ -85,11 +99,13 @@ any live state -- SIGINT/SIGTERM --> stopping --> stopped
85
99
 
86
100
  `failed` means the last candidate failed; it does not discard the last successful output or terminate watch mode. A watcher event during `building`/`rebuilding` sets one dirty generation marker. The coordinator starts exactly one follow-up after the owned child closes. It never starts a retry while prior compiler work is still live.
87
101
 
88
- Native filesystem events require a bounded reconciliation strategy because Node and TypeScript both document platform-dependent watcher behavior. Version 1 watches the explicit manifest/source files and relevant parent directories, re-scans the declared graph after each hint, supports a documented polling fallback, and suppresses no-op cycles by content hash. The publication root and every generated/build projection are rejected as source roots and are never watched.
102
+ Native filesystem events require a bounded reconciliation strategy because Node and TypeScript both document platform-dependent watcher behavior. Version 1 watches the explicit manifest/source files and their distinct parent directories without recursive watching, filters publisher-owned parent events, re-scans the complete graph after each coalesced hint, supplements native events with a bounded reconciliation interval, switches wholly to polling when native subscription creation or a live watcher fails, and suppresses no-op cycles by content hash. Polling metadata is only a reconciliation hint, and unchanged invalid graphs do not emit repeated failed cycles. The publication root and every generated/build projection are rejected as sources and are never direct subscriptions, preventing publication feedback cycles.
103
+
104
+ The implemented pre-pointer currentness guard runs only after every target validator/checker has closed. It re-loads and hashes the complete graph; changed content rejects and cleans the stale staged candidate, while one dirty marker admits a single immediate latest-state follow-up. A later event in the narrow guard-to-pointer window cancels publication without cancelling a healthy checker earlier in the cycle.
89
105
 
90
106
  ### Reporting contract
91
107
 
92
- Human output is concise and stable. A machine-readable mode emits one JSON record per state transition with at least project identity, monotonically increasing cycle number, source snapshot hash, target ID/role, state, timing, changed paths, tool identity, exit status, and a structured diagnostic when present.
108
+ Task 039 human output is concise and stable. Its machine-readable mode emits deterministic state records with project identity, cycle `1`, source snapshot hash, ordered target ID/role/results, exit status, and a structured diagnostic when present. Generation-only records deliberately report state rather than nondeterministic elapsed time. Task 040 checked-stage records add exact tool/process identity and lifecycle timing. Task 043 watch records add stable changed paths, cycle duration, succeeded/failed/recovered/superseded/cancelled classification, one terminal record per admitted cycle, and one separate watcher terminal. Task 044 adds the nonterminal `cycle-dirty` acknowledgement used to synchronize a controlled active-check burst with the coordinator's admitted follow-up ownership.
93
109
 
94
110
  Exactly one terminal cycle record is emitted per cycle. Process exit is non-zero for failed one-shot builds, but ordinary watch-cycle failures keep the watcher process alive. Startup/configuration failure exits. Signal-driven shutdown forwards cancellation to an active owned child, waits for `close`, removes subscriptions and staging state, and exits once.
95
111
 
@@ -115,7 +131,7 @@ Exactly one terminal cycle record is emitted per cycle. Process exit is non-zero
115
131
  - the same watcher/materializer/runner code handles every source/target pairing;
116
132
  - acceptance uses a bounded matrix: all frontends and all text targets are covered, with the JavaScript/JSDoc-to-Java path plus representative cross-family paths, not a quadratic promise that every semantic feature works for every pair.
117
133
 
118
- Binary and application targets use the same generation watcher only after explicit target policy is defined. Browser Wasm can validate/instantiate in its own lane. Android and Flutter checks are heavier platform builds and must be opt-in rather than an automatic keystroke default. iOS remains generation-only until the separately deferred Apple/Xcode acceptance work is authorized; this roadmap does not reopen Tasks 026 or 027.
134
+ Binary and application targets use the same generation watcher only after explicit target policy is defined. Browser Wasm can validate/instantiate in its own lane. Android and Flutter checks are heavier platform builds and must be opt-in rather than an automatic keystroke default. Direct public iOS generation remains available with explicit configuration, but Task 039 manifest version 1 cannot express that configuration and rejects iOS targets; Apple/Xcode acceptance remains separately deferred. This roadmap does not reopen Tasks 026 or 027.
119
135
 
120
136
  ## Test strategy
121
137
 
@@ -147,7 +163,7 @@ Binary and application targets use the same generation watcher only after explic
147
163
  046 later binary/application policies
148
164
  ```
149
165
 
150
- Tasks 038–045 are the selected text-language delivery chain. Task 045 is the single terminal acceptance task for that chain. Task 046 is a non-blocking later extension.
166
+ Tasks 038–041 and 043–044 are the implemented publication, one-shot project-build, Java plus interpreted/managed checks, watch-orchestration foundation, and first packed checked slice. Tasks 042 and 045 remain the selected text-language check/watch delivery chain, with Task 045 as its single terminal acceptance task. Task 046 is a non-blocking later extension.
151
167
 
152
168
  ## Non-goals
153
169
 
package/docs/zig.md CHANGED
@@ -26,6 +26,8 @@ Strings are immutable `[]const u8`. Literals borrow static storage; concatenatio
26
26
 
27
27
  `build.zig` exposes only Zig's standard optimization option and the host target. Acceptance copies validated artifacts to a fresh temporary project, uses distinct empty local/global caches per mode, blocks proxy/package-fetch variables, runs `zig fmt --check src/main.zig build.zig`, `zig build test`, `zig build`, and the installed executable in Debug, ReleaseSafe, and ReleaseFast, and verifies that input artifact hashes never change. Cross-compilation and package dependencies are outside this profile.
28
28
 
29
+ The registered Task 042 developer plan accepts only that exact standard-library-only `build.zig` and generated Zig sources. It runs the Debug project build with generation-owned local/global caches and `--prefix`, then `zig fmt --check` over the complete staged set. HOME, TMPDIR, both caches, and the absolute-root-bearing Debug output prefix are removed after close, so no executable leaks or is published. `zig build test` plus build/run in Debug, ReleaseSafe, and ReleaseFast remain explicit acceptance/TensorBuzz profiles rather than automatic watcher branches.
30
+
29
31
  ## Provenance and diagnostics
30
32
 
31
33
  Function, parameter, local, type, assignment, operator/helper, callee, argument, literal, return, condition, output, and entry-statement occurrences retain exact or anchored semantic provenance in `src/main.zig`. The runtime, arena, output helpers, punctuation, ordered-region markers and signatures, typed ordering temporaries, conditional-right-hand plumbing, necessary unused/unmutated binding scaffolds, and entry shell are synthetic with related semantic origins. `build.zig` has artifact-level synthetic configuration provenance. The embedded Source Map v3 names `src/main.zig`; Zig source-map directives and alternate filenames are rejected.
@@ -0,0 +1,3 @@
1
+ task-044
2
+ 5
3
+ enabled
@@ -0,0 +1,23 @@
1
+ {
2
+ "schema": "SemantifoldProject",
3
+ "version": 1,
4
+ "id": "jsdoc-java-watch",
5
+ "publicationRoot": ".semantifold",
6
+ "sources": [
7
+ {
8
+ "id": "main",
9
+ "path": "src/main.js",
10
+ "language": "javascript",
11
+ "entry": true
12
+ }
13
+ ],
14
+ "targets": [
15
+ {
16
+ "id": "java-main",
17
+ "language": "java",
18
+ "role": "text",
19
+ "sourceProjection": "targets/java/source",
20
+ "buildProjection": "targets/java/classes"
21
+ }
22
+ ]
23
+ }
@@ -0,0 +1,21 @@
1
+ /**
2
+ * @param {number} left
3
+ * @param {number} right
4
+ * @returns {number}
5
+ */
6
+ function add(left, right) {
7
+ return left + right
8
+ }
9
+
10
+ /**
11
+ * @param {boolean} enabled
12
+ * @returns {string}
13
+ */
14
+ function label(enabled) {
15
+ if (enabled) return "enabled"
16
+ else return "disabled"
17
+ }
18
+
19
+ console.log("task-044")
20
+ console.log(add(2, 3))
21
+ console.log(label(true))