wizz-method 1.14.0 → 1.16.0

package/src/bmm-skills/4-implementation/wizz-retrospective/customize.toml

@@ -30,12 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+persistent_facts = []
 
-# Scalar: executed when the workflow reaches Step 13 (Final Summary and Handoff),
-# after the retrospective document is saved and sprint-status is updated. Override wins.
+# Scalar: executed at the end of Phase 5 (Close), after the retrospective
+# document is saved and sprint-status is updated. Override wins.
 # Leave empty for no custom post-completion behavior.
 
 on_complete = ""

package/src/bmm-skills/4-implementation/wizz-retrospective/references/acceptance-verdict.md

@@ -0,0 +1,55 @@
+# Decide: Routing and the Acceptance Verdict
+
+Phase 4. Turn the consolidated findings into two outputs: routed action items the human can act on, and an honest verdict on whether the epic met its acceptance criteria. This skill proposes; it does not auto-apply fixes or edit the project spec. The human decides what executes.
+
+## Route each finding
+
+Give every finding two independent dispositions:
+
+- **What to do about this instance** — *fix now*, *defer*, or *accept as-is*. Fix-now findings become action items. Deferred findings carry enough context to be acted on later without re-investigation. Accepted deviations are recorded so later retros stop re-flagging them.
+- **What would prevent the next one** — the upstream lesson: spec wording, story sizing, a missing convention or gate, or nothing. This is where a recurring finding becomes a process change rather than a one-off fix.
+
+Findings from sub-agents or the team discussion are unverified reports, not established facts. Before an action item relies on one, re-check it against the primary source — reopen the file, the commit, the spec. A finding whose source does not hold up is dropped, not routed.
+
+## Action items
+
+Compile fix-now findings and process lessons into specific, owned action items. Each names what to change and who owns it. Two kinds are *proposed, not applied* in this version:
+
+- **Remediation** — code fixes are written up as action items (or story-shaped work) for the normal dev loop to execute later. The retrospective does not run the dev loop itself.
+- **Spec reconciliation** — where the as-built diverges from the spec, propose the reconciliation as an action item with the evidence attached. The human applies it to the project contract; an uncertain interpretation is never written into the spec automatically.
+
+## Previous-retro follow-through
+
+When a prior retro exists, check whether the action items it committed to were completed. Read `action_items` in `{implementation_artifacts}/sprint-status.yaml` and, for every entry belonging to an earlier epic that is not already `done`, record one line in the retrospective document's Previous-retro follow-through section:
+
+- **How to address the item** — its `id`, exactly as the file spells it. Legacy entries written before ids existed have none; for those, record the item's `epic` (the integer in the file) plus its exact `action` text, character for character. One or the other is what Phase 5 needs to name the item at all.
+- **Whether it landed** — with the source that shows it: the commit, the file and line, the test. An item you cannot point at is "no evidence found", not "not done" — the reader must be able to tell a checked item from an unchecked one.
+- **The status it argues for** — `done` for a landed item, `in-progress` for one demonstrably underway, or nothing. A proposal, never a write.
+
+That record is exactly what Phase 5's `--set-action-status` offer reads: the selector becomes the JSON, the evidence is what the user is asked to confirm, and the proposed status is written only if they confirm it. A run with no prior retro, or one whose `sprint-status.yaml` is unreadable or carries no `action_items`, records that there was nothing to follow through on — and which of those it was, so a missing file is never mistaken for "no outstanding items."
+
+## The verdict
+
+Judge the final state against the epic's declared acceptance criteria. If the epic declared none, profile the criteria from the diff and stories and mark the verdict as **profiled** rather than declared. Weigh verification results (the Phase 2 behavior check) and unresolved findings. Render one of:
+
+- **Accepted** — criteria demonstrably met in the evidence, no blocking findings open, and **no unfinished stories** for this epic.
+- **Accepted-with-open-items** — criteria met, but named findings remain deferred and tracked — still only when every story of this epic is `done`.
+- **Rejected** — criteria not met, a blocking finding stands unresolved, **or any of this epic's stories is still not `done`**.
+
+### Unfinished stories
+
+`pending_stories` is authoritative for this epic's incomplete work, whichever mode produced it: sprint-status story keys in file order from `detect-epic`, or `stories.yaml` ids in list order whose artifact status is not `done`. When that list is non-empty:
+
+- The **machine** verdict is **rejected**. Name every unfinished story key in the Acceptance verdict section as the evidence. Do not soften this to accepted-with-open-items: unfinished delivery is not an open finding about a finished epic — the epic itself is incomplete.
+- Record the unfinished keys in Epic summary (interactive) or Assumptions (headless) as the Inputs section already requires.
+- Headless runs have no human at the console: the document's verdict is **rejected** when `pending_stories` was non-empty. Interactive runs may still let a human override (rule 1 below) after seeing the list.
+
+If the completeness check did not run (no readable `sprint-status.yaml`), do **not** render a rejected or accepted verdict from the absence of data — say the check was unavailable and weigh only the criteria and findings you have.
+
+Three hard rules:
+
+1. A human decision always overrides the machine verdict.
+2. An epic that fails its criteria with **no** human decision is recorded as **not accepted** — never as silently accepted.
+3. A non-empty `pending_stories` list makes the machine verdict **rejected**, including in headless mode.
+
+The verdict and its evidence carry into the Phase 5 document.

package/src/bmm-skills/4-implementation/wizz-retrospective/references/aggregate-views.md

@@ -0,0 +1,17 @@
+# Aggregate Views
+
+Phase 2. An epic is many coding sessions, each validated in isolation; the defects that matter are the ones no single session — and no single diff hunk — could see. Nine sessions each added three hundred lines and none ever saw the 3,000-line class they collectively built. These views are properties of the *whole* change, derived across the full diff range from Phase 1.
+
+Prefer deterministic derivation: a script that measures the codebase is evidence; a model's impression is not. Where you compute a view inline instead of by script, record the narrowed scope. Every observation that becomes a finding carries a source reference — the file, the symbol, the commits. `references/evidence-gathering.md` is authoritative for what every `git_evidence.py` key means, including the commit-level `is_merge` and `stories` (every story id a subject names, so a commit spanning two counts for both) — read it there before deriving anything from the numbers.
+
+## The catalog
+
+- **Architecture delta** — how the dependency structure changed across the epic. Where a language-native dependency tool exists (dependency-cruiser, madge, pydeps, and the like), run it before and after the range and diff the graphs; otherwise derive the module/import graph from the changed files. Look for new cross-cutting dependencies, layering violations, and cycles introduced — structure the code's own conventions would forbid but no single story tripped.
+- **Duplication map** — the same problem solved more than one way across stories. Two sessions independently writing near-identical logic, or a helper reimplemented because the second session did not know the first existed.
+- **God-class / size growth** — files that grew past a healthy size *over the epic*, invisible per-commit because each session added only a little. The `git_evidence.py` pre-pass (Phase 1) reports `added` / `deleted` / `net` per path in `files` — *change volume*, not a file's absolute size or a per-commit growth rate. Those sums cover the range's **non-merge** commits only, and they are always integers: an unmeasurable revision is left out of them rather than nulling them. Rank on `files`, then open the top of the ranking and read each file's real current size and structure before calling anything a god-class — high net churn makes a file a candidate to inspect, not a verdict on its own. Three qualifiers say how far the ranking can be trusted: `binary_revisions` counts that path's revisions whose churn could not be measured, so its true volume is *at least* what the sums report; `merges_measured` short of `merge_count` means some merges were never measured at all, which caps how complete the ranking can be; and `merge_files` mostly restates churn `files` already counted, so summing the two double counts — but it is not redundant, because a merge's first-parent diff also carries whatever the conflict resolution itself added, code that lives in no non-merge commit and therefore appears in `files` nowhere. So read `merge_files` separately, for the paths whose churn shows up only there, rather than discarding it as double counting. Whether a flagged file is genuinely a god-class or legitimately large stays your judgment.
+- **Pattern divergence** — where the epic's code diverges from the conventions the surrounding codebase already established: naming, error handling, test structure, module boundaries. Agents learn conventions by pattern-matching the code, so divergence compounds.
+- **Spec-to-implementation reconciliation** — where the as-built diverges from what the epic spec and PRD/architecture described. Requirements silently dropped, added behavior nobody specified, intent reinterpreted between stories. Each divergence is either a defect (fix), an accepted deviation (record so later runs stop re-flagging it), or a spec that should be reconciled to reality (propose in Phase 4).
+
+## Delegation
+
+When sub-agents are available, delegate the derivation: each returns evidence with source refs and checked scope, never a verdict — the parent consolidates and decides. Give each a narrow view and an explicit return format. When sub-agents are unavailable, compute the highest-value views inline (architecture delta and spec reconciliation first) and record which views were narrowed or skipped.

package/src/bmm-skills/4-implementation/wizz-retrospective/references/evidence-gathering.md

@@ -0,0 +1,30 @@
+# Evidence Gathering
+
+Phase 1 of the retrospective. Enumerate what the completed epic produced, so every later analysis works from real artifacts instead of memory. Output is an inventory: what exists, what is missing, and the diff range the rest of the retro will read.
+
+## Inventory checklist
+
+Collect what the epic produced and note the source path or range of each:
+
+- **Epic spec** — the epic file under `{planning_artifacts}`, including any declared acceptance criteria. If the spec declares how the epic will be judged, that governs Phase 4; if not, note that the verdict will be profiled from the diff.
+- **Story files** — the story specs implemented under this epic (`{implementation_artifacts}`), each carrying its intent and context. These mark the boundaries between coding sessions.
+- **Diff range and commits** — the full set of changes the epic introduced. Establish the range from the first and last story commits (or ask the user for it). The range must *include* the first story commit: `A..B` excludes `A`, so use the parent of the first commit as the left endpoint — `<first-commit>^..<last-commit>` — or the whole first story disappears from the diff, the commit attribution, and the verdict evidence. Then run `python3 {skill-root}/scripts/git_evidence.py --repo {project-root} --range <range> --stories <story-ids>` to get, as JSON, the per-story commit attribution and the per-file change volume — added / deleted / net across the range — that Phase 2 reads. Record the range explicitly; Phase 2's aggregate views and the `wizz-code-review` pass both read it. When the range cannot be established, say so and narrow the scope rather than guessing. Read the output keys precisely: each commit carries `is_merge` and `stories` — *every* id its subject names, so a commit spanning two stories counts for both. `files` sums non-merge commits only. `merge_files` is each measured merge's diff against its first parent, so it *restates* the churn that merge brought in plus whatever the conflict resolution added — never add it into `files`, and never read it as merge-introduced work on its own. `merges_measured` counts the merges on the range head's first-parent spine; `merge_count` counts every merge in the range, so a gap between the two means merges went unmeasured. `binary_revisions` is unmeasured churn, not zero churn.
+- **Sprint status** — `{implementation_artifacts}/sprint-status.yaml`, for which stories are `done` and the current retro-key state.
+- **Previous retrospective** — the prior epic's retro doc, if one exists, so Phase 4 can check whether last epic's action items landed.
+- **Session logs** — conversation or session records for the epic's stories, when available. They are the only record of *why* a session took an unexpected turn — what was tried and abandoned. They are also the evidence most likely to be deleted or expire, so capture references now.
+
+## Stories mode
+
+A stories-mode epic is a spec folder. Map it onto the checklist above: `SPEC.md` is the epic spec; `stories.yaml` in list order is the story list, each entry's artifact being the single `stories/<id>-*.md` it names; there is no sprint status; the previous retrospective, when resuming, is `{spec-folder}/RETROSPECTIVE.md`; session logs are unchanged.
+
+The diff range differs. Each story records its own baseline in its artifact frontmatter — `baseline_revision` (deprecated) or `baseline_commit` — so there is no single epic-wide range. The range end is the next story's baseline in list order, which is exact because neither skill adds a commit of its own after the work. For the last story, when nothing records the end, derive it from the history — usually `HEAD`, though not always — and mark it inferred rather than recorded. A baseline that is absent or is not a revision leaves that story with no commit or diff evidence — record that too. Group the stories sharing an identical range and run `git_evidence.py` once per distinct range, passing that group's ids as one comma-separated `--stories` value. No `^` is needed here: unlike the sprint-mode range above, the recorded baseline is already the pre-change commit. Ranges may overlap or diverge; count a shared commit or file change once in the aggregate views while keeping each story's range as its provenance.
+
+## Missing evidence
+
+Evidence availability varies; never hide a gap. Each later analysis declares what it needs and, when that input is absent, records a narrowed scope rather than guessing. A reader of the final retro must always be able to tell **"checked and clean"** from **"never checked."**
+
+- Missing session logs → process-lesson analysis is skipped, and the retro says so.
+- No declared acceptance criteria → the verdict is profiled from the diff and stories, flagged as profiled rather than declared.
+- Sub-agents unavailable → analyses that would delegate run inline over a narrowed scope, and the narrowing is recorded.
+
+Carry the inventory forward into Phase 2 as the authoritative list of what is available to read.

package/src/bmm-skills/4-implementation/wizz-retrospective/references/retro-document.md

@@ -0,0 +1,84 @@
+# Finalize: Retrospective Document and Sprint Status
+
+Phase 5. Finalize the retrospective and update sprint tracking. Two writes: the retrospective document, and the `sprint-status.yaml` update. Stories mode makes only the first.
+
+## The retrospective document
+
+This document is the run's working artifact: it is created as a skeleton once the epic is fixed and filled as each phase completes, so Phase 5 finalizes rather than writes it from scratch. It lives at `{implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md`, in `{document_output_language}`, as readable markdown; ensure `{implementation_artifacts}` exists. In stories mode it lives at `{spec-folder}/RETROSPECTIVE.md` instead — a fixed name, so a resumed run finds it — and carries the same frontmatter without `epic`, which the folder already names.
+
+Open the document with YAML frontmatter a machine can read without parsing the prose — an epic gate or orchestrator keys off `verdict` to decide whether to hold the next epic:
+
+```
+---
+epic: {{epic_number}}
+date: {date}
+verdict: accepted | accepted-with-open-items | rejected
+criteria: declared | profiled
+headless: true | false
+---
+```
+
+Keep `verdict` in sync with the Acceptance verdict section below. Do not encode the verdict in the sprint-status retro key — that key's value stays `done` so the existing lifecycle consumers (sprint planning's `optional ↔ done` transition, status TUIs) keep working unchanged.
+
+That holds for a **rejected** epic too: the update below marks the retro key `done` whichever way the verdict went, because `done` there means *the retrospective ran*, not *the epic passed*. The script writes no verdict of any kind into `sprint-status.yaml` — there is no `retro_verdict` key and `--verdict` is only echoed back in the result JSON — so a gate or orchestrator that acts on the verdict **must** read this document's frontmatter. Reading sprint-status alone cannot tell a rejected epic from an accepted one.
+
+Sections:
+
+- **Epic summary** — which epic, the diff range, stories completed, any stories still unfinished (`pending_stories`) that the user accepted retro-ing over, the evidence inventory (what was available, what was missing). Unfinished stories force the machine acceptance verdict to **rejected** (see `references/acceptance-verdict.md`).
+- **Findings** — grouped by aggregate view and by lens, each with its source reference and disposition (fix now / defer / accept). This is the record; do not summarize away the provenance.
+- **Behavior verification** — what was exercised end to end and what was observed, or an explicit note that runtime behavior was not exercised.
+- **Previous-retro follow-through** — if a prior retro exists, whether its action items landed, with evidence, and the selector Phase 5 would need to act on each (`references/acceptance-verdict.md` specifies what to record).
+- **Action items** — the routed fix-now items and process lessons, each with an owner. Note which are proposed remediation or spec reconciliations awaiting human application.
+- **Acceptance verdict** — accepted / accepted-with-open-items / rejected, whether the criteria were declared or profiled, and the evidence behind the call.
+- **Open questions** — what a human answer would materially change, and anything the analyses could not resolve.
+- **Assumptions** — in headless runs, every choice made without the user: which epic was selected (invocation or auto-detect), the `detect-epic --epic <N>` (or unflagged) result including any non-empty `pending_stories`, a machine **rejected** verdict forced by unfinished stories or rendered with no human decision, each proposed item. Omit in interactive runs — an interactive run records the same facts where the user confirmed them, in Epic summary.
+
+Do not state time estimates anywhere in the document.
+
+## Sprint-status update
+
+Do not hand-edit `sprint-status.yaml` — its comment blocks and quoting are exactly the write that most often corrupts the file. Use the bundled script, which round-trips through a comment-preserving YAML parser, force-quotes values so punctuation (a leading `#`, a colon) cannot break parsing, and validates the result — restoring the original file untouched if the write does not verify:
+
+```
+uv run --no-cache {skill-root}/scripts/sprint_status.py update \
+  --file "{implementation_artifacts}/sprint-status.yaml" \
+  --epic {{epic_number}} --set-retro-done \
+  --add-action '[{"action":"...","owner":"..."}, ...]' \
+  --ref "{implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md" \
+  --verdict "<accepted | accepted-with-open-items | rejected>" \
+  --date "{date}"
+```
+
+Keep every value quoted. `--date` is parsed as `MM-DD-YYYY HH:MM` and nothing else — unpadded spellings like `1-2-2026 9:05` are accepted and normalized to the padded form, but a value that does not parse is rejected with `ok: false`, `restored: true` and exit 1, before the file is touched, and the whole update is a no-op. So pass `{date}` only if it is already in that form; otherwise reformat it, or omit the flag entirely and let the script stamp the current time itself. That format carries a space, which is why the flag must be quoted: unquoted, `--date 07-28-2026 14:23` splits into two argv words and dies at argparse (`{"ok": false, "error": "argument error: unrecognized arguments: 14:23"}`, exit 2). `--file` and `--ref` are quoted for the same reason — an `{implementation_artifacts}` path containing a space breaks them exactly the same way.
+
+It sets `development_status["epic-{{epic_number}}-retrospective"]` to `done`, appends one `action_items` entry per proposed item, and bumps `last_updated`. Each appended item carries `status: open`, a stable `id` (`epic-<N>-retro-item-<n>-<slug>` derived from the action text, or the `id` you supply in the JSON), and a `ref` back to this retro document (from `--ref`, or a per-item `ref` in the JSON) — so an orchestrator can dedupe items across re-runs and dispatch each one to its full, sourced finding. `--verdict` is not written into the file; it is echoed back in the result JSON as a signal for consumers. It accepts exactly the frontmatter vocabulary — `accepted`, `accepted-with-open-items`, `rejected` — and any other spelling is rejected (`ok: false`, `restored: true`, exit 1) before the file is touched. Read the JSON it returns:
+
+- `ok: true` → report the retro-key transition, `action_items_added`, `action_items_updated`, and the echoed `verdict`.
+- `ok: false` → the file was left untouched (`restored: true`); surface the error, do not hand-edit. `restored: false` means the rollback write also failed and the file may be incomplete — warn the user explicitly.
+- `restored` speaks only for a command that may have written. Every `update` failure carries it; `detect-epic` never emits it, because it never writes; and an invocation the parser itself rejects (`argument error: ...`, exit 2) carries neither the key nor a file to speak about. Read a missing `restored` as "nothing was at risk", never as `false`.
+- `retro_key_found: false` → the retro key was absent, so nothing was marked done; the document still saved, but tell the user sprint-status needs a manual retro entry.
+- `retro_key_found: null` → `--set-retro-done` was not passed, so the key was never looked for. Distinct from `false`, which is a real absence the user needs to be told about.
+
+Moving a *previous* epic's action items off `open` is recorded in the retro document either way. When the Phase 4 follow-through has evidence an item landed, or the user says one did, offer to update the sprint-status entries too and run `--set-action-status` with exactly what the user confirms — that flag is the only supported way to change a status; hand-editing never is. It can be passed in the same invocation as the update above, or run on its own:
+
+```
+uv run --no-cache {skill-root}/scripts/sprint_status.py update \
+  --file "{implementation_artifacts}/sprint-status.yaml" \
+  --epic {{epic_number}} \
+  --set-action-status '[{"id":"epic-1-retro-item-1-add-error-handling","status":"done"},{"epic":1,"action":"Exact action text","status":"in-progress"}]'
+```
+
+Rules:
+
+- Select an item by its `id`, or — for legacy entries written before ids existed — by `epic` plus the item's exact `action` text. An entry carrying both uses the `id`. Matching is exact: no trimming, no case folding, and `epic` must be a JSON integer. The `--epic` flag does not scope selectors; it only names the retro key and the epic recorded on appended items, so items from any epic are addressable in one call.
+- The only statuses are `open`, `in-progress`, and `done`. `wizz-sprint-planning`'s status view counts both `open` and `in-progress` as open action items, so only `done` retires an item from the surfaced list — moving something to `in-progress` records progress, it does not quiet the dashboard.
+- Every selector must resolve to exactly one item already in the file. Matching nothing, matching more than one, or colliding with another entry in the same array aborts the whole invocation — `ok: false`, `restored: true`, the file byte-identical and nothing partially applied. "Whole invocation" includes any `--set-retro-done` and `--add-action` passed in the same call: one mistyped selector drops the entire update, so re-run the full command after fixing it rather than assuming the retro key was set.
+- Items appended by `--add-action` in the same run are not addressable in that run; they are always written as `open`.
+- Only ever apply a status the user confirmed, and in a headless run do not pass this flag at all.
+- Success reports `action_items_updated`.
+
+Only ever apply a status the user confirmed: the evidence justifies proposing a transition, and only the user's confirmation justifies writing it. In a headless run do not use this flag at all — record the transitions you would have proposed in the Previous-retro follow-through section and leave the prior items' statuses alone.
+
+## Finish
+
+Report where the document was saved, the verdict, and the action-item count. Then, if `{workflow.on_complete}` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/wizz-retrospective/references/team-discussion.md

@@ -0,0 +1,22 @@
+# Team Discussion (opt-in)
+
+An optional discussion layer over Phase 2's findings, off by default. It exists for users who want the retrospective discussed from multiple perspectives, the way a team would. One rule: **the team discusses evidence, never invention.** Agents speak only to findings that carry source references. No agent may describe an event that did not happen or report a pattern the diff does not show.
+
+## When to run it
+
+Only when asked — "discuss it as a team," "run party mode," or similar. A default run never enters this phase.
+
+## How to run it
+
+Invoke **`wizz-party-mode`**, seeded with the consolidated Phase 2 findings and the epic context, so the installed agents react as real subagents with independent thinking rather than a scripted dialogue. Seed it with:
+
+- The findings, each with its source reference, grouped by the aggregate view or lens that produced it.
+- The improvements the evidence confirms — real gains, patterns that worked — so positive observations are grounded in fact.
+- The epic's acceptance criteria (or the profiled stand-in), so the discussion can weigh the verdict.
+- The previous epic's action items and whether they landed, when a prior retro exists, so accountability is grounded in fact.
+
+If `wizz-party-mode` is unavailable, a discussion the user asked for must not silently fail to happen. Run it inline over the same seed — take each perspective yourself, hold every perspective to sourced findings — and record in the retrospective document that the discussion ran inline rather than through the installed agents. Record it as the narrowing it is: one model playing every role loses the independent disagreement that surfaces missed findings. State that in the document rather than omitting it.
+
+Facilitate in `{communication_language}`, keep the user an active participant, and steer toward systemic understanding over blame — the point is which process or convention would have prevented a finding, not who wrote the line. Capture anything the discussion surfaces that the analyses missed; a genuinely new observation becomes a finding only once you can tie it to a source, otherwise it is a question for Phase 4, not a conclusion.
+
+The discussion does not replace Phase 4. Its output feeds the action items and the verdict; it does not render them.

package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/git_evidence.py

@@ -0,0 +1,304 @@
+# /// script
+# requires-python = ">=3.10"
+# ///
+"""Measure git commit and file-change evidence over a revision range.
+
+Prints ONLY JSON to stdout. Errors are emitted as JSON to stdout with a
+non-zero exit code: 2 for invalid arguments (rejected before git runs),
+1 for git or I/O failures. This script only MEASURES — it never judges
+acceleration or violations. The model interprets the numbers.
+
+Two git passes. The first lists every commit in the range (merges included)
+and sums the per-file churn of the non-merge commits, which is what `files`
+reports. The second runs only when the range contains merges and measures
+those merges alone, reported separately as `merge_files` — never folded into
+`files`, because a merge's diff against its first parent restates the churn
+of the commits it merged in, which the first pass already counted.
+"""
+
+import argparse
+import json
+import os
+import re
+import subprocess
+import sys
+
+UNIT_SEP = "\x1f"
+# sha, space-separated parents (empty for a root commit), subject.
+LOG_FORMAT = f"--format=%H{UNIT_SEP}%P{UNIT_SEP}%s"
+
+
+def _emit(obj, code=0):
+    sys.stdout.write(json.dumps(obj))
+    sys.exit(code)
+
+
+class JsonArgumentParser(argparse.ArgumentParser):
+    """Emit argparse failures on the JSON-only stdout contract, not usage text.
+
+    The parser is constructed with ``add_help=False``. The override below covers
+    ``error()``, but ``-h`` never reaches it: the built-in help action calls
+    ``print_help()`` and ``exit(0)`` directly, which would put plain usage text
+    on stdout with a zero exit and break the JSON-only contract. Removing the
+    action instead of intercepting it routes ``-h`` through the already-tested
+    ``error()`` path as an ordinary unrecognized argument. The cost is that the
+    ``help=`` strings are unreachable from the CLI; the skill's references carry
+    the usage a human needs.
+    """
+
+    def error(self, message):
+        _emit({"ok": False, "error": f"argument error: {message}"}, 2)
+
+
+def _parse_numstat_line(line):
+    # numstat lines: "<added>\t<deleted>\t<path>"; binary files use "-".
+    parts = line.split("\t")
+    if len(parts) < 3:
+        return None
+    added_raw, deleted_raw, path = parts[0], parts[1], "\t".join(parts[2:])
+    added = None if added_raw == "-" else int(added_raw)
+    deleted = None if deleted_raw == "-" else int(deleted_raw)
+    return added, deleted, path
+
+
+def _git_log(repo, extra_args, rng):
+    """Run one `git log --numstat` pass over `rng` and return its stdout.
+
+    `core.quotePath=false` keeps non-ASCII paths as real UTF-8 strings instead
+    of octal escapes, and `--no-renames` makes a rename an honest delete + add
+    instead of an unopenable "src/{a => b}" pseudo-path that splits one file's
+    churn across several keys. Both matter for every pass, so both live here.
+
+    `log.diffMerges=separate` is pinned on the command line because it is what
+    `-m` means: a user or repo config setting it to `off` makes pass 2 emit no
+    file rows at all, so `merge_files` would come back empty beside a non-zero
+    `merges_measured` and read as "the merges changed nothing".
+    """
+    cmd = [
+        "git",
+        "-c",
+        "core.quotePath=false",
+        "-c",
+        "log.diffMerges=separate",
+        "-C",
+        repo,
+        "log",
+        "--numstat",
+        "--no-renames",
+        *extra_args,
+        LOG_FORMAT,
+        rng,
+        "--",  # terminate rev parsing so the range can never match a pathspec
+    ]
+    try:
+        # Decode explicitly: git emits UTF-8 path bytes regardless of the
+        # caller's locale, and a C locale would otherwise decode them as ASCII.
+        # surrogateescape, not replace: replace maps every invalid byte to the
+        # same U+FFFD, so two distinct non-UTF-8 paths would collapse into one
+        # `files` key with their churn silently summed. Lone surrogates survive
+        # json.dumps (escaped as \udcXX under ensure_ascii) and json.loads.
+        proc = subprocess.run(
+            cmd,
+            capture_output=True,
+            text=True,
+            encoding="utf-8",
+            errors="surrogateescape",
+            env={k: v for k, v in os.environ.items() if not k.startswith("GIT_")},
+        )
+    except Exception as exc:  # noqa: BLE001
+        _emit({"ok": False, "error": str(exc)}, 1)
+
+    if proc.returncode != 0:
+        # stderr can be empty (a signal kill, a quiet failure); the exit code is
+        # then the only thing left to report, so never emit an empty error.
+        _emit(
+            {
+                "ok": False,
+                "error": proc.stderr.strip() or f"git exited {proc.returncode}",
+            },
+            1,
+        )
+    return proc.stdout
+
+
+def _parse_log(output, stories):
+    """Turn one pass's log output into (commits, files_map). Shared by both."""
+    commits = []
+    files = {}  # path -> {path, _added, _deleted, binary_revisions, commit_count}
+    seen = set()
+    counting = True
+
+    for raw in output.splitlines():
+        if UNIT_SEP in raw:
+            sha, parents, subject = raw.split(UNIT_SEP, 2)
+            # Under -m, git repeats a merge's header once per parent unless it
+            # also honours --first-parent (git 2.31+). Count only the first
+            # block for a sha — git emits parents in order, so that block is
+            # the first-parent diff either way, and no churn is double counted.
+            counting = sha not in seen
+            if not counting:
+                continue
+            seen.add(sha)
+            commits.append(
+                {
+                    "sha": sha,
+                    "subject": subject,
+                    # Every id the subject names, in --stories order: a commit
+                    # spanning two stories belongs to both. Word-boundary match
+                    # so a story id like "1-2" does not also match "11-2".
+                    "stories": [
+                        sid
+                        for sid in stories
+                        if re.search(rf"\b{re.escape(sid)}\b", subject)
+                    ],
+                    "is_merge": len(parents.split()) > 1,
+                }
+            )
+            continue
+
+        if not counting or not raw.strip():
+            continue
+
+        parsed = _parse_numstat_line(raw)
+        if parsed is None:
+            continue
+        added, deleted, path = parsed
+
+        entry = files.get(path)
+        if entry is None:
+            # _added/_deleted are running sums over the path's text revisions.
+            entry = {
+                "path": path,
+                "_added": 0,
+                "_deleted": 0,
+                "binary_revisions": 0,
+                "commit_count": 0,
+            }
+            files[path] = entry
+
+        entry["commit_count"] += 1
+        if added is None or deleted is None:
+            # A binary revision is unmeasurable, not zero — count it alongside
+            # the sums instead of nulling the path's real measured churn.
+            entry["binary_revisions"] += 1
+        else:
+            entry["_added"] += added
+            entry["_deleted"] += deleted
+
+    return commits, files
+
+
+def _file_list(files):
+    return [
+        {
+            "path": entry["path"],
+            "added": entry["_added"],
+            "deleted": entry["_deleted"],
+            "net": entry["_added"] - entry["_deleted"],
+            "commit_count": entry["commit_count"],
+            "binary_revisions": entry["binary_revisions"],
+        }
+        for entry in files.values()
+    ]
+
+
+def main(argv=None):
+    parser = JsonArgumentParser(
+        description=(
+            "Measure commit and per-file change evidence over a git revision "
+            "range. Measures only; does not judge."
+        ),
+        add_help=False,
+    )
+    parser.add_argument("--repo", default=".", help="Path to the git repo (default: .)")
+    parser.add_argument("--range", dest="range", help="Revision range REV..REV")
+    parser.add_argument(
+        "--stories",
+        help="Comma-separated story ids to match against commit subjects.",
+    )
+    args = parser.parse_args(argv)
+
+    stories = []
+    if args.stories:
+        # dict.fromkeys dedupes while keeping the caller's order: a repeated id
+        # would otherwise land twice in a commit's `stories`, double counting
+        # that commit in any per-story total built from the output.
+        stories = list(
+            dict.fromkeys(s.strip() for s in args.stories.split(",") if s.strip())
+        )
+
+    if not args.range:
+        _emit(
+            {
+                "range": None,
+                "note": "no range supplied",
+                "commits": [],
+                "files": [],
+            }
+        )
+
+    # Accept only an explicit REV..REV range. Anything else silently measures
+    # the wrong thing: a leading "-" is consumed by git as an option, a single
+    # rev logs all history up to it, a bare pathspec logs by path, an empty
+    # endpoint ("..", "a..", "..b") makes git default that side to HEAD, and a
+    # three-dot "A...B" is a symmetric difference — a different commit set
+    # entirely. partition splits at the FIRST "..", so any of those extra-dot
+    # shapes leaves `right` empty or dot-prefixed.
+    left, _, right = args.range.partition("..")
+    if (
+        args.range != args.range.strip()
+        or args.range.startswith("-")
+        or not left
+        or not right
+        or right.startswith(".")
+    ):
+        _emit(
+            {
+                "ok": False,
+                "error": f"invalid --range {args.range!r}: expected a revision range like REV..REV",
+            },
+            2,
+        )
+
+    # Pass 1 — the listing. No extra args, so full topology: every commit in
+    # the range including merges, which is what per-story attribution reads.
+    # Merges contribute no numstat rows here, so `files` is non-merge churn.
+    commits, files = _parse_log(_git_log(args.repo, [], args.range), stories)
+    merge_count = sum(1 for commit in commits if commit["is_merge"])
+
+    # Pass 2 — merge churn, only when there is any. `-m --first-parent
+    # --min-parents=2` walks the range head's first-parent spine and emits
+    # exactly one diff-against-first-parent block per merge sitting on it.
+    # Merges off that spine are counted in merge_count and never measured,
+    # which is precisely why merges_measured is a separate key: the gap
+    # between the two is a visible statement that some merges went
+    # unmeasured. This never folds into `files` — a merge's first-parent diff
+    # restates the churn of the commits it merged in, which pass 1 already
+    # counted, so adding it in would double count.
+    merge_commits, merge_files = [], {}
+    if merge_count:
+        merge_commits, merge_files = _parse_log(
+            _git_log(
+                args.repo,
+                ["-m", "--first-parent", "--min-parents=2"],
+                args.range,
+            ),
+            stories,
+        )
+
+    _emit(
+        {
+            "range": args.range,
+            "commit_count": len(commits),
+            "merge_count": merge_count,
+            "merges_measured": len(merge_commits),
+            "commits": commits,
+            "files": _file_list(files),
+            "merge_files": _file_list(merge_files),
+            "stories_supplied": stories,
+        }
+    )
+
+
+if __name__ == "__main__":
+    main()