Setup Status

Read-only cross-analysis over every setup skill in the brewcode suite. It answers one question: what is already set up in this project, what drifted, what was never installed — and hands back the exact command to run for each row.

Every probe is read-only. No file is created, edited or deleted by the report itself; allowed-tools carries no Write, no Edit, no Agent. Each probe is an existence check, a cmp, or a one-line grep. The single exception is Phase 1c's opt-in one-key merge into a settings.json, which happens only after the user picks it — see Why it does not run the setups.

Prompt contract

Position 1 of $ARGUMENTS is a free-form prompt (RU/EN). This skill has no modes to select — report is the only behavior — so the prompt carries exactly one optional decision: which plugin or skill to filter to.

1. There are no flags and no destructive path — nothing to strip.
2. Extract a plugin name (brewcode, brewtools, brewdoc) or a skill name (semble-setup, docsync, task board, ...) from the prompt if one is present; that becomes the filter. Prose naming neither is unrecognised text, not an error -> full report.
3. Empty arguments -> full cross-plugin report. Nothing here is chosen by asking.
4. AskUserQuestion fires at most ONCE per run, and only for Phase 1c's task-tools offer — the one outcome-changing choice this skill has. The filter is never asked about.
5. Prose that is not a plugin/skill name is still input: extract the name from it, never treat the first word as a positional filter.

Then print this block ONCE, right before the report (Phase 4) — the only possible mutation is the Phase 1c env key, and it comes after the report:

PLAN — brewcode:setup-status
INPUT:  <arguments verbatim, or "(empty)">
MODE:   report — <full cross-plugin | filtered: <plugin/skill>>
SCOPE:  <resolved plugin(s)/skill(s) in scope>
DO:     <2-5 imperative bullets: resolve plugin roots, probe artifacts, read stamps, classify;
         add "offer to enable the task-graph tools" when Phase 1c's verdict is `off`>
RESULT: <the report the user ends up holding; name the settings.json write when one is offered>

Labels are literal; values follow the conversation language.

Why it does not run the setups

Each setup skill is an interactive generator: it fans out subagents, analyses the repo and asks the user real questions. Running two of them back-to-back in one session degrades both — the context fills with the first one's analysis, and the second one's questions get answered against stale findings. So the correct flow is:

This skill reports. The user runs each setup by hand, ideally one per fresh session.

There is no --run, no --fix, no auto mode, and no plan to add one. If the user asks for one, say this paragraph and print the run-list instead.

One carve-out, and it is not a setup. Phase 1c's CLAUDE_CODE_ENABLE_TODO_TOOLS offer merges ONE key into ONE settings.json. It spawns no subagent, analyses nothing, generates nothing, and asks exactly one question — none of the properties that make batching setups harmful apply to it. The promise above is about the eleven setups and stays whole: this skill still runs none of them.

Outside that single env key, this skill creates, edits and deletes nothing.

Arguments: $ARGUMENTS — empty = full report. A plugin name (brewcode, brewtools, brewdoc) filters to that plugin's rows. A skill name (semble-setup, docsync, task board) filters to that one row and prints its detection rule in full. Unrecognised text = full report.

Two questions, two signals

Every setup artifact in a project carries a content_version — the release in which its own content last actually changed — alongside a version — the plugin release that produced this install. The field contract (version, content_version, generated_by, last_updated, doc_type, and which carrier each file type uses) lives in ONE place: references/artifact-metadata.md. This skill consumes it and never restates it.

version — which plugin release produced this install — stays readable on every row and every verdict; it answers a real question, just not this skill's headline one, since it bumps on every plugin release whether or not this artifact's own content changed, which is exactly what was producing false stale reports before content_version existed. Report content_version first, version beside it as provenance, the owner when it disagrees, the byte verdict last.

None answers another's question. A hand-edited installed hook still carries the X.Y.Z content_version stamp it was copied with, so the stamp cannot see body drift — cmp can. And cmp is meaningless for a generated artifact, which is AI-authored per project and never byte-equal to any asset — only the stamp reaches those. The owner is orthogonal to both: a file written by the WRONG setup can be at the current content_version and byte-perfect, and nothing but generated_by will say so.

Of the five fields in the contract, this skill reads three — content_version (headline), generated_by, and version (secondary, displayed but never decisive). Why last_updated and doc_type are deliberately unread is argued once, in Phase 2a; do not add a reader for them without an actionable verdict to attach.

Two stamping moments, and the difference matters when reading a row:

The Roster — SINGLE SOURCE OF TRUTH

Every fact this skill knows about a setup lives in this ONE table. Adding a future setup = adding ONE row. Nothing else in this file, and no script, encodes the roster.

$BC / $BT / $BD = the resolved plugin roots from Phase 0.

Rows 8 and 10 share one precedence rule: the setup's own generated JSON is the preferred carrier, and the byte-copied companion's brewcode-meta: line is the documented fallback for as long as that JSON goes unstamped. Read the JSON first; fall through silently; never report LEGACY on a row whose fallback carrier answered.

Row 2 — the .sembleignore carve-out. Like hard-sync.md it is shipped as mechanism a (STAMPED_FILES, kind marker) and copied verbatim by install_managed, so it LOOKS like a cmp partner. It is not one. install_ignore_apply (semble-guidance.sh:564-585, reached through the install_ignore dispatcher at :618-620) runs install_candidates after install_managed has copied the template, and that function appends a # --- brewcode:semble measured candidates --- block measured from THIS repo (:500-555) — every line commented out, proposals only. So a HEALTHY, freshly-installed .sembleignore differs from assets/sembleignore.template by construction, exactly like row 9. Fed to Phase 2b it prints DIFFERS beside a CURRENT stamp, which Phase 3 rule 9 turns into stale (bytes drifted) — and row 2's only two readings of that (metadata-only re-sync or prose hand-edit needing --force) are both wrong. --force there takes a backup and overwrites the user's own uncommented exclusions. Never cmp it, never prescribe --force for it, never name it in a remedy for byte drift.

Unlike row 9, its STAMP is still read. The installer's comparison strips both the # brewcode-meta: line and the whole candidates block from both sides (sg_strip_metaline, :401-411), so a template update still writes through on the metadata-only branch and the stamp genuinely moves. Phase 2a on .sembleignore is valid; Phase 2b on it is not. The two carve-outs differ exactly there: hard-sync.md loses BOTH signals, .sembleignore loses only cmp.

unchanged from the installer does NOT mean byte-equal to the template. install_ignore_apply snapshots the file around both halves and collapses a clean net-zero run — re-sync then a byte-identical re-append — back to ignore: up to date (:576-584; the dry-run path predicts the same verdict by simulating into a temp dir, install_ignore_dry:591-616). So a back-to-back re-run over an unchanged repo reports ignore: up to date — while the file on disk still differs from assets/sembleignore.template by the whole candidates block. Do not read the installer's unchanged as licence to cmp the pair; the two answer different questions.

A re-run over a repo whose FILE SET moved does report changed, because the scan re-measures and the block genuinely changes. That is real byte movement, still not a drift signal, and still not something cmp against the template can express.

Row 9 — why the dashboard parses instead of executing. bash "$BD/skills/memory-sync-setup/scripts/generate.sh" status prints a richer verdict (STAMP_FORMAT, META_*, DRIFTS, VERDICT) and is genuinely read-only — its status_report only reads and echoes, and resolve_root only cds. It is still the wrong default here: it re-scans the whole memory surface (real work, not a probe), it exit 1s when the cwd is not a repo root, and it returns a private verdict vocabulary that would have to be translated into this skill's states — which puts roster knowledge inside a foreign script and breaks "no script encodes the roster". So: read the frontmatter with the Phase 2a block like every other row, and put generate.sh status in the Command column as something the USER may run when row 9 is not green.

Row 9 — the hard-sync.md carve-out. It is shipped as mechanism a (STAMPED_FILES row, kind md) and cpd verbatim, so it LOOKS like a cmp partner. It is not one, and listing it as one made this dashboard report drift on every correctly-installed project. The emitted references/hard-sync.md carries two of the generator's twelve BLOCK placeholders — {PATHS_PRECISION_TABLE} and {OBVIOUS_VS_DOMAIN_TABLE} — which the generator's own Phase 3 fills with project-specific tables via Edit, and generate.sh validate FAILS while either is unfilled. So a HEALTHY install differs from the plugin source by construction: cmp DIFFERS is the success state, not drift, and no mode can ever clear it without destroying the user's tables. Its baked stamp is frozen at the release that emitted it for the same reason — refresh_refs refuses to re-copy a file whose content differs — so feeding it to Phase 2a would print a permanent BEHIND. Never cmp it, never stamp-read it, never name it in a remedy. The row's version signal is the anchor's frontmatter and nothing else.

The two references that DO pair up are cleared by upgrade, and only by it. generate.sh:514 refresh_refs() (reached from restamp, which is the mandatory last step of upgrade — memory-sync-setup/SKILL.md mode upgrade step 3) re-copies a reference only when that is provably lossless, and prints which case fired:

Line	Condition	Clears a cmp DIFFERS?
REF OK:	already byte-identical	n/a — the row was SAME
REF RESTORED:	the file was absent; nothing local to lose	yes
REF RECOPIED:	the ONLY difference is the brewcode-meta: release-stamp line	yes — this is the plugin-update case
REF DIFFERS:	real content differs (hand-edit, filled BLOCKs, prose moved in a newer release)	no — the file is left untouched, by design

A REF DIFFERS: on memory-guide.md or agent-audit.md after an upgrade therefore means a genuine local edit: report stale (bytes drifted), say upgrade will NOT overwrite it, and tell the user to diff against $BD/skills/memory-sync-setup/references/<name> and port by hand. Do not prescribe a mode that would silently discard their edit — there is none.

Every secondary must be EXCLUSIVE to its row. A shared artifact — .claude/agents/*.md, .claude/agents/intent-guard.md (superreview and teams both emit it), any hand-written agent — is not evidence that THIS setup ran, and listing one makes Phase 3 rule 3 report a partial install in every project that merely has an agent file. If a setup owns no exclusive secondary, leave the cell empty and let the anchor decide.

Row 3 baseline mapping (the only non-obvious cmp pairing):

<stack> is the one per-stack reference the install picked — go.md, java-kotlin.md, python.md or typescript-react.md. It is substituted and baseline-copied exactly like the other four; only its filename varies. Absent from an install that predates it: report the other four and say the per-stack ref is missing, never DIFFERS.

NOT setups — never appear in the report

Recurring tools, not one-time installs. They are correct to run repeatedly and have no installed state to report: brewcode:agents, skills, rules, convention, e2e; brewtools:text-optimize, text-human, secrets-scan, ssh, deploy, plugin-update, provider-switch; brewdoc:md-to-pdf, my-claude, publish.

Phase 0 — Resolve plugin roots

A plugin that is not installed makes every one of its rows n/a — never missing. Do not assume all four are present.

The plugin version is the number every stamp is compared against, so resolve it with the SAME precedence the brewcode SessionStart hook uses (brewcode/hooks/session-start.mjs, parseVersion): the cache directory basename first, .claude-plugin/plugin.json .version second. One precedence, two consumers — do not invent a third.

EXECUTE using Bash tool:

for p in brewcode brewdoc brewtools brewui; do
  r=$({ ls -d "$HOME/.claude/plugins/cache/claude-brewcode/$p"/*/ 2>/dev/null || true; } | sort -V | tail -1 | sed 's:/*$::')
  if [ -n "$r" ] && [ -d "$r" ]; then
    v=$(basename "$r")
    case "$v" in
      [0-9]*.[0-9]*.[0-9]*) : ;;
      *) v=$(grep -o '"version"[[:space:]]*:[[:space:]]*"[^"]*"' "$r/.claude-plugin/plugin.json" 2>/dev/null | head -1 | sed 's/.*:[[:space:]]*"//; s/"$//' || true) ;;
    esac
    echo "$p ROOT=$r VERSION=${v:-unknown}"
  else echo "$p ROOT=none VERSION=none"; fi
done
echo "PROJECT=$PWD"
test -d "$PWD/.claude" && echo "DOTCLAUDE=yes" || echo "DOTCLAUDE=no"
echo "OK"

STOP if FAILED — cannot resolve the cache; report it and stop rather than calling everything missing. All four roots none also means stop: nothing installed, nothing to report.

Bind $BC, $BT, $BD and their versions from the output. DOTCLAUDE=no is a legitimate answer — every row is missing, print the table anyway. VERSION=unknown on a plugin that IS installed means no comparison is possible for its rows: report installed (plugin version unresolved) and say why.

Phase 1 — Probe artifacts

One generic block, fed from the roster. Paste the anchor + secondary paths of the rows in scope (after the $ARGUMENTS filter) into the heredoc — relative to the project root, one per line, a trailing / for a directory, globs allowed.

EXECUTE using Bash tool:

cd "$PWD" || exit 1
while IFS= read -r rel; do
  [ -z "$rel" ] && continue
  case "$rel" in
    */)    [ -d "$rel" ] && echo "DIR  $rel" || echo "MISS $rel" ;;
    *"*"*) n=$({ find . -path "./$rel" 2>/dev/null || true; } | wc -l | tr -d ' '); n=${n:-0}; [ "$n" -gt 0 ] && echo "GLOB $rel ($n)" || echo "MISS $rel" ;;
    *)     if [ -f "$rel" ]; then echo "FILE $rel"
           elif [ -f "$rel.disabled" ]; then echo "PARK $rel.disabled"
           else echo "MISS $rel"; fi ;;
  esac
done <<'PATHS'
.claude/teams/*/team.md
.claude/teams/*/trace-ops.sh
.claude/rules/semble-first.md
PATHS
echo "OK"

PARK is present, not missing. Five setups disable by renaming their entry file to <name>.disabled (Phase 1b), and the body stays byte-identical — so a PARK line never feeds Phase 3's missing or partial rules, and the file it names is still a readable version stamp.

Then the settings.json wiring greps — textual counts only, they do not prove the entries are well-formed or attached to the right event:

EXECUTE using Bash tool:

for f in .claude/settings.json .claude/settings.local.json; do
  [ -f "$f" ] || { echo "$f absent"; continue; }
  for k in think-short agent-deadline agent-return agent-router hardmode-guard docsync; do
    echo "$f $k=$({ grep -c "$k" "$f" 2>/dev/null || true; } | tr -d ' ')"
  done
done
echo "OK"

Global-scope twins for rows 5, 6 and 11 (think-short-setup, agent-deadline-setup and agent-return-setup install to project or ~/.claude) — read-only, never written:

EXECUTE using Bash tool:

for f in "$HOME/.claude/hooks/think-short-session.mjs" "$HOME/.claude/hooks/agent-deadline-guard.mjs" "$HOME/.claude/agent-deadline.json" \
         "$HOME/.claude/hooks/agent-return-guard.mjs" "$HOME/.claude/hooks/agent-return-contract.mjs" "$HOME/.claude/hooks/agent-return-budget.mjs" "$HOME/.claude/agent-return.json"; do
  [ -f "$f" ] && echo "FILE $f" || echo "MISS $f"
done
echo "OK"

Phase 1b — Disable switches

disable is a canonical verb on all eleven setups, and a deliberately disabled setup is neither broken nor stale. Every row therefore leaves a probeable off-switch, in one of two mechanisms:

An absent enabled key does NOT mean the same thing on every row — read the writer, never the key name. Two opposite defaults ship side by side, and conflating them inverts a whole row:

Row	Reader's test	Absent key means	Consequence for this skill
6 agent-deadline	cfg.enabled !== true -> return (agent-deadline-guard.mjs:354)	INERT	a key-less config is disabled, never installed — reporting it live claims a deadline is enforced when none is
7 agent-router	default enabled: true, flipped only on raw.enabled === false (agent-router.mjs:118, :259, :571)	ENABLED	a key-less config is live; reporting it off would tell the user to enable an already-armed hook
10 docsync	c.enabled !== false in all three hooks (docsync-track.mjs:72, docsync-watch.mjs:69, docsync-gate.mjs:78)	ENABLED	same as row 7 — back-compat installs predating the key are live
11 agent-return	CONFIG.enabled === true -> on, anything else off (agent-return-budget.mjs:111)	INERT	same as row 6 — a key-less config is disabled, and reporting it live claims a return budget that is never applied

Rows 7 and 10 are opt-out, rows 6 and 11 are opt-in. The probe below therefore emits a THIRD token, no-key, instead of guessing — and Phase 3 rule 2 maps it per row, not globally.

EXECUTE using Bash tool — config flags. Every arm prints a line: a row that produces no output at all is indistinguishable from a row the block forgot, so ABSENT is stated, never implied:

for d in "$PWD/.claude" "$HOME/.claude"; do
  j="$d/agent-deadline.json"
  if [ -f "$j" ]; then
    e=$({ tr -d ' \n' < "$j" | grep -o '"enabled":[a-z]*' || true; } | head -1)
    echo "agent-deadline $j: ${e:-no-key} (absent/no-key = INERT)"
  else echo "agent-deadline ABSENT $j"; fi
  r="$d/agent-return.json"
  if [ -f "$r" ]; then
    e=$({ tr -d ' \n' < "$r" | grep -o '"enabled":[a-z]*' || true; } | head -1)
    echo "agent-return $r: ${e:-no-key} (absent/no-key = INERT)"
  else echo "agent-return ABSENT $r"; fi
done
for f in .claude/semble/state.json .claude/brewtools/agent-router.json .claude/brewtools/manager/state.json; do
  if [ -f "$f" ]; then
    echo "$f: $({ tr -d ' \n' < "$f" | grep -o '"\(enabled\|hard\|phase\)":[^,}]*' || true; } | tr '\n' ' ')"
  else echo "$f absent"; fi
done
c=.claude/docsync/config.json
if [ -f "$c" ]; then
  case "$(tr -d ' \n' < "$c")" in
    *'"enabled":false'*) echo "docsync PARKED $c (enabled:false)" ;;
    *)                   echo "docsync LIVE   $c (enabled:true or key absent — absent means enabled)" ;;
  esac
else echo "docsync ABSENT $c"; fi
echo "OK"

Row 7's agent-router.json and row 10's config.json take the opposite default: no enabled token in the output line is ENABLED, and neither ever yields disabled on a missing key.

EXECUTE using Bash tool — entry-file parking. Row 5 (think-short) parks; it belongs here, not in the config-flag block above. LIVE / PARKED / ABSENT are three distinct answers and the block never collapses them: ABSENT means never deployed, PARKED means deployed and switched off:

for f in .claude/skills/superreview/SKILL.md .claude/skills/memory-sync/SKILL.md \
         .claude/agents/task-tracker.md .claude/skills/task-board/SKILL.md \
         .claude/skills/task-spec/SKILL.md .claude/rules/tasks.md; do
  if   [ -f "$f" ];          then echo "LIVE   $f"
  elif [ -f "$f.disabled" ]; then echo "PARKED $f.disabled"
  else                            echo "ABSENT $f"; fi
done
for d in "$PWD/.claude" "$HOME/.claude"; do
  p="$d/hooks/think-short-prompt.md"
  if   [ -f "$p" ];           then echo "LIVE   $p"
  elif [ -f "$p.disabled" ];  then echo "PARKED $p.disabled"
  else                             echo "ABSENT $p"; fi
done
for t in .claude/teams/*/team.md; do
  [ -f "$t" ] || continue
  n=$(basename "$(dirname "$t")")
  awk '/^## Agents/{a=1;next} a&&/^## /{exit} a&&/^\|/{split($0,c,"|");gsub(/[`[:space:]]/,"",c[2]);if(c[2]!=""&&c[2]!~/^-+$/&&c[2]!="Agent")print c[2]}' "$t" |
  while IFS= read -r m; do
    [ "$m" = "intent-guard" ] && continue
    l=0; p=0
    [ -f ".claude/agents/$m.md" ] && l=1
    [ -f ".claude/agents/$m.md.disabled" ] && p=1
    if   [ "$l$p" = "11" ]; then echo "CONFLICT team:$n $m"
    elif [ "$l" = 1 ];      then echo "LIVE   team:$n $m"
    elif [ "$p" = 1 ];      then echo "PARKED team:$n $m"
    else                         echo "ABSENT team:$n $m"; fi
  done
done
echo "OK"

Row 5 prints one line per scope, and only the scope whose think-short-session.mjs Phase 1 found is the answer — ABSENT on the other scope is not a finding. ABSENT on the installed scope while its four hooks are wired is partial, not disabled: the hooks fire and inject nothing, which is a broken install, and the whole reason this row cannot be probed by presence of the hooks alone.

Reading the two multi-artifact rows (1 and 4), where a toggle can land halfway:

Phase 1c — Environment prerequisites

One prerequisite, not a roster row: the task-graph tools. Claude Code 2.1.233 stopped shipping TaskCreate / TaskGet / TaskUpdate / TaskList and TodoWrite on Opus 4.8, Sonnet 5, Fable 5, Mythos 5 and newer, behind CLAUDE_CODE_ENABLE_TODO_TOOLS=1 (tools reference, env vars). Every manager-framework instruction that says build the task graph first is unexecutable while the key is unset, and nothing announces that — the tools are simply absent. Probe it in three steps, in this order.

a. Claude Code version. claude --version prints 2.1.233 (Claude Code). Compare the three components as INTEGERS — a string compare puts 2.1.99 above 2.1.233 and inverts the whole answer. Below 2.1.233 the tools are on by default: print one line, CC <ver> < 2.1.233 — task tools on by default, check skipped, skip steps b and c, and make no offer in Phase 4.

EXECUTE using Bash tool:

node --input-type=module -e '
const cur = (process.argv[1] || "").split(".").map(n => parseInt(n, 10) || 0);
const need = [2, 1, 233];
let cmp = 0;
for (let i = 0; i < 3; i++) { if ((cur[i] || 0) !== need[i]) { cmp = (cur[i] || 0) - need[i]; break; } }
console.log(cmp < 0
  ? `CC ${cur.join(".")} < 2.1.233 — task tools on by default, check skipped`
  : `CC ${cur.join(".")} >= 2.1.233 — gate applies`);
' "$(claude --version 2>/dev/null | awk '{print $1}')" && echo "✅" || echo "❌ FAILED"

b. The key, in all three settings layers, read as JSON — never grepped. env is a nested object and a grep hit proves nothing about which block the token sits in. A missing file is a normal answer, not an error, and the FIRST layer carrying the key is the one reported:

EXECUTE using Bash tool:

node --input-type=module -e '
import fs from "node:fs";
import os from "node:os";
import path from "node:path";
const layers = [
  ["global",  path.join(os.homedir(), ".claude", "settings.json")],
  ["project", path.join(process.cwd(), ".claude", "settings.json")],
  ["local",   path.join(process.cwd(), ".claude", "settings.local.json")],
];
let on = null;
for (const [name, f] of layers) {
  if (!fs.existsSync(f)) { console.log(`${name} ABSENT ${f}`); continue; }
  let j;
  try { j = JSON.parse(fs.readFileSync(f, "utf8")); }
  catch { console.log(`${name} UNPARSABLE ${f}`); continue; }
  const v = j && j.env ? j.env.CLAUDE_CODE_ENABLE_TODO_TOOLS : undefined;
  console.log(`${name} ${v === undefined ? "no-key" : JSON.stringify(v)} ${f}`);
  if (on === null && v !== undefined && String(v) !== "0") on = name;
}
console.log(`TODO_TOOLS ${on ? `on (${on})` : "off"}`);
' && echo "✅" || echo "❌ FAILED"

c. Verdict — the block's own last line, one of two:

UNPARSABLE on a layer is not off for that layer — it is a broken settings file. Say which file, and never offer to write into it (the merge in Phase 4 refuses it too).

Phase 2a — Read the content_version stamps (the headline)

ONE generic block for all eleven rows: it dispatches on file extension, so the roster's carrier column is the only thing that decides which path goes in. Paste into PLUGIN_ROOT the ROOT= Phase 0 printed for the plugin whose rows you are scanning and set PLUGIN to that plugin's name — run it three times, once per plugin, since brewcode / brewtools / brewdoc can sit at different versions. Nothing else changes between the three runs.

The heredoc is the complete set, enumerated — never a sample to expand. It carries all twenty-one carrier lines for all eleven rows on every run and filters by the PLUGIN tag, so a row cannot be silently dropped by an operator who expands two exemplars and stops. Two assertions make drift LOUD rather than silent: TOTAL must be 21 (a line deleted anywhere aborts, even in a plugin group this run is not scanning) and SEEN must equal the group's WANT (3 / 15 / 3). Both are exit 1, not a warning. Adding a roster row means adding its carrier lines here — each with its plugin-side content_version source in field 4 — AND raising both counts in the same edit — that is the whole cost, and the assertion is what charges it.

Never type the plugin version into this block. It is re-derived from PLUGIN_ROOT with the same precedence Phase 0 used — cache-directory basename first, .claude-plugin/plugin.json .version second — so the comparison can never be pinned to a number that was current when this file was written. The authority for that precedence is brewcode/hooks/session-start.mjs parseVersion, which matches /\/(\d+\.\d+\.\d+)\/?$/ on the root and falls back to plugin.json: one precedence, two consumers.

content_version is compared PER ARTIFACT, never to the release-wide $PLUGIN_VER. references/artifact-metadata.md §6 defines the comparison as the plugin's own current content_version for that same artifact — a byte-copied asset the plugin itself has not touched in three releases keeps a content_version three behind $PLUGIN_VER on BOTH sides, and comparing it to $PLUGIN_VER printed BEHIND on a genuinely current install, reproducing the exact false-staleness this field exists to fix. So every STAMPS line carries a FOURTH field: the plugin-side file that supplies (or bakes) that artifact's content_version, resolved under $PLUGIN_ROOT exactly like a cmp pair. For a byte-copied asset that is the asset itself; for a generated artifact it is the generator's own SKILL.md, whose brewcode-meta: marker every installer self-locates {CONTENT_VERSION} from.

$PLUGIN_VER stays the reference in exactly three cases: the installed artifact carries no content_version at all (the headline falls back to version, same as before), the line names no source, or the source's own value is absent or placeholder-shaped. Every verdict line prints which basis it used — cv-src or plugin-ver — so a fallback is never silent, and a source path missing from the cache prints its own SRC-MISS line beside the verdict.

This is NOT the §4 idiom, and citing §4 here would be wrong. references/artifact-metadata.md §4 rank 3 calls the cache glob "forbidden as the primary path" — and it is right, for a writer. A generator that stamps an artifact must record the version it is RUNNING AS, which under claude --plugin-dir ./brewcode is the checkout, not the cache; resolving from the cache there bakes a number the run never used. This skill writes nothing and stamps nothing. Its question is the opposite one — which installed plugin is the artifact on disk being compared against — and the installed plugin IS the cache leaf that Phase 0 already resolved and printed. Re-deriving it from PLUGIN_ROOT's basename is reading back the answer, not guessing at one; the plugin.json fallback covers a root that is not a version-named leaf. §4's own guard against "picks a stale leaf when several versions are cached" is discharged by Phase 0's sort -V | tail -1, and the --plugin-dir hazard is discharged by the Guards table, which STOPs when no cache root exists rather than substituting the checkout.

EXECUTE using Bash tool:

PLUGIN_ROOT=/abs/root/printed/by/phase0
PLUGIN=brewcode          # brewcode | brewtools | brewdoc - selects which STAMPS lines run
PLUGIN_VER=$(basename "$PLUGIN_ROOT")
case "$PLUGIN_VER" in
  [0-9]*.[0-9]*.[0-9]*) : ;;
  *) PLUGIN_VER=$(grep -o '"version"[[:space:]]*:[[:space:]]*"[^"]*"' "$PLUGIN_ROOT/.claude-plugin/plugin.json" 2>/dev/null | head -1 | sed 's/.*:[[:space:]]*"//; s/"$//' || true) ;;
esac
case "$PLUGIN_VER" in
  [0-9]*.[0-9]*.[0-9]*) : ;;
  *) echo "ABORT: plugin version unresolved for $PLUGIN_ROOT (got '${PLUGIN_VER:-}') - no comparison is possible, do not feed it to sort -V"; exit 1 ;;
esac
echo "PLUGIN_VER=$PLUGIN_VER"
read_meta() {
  rf=$1; v=""; cv=""; sg=""
  case "${rf%.disabled}" in
    *.json)
      v=$({ grep -o '"version"[[:space:]]*:[[:space:]]*"[^"]*"' "$rf" 2>/dev/null || true; } | head -1 | sed 's/.*:[[:space:]]*"//; s/"$//')
      cv=$({ grep -o '"content_version"[[:space:]]*:[[:space:]]*"[^"]*"' "$rf" 2>/dev/null || true; } | head -1 | sed 's/.*:[[:space:]]*"//; s/"$//')
      sg=$({ grep -o '"generated_by"[[:space:]]*:[[:space:]]*"[^"]*"' "$rf" 2>/dev/null || true; } | head -1 | sed 's/.*:[[:space:]]*"//; s/"$//') ;;
    *.mjs|*.js|*.sh|*.bash)
      m=$({ sed -n '1,5p' "$rf" | grep -o 'brewcode-meta:.*' || true; } | head -1)
      v=$({ printf '%s\n' "$m" | grep -o 'version=[^ ]*' || true; } | sed 's/version=//')
      cv=$({ printf '%s\n' "$m" | grep -o 'content_version=[^ ]*' || true; } | sed 's/content_version=//; s/-->$//')
      sg=$({ printf '%s\n' "$m" | grep -o 'generated_by=[^ ]*' || true; } | sed 's/generated_by=//; s/-->$//') ;;
    *)
      h=$(sed -n '1,40p' "$rf")
      m=$({ printf '%s\n' "$h" | grep -o 'brewcode-meta:.*' || true; } | head -1)
      v=$({ printf '%s\n' "$h" | grep -o '^version:[[:space:]]*.*' || true; } | head -1 | sed 's/^version:[[:space:]]*//; s/^"//; s/"$//; s/[[:space:]]*$//')
      [ -n "$v" ] || v=$({ printf '%s\n' "$h" | grep -oE '^\|[[:space:]]*Version[[:space:]]*\|[^|]*\|' || true; } | head -1 | sed 's/^.*Version[[:space:]]*|[[:space:]]*//; s/[[:space:]]*|$//')
      [ -n "$v" ] || v=$({ printf '%s\n' "$m" | grep -o 'version=[^ ]*' || true; } | sed 's/version=//')
      cv=$({ printf '%s\n' "$h" | grep -o '^content_version:[[:space:]]*.*' || true; } | head -1 | sed 's/^content_version:[[:space:]]*//; s/^"//; s/"$//; s/[[:space:]]*$//')
      [ -n "$cv" ] || cv=$({ printf '%s\n' "$h" | grep -oE '^\|[[:space:]]*Content Version[[:space:]]*\|[^|]*\|' || true; } | head -1 | sed 's/^.*Content Version[[:space:]]*|[[:space:]]*//; s/[[:space:]]*|$//')
      [ -n "$cv" ] || cv=$({ printf '%s\n' "$m" | grep -o 'content_version=[^ ]*' || true; } | sed 's/content_version=//; s/-->$//')
      sg=$({ printf '%s\n' "$h" | grep -o '^generated_by:[[:space:]]*.*' || true; } | head -1 | sed 's/^generated_by:[[:space:]]*//; s/^"//; s/"$//; s/[[:space:]]*$//')
      [ -n "$sg" ] || sg=$({ printf '%s\n' "$h" | grep -oE '^\|[[:space:]]*Generated by[[:space:]]*\|[^|]*\|' || true; } | head -1 | sed 's/^.*Generated by[[:space:]]*|[[:space:]]*//; s/[[:space:]]*|$//; s/^`//; s/`$//')
      [ -n "$sg" ] || sg=$({ printf '%s\n' "$m" | grep -o 'generated_by=[^ ]*' || true; } | sed 's/generated_by=//; s/-->$//') ;;
  esac
  v=${v:-}; cv=${cv:-}; sg=${sg:-}
}
stamp_one() {
  sf=$1; so=$2; ss=$3
  case "$sf" in "~/"*) sf="$HOME/${sf#\~/}" ;; esac
  if [ ! -f "$sf" ] && [ -f "$sf.disabled" ]; then sf="$sf.disabled"; fi
  if [ ! -f "$sf" ]; then echo "MISSING   $sf"; return; fi
  # Source FIRST: read_meta writes the globals v/cv/sg, so the reference has to be resolved before
  # the artifact's own read clobbers them. That ordering is what removes the alias trio.
  ref=""; basis=""; srcmiss=""
  if [ -n "$ss" ]; then
    if [ ! -f "$PLUGIN_ROOT/$ss" ]; then srcmiss="$PLUGIN_ROOT/$ss"
    else
      read_meta "$PLUGIN_ROOT/$ss"
      case "$cv" in
        ''|*'{'*|*'}'*|*'<'*|*'>'*) : ;;
        *) ref=$cv; basis=cv-src ;;
      esac
    fi
  fi
  read_meta "$sf"
  hv=$cv; [ -n "$hv" ] || hv=$v
  if [ -n "$so" ]; then
    if   [ -z "$sg" ];        then echo "OWNER-NONE  $sf (expected $so)"
    elif [ "$sg" != "$so" ];  then echo "OWNER-WRONG $sf ($sg, expected $so)"; fi
  fi
  if [ -z "$hv" ]; then
    r=$(grep -cE 'memory-sync template v|intent-guard template v|SKILL METADATA[^A-Za-z]*generated|<!-- last-updated:|\*\*Last Updated:\*\*|"?(updatedAt|updated_at|lastUpdated|lastSetup|lastVerifiedAt|checkedAt)"?[[:space:]]*:' "$sf" 2>/dev/null || true); r=${r:-0}
    [ "$r" -gt 0 ] && echo "LEGACY-FMT  $sf (retired stamp format)" || echo "LEGACY-NONE $sf (no stamp at all)"
    return
  fi
  case "$hv" in *'{'*|*'}'*|*'<'*|*'>'*) echo "PLACEHLD  $sf ($hv)"; return ;; esac
  # An artifact carrying a content_version is measured against its SOURCE's content_version. If that
  # source is absent from the cache no reference exists, so there is no staleness to claim: report
  # the gap and stop. Falling through to $PLUGIN_VER is how a byte-current artifact was reported
  # BEHIND (BCOP06 false staleness). An artifact with only a `version` never used cv-src anyway --
  # $PLUGIN_VER is its legitimate reference, so the missing source does not silence it.
  if [ -n "$srcmiss" ] && [ -n "$cv" ]; then
    echo "SRC-MISS  $srcmiss (content_version reference absent from the cache - no verdict for $sf)"
    return
  fi
  # cv-src answers only for an artifact that HAS a content_version; a version-only one falls back.
  if [ -z "$ref" ] || [ -z "$cv" ]; then ref=$PLUGIN_VER; basis=plugin-ver; fi
  if [ "$hv" = "$ref" ]; then echo "CURRENT   $sf ($hv, $basis)"; return; fi
  older=$(printf '%s\n%s\n' "$hv" "$ref" | sort -V | head -1 || true)
  if [ "$older" = "$hv" ]; then echo "BEHIND    $sf ($hv -> $ref, $basis)"; else echo "AHEAD     $sf ($hv > $ref, $basis)"; fi
}
SEEN=0; TOTAL=0
while IFS='|' read -r pl pat owner src; do
  [ -z "$pl" ] && continue
  TOTAL=$((TOTAL+1))
  [ "$pl" = "$PLUGIN" ] || continue
  SEEN=$((SEEN+1))
  case "$pat" in
    *'*'*)
      n=0
      for gm in $pat; do [ -e "$gm" ] || continue; n=$((n+1)); stamp_one "$gm" "$owner" "$src"; done
      [ "$n" -gt 0 ] || echo "MISSING   $pat (glob matched nothing)" ;;
    *) stamp_one "$pat" "$owner" "$src" ;;
  esac
done <<'STAMPS'
brewcode|.claude/teams/*/team.md|brewcode:teams-setup|skills/teams-setup/SKILL.md
brewcode|.claude/rules/semble-first.md|brewcode:semble-setup|skills/semble-setup/assets/semble-first.md.template
brewcode|.claude/skills/superreview/SKILL.md|brewcode:superreview-setup|skills/superreview-setup/SKILL.md
brewtools|.claude/features/board.md|brewtools:task-board-setup|skills/task-board-setup/SKILL.md
brewtools|.claude/hooks/think-short-session.mjs|brewtools:think-short-setup|skills/think-short-setup/assets/think-short-session.mjs
brewtools|~/.claude/hooks/think-short-session.mjs|brewtools:think-short-setup|skills/think-short-setup/assets/think-short-session.mjs
brewtools|.claude/hooks/agent-deadline-guard.mjs|brewtools:agent-deadline-setup|skills/agent-deadline-setup/assets/agent-deadline-guard.mjs
brewtools|~/.claude/hooks/agent-deadline-guard.mjs|brewtools:agent-deadline-setup|skills/agent-deadline-setup/assets/agent-deadline-guard.mjs
brewtools|.claude/agent-deadline.json|brewtools:agent-deadline-setup|skills/agent-deadline-setup/assets/INSTALL.md
brewtools|~/.claude/agent-deadline.json|brewtools:agent-deadline-setup|skills/agent-deadline-setup/assets/INSTALL.md
brewtools|.claude/hooks/agent-router.mjs|brewtools:agent-router-setup|skills/agent-router-setup/assets/agent-router.mjs
brewtools|.claude/brewtools/agent-router.json|brewtools:agent-router-setup|skills/agent-router-setup/assets/INSTALL.md
brewtools|.claude/brewtools/manager/state.json|brewtools:manager-setup|hooks/lib/manager-state.mjs
brewtools|.claude/brewtools/manager/hardmode-guard.mjs|brewtools:manager-setup|hooks/hardmode-guard.mjs
brewtools|.claude/hooks/agent-return-guard.mjs|brewtools:agent-return-setup|skills/agent-return-setup/assets/agent-return-guard.mjs
brewtools|~/.claude/hooks/agent-return-guard.mjs|brewtools:agent-return-setup|skills/agent-return-setup/assets/agent-return-guard.mjs
brewtools|.claude/agent-return.json|brewtools:agent-return-setup|skills/agent-return-setup/assets/INSTALL.md
brewtools|~/.claude/agent-return.json|brewtools:agent-return-setup|skills/agent-return-setup/assets/INSTALL.md
brewdoc|.claude/skills/memory-sync/SKILL.md|brewdoc:memory-sync-setup|skills/memory-sync-setup/SKILL.md
brewdoc|.claude/docsync/config.json|brewdoc:docsync-setup|skills/docsync-setup/SKILL.md
brewdoc|.claude/hooks/docsync-track.mjs|brewdoc:docsync-setup|skills/docsync-setup/assets/docsync-track.mjs
STAMPS
case "$PLUGIN" in
  brewcode)  WANT=3 ;;
  brewtools) WANT=15 ;;
  brewdoc)   WANT=3 ;;
  *)         echo "ABORT: PLUGIN must be brewcode, brewtools or brewdoc (got '$PLUGIN')"; exit 1 ;;
esac
[ "$TOTAL" = 21 ] || { echo "ABORT: STAMPS holds $TOTAL carrier lines, the roster's eleven rows need 21 - the set drifted from the roster"; exit 1; }
[ "$SEEN" = "$WANT" ] || { echo "ABORT: $SEEN of $WANT $PLUGIN carrier lines reached the loop"; exit 1; }
echo "ROWS $SEEN/$WANT for $PLUGIN (21 carrier lines over 11 roster rows)"
echo "OK"

Each heredoc line is plugin|path|expected-owner|content_version-source. The owner is the row's own <plugin>:<skill> — the roster's Skill column with the leading / dropped — so it needs no new roster column and cannot drift from it. The source is $PLUGIN_ROOT-relative and is read with the same carrier dispatch as the artifact: for a byte-copied asset it IS the asset (assets/<same name>), for a generated artifact it is the generator's SKILL.md, whose line-10 brewcode-meta: marker every installer self-locates {CONTENT_VERSION} from. Leave a field empty to skip that check — no owner, or no per-artifact comparison (then $PLUGIN_VER is the reference).

How the twenty-one lines map onto the eleven rows — the mapping the two assertions enforce:

Three things the enumeration made the block responsible for, rather than the operator:

• Row 1's glob is expanded by the block, one verdict per team, so a repo with several teams at several versions prints them all. A glob that matches nothing prints one MISSING for the pattern. Never hand-resolve it — hand-resolution is how a second team goes unread.
• ~/ is expanded against $HOME so the global-scope twins of rows 5, 6 and 11 are real paths. Both scopes are always scanned and MISSING on the scope that is not installed is not a finding — the same rule Phase 1b states for row 5. Only the scope Phase 1 found is the answer.
• Rows 6, 7, 8, 10 and 11 print two lines each per installed scope, and the roster's precedence decides which is the headline — the JSON first on 6, 7, 10 and 11; on row 8 the state.json first and the guard's brewcode-meta line only when state.json carries no version key. The second line is never a contradiction to reconcile; it is the fallback answering.

Row 8 can print LEGACY-NONE on a perfectly current install, and that is the documented path, not a legacy finding. writeState OMITS version when it cannot resolve the plugin version rather than stamping unknown (brewtools/hooks/lib/manager-state.mjs:242-252) — see references/artifact-metadata.md, "A writer that cannot resolve the version ABORTS". An absent key is exactly the missing signal the roster's row 8 defines, so read the guard's line beneath it and report from that. LEGACY-NONE on state.json with a CURRENT guard line is installed, not stale (legacy, unstamped).

The reference each verdict was measured against is printed in the same line: cv-src = the plugin's own content_version for that artifact, plugin-ver = the $PLUGIN_VER fallback.

The owner check prints an EXTRA line beside the version verdict, never instead of it — a file can be CURRENT and owner-wrong at once, and that pair is the whole point:

Why generated_by gets a reader and last_updated/doc_type do not. Five fields are written; the question for each is whether a reader can turn it into an ACTIONABLE verdict:

The .disabled fallback is what keeps a disabled install from reading as an unstamped one. A parked entry file (Phase 1b) is byte-identical to the live one, stamp included, so the block retries $f.disabled before giving up and dispatches the carrier on the name with .disabled stripped. The printed path keeps the suffix, so the row's version is real and its parked state is visible in the same line. Without this a disable would turn every affected row into MISSING -> missing, i.e. "never installed" — the exact misreading a reversible off-switch must not produce.

The carriers the block understands are exactly the ones in references/artifact-metadata.md §2, and version and generated_by are read out of the SAME carrier on every branch — never one from the frontmatter and the other from a comment:

The brewcode-meta: fallback on the third row exists because think-short-prompt.md and the three memory-sync references carry their stamp as an HTML comment — those bodies are injected into a prompt or cited verbatim, so frontmatter would leak into the text. It scans the whole 40-line head rather than the first 5 because the content_version SOURCES of the generated rows are plugin SKILL.md files, whose marker sits at line 10, under nine lines of frontmatter. The generated_by= extraction strips a trailing --> for exactly that reason: in <!-- brewcode-meta: version=X.Y.Z generated_by=brewdoc:memory-sync-setup --> the owner is the last token before the comment close.

Values are quoted in YAML and JSON (version: "X.Y.Z", content_version: "X.Y.Z", generated_by: "brewcode:teams-setup") and bare in the header table (| Version | X.Y.Z |, | Content Version | X.Y.Z |); the block strips quotes either way, and backticks off a header-table owner cell.

The PLACEHLD test is deliberately generic — never a list of known tokens. The sanctioned spellings are single-brace {PLUGIN_VERSION} and {CONTENT_VERSION} (references/artifact-metadata.md §4), but retired angle-bracket forms (<plugin X.Y.Z>, <date +%F>, <YYYY-MM-DD>) and the retired double-brace {{PLUGIN_VERSION}} still reach artifacts installed by older releases. So the test matches ANY {, }, < or > in the value. A real version is X.Y.Z and can hold none of them, so this never false-positives — and an unsubstituted token can never be fed to sort -V, which would otherwise turn "substitution never ran" into a confident BEHIND/AHEAD. Never hardcode how many placeholder spellings exist; the character test outlives the list.

The LEGACY-FMT grep is the mirror image — it names the exact retired strings of references/artifact-metadata.md §8. SKILL METADATA matches only when followed by generated (SKILL METADATA - generated <ts>, dash spelling irrelevant): live skills use the bare words in other sentences, and a bare-substring match would report a current artifact as legacy.

And its reach is the heredoc, which carries ARTIFACTS only. The retired spellings of §8 are provenance keys, so the grep is only ever meaningful on a file whose version is a staleness signal. references/artifact-metadata.md §9 puts ephemeral runtime state out of scope entirely — epoch-ms markers, TTL caches, .claude/semble/state.json, .claude/docsync/state-<session_id>.json — and none of those may be added to the STAMPS heredoc even when a row lists them as secondaries. Feeding one in is the only way this grep can false-positive: a checkedAt-style key inside a runtime cache is correct code, not a legacy stamp. brewcode/hooks/session-start.mjs was the tree's last such collision and now spells its TTL marker fetchedAtMs, so no shipped file trips the detector today — but the scope rule, not the rename, is what keeps that true.

last_updated is deliberately ABSENT from .mjs/.sh stamps and from the byte-copied semble-first.md — a date there would churn the file on every release and break cmp. Missing last_updated on a mechanism-a asset is the spec working as designed, never a legacy stamp. Only content_version (or version, on an artifact that carries none) decides this skill's verdict.

|| true on every no-match-tolerant command is MANDATORY in every fence in this file, not just this one. grep exits 1 on no-match, find and ls exit non-zero on an absent path or an unmatched glob — and all three of those are the NORMAL case for a read-only probe that expects most things to be absent. Under set -euo pipefail the failure propagates out of the pipeline (pipefail carries it past wc, sed, tr, head) and out of the command substitution, and the block aborts before printing anything at all: the emptier the project, the less the dashboard says. The idiom is x=$({ cmd || true; } | rest) — the || true goes on the command that legitimately fails, INSIDE the pipeline, so a genuine failure downstream still surfaces. grep -c needs x=${x:-0} after it as well: it prints 0 and exits 1 on no match, so || true alone leaves the 0 but a bare $(grep -c …) on a missing file leaves the variable empty and [ "$x" -gt 0 ] then fails on an empty operand.

Hardened here for the same reason: Phase 0's and Phase 5's ls -d …/*/ (an uninstalled plugin is an unmatched glob — under zsh it is a hard no matches found), and Phase 1's find -path on a glob row.

Phase 2b — cmp the byte-copied files (corroboration)

Only for rows whose roster cell names a cmp pair, and only when the anchor exists. Feed project|plugin pairs built from the roster (absolute plugin paths from Phase 0).

EXECUTE using Bash tool:

while IFS='|' read -r a b; do
  [ -z "$a" ] && continue
  if   [ ! -f "$a" ]; then echo "ABSENT  $a"
  elif [ ! -f "$b" ]; then echo "NOSRC   $b"
  elif cmp -s "$a" "$b"; then echo "SAME    $a"
  else echo "DIFFERS $a"; fi
done <<'PAIRS'
.claude/hooks/semble-session.mjs|/abs/BC/skills/semble-setup/assets/semble-session.mjs
PAIRS
echo "OK"

DIFFERS on a file whose stamp reads CURRENT is the case the stamp alone cannot see: the copy came from this plugin version but its bytes no longer match — a hand-edit, or an install that was never re-run after a same-version rebuild. Report stale (bytes drifted) and name the file.

Only a byte-STABLE copy belongs in PAIRS. A file the install fills or appends to after copying it — memory-sync's references/hard-sync.md (BLOCKs filled by the generator's Phase 3) and the repo-root .sembleignore (measured-candidates block appended by install_candidates) — differs on every healthy project and must never be fed in; see the row-2 and row-9 carve-outs. Before adding a pair, check the writer: if any mode writes that path after the cp, cmp answers a question nobody asked, and the remedy the dashboard then prescribes destroys the content the installer put there.

Both violations were found by RUNNING the loop against a healthy fixture, never by reading the roster. Re-verify a pair the same way: install into a throwaway repo and check the loop prints SAME on a fresh install.

Phase 3 — Classify

Exactly one state per row, in this order:

State vocabulary is unchanged — n/a · missing · disabled · partial · stale · installed. stale takes one of four qualifiers when a stamp or byte signal fired — rules 5-7 and 9, matching references/artifact-metadata.md §6: (X -> Y) a version behind or ahead, (legacy stamp) a retired stamp format, (legacy, unstamped) no stamp at all, (bytes drifted) right version wrong bytes. Rule 8's absence and wiring signals print a bare stale with no qualifier, naming the missing artifact (or the wiring gap) in found instead. Nothing else is a state.

Rules 2 and 3 are the two that stop false alarms:

• disabled is evaluated FIRST, ahead of missing, partial and stale. Five setups disable by parking their entry file, so on a disabled install the anchor itself is renamed away and every later rule would misfire — missing ("never installed"), or partial ("repair this") for something the user switched off on purpose. Inversely, a semble at enabled:false, a manager wall at hard:false or a docsync at enabled:false has every file in place and must NOT be reported installed: the mechanism is inert. A disabled row's Command column offers enable, never upgrade, and it never enters the run-list.
• A missing enabled key is resolved per row, from the reader, never by a house default. Rows 6 (agent-deadline) and 11 (agent-return) are opt-in — cfg.enabled !== true / CONFIG.enabled === true — so no-key is disabled. Rows 7 and 10 are opt-out, so a missing key is live and never reaches this rule. Applying one default to all four inverts two of them, and an inverted row 6 or 11 is the worst of the two directions: it reports a deadline as enforced, or a return budget as applied, when the guard returns on its first line.
• Anchor MISS is decisive — but a .disabled twin is not a MISS. The anchor is the artifact only that setup writes. No anchor in EITHER spelling = not installed, whatever else the project happens to contain. Never call a row partial on the strength of a shared file (see the exclusivity note in the roster), and never call a parked artifact absent.

The verdict for a disabled install is disabled plus its real version. Print the stamp Phase 2a read out of the parked file (or out of the untouched config), not --: the install has a version, it is simply not active. disabled is never combined with a stale qualifier — if a switched-off row is also behind, say so in the found column and still offer enable, because upgrade on a parked install is what the owning setups explicitly refuse (task-board-setup STOPs, memory-sync's validate FAILs, superreview's validate FAILs — all three tell the user to enable first).

Read the stamp; never guess a version. content_version is the headline field on all eleven rows and reading it — against the plugin's own value for that artifact — is the job. version stays real data too, displayed as provenance and used as the fallback headline on an artifact installed before its setup was wired for content_version. What stays forbidden is unchanged in spirit: never invent a version an artifact does not carry, never infer staleness from a file's mtime, never derive a version from a directory name inside the project, and never report a signal this roster does not define. An artifact with no stamp is stale (legacy stamp) — that is a fact about the install, not licence to estimate what produced it.

Two facts that look like staleness and are not:

• DIFFERS on row 8's guard means only that manager-setup install has not been re-run since the last brewtools update — the wall still works. Report stale, and say that in one clause. That is a different finding from hard: false, which is rule 3's disabled and outranks it.
• A hook copied under ~/.claude while the project also has one is a scope answer, not a conflict. Report the scope; rows 5, 6 and 11 are legitimately global.

Phase 4 — Output

Print the PLAN block (Prompt contract above) first, then lead with ONE line, before anything else — how many rows are behind the installed plugin:

4 of 11 setups are behind the installed plugin (2 stale by content_version, 1 legacy stamp, 1 drifted bytes).

Count only rows whose stamp is not CURRENT plus stale (bytes drifted). missing, disabled and n/a are not "behind" — they are not installed, switched off, or not applicable. If the number is 0, say all 11 setups are at <the resolved plugin version> and still print the table.

Then ONE table, rows in roster order, filtered by $ARGUMENTS. Answer in the language the user wrote in (RU or EN) — translate the prose, never the paths or the commands.

In the sample above A.B.C stands for the installed plugin version and X.Y.Z for the artifact's own content_version stamp (or version, when the artifact predates its setup's stamping) — the real report prints real numbers, and no literal version is ever carried in from this file.

Content Version column format: X.Y.Z when current, X.Y.Z -> A.B.C when behind (stamp then plugin), legacy -> A.B.C for a retired stamp format, unstamped -> A.B.C when there is no stamp at all, the raw token when a placeholder survived, -- for missing and n/a. X.Y.Z = X.Y.Z reads "stamp matches, the problem is elsewhere" — use it on stale (bytes drifted) so the reader is not left hunting for a version difference that does not exist. A.B.C here is the reference the verdict actually used — the plugin-side artifact's own content_version when the roster line names a source, $PLUGIN_VER only on the fallbacks Phase 2a prints as plugin-ver. An artifact carrying no content_version prints its version fallback instead — same format, same meaning, just the older field.

The Command column is a ready-to-paste line. For stale and partial it MUST carry a concrete fine-tune prompt naming what to refresh — the drifted file, the missing artifact, the layer that was never retrofitted, the placeholder that never resolved. A bare upgrade with no prompt is not acceptable output.

A remedy MUST be able to clear the verdict it follows. upgrade was for a long time the mode nobody owned: it refreshed content and left the stamp where it was, so status said stale, upgrade said success, and the next status said stale again. Every roster row now carries a Remedy check clause naming the code that proves its upgrade restamps. Two consequences bind this column:

Never emit	Because
the mode that JUST failed, as the fix for its own failure	that is the closed loop above. If a mode cannot clear its own verdict, name the one that can, or say plainly that no mode can and the user must act by hand
upgrade on a row whose roster cell does not carry a Remedy check	an unverified remedy is a guess. Print the finding without a command rather than a command that does nothing

Three findings in this roster genuinely have NO mode that clears them, and each must be reported as such instead of dressed in a command: row 9's hard-sync.md (DIFFERS is the healthy state), a REF DIFFERS: hand-edit on row 9's other two references, and a prose hand-edit of row 2's semble-first.md (skipped as user_modified; only --force overwrites, and it is not a skill mode). Say what the user must diff and port by hand.

.sembleignore is NOT a fourth: it is carved out of the cmp set, so this dashboard produces no byte verdict for it at all. --force on it overwrites the user's own uncommented exclusions — never print it.

Use the canonical modes ONLY: status · install · upgrade · enable · disable · uninstall · purge. The retired verbs (create, update, cleanup, init, on, off, setup, remove, reset) were removed — teams-setup in particular now parses anything unknown as a TEAM NAME, so emitting /brewcode:teams-setup cleanup "..." would install a team called cleanup. Never print one.

Two setups add extra verbs AFTER the canonical set, and those are live: semble-setup has reindex | optimize | resume, agent-router-setup and manager-setup take level <...>. Use an extra verb only when the roster row's finding is exactly what it fixes; otherwise the canonical verb plus a free-text prompt.

The run-list — grouped by real dependency, not just tier

A flat partial -> stale -> missing list hides one real dependency this suite has: several rows consume what teams-setup creates (agent names for routing/byAgentType, or the shared intent-guard it emits) or run faster once semble-setup's code index exists, since every setup below fans out subagents that read this repo. Group the run-list into these SIX stages, fixed order; a row not in scope (n/a, installed, disabled, or filtered out by $ARGUMENTS) is skipped, never renumbered, and a stage with zero rows in scope prints no header at all:

Within a stage, keep the existing tier order — partial (broken install) before stale before missing. disabled, installed and n/a rows never appear in the run-list — a switched-off mechanism is a choice, not a defect. Mention a disabled row once, below the list, tagged with the stage it would occupy if re-enabled, alongside its enable command.

The closing paragraph is not optional — it is the one place the user sees why this dashboard hands back commands instead of running them. Print it every time, even when the list has one entry. Number rows CONTINUOUSLY across stages (1, 2, 3, … — never restart per stage), and keep every line copy-pasteable on its own:

Run in this order, ONE PER SESSION:

  🔧 Stage 1 — fix global drift first (cheap, unlocks every stage below)
    1. /brewtools:think-short-setup upgrade "..."
    2. /brewtools:agent-return-setup upgrade "..."

  🔍 Stage 2 — search foundation
    3. /brewcode:semble-setup install

  👥 Stage 3 — agent root
    4. /brewcode:teams-setup install

  🔗 Stage 4 — agent consumers (needs stage 3's agents)
    5. /brewtools:agent-router-setup install
    6. /brewtools:manager-setup install
    7. /brewtools:agent-deadline-setup install
    8. /brewcode:superreview-setup install

  📋 Stage 5 — process layer
    9. /brewtools:task-board-setup install

  📚 Stage 6 — docs last (snapshots the finished config)
    10. /brewdoc:memory-sync-setup install
    11. /brewdoc:docsync-setup install

⚠️  Nothing above was run for you, by design. Each of these is an interactive generator: it
    fans out several subagents, analyses the repo and asks you real questions. Two in one
    session degrade each other — the context fills with the first one's analysis and the
    second one's questions get answered against stale findings. Start a fresh session per
    command, one row at a time.

The sample above lists all eleven for illustration only — a real run prints ONLY the rows this report found out of scope (not installed/disabled/n/a), so most runs show 2–5 stages, several skipped entirely. A single out-of-scope row still gets the full closing paragraph, just a one-line list under its own stage header.

The one offer — task-graph tools

Below the run-list, print Phase 1c's verdict as one line, always:

Task tools: on (global ~/.claude/settings.json)      <- verdict `on`
Task tools: OFF — TaskCreate/TaskUpdate/TaskList/TaskGet and TodoWrite are not available on this
            model. CLAUDE_CODE_ENABLE_TODO_TOOLS is unset in all three settings layers.

Then, and only when the verdict is off AND Phase 1c said the gate applies, ask exactly ONE AskUserQuestion — header Task tools, three options in this order:

Never ask when the verdict is on, never ask when Phase 1c skipped the check on an older Claude Code, and never ask twice in one run. Leave off ends it: print the manual line and stop.

On Global or This project only, run the merge — node via Bash, never Write/Edit. ~/.claude/** is a sensitive path for the editing tools (.claude/rules/avoid.md #6) and a subprocess is the sanctioned route; it also read-merges instead of overwriting, which no whole-file write does. Pass global or project as the single argument:

EXECUTE using Bash tool:

node --input-type=module -e '
import fs from "node:fs";
import os from "node:os";
import path from "node:path";
const scope = process.argv[1];
const file = scope === "global"
  ? path.join(os.homedir(), ".claude", "settings.json")
  : path.join(process.cwd(), ".claude", "settings.json");
fs.mkdirSync(path.dirname(file), { recursive: true });
let cfg = {};
if (fs.existsSync(file)) {
  try { cfg = JSON.parse(fs.readFileSync(file, "utf8")) || {}; }
  catch { console.error(`REFUSED ${file} is not valid JSON — fix it by hand`); process.exit(1); }
}
cfg.env = { ...(cfg.env || {}), CLAUDE_CODE_ENABLE_TODO_TOOLS: "1" };
const tmp = `${file}.tmp-${process.pid}`;
fs.writeFileSync(tmp, JSON.stringify(cfg, null, 2) + "\n");
fs.renameSync(tmp, file);
console.log(`WROTE ${file} env.CLAUDE_CODE_ENABLE_TODO_TOOLS=1`);
' global && echo "✅" || echo "❌ FAILED"

Every other key in the file survives — the merge parses, adds one key under env, and renames a temp file over the original, so a crash mid-write leaves the old file intact. An unparsable settings file is REFUSED, never rewritten: say so and hand the path back.

Then report, in two lines and no more:

Task tools: enabled — env.CLAUDE_CODE_ENABLE_TODO_TOOLS=1 in <the file that was written>.
Takes effect in new sessions, and usually in this one — the tool roster is re-read per request.

If the user picked Leave off, print the manual route instead and move on: add "env": { "CLAUDE_CODE_ENABLE_TODO_TOOLS": "1" } to ~/.claude/settings.json.

Phase 5 — Roster self-check

The self-updating property, as a WARNING. It never writes.

EXECUTE using Bash tool:

for p in brewcode brewdoc brewtools brewui; do
  r=$({ ls -d "$HOME/.claude/plugins/cache/claude-brewcode/$p"/*/ 2>/dev/null || true; } | sort -V | tail -1 | sed 's:/*$::')
  [ -n "$r" ] || continue
  { find "$r/skills" -maxdepth 1 -type d -name '*-setup' 2>/dev/null || true; } | sed "s|.*/|$p:|"
done
echo "OK"

Compare that list against the roster's 11 commands. Phase 1c is not a twelfth row and is never counted here — CLAUDE_CODE_ENABLE_TODO_TOOLS is an environment prerequisite, not a setup skill: it has no *-setup dir on disk, no artifact, no version stamp and no canonical modes. The count below stays 11 whatever Phase 1c reported.

Print warnings above the table so they are not lost under it. Never edit the roster to fix a warning — that is the user's call, in this repo, in a separate change.

Guards