@brunosps00/dev-workflow 1.3.0 → 1.5.0

package/scaffold/skills/dw-memory/SKILL.md

@@ -52,7 +52,7 @@ Create `MEMORY.md` and `<N>_memory.md` on first use with the template below. Nev
 - Branch: <branch-name>
 
 ## Durable Decisions
-- <decision 1> — <one-line rationale>
+- <decision 1> — <one-line rationale> — [confidence: 0.7; seen in tasks 1,3]
 
 ## Cross-Task Constraints
 - <constraint discovered during implementation that affects multiple tasks>
@@ -124,6 +124,16 @@ Before promoting an item from `<N>_memory.md` to `MEMORY.md`, ask:
 
 All three must be "yes" to promote. If any is "no", the item stays in task memory.
 
+### Confidence signal
+
+Tag each durable decision with a confidence in `[0.3–0.9]` plus the tasks that confirmed it — `… — [confidence: 0.7; seen in tasks 1,3,5]`:
+
+- Confirmed in **≥2 of the last 3 tasks** with no contradiction → **≥0.7** (trust it; safe to act on without re-deriving).
+- Confirmed once, or inferred but not yet reused → **0.3–0.5** (tentative; gather more signal before relying).
+- Contradicted by a later task or the repo → lower it or drop the decision (see Error Handling).
+
+Confidence makes cross-task learning explicit and is the signal `/dw-learn` reads to promote high-confidence decisions into durable instincts, constitution principles, or rules.
+
 ### Belongs in shared memory
 - A discovered constraint affecting multiple tasks ("the Stripe API rate-limits to 100 req/s — batch operations must respect this")
 - A cross-cutting architectural decision made during implementation ("chose React Server Components for data fetching across the whole feature")
@@ -179,6 +189,7 @@ This budget is doctrine, not a hard gate. No command currently rejects work for
 - `/dw-run` — reads memory before coding; updates `<N>_memory.md` during; runs promotion test + updates `MEMORY.md` at the end.
 - `/dw-run` — runs promotion + compaction between tasks, so each task starts with clean shared state.
 - `/dw-autopilot` — threads memory through every phase (brainstorm → PRD → techspec → tasks → execution); on re-invocation reads `MEMORY.md` first to reconstitute cross-session context.
+- `/dw-learn` — synthesizes confidence-tagged decisions here (plus bugfixes, deviations, git history) into atomic **instincts** in `.dw/memory/instincts/`; format, confidence rules, and promotion path in `references/instincts.md`.
 
 Callers should mention this skill in their "Skills Complementares" section.
 

package/scaffold/skills/dw-memory/references/instincts.md

@@ -0,0 +1,45 @@
+# Instincts — promoting durable memory into reusable behavior
+
+An instinct is a small, atomic, confidence-weighted behavior learned from THIS project's work, promotable
+into a constitution principle or rule. Instincts live in `.dw/memory/instincts/*.md` and are proposed and
+curated by `/dw-learn` — never written without explicit approval. There is no always-on observer; instincts
+are synthesized on demand from what the project already recorded (see `/dw-learn` sources).
+
+## File format (`.dw/memory/instincts/<slug>.md`)
+
+```markdown
+---
+id: prefer-result-type-in-services
+trigger: when writing a service method that can fail
+confidence: 0.7          # 0.3 tentative … 0.9 near-certain (same scale as durable decisions)
+domain: error-handling   # code-style | testing | error-handling | git | workflow | security
+scope: project           # project | global
+evidence:
+  - "MEMORY.md decision (seen in tasks 3,5)"
+  - "bugfix 004-null-order — same root cause"
+---
+
+# Prefer Result type in services
+
+## Action
+Return a typed Result/union from fallible service methods instead of throwing across layers.
+
+## Why
+Two bugfixes traced to exceptions swallowed between layers; the confidence-tagged decision in MEMORY.md
+already prefers this.
+```
+
+## Confidence (reuse the promotion signal)
+
+Same scale and rule as durable decisions (see the **Confidence signal** section of this skill): ≥2
+independent confirmations in recent work → ≥0.7. Lower it when a later task contradicts the instinct; drop
+it when it stops being true.
+
+## Promotion path
+
+- **≥0.7, project scope** → propose as a `.dw/constitution.md` principle (via the `/dw-analyze-project`
+  Step 8 flow) or a note on the relevant `.dw/rules-library/<stack>.md`.
+- **Seen across multiple projects** → mark `scope: global` (a candidate for a shipped rule/skill).
+
+High-confidence instincts (≥0.7) whose `trigger` matches the current work are loaded on demand by `/dw-run`
+and `/dw-plan` — the same lazy pattern as `.dw/rules/concerns.md`. Never bulk-load the whole instinct set.

package/scaffold/skills/dw-minimalism/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: dw-minimalism
+description: Pre-generation YAGNI gate. Before writing new code, infra, or abstractions, climb the decision ladder (need it? reuse? stdlib? native? installed dep? one line?) at the active lite/full/ultra intensity. Triggers from /dw-run, /dw-plan, /dw-review and any "add X / build Y" intent.
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+---
+
+# dw-minimalism — Write the Least Code That Solves the Problem
+
+The cheapest code to maintain is the code you never wrote. This skill runs a
+**pre-generation gate**: before producing a new function, file, dependency, or
+abstraction, justify it against a decision ladder. It is the missing rung
+between `dw-search-first` (which evaluates *external dependencies*) and
+`dw-simplification` (which cleans up code *after* it exists).
+
+## When to Use
+
+Read this skill when:
+
+- `/dw-plan` is about to specify new modules/services — pressure-test scope before tasks are written.
+- `/dw-run` is about to implement — climb the ladder before the first line of new code.
+- `/dw-review` flags over-engineering (speculative generality, premature abstraction, unused options).
+- The user (or a task) says "add X", "build Y", "create a helper/wrapper/abstraction for Z".
+
+Do NOT use to:
+
+- Block code that is genuinely required by an accepted PRD/TechSpec acceptance criterion.
+- Strip safety, validation, accessibility, security, or error handling — minimalism is about *necessity*, never about cutting correctness. Removing a guard is not minimalism.
+- Re-litigate existing code you are not touching (that is `dw-simplification`'s scope discipline).
+
+## The Decision Ladder
+
+Evaluate **in order** and stop at the first rung that resolves the need. Record which rung justified the decision.
+
+1. **Does it need to exist? (YAGNI)** — Is there a current, concrete requirement, or is this for an imagined future? No requirement → don't build it. Defer to a task/ADR instead.
+2. **Already in the codebase?** — Search first (`grep`/`glob`/`.dw/intel/`). Reuse an existing function, type, or pattern over a new one.
+3. **Standard library / language built-in?** — Prefer the platform's own primitives over hand-rolled equivalents.
+4. **Native framework feature?** — The framework/runtime already in use may cover it (routing, validation, caching, etc.).
+5. **An already-installed dependency?** — Use a package the project already depends on before adding a new one. (New dependency → hand off to `dw-search-first` for the adopt/wrap/compose/build decision.)
+6. **Can it be one line / inlined?** — A small inline expression often beats a new helper, indirection layer, or config knob. Don't extract until there are real, repeated call sites.
+7. **Only then: the minimum viable implementation** — the smallest change that satisfies the requirement, no speculative parameters, hooks, or generality.
+
+If you cannot name the rung that justifies the code, you are not ready to write it.
+
+## Intensity Modes
+
+The active mode is read from `.dw/minimalism.json` (`{"mode":"full"}`); default `full` when absent.
+
+| Mode | Behavior |
+|------|----------|
+| `off` | Skill is dormant; no minimalism gate applied. |
+| `lite` | Apply rungs 1–2 only (YAGNI + reuse). Light touch; flags only obvious over-build. |
+| `full` | **Default.** Apply the full ladder; flag speculative generality and premature abstraction. |
+| `ultra` | Aggressive. Prefer inlining over any new helper/file; demand explicit justification for every new module, dependency, parameter, and config option. |
+
+Stricter modes raise the bar for "this needs to exist"; none of them authorize cutting correctness, validation, or security.
+
+## Anti-patterns this gate catches
+
+- A new utility/wrapper with a single caller (rung 6 — inline it).
+- A config flag, strategy interface, or plugin point with exactly one implementation (rung 1 — YAGNI).
+- A hand-rolled debounce/clone/group-by/date-format when stdlib or an installed dep already has it (rungs 3–5).
+- A new dependency for a few lines of logic (rung 5 → `dw-search-first`).
+- "Future-proofing" abstractions for requirements that do not exist yet (rung 1).
+
+## Red Flags (stop and climb the ladder)
+
+"we'll probably need", "to be safe", "make it generic", "for flexibility",
+"in case we want to", a base class / interface with one subclass, an options
+object where every caller passes the same value.
+
+## Composition
+
+- **New external dependency?** → hand off to `dw-search-first` (adopt / wrap / compose / build).
+- **Code already exists and is too complex?** → that is `dw-simplification` (Chesterton's Fence, behavior-preserving).
+- This skill sits *before* both: it decides whether the code should be written at all.
+
+## Structured Return
+
+When invoked directly or by a harness, return or merge this block:
+
+- **Status:** `PASS` when the proposed code is the minimum justified by a ladder rung, `FINDINGS` when over-build is detected and a leaner alternative exists, `BLOCKED` when the requirement is too unclear to judge necessity, `NOT_APPLICABLE` when no new code/dependency/abstraction is being introduced.
+- **Scope:** the proposed code, the requirement it serves, and the active intensity mode.
+- **Evidence:** the ladder rung that justified (or failed) the code, search hits for existing reuse, stdlib/native/installed-dep alternatives checked.
+- **Artifacts:** the leaner alternative, a deferral task/ADR for speculative work, or the minimal implementation sketch.
+- **Decisions:** build / reuse / inline / use-existing-dep / defer / skip — with the rejected heavier option.
+- **Risks:** correctness or safety that must NOT be cut, hidden requirement that could justify more, future cost of the deferral.
+- **Next Step:** write the minimal version, reuse the found code, or hand off to `dw-search-first`/`dw-simplification`.
+
+## Inspired by
+
+Adapted from [`DietrichGebert/ponytail`](https://github.com/DietrichGebert/ponytail)
+(MIT) — the "lazy senior developer" decision ladder and lite/full/ultra intensity
+modes. Rebased on dev-workflow conventions and wired to compose with
+`dw-search-first` and `dw-simplification`.

package/scaffold/skills/dw-review-rigor/SKILL.md

@@ -21,6 +21,17 @@ By `/dw-review --code-only`, `/dw-review --coverage-only`, `/dw-refactor`, and `
 - The scope the caller is reviewing (file paths, directories, or PR diff).
 - Optional: prior review reports in `.dw/spec/prd-*/reviews/` — so this round only surfaces NEW findings.
 
+## Pre-Report Gate
+
+Before writing ANY finding, clear four checks — if any is "no"/"unsure", downgrade or drop it (an unactionable finding is noise):
+
+1. **Location** — exact file and line?
+2. **Failure mode** — a concrete input/state and the bad outcome it produces?
+3. **Context** — read the surrounding code (callers, imports, tests), not just the flagged line?
+4. **Severity** — defensible against Rule 2's definitions? (a missing JSDoc is never HIGH)
+
+Report only findings you are **>80% confident** are real. A style preference no rule backs is not a finding. See `references/false-positives.md` for patterns LLM reviewers habitually mis-flag.
+
 ## The Five Rules
 
 ### 1. De-duplicate before writing
@@ -111,6 +122,7 @@ The caller emits:
 2. **Counts** — critical / high / medium / low.
 3. **Findings** — ordered by severity, each in the format above.
 4. **Well-implemented aspects** — short bulleted list, calibrates tone.
+5. **Self-score** — rate the report on the five axes in `references/self-eval-rubric.md`; any axis below top cites the gap, then fix (<30s) or flag.
 
 ## Critical Rules
 

package/scaffold/skills/dw-review-rigor/references/false-positives.md

@@ -0,0 +1,21 @@
+# False Positives — patterns LLM reviewers habitually mis-flag
+
+Loaded on demand by the Pre-Report Gate. Skip these unless you have evidence **specific to this codebase**
+(a failing test, a real caller that doesn't guard, a project rule that forbids it). Flagging them anyway is
+the most common way an AI review drowns real findings in noise.
+
+| Tempting finding | Why it's usually wrong |
+|---|---|
+| "Add error handling here" | The error path is already handled by the caller or the framework — Express/Koa middleware, a React error boundary, a top-level `catch`, or a job runner that retries. Trace one level up before flagging. |
+| "Missing input validation" | The function is internal and every caller already validated at the boundary. Validation belongs at the trust boundary, not on every hop. |
+| "Magic number" | Well-known constants are self-documenting: HTTP codes (200/404/500), `1000`/`60`/`24`/`1024`, array index `0`/`-1`, `100` for percent. Only flag opaque domain numbers with no name. |
+| "Function too long" | Length ≠ complexity. Exhaustive `switch`, config/lookup objects, test tables, and generated code are long *and* simple. Flag high branching/nesting, not line count. |
+| "Missing JSDoc/docstring" | Internal helpers whose name and signature are self-describing don't need docs. Reserve for public API or non-obvious contracts. |
+| "Possible null dereference" | A preceding line already narrowed the type or an `if` guard is in scope. Read the few lines above before asserting. |
+| "Use `const` / style nit" | The linter/formatter already enforces this (Rule 4). It is a linter task, not a review finding. |
+| "This could be a race condition" | Only real if there is actual shared mutable state across concurrent paths. A single-threaded request handler touching a local variable is not a race. |
+| "Add a test for this" | Valid only if the behavior is untested AND load-bearing. Don't demand tests for trivial getters or framework glue. |
+| "Extract this into a helper (DRY)" | Two similar lines are not duplication worth an abstraction. Premature extraction couples unrelated call sites — see `dw-minimalism`. |
+
+**Rule of thumb:** if the "fix" would be rejected by a competent maintainer as busywork, it is a false
+positive. When unsure whether a pattern is intentional, apply Rule 3 (verify intent) before writing it.

package/scaffold/skills/dw-review-rigor/references/self-eval-rubric.md

@@ -0,0 +1,38 @@
+# Self-Evaluation Rubric — five axes, evidence required
+
+A structured way for an agent to rate its own output **before** handing it over, without waiting for user
+feedback. Used by `dw-review-rigor` (score the review itself) and cited by `dw-cli-run` (the 0–10 delivery
+gate applies the same evidence discipline). Adapted from the ECC `agent-self-evaluation` skill.
+
+## The five axes (score each 1–5)
+
+| Axis | Question | What a low score catches |
+|---|---|---|
+| **Accuracy** | Are the facts, claims, and code correct? | Hallucinated APIs, wrong file paths, syntax errors, unverified assertions |
+| **Completeness** | Did it cover everything the request asked? | Missed edge cases, skipped subtasks, unhandled error paths |
+| **Clarity** | Is it understandable and well-structured? | Confusing explanations, jargon, rambling, missing context |
+| **Actionability** | Can the user act on it immediately? | Vague suggestions, missing steps, "you should X" without showing how |
+| **Conciseness** | Is it the minimum needed to be complete? | Redundancy, over-explanation, filler, restating the question |
+
+Scale: **5** = no reasonable improvement · **4** = minor nits · **3** = one notable weakness · **2** = a clear
+gap that hurts usability · **1** = fundamentally misses the request.
+
+## The one hard rule: evidence for every score below 5
+
+A score under 5 **must cite the specific gap** — quote the line, name the missing case, point at the
+redundancy. "Completeness: 3 — doesn't handle the empty-array case in `parse()`" is a real score;
+"Completeness: 3 — could be more thorough" is hand-waving and not allowed.
+
+## What to do with the scores
+
+1. Score each axis independently (don't average away a real weakness).
+2. If any axis is **≤ 3**: fix it now when the fix is under ~30 seconds; otherwise flag it explicitly in the
+   output so the user knows the gap exists.
+3. Keep the self-score short — a few lines, not a second report.
+
+## Anti-patterns
+
+- **"Everything is a 5"** with no evidence — the most common failure; it means you didn't actually evaluate.
+- **Over-penalizing scope** — grade only what was requested, not scope you invented.
+- **Re-litigating decisions** — evaluate execution quality, not whether a settled decision was right.
+- **Personal preference as a gap** — a nit the linter doesn't enforce and no rule backs is not a real deduction.

package/scaffold/skills/dw-silent-failure/SKILL.md

@@ -19,7 +19,8 @@ Use during `/dw-review`, `/dw-bugfix`, and `/dw-qa --fix` when failures may be h
 - Log-only handling where callers need the failure.
 - Generic rethrows that lose stack or input context.
 - Async work launched without awaiting, tracking, or explicit detachment.
-- Network/database/filesystem calls without timeout or rollback where the project requires it.
+- Network/database/filesystem calls without a **timeout** — the call can hang indefinitely and block everything waiting on it.
+- Transactional work (multi-step writes, DB mutations, chained external calls) without **rollback** on partial failure — leaves silently corrupted or half-written state.
 
 ## Reporting Standard
 
@@ -27,7 +28,8 @@ Only flag a finding when you can name:
 
 - the exact location,
 - the trigger,
-- the hidden bad outcome,
+- the severity (critical / high / medium),
+- the hidden bad outcome and its impact (what the user or system experiences when it fires),
 - the minimal fix.
 
 Inspired by ECC's `silent-failure-hunter`; adapted as both a skill and a dispatchable `dw-silent-failure-hunter` agent.

package/scaffold/skills/dw-simplification/SKILL.md

@@ -99,6 +99,18 @@ If a simplification touches >500 lines, **don't do it manually**. Use:
 
 Manual edits across hundreds of lines are how subtle bugs creep in.
 
+## Refactor risk levels
+
+Before removing or restructuring, categorize by blast radius and act in that order — never all at once:
+
+| Risk | Examples | Discipline |
+|------|----------|-----------|
+| **SAFE** | Unused exports, unused deps, unreachable branches | Batch-remove, run the gate after each batch, commit |
+| **CAREFUL** | Consolidate duplicates, extract/inline, rename symbol | One or two per commit; re-read callers first |
+| **RISKY** | Change a public API, alter a data structure, extract a layer | One per commit; regression tests first; pair review / ADR |
+
+Start with SAFE and graduate only after the gate is green. For finding SAFE candidates on JS/TS (and other ecosystems), see `references/dead-code-tools.md`. This composes with Chesterton's Fence (Rule 1) — a tool calling code "unused" still needs the WHY check before deletion (reflection, dynamic imports, and framework entry points are invisible to static analysis).
+
 ## Verification protocol
 
 Before committing the simplification:
@@ -139,6 +151,7 @@ In the formal Level 3 review (post-Level 2 chain from `dw-review-implementation`
 - `references/complexity-metrics.md` — when each metric (cyclomatic, cognitive, depth, fanout) actually matters; how to measure cheaply.
 - `references/behavior-preserving.md` — characterization tests, refactor with test gate, rollback patterns, codemod tooling per language.
 - `references/deep-modules.md` — high-leverage modules behind small interfaces; deletion test, locality, leverage, seam, adapter diagnostic; anti-patterns (shallow wrapper, god-module). Invoked by `/dw-refactor` and `/dw-brainstorm` refactor-audit mode.
+- `references/dead-code-tools.md` — per-ecosystem tools that surface SAFE-tier dead-code candidates (knip/depcheck/ts-prune for JS/TS; vulture/ruff for Python; deadcode/staticcheck for Go; cargo-udeps for Rust). Candidates still pass Chesterton's Fence before deletion.
 
 ## Inspired by
 

package/scaffold/skills/dw-simplification/references/dead-code-tools.md

@@ -0,0 +1,23 @@
+# Dead-code detection tools (find candidates; then apply Chesterton's Fence)
+
+Detection tools surface **candidates** — they do not know about reflection, dynamic imports, framework
+entry points, or external consumers of a public API. Every hit is a SAFE-tier candidate to verify, not an
+automatic deletion. Run the gate (lint + tests + build) after each batch.
+
+## JavaScript / TypeScript
+- `npx knip` — unused files, exports, and dependencies in one pass (the broadest single tool).
+- `npx depcheck` — unused and missing npm dependencies.
+- `npx ts-prune` — unused TypeScript exports.
+- `npx eslint . --report-unused-disable-directives` — stale `eslint-disable` comments.
+
+## Other ecosystems
+- **Python:** `vulture`, `ruff` (`F401` unused imports), `deptry` (unused dependencies).
+- **Go:** `deadcode` (golang.org/x/tools/cmd/deadcode), `staticcheck` (`U1000`).
+- **Rust:** `cargo +nightly udeps` (unused deps), the compiler's own `dead_code` warnings.
+- **C# / .NET:** Roslyn analyzers (`IDE0051` unused private member, `IDE0059` unnecessary assignment).
+
+## Discipline
+1. Run the tool; treat every result as a **SAFE-tier candidate**, not a confirmed removal.
+2. For each candidate, apply Chesterton's Fence (Rule 1) — dynamic/reflective/plugin use won't appear in static analysis.
+3. Remove in batches by category (deps → exports → files); run the gate after each batch; commit per batch.
+4. Anything the tool flags that turns out to be load-bearing → add a comment explaining why, so the next pass doesn't re-flag it.

package/scaffold/skills/dw-testing-discipline/SKILL.md

@@ -38,6 +38,23 @@ Each rule has nuance read `references/core-rules.md` for the long version with e
 - Verifying browser-side trust boundaries (auth, CSRF, headers) → `references/security-boundary.md`.
 - Picking which test workflow applies (UI / network / perf) → `references/three-workflow-patterns.md`.
 
+## Step 0 — detect the runner before writing any test
+
+Do not assume `npm test`. The package manager and the test runner are different things — confirm both:
+
+1. Read `package.json` `scripts.test` (plus `test:watch` / `test:coverage`), or the language equivalent (`pyproject.toml`/`tox.ini`, `Cargo.toml`, `*.csproj`, `go.mod`).
+2. Identify the actual runner: jest / vitest / mocha / `node:test` / `bun:test` / pytest / `go test` / `cargo test` / `dotnet test`.
+3. Invoke it through the project's package manager, not a hardcoded `npm`:
+
+| Manager | test | watch | coverage |
+|---|---|---|---|
+| npm | `npm test` | `npm test -- --watch` | `npm run test:coverage` |
+| pnpm | `pnpm test` | `pnpm test --watch` | `pnpm test:coverage` |
+| yarn | `yarn test` | `yarn test --watch` | `yarn coverage` |
+| bun (native) | `bun test` | `bun test --watch` | `bun test --coverage` |
+
+**Bun gotcha:** `bun test` runs Bun's native runner (`bun:test`); `bun run test` runs whatever `scripts.test` is (often jest/vitest). They are not interchangeable — use the one the project actually configures. When unsure, confirm with `<runner> --help`.
+
 ## Reference router
 
 | Doing what | Read |

package/scaffold/skills/dw-ui-discipline/SKILL.md

@@ -34,7 +34,7 @@ Find the project's design source-of-truth in this order:
 4. Component library config — `components.json` for shadcn, theme exports.
 5. Storybook stories (implicit canonical components).
 
-If **at least one** exists: it wins. Defer to it. If a needed token is missing (e.g., a danger-secondary color), propose adding it to the authority FIRST, not inline.
+**Stop at the first match** in this list — that source is the authority; defer to it and do not override it with a lower rung or a training-data default. If a needed token is missing (e.g., a danger-secondary color), propose adding it to the authority FIRST, not inline.
 
 If **none exists**: read `references/curated-defaults.md` and pick one of the 10 neutral palettes + one of the 10 font pairings shipped there. Mark the choice in the techspec/PR description: "Design source: no project authority found; using curated default `<name>`; recommend establishing `DESIGN.md`."
 

package/scaffold/skills/dw-verify/SKILL.md

@@ -160,7 +160,7 @@ Verification failure is information, not a dead end. Protocol:
 
 Discover the project gate before claiming success. Prefer documented gates in `.dw/rules/`, then package scripts such as `verify`, `check`, `ci`, or `test`, then Makefile/just/pyproject equivalents. If no verification command exists, state that explicitly in the Verification Report and avoid completion language.
 
-Load `references/verification-discovery-and-attribution.md` when you need the full discovery checklist, command integration table, or attribution notes.
+Load `references/verification-discovery-and-attribution.md` for the discovery checklist and attribution notes, or `references/pre-check-and-status.md` for the cheap diff-hygiene grep and the compact polling status line.
 
 ## Structured Return
 

package/scaffold/skills/dw-verify/references/pre-check-and-status.md

@@ -0,0 +1,28 @@
+# Cheap pre-check + compact status
+
+Two lightweight companions to the full verification gate. Neither replaces the Verification Report — they
+run *around* it.
+
+## Diff hygiene (cheap pre-commit grep)
+
+Before running the full pipeline, one fast grep over the staged diff catches the most common "left it in"
+mistakes:
+
+```bash
+git diff --cached | grep -nE 'console\.(log|debug)|debugger|TODO: *remove|sk-[A-Za-z0-9]|api[_-]?key|password *='
+```
+
+Hits are a smell to clear, not a gate by themselves. This is **not** the security gate — `/dw-secure-audit`
+(gitleaks + Trivy + Semgrep) remains the authoritative secret/vuln check before commit/PR. Use this grep as a
+2-second sanity pass, then run the real pipeline.
+
+## Compact status (for real-time polling)
+
+When a runner (e.g. `dw-cli-run`) polls progress *between* full reports, a one-line form is enough:
+
+```
+Build: PASS | Lint: PASS | Tests: 42/42 | Verdict: READY
+```
+
+The compact line never replaces the full report — the final completion claim still requires the Verification
+Report Template with cited command output. Use the compact line for progress, the full template for the claim.