Build the initial PatchSlim CLI

[Apex-Studio-He]

Why

Large refactors and experimental changes often contain files or hunks that are
not required for the behavior a pull request is meant to deliver. Reviewing
that noise by hand is slow, while line-count heuristics cannot determine whether
a change is behaviorally necessary.

PatchSlim treats a focused test command as an oracle and searches for a smaller
committed Git diff that still passes it.

What this adds

• A TypeScript CLI with doctor, init, inspect, minimize, and report
  commands.
• Stable JSON output for scripts and integrations.
• Merge-base discovery and candidate evaluation in an isolated temporary
  worktree.
• File-level followed by hunk-level delta debugging with candidate caching and
  a configurable time budget.
• Conservative protection for tests, fixtures, snapshots, migrations,
  documentation, CI, manifests, lockfiles, PatchSlim configuration, and Git
  control files.
• Quick gates for candidate filtering and repeated full validation before any
  result is accepted.
• JSON and Markdown reports plus two patch artifacts:
  • apply.patch transforms the original head into the minimized result.
  • candidate.patch recreates the minimized result from the merge base.
• Release documentation, a workflow diagram, a changelog, reproducible package
  checks, and a Node 20/22/24 CI matrix.

Release-audit fixes

The release pass found and locked down several edge cases:

• Protected-base oracle checks now repeat, so an intermittently passing weak
  oracle fails closed as BASE_ORACLE_UNSTABLE.
• Renames remain protected when either the old or new path matches a protection
  rule.
• Configuration files reject unsupported schema versions and unknown fields
  instead of silently ignoring misspelled safety settings.
• A CLI --timeout now becomes the default for setup commands as well as the
  oracle and gates.
• Report loading validates the required runtime shape before rendering.
• npm pack builds through the local toolchain and no longer depends on a
  globally resolved pnpm version.

Safety model

PatchSlim fails closed when:

• the oracle does not pass consistently on the original head;
• the oracle passes, or changes result, after all reducible production changes
  are removed;
• a configured gate is already failing on the original head;
• setup modifies tracked state or creates unignored files;
• a command times out or the run is interrupted.

Every candidate and command stage is reconstructed from the merge base. Ignored
test output is cleared between stages, while ignored dependency directories
created by setup are preserved. The current checkout is never reset or cleaned,
and a candidate is never applied automatically.

Validation

• pnpm release:check
• 8 test files and 38 tests passing
• full suite passing on Node.js 20.20.2, 22.23.1, and 24.18.0
• JavaScript and Python end-to-end fixtures
• text hunks, added files, binary diffs, renames, mode changes, spaces, and
  Unicode paths
• weak oracle, unstable head, unstable protected base, failing gate, timeout,
  setup pollution, cache pollution, and interruption coverage
• installed release tarball invoked under Node 20 and Node 24
• installed CLI used for a complete minimize run
• apply.patch applied to the original head and verified by the protected test
• deterministic fixture reduction from 4 files +8/-3 to 2 files +6/-2
• clean production dependency audit
• Publint, Markdownlint, SVG XML validation, and package-content inspection

Current limits

• Only committed changes are minimized.
• Results are evidence relative to the configured oracle, not proof of complete
  behavioral equivalence.
• Renames, binary files, mode changes, and protected paths are handled
  atomically.
• The reducer seeks a locally minimal passing result; it does not guarantee a
  globally smallest patch.
• Repositories are trusted input because configured commands run with the
  current user's host permissions.
• A sandboxed or container executor is not included in v0.1.0.

Review focus

• Whether the repeated head-pass/protected-base-fail preflight is conservative
  enough for the first release.
• Whether the default protection rules are safe without making the reducer
  ineffective.
• Whether the two-patch artifact model is clear for both manual and scripted
  workflows.