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 bounded control flow, multi-output pagination, dependency-aware incremental builds and optional conservative final-artifact minification.

Dependable is used deliberately. It does not claim Nift can never fail; it claims the behaviour this page's evidence covers is explicit, checked, bounded, and backed by retained regression evidence, with the remaining boundaries recorded rather than hidden. Each section below states both what is established and where the guarantee stops.

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 maintained source-tree and independent layers cover the current CLI grammar, template language, structured data, pagination, project contracts, initializer targets, failure recovery and filesystem behavior. The v4.0.7 release candidate passed the complete 22-module external contract plus its historical/ruthless extension, native four-platform archive rehearsal and documentation-site build. Longer historical and sanitizer campaigns remain separately contextualized on Battle tested; a timeout or an old pass is never silently promoted into fresh evidence.

Contracts that are ready to rely on

• templated tracked items execute exactly one @content across the rendered template/input graph, while template-less entries use their content as the top-level source;
• resolved local paths are project-contained and relative output paths are generated correctly;
• dependencies and checked requirements drive explainable incremental decisions, with tracked producers owning their own build state;
• 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;
• paginated tracked items rebuild their complete owned page set, render pagination pages concurrently and preserve the previous successful set on failed replacement;
• 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 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. The initializer/target matrix is also green on native Linux, macOS and Windows, and the v4.0.7 release rehearsal extracted and exercised its Linux x86-64, macOS arm64, macOS x86-64 and Windows x86-64 archives on native runners. This is stronger than source portability alone, but it is still distinct from proving every package manager, OS release, filesystem or deployment environment. Distribution channels must therefore be tested from the public packages users actually install; end-to-end provider deployments remain useful dogfooding rather than a prerequisite for documenting a target preset.

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 with a small measured memory footprint on the exercised fixtures. In the reproducible 10,000-page comparison, Nift's clean-build median was 0.165 s with 10.0 MiB median peak aggregate RSS; the same run measured one-page incremental builds at 0.119 s / 9.7 MiB. A dogfooding pass caught a later O(n²) full-build regression in transactional stale-temp cleanup; that path is now repaired and protected by a dedicated 1,000→4,000-page full-build scaling guard alongside the existing tracked-project scaling guard. Recovery is additionally epoch-scoped so a long-running build --auto process can clean a dead-owner temp on the next relevant pass without returning to per-file directory scans; a direct scan-count guard and independent black-box contract protect that boundary. Absolute benchmark numbers remain machine-specific; the maintained guarantee is proportional scaling rather than a universal wall-clock time.

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.