Status · Scope, evidence and remaining risk

Is Nift production-ready?

Yes—for its documented website-generation contract and the environments directly exercised by the current evidence. That is a scoped engineering judgement, not a claim that every platform, hosting workflow or possible template is automatically certified.

What “production-ready” means here

Nift is ready to be a dependable generation layer when a project's needs fit its stated model: tracked text outputs, reusable templates/partials, checked project-local paths, JSON-backed data and control flow, dependency-aware incremental builds and optional conservative final-artifact minification.

It does not mean Nift has become a browser framework, package manager, TypeScript compiler, bundler, image pipeline, backend runtime or universal CMS. Those boundaries are part of the readiness argument: specialist work remains with specialist tools rather than being reimplemented incompletely inside Nift.

The evidence behind the verdict

The source tree currently exposes 24 focused targets. The most recent project-contract checkpoint also established all 16 modern standalone black-box modules in that validation group, then rebuilt the real Nift documentation site with the candidate. Longer historical and sanitizer gates are kept separately contextualized on Battle tested; a timeout or historical pass is not silently promoted into fresh evidence.

Contracts that are ready to rely on

• tracked content and templates compose predictably through @content and nested @input;
• resolved local paths are project-contained and relative output paths are generated correctly;
• dependencies and existence-only requirements drive explainable incremental decisions;
• modified, hash and hybrid modes implement distinct documented change-detection policies;
• failed rendering/minification does not overwrite the last successful output and page metadata;
• JSON data, the supported JSON Schema subset, project contracts and bounded control flow fail explicitly outside their contract;
• tracked entries can intentionally omit a template and are regression-protected as first-class text-output builds;
• concurrent builds preserve page-level state and avoid duplicate writes to one tracked output;
• supported final HTML/CSS/JS/JSX/JSON/XML/SVG artifacts can be conservatively minified.

Operational limits still matter

Production use should pin or deliberately select the Nift binary used by CI and deployment, preserve canonical source separately from generated output, and treat .nift metadata/hash state as build state when relying on incremental behavior across machines. A clean build-all remains the authoritative fallback when restoring an incomplete cache or validating a release candidate.

Checkpoint 10 now provides scoped behavioral evidence across GitHub's Linux, macOS and Windows runners: the same 18-case portable corpus produced equivalent normalized semantics with zero mismatches, while two genuinely platform-specific cases were classified separately. That is stronger than source portability alone, but it is still distinct from proving every package manager, OS release, filesystem or deployment environment. Distribution channels should therefore be tested from the public packages users actually install.

Security and failure boundaries

Nift processes project-controlled templates, content, JSON and paths; it is not a sandbox for hostile template authors. Its safety contract focuses on project-root containment, controlled parsing/configuration failures, collision refusal, non-destructive failed builds and defensive filesystem behavior. Applications still own the security of generated client/server code and any external build commands they choose to run.

Performance readiness

Native startup, parallel page work and dependency-aware incremental checks make Nift comfortably fast on the exercised fixtures, including the documented 10,000-page comparison. Those numbers are checkpoint evidence on a particular machine, not a universal guarantee. Production readiness depends more on stable behavior and proportional rebuild work than on winning every benchmark.

The website is part of the release gate

A candidate should compile Nift cleanly, pass the appropriate focused and independent suites, build this complete site with the exact candidate binary, resolve important links/assets, preserve system/light/dark and responsive behavior, and keep downloads, examples and version-sensitive claims current. A successful unit test run does not excuse stale public documentation.

What would lower this assessment?

Uncontrolled data loss, project-root escape, silent ignored configuration, corrupted incremental state, non-deterministic concurrent writes, semantic minifier regressions, an inability to rebuild the official sites or a widening gap between docs and implementation would all be production blockers. The readiness judgement is maintained by retaining those families as contracts—not granted permanently by reaching one checkpoint.

What comes after readiness?

Production-ready is not “finished”, but the next step is no longer another arbitrary hardening checkpoint. Nift has reached the planned hardening plateau. The highest-value evidence now comes from distributing the latest code through real installation channels, testing those public packages in clean environments, continuing dogfooding, and responding to findings from unfamiliar projects and users. New features still need to justify their place in the small core, and real defects should become permanent regressions where practical.