human-to-code 0.1.16 → 0.1.18

package/docs/MODULES.md

@@ -71,6 +71,7 @@ accept typed, already-reviewed data and perform no I/O or mutation.
 | Module | Purpose |
 | --- | --- |
 | `direct-conversion.ts` | System and user messages for whole-file and inline direct conversion, including FileMemory rules and examples. |
+| `direct-repair.ts` | Bounded cross-file repair messages for one generated JS/TS unit: original instruction, current candidate, normalized compiler diagnostics, and related generated files, all framed as untrusted data. |
 | `guided-patch.ts` | Structured patch-generation messages: reviewed contract, target profile, immutable snapshot hash, compiler skills, and wrapped untrusted evidence. |
 | `guided-repair.ts` | Bounded repair messages that freeze contract, snapshot, validation plan, paths, operations, and scope. |
 | `provider-output.ts` | Host-enforced JSON output-contract message used only when a provider lacks native JSON Schema support. |
@@ -88,9 +89,13 @@ accept typed, already-reviewed data and perform no I/O or mutation.
 | `discovery.ts` | Bounded file walking and conversion-unit creation, including existing-target and unsupported-marker notices. |
 | `declarations.ts` | Language-aware declared-identifier extraction, including type-led C, C++, C#, and Java declarations. |
 | `replacement.ts` | Exact inline-marker byte verification plus newline-preserving indentation formatting shared by memory and application. |
-| `candidate-validation.ts` | Pre-write syntax gate: TypeScript parser diagnostics for JS/TS and deterministic structure checks for other direct languages. It does not claim semantic or sandbox verification. |
+| `candidate-validation.ts` | Baseline-aware pre-write syntax gate: TypeScript parser diagnostics for JS/TS and deterministic structure checks for other direct languages. Inline units are rejected only for newly introduced diagnostics. It does not claim semantic or sandbox verification. |
+| `candidate-overlay.ts` | In-memory candidate overlay combining whole-file outputs and inline replacements for staged validation; the working tree stays unchanged and stale or conflicting units are excluded fail-closed. |
+| `program-diagnostics.ts` | Combined TypeScript Compiler API validation over the candidate overlay: permissive fixed compiler options, an overlay-aware compiler host, bundled `node:` builtin typings, and multiplicity/location-aware baseline-vs-candidate diagnostic comparison. Static compilation only — it never imports or executes project code. |
+| `dependency-graph.ts` | Resolved-import dependency grouping of candidate files and bounded diagnostic-to-unit attribution; diagnostics that cannot be safely attributed fail the whole staged batch. |
+| `staged-validation.ts` | Orchestrates overlay build, combined program validation, group rejection, and the bounded per-unit repair budget (secret-scanned repair context, injected repair callback). Produces per-unit accept/reject results for the CLI. |
 | `file-memory.ts` | Ephemeral declaration memory, replacement normalization, candidate-validation retry isolation, and sequential per-file generation. |
-| `generation-client.ts` | One direct provider request through OpenAI-compatible chat or Ollama, using the central direct prompt builder. |
+| `generation-client.ts` | Direct provider requests through OpenAI-compatible chat or Ollama: one conversion request per unit plus bounded cross-file repair requests, always using the central prompt builders. |
 | `presentation.ts` | Stable conversion receipt and unambiguous single-code-block extraction; rejects multiple or unterminated fences. |
 | `application.ts` | Stale-safe inline replacement and exclusive whole-file creation that never overwrites a sibling. |
 | `index.ts` | Direct-agent export surface used by the CLI and package entry point. |
@@ -133,5 +138,6 @@ accept typed, already-reviewed data and perform no I/O or mutation.
 | `test/planner.test.ts`, `test/patch.test.ts`, `test/snapshot.test.ts`, `test/run-store.test.ts`, `test/validation.test.ts`, `test/guided-agent.test.ts` | Guided mechanics and lifecycle stage by stage, including apply/rollback and repair limits. |
 | `test/direct-agent.test.ts` | Lexical marker discovery, FileMemory indexing/normalization, provider prompts, retry isolation, and application. |
 | `test/direct-reliability.test.ts` | Regression coverage for direct issues 02 and 04–11: JSDoc, output cleanup, validation, overwrite/staleness/indent guards, regex memory, C-family declarations, and discovery notices. |
+| `test/staged-validation.test.ts` | Issue 12 coverage: calculator-style cross-file rejection, consistent-candidate acceptance, bounded repair success and exhaustion, named-import/member/union/arity detection, baseline tolerance and multiplicity comparison, dependency-group isolation, and overlay write guards. |
 | `test/cli.test.ts` | Command surface and exit codes. |
 | `test/package-smoke.mjs` | Packed-tarball install, public import, installed-CLI invocation (`npm run package:check`). |

package/docs/SCALABILITY.md

@@ -88,9 +88,15 @@ between releases:
   validate at the boundary and let types flow.
 - **Minimal production dependencies.** HTTP, hashing, JSON, process handling,
   provider access, and orchestration use Node built-ins. TypeScript is the one
-  deliberate runtime parser dependency for direct JS/TS candidate validation.
-  Adding another runtime dependency changes the supply-chain posture and needs
-  a design discussion first.
+  deliberate runtime compiler dependency for direct JS/TS candidate validation,
+  both per-file syntax checks and the combined candidate-project type check;
+  `@types/node` ships with it so `node:` builtin imports resolve in target
+  projects without their own type dependencies. Combined validation builds a
+  TypeScript program over the project's JS/TS files per staged pass, so its
+  cost grows with project size — the walk is bounded and `skipLibCheck` is
+  forced, but very large repositories pay a real compile cost per conversion
+  run. Adding another runtime dependency changes the supply-chain posture and
+  needs a design discussion first.
 - **Errors are typed and named.** Each layer exports its own error classes
   (`ArtifactValidationError`, `ProviderError`, `PatchSafetyError`, …) so the
   CLI can map failures to exit codes without string matching. Error messages

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "human-to-code",
-  "version": "0.1.16",
+  "version": "0.1.18",
   "description": "Safely turn reviewed natural-language change contracts into validated code patches.",
   "type": "module",
   "main": "./dist/index.js",
@@ -29,6 +29,7 @@
     "node": ">=24.0.0"
   },
   "dependencies": {
+    "@types/node": "24.13.3",
     "typescript": "5.9.3"
   },
   "scripts": {
@@ -52,7 +53,5 @@
   "publishConfig": {
     "access": "public"
   },
-  "devDependencies": {
-    "@types/node": "24.13.3"
-  }
+  "devDependencies": {}
 }