How AI contributes to Minify++ without becoming the correctness oracle.

Minification is unusually hostile to plausible-looking changes: one removed byte can alter parsing or runtime meaning. AI is useful here because it can explore ambiguity families quickly—but only inside an evidence-driven process where compilers, parsers, runtimes, sanitizers and retained regressions decide what is safe.

Living handovers are the starting context

Each repository carries a concise root HANDOVER.md and deeper living documents for architecture, development, testing, decisions, roadmap and project history where the project needs them. They preserve the knowledge that is expensive to reconstruct: scanner boundaries, token hazards, API/CLI contracts, production evidence, known limitations and the reasons earlier approaches were accepted or rejected.

These documents are maintained with the code. They are not frozen transcripts or a substitute for reading implementation and tests. Source remains authoritative; handovers explain how to orient yourself, where the risk lives and which evidence must move with a change.

The development loop

define the exact format/semantic boundary
        ↓
ask a real parser or runtime where possible
        ↓
add the smallest focused regression
        ↓
implement the family-level rule
        ↓
run direct + cross-format + CLI/API tests
        ↓
fuzz, sanitize and benchmark in proportion to risk
        ↓
reconcile docs, handovers and production claims

Tests are layered because “valid output” is not enough

A finding should become more than a one-off fixture. Development asks which general rule failed—such as whitespace removal manufacturing a CSS comment opener, JSX delimiter or HTML/XML marker—and protects the whole family without making unrelated formats more aggressive.

Independent evidence reduces confirmation bias

The standalone Minify++ implementation and Nift's embedded copy are reconciled rather than assumed identical. The independent regression suite owns compiler-agnostic expectations. Nift integration tests separately prove that build-time minification selects formats correctly, fails non-destructively and refreshes incremental metadata when minification policy changes.

Contract-based testing: protect meaning, not implementation shape

A contract test starts with a public promise and deliberately avoids depending on the scanner helper, state enum or internal function currently used to keep it. That makes the test useful through refactors and across the standalone implementation, Nift's embedded copy and any future compatible implementation.

public contract
  given valid input + selected format/options
  when Minify++ succeeds
  then output is valid, meaning is preserved,
       the promised comments/whitespace rules hold,
       and a second minification remains stable

failure contract
  given malformed or unsupported input
  when Minify++ rejects it
  then status is non-zero, diagnostics are controlled,
       and the previous destination is not damaged

Contracts are format-specific

One contract, several evidence levels

A focused regression may pin the smallest counterexample, a differential or parser test may establish semantic equivalence, a CLI/API case may protect the user boundary, and fuzz/idempotence/sanitizer gates may attack the same promise at scale. These are not competing tests: they triangulate one contract from different failure surfaces.

Contracts prevent test laundering

It is easy to write a test that merely confirms the output produced by the current implementation. Contract-based development instead asks what users are entitled to rely on. Expected output bytes are asserted only where byte shape is genuinely contractual; otherwise validity, runtime results, preserved tokens, error status and non-destructive behavior are stronger oracles.

Changing a contract is a product decision

If a proposed optimization conflicts with an existing contract, the test is not automatically “outdated”. First decide whether the implementation is wrong, the public promise was too broad, or a versioned behavior change is justified. Then update implementation, independent evidence, documentation, handovers and format-version policy together.

Checkpoints, not endless speculative edits

Work proceeds through bounded checkpoints with a stated question and exit evidence. A checkpoint may focus on one ambiguity, a format audit, API behavior, native safety, fuzzing or performance. It is complete when the relevant gates pass and the public contract has been reconciled—not merely when code compiles.

Commits should describe the protected behavior. Generated website output is committed separately from canonical Nift source, and pushes/releases remain deliberate publication actions.

What AI is especially good at here

• Generating neighboring counterexamples around a discovered token boundary.
• Comparing standalone, embedded and regression-suite behavior.
• Tracing a failure from public API through scanner state to emitted bytes.
• Auditing documentation claims against executable evidence.
• Maintaining test, handover, roadmap and website context together.

What remains a human/product decision

How conservative a format should be, which compatibility boundary is worth supporting, when platform evidence is sufficient and when a release deserves a production claim are product judgements. AI can make the trade-offs explicit and gather evidence; it should not quietly expand the contract.