/ripwire-fresh-eyes

name: ripwire-fresh-eyes
description: >
  Maintenance risk in code you did NOT write — inheriting a module, planning a refactor, a suspected
  god object, 'what's gnarly / where's the rot / safe to touch?': hotspots, dead or inactive code,
  switches/defaults (--flags), clones, a function's real shape, bus factor, co-change. Naming the fix
  or judging YOUR new code → quality-bar. A single-lens question is a single call.
allowed-tools: Bash, Read

Fresh-eyes risk review with ripwire

> Routing: > • Any DIFF — your own, or an incoming PR you're reviewing — about to push or merge → **ripwire-change-check**. > • **You have the measurement and now need the FIX** — which refactor a measured shape calls for, its > precondition, and the fix-then-prove loop → **ripwire-quality-bar**'s shape → refactor playbook. > • Architecture health (deps metrics, layering rules, modules) → **ripwire-layers**. > • Finding where a specific BUG lives → **ripwire-find-bug**. > • Not sure which skill? → **ripwire-router**. > > **Scope it to one unfamiliar subsystem** you're about to touch, instead of the whole tree, two ways: > point `<dir>` at the subdirectory (`ripwire src/net --hotspots`), or keep the repo root and `--exclude` the > rest. `--dead-code=DIR` also scopes directly. This is how you turn the repo-wide sweep into a > "what's-gnarly-in-code-I-didn't-write" read of one module.

`<dir>` = repo root. Add `--exclude=build --exclude=.git` (repeatable) to keep build artifacts out — they otherwise show up as false clones and dead code. This composes descriptive passes into one snapshot; run the sections your question needs.

**Inheriting this subsystem?** Check `ripwire <dir> --notes --legend=compact` first — a prior agent's pinned gotcha (`--note-add`'d trap, flake, or invariant) is the cheapest fact you can pick up before you start reading.

Core health passes

1. **Maintenance hotspots** — `ripwire <dir> --hotspots --legend=compact`

   <hotspots window="12mo" ranked="33"><f p="./src/main.cpp" churn="53" ccx="1365" score="72345" top="main:1306"/> …

`score = churn × ccx` (commits × Σ cognitive complexity). Top files = where developers keep working *and* the code is hard — the highest-leverage places to improve. `top=` names the worst function. **Recent regression, not an all-time read?** `--hotspots --since="2 weeks ago"` (or `--since=HEAD~20`) scopes churn to commits after that point; unresolvable/absent `--since` degrades silently to all-history. **On C-family/C# code, discount a body carrying `ppalt=`:** its `cx=`/`ccx=`/`nest=`/`loc=`/`locals=` are summed over EVERY `#else`/`#ifdef` branch (deterministic, but an over-count vs any single build), so a high score on a `ppalt=`-heavy function can be the preprocessor fan-out, not the logic — read `ppalt=` before calling a row the worst in the file.

1a. **"What changed recently / who touched this / what is moving here?"** — `ripwire <dir> --rank-by=churn-decay --legend=compact`

   <recent n="40" of="1857" merge_bombs_skipped="5"><rc p="src/graph.h" w="0.91" age="2"/> …

The HISTORY question, not the working-tree one: `--situ` answers what *you* changed and have not committed, this answers what the repository has been moving, newest-and-heaviest first. **Scope it to a directory: `ripwire <dir> --rank-by=churn-decay --in=DIR`** (root-relative, and it must exist under the root) — a second `<recent scope="DIR" …>` block follows the global one and the symbol map collapses to a counted stub, so the answer is the window rather than a whole-repo map. `merge_bombs_skipped="N"` is the disclosure that N commits touching more than 100 indexed files were left out of the weighting — if the commit you are hunting is a giant rename, it is in that N and not in the rows. `--since=REV|DATE` bounds the window; `--limit/--offset` page the scoped block. `ripwire <dir> --help-task="what changed recently in DIR" --legend=compact` routes here on its own.

1b. **What is BUILT but DARK here?** — `ripwire <dir> --flags --legend=compact` (`=SUBSTR` to narrow)

   <flags gates="98" dark_gates="90" compile="32" cmake="9" env="57"><gate name="X_HARMONY_SFX" kind="compile"
     default="0" dark="1" regions="7" loc="45" reads="8" p="sound/audioWiringFlags.h" l="47"/> …

Inheriting a repo, the invisible half is the code that ships compiled OUT. This harvests all three gate patterns — `#ifndef`/`#define` header gates, CMake `option()`, `getenv()` reads — with each gate's **default** and the size of the code it guards, dark first. Two things `--grep` cannot tell you: when a name is BOTH a header gate defaulting to `0` and a CMake `option(... ON)`, the **CMake default wins** (it is what the build passes) and the header appears as an `<also>` row — the contradiction a reader who greps the header gets wrong; and a gate whose default IS another gate's name resolves through the alias chain, so a master switch reports `<aliases n=…>` instead of a misleading `loc="0"`. **Limits:** lexical, not preprocessed — this is the in-repo default, never the value *your* build used. A gate needs a value (`#ifndef F` / `#define F 0`); valueless pairs are include guards and are excluded. A gate read as a value (`constexpr bool k = F != 0;` then `if constexpr`) honestly reports `regions="0"` here — **`--flip` below lifts exactly that limit.**

1b-ii. **If I flip THIS one, what lights up?** — `ripwire <dir> --flags --legend=compact --flip=NAME`

   <flip gate="X_RRF_ALL" kind="cmake" default="ON" dark="0" family="12" regions="0" loc="0" branches="43"
     bindings="11" hosts="11" downstream="95" dependents="146" tests="23" untested="0">
     <member name="X_RRF_ISLANDS" via="alias" branches="12"/> …
     <lights r="0" b="43"><b p="canyon/simLevel.cpp" l="133" gate="X_RRF_WIDTHWAVE" via="kWidthWave"
       sym="buildStripTable"/> …

A list of ~90 dark gates is a map, n