v1.2.0

Developer-workflow release. No breaking changes; all existing commands and
.klr semantics are unchanged.

Added

• killer graph [--json] — a structural project-graph engine. Parses
  per-file imports (Rust, JavaScript/TypeScript, Python, Go, Java, Ruby) and
  declared dependencies from manifests (Cargo.toml, package.json,
  requirements.txt, go.mod), then reports the most-imported modules, import
  hotspots, and possibly-unused declared dependencies — a supply-chain
  signal. Dependency usage is matched best-effort (hyphen/underscore
  normalization, plus an inline crate::path scan for Rust). --json emits the
  full node/edge graph.
• killer benchmark [--runs N] — times repeated scans and reports min/avg
  latency and files-per-second / lines-per-second throughput.
• killer fuzz — surfaces the .klr mutate/fuzz generators as a
  first-class command. Without --url it previews the adversarial inputs it
  would send; with --url it fires each one at a target (using the same
  zero-dependency HTTP client and request encoding as .klr mutate) and
  flags any input that triggers a 5xx server fault or an unreachable target.
  --list prints the generator catalog; --generators selects a subset;
  --field sets the mutated key; --fail-on-issues gates CI.
• killer watch — re-runs a scan whenever a source file changes, using a
  dependency-free polling watcher (periodic mtime snapshots, diffed between
  ticks) that honors the same ignore rules as killer scan. --interval
  tunes the poll period.
• killer init --scaffold — in addition to writing .killer.toml, creates
  a security-tests/ directory with a runnable starter .klr file so a new
  project can run its first test immediately.

Changed

• The fuzz-generator table now lives in a single fuzz module and is shared by
  both the .klr runner and killer fuzz, so the two can never drift.

Notes on scope

killer fuzz is a CLI surface over the existing input generators — not a
coverage-guided fuzzing engine — and killer watch polls rather than
subscribing to OS file events. killer graph is a structural graph
(imports + declared dependencies with heuristic usage matching), not a semantic
or data-flow graph. A standalone fuzzing/chaos subsystem, a true multi-language
IR / data-flow engine, a ratatui TUI, and a plugin marketplace remain on the
roadmap, not shipped.