devflow-kit 1.0.0 → 1.1.0

package/scripts/hooks/session-start-memory.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 
 # Working Memory: SessionStart Hook
-# Reads .docs/WORKING-MEMORY.md and injects it as additionalContext for the new session.
+# Reads .memory/WORKING-MEMORY.md and injects it as additionalContext for the new session.
 # Also captures fresh git state so Claude knows what's changed since the memory was written.
 # Adds staleness warning if memory is >1 hour old.
 
@@ -17,12 +17,7 @@ if [ -z "$CWD" ]; then
   exit 0
 fi
 
-# Only activate in DevFlow-initialized projects
-if [ ! -d "$CWD/.docs" ]; then
-  exit 0
-fi
-
-MEMORY_FILE="$CWD/.docs/WORKING-MEMORY.md"
+MEMORY_FILE="$CWD/.memory/WORKING-MEMORY.md"
 
 # No memory file = nothing to restore (fresh project or first session)
 if [ ! -f "$MEMORY_FILE" ]; then
@@ -31,6 +26,13 @@ fi
 
 MEMORY_CONTENT=$(cat "$MEMORY_FILE")
 
+# Read accumulated patterns if they exist
+PATTERNS_FILE="$CWD/.memory/PROJECT-PATTERNS.md"
+PATTERNS_CONTENT=""
+if [ -f "$PATTERNS_FILE" ]; then
+  PATTERNS_CONTENT=$(cat "$PATTERNS_FILE")
+fi
+
 # Compute staleness warning
 if stat --version &>/dev/null 2>&1; then
   FILE_MTIME=$(stat -c %Y "$MEMORY_FILE")
@@ -40,6 +42,30 @@ fi
 NOW=$(date +%s)
 AGE=$(( NOW - FILE_MTIME ))
 
+# Check for pre-compact memory snapshot (compaction recovery)
+BACKUP_FILE="$CWD/.memory/backup.json"
+COMPACT_NOTE=""
+if [ -f "$BACKUP_FILE" ]; then
+  BACKUP_MEMORY=$(jq -r '.memory_snapshot // ""' "$BACKUP_FILE" 2>/dev/null)
+  if [ -n "$BACKUP_MEMORY" ]; then
+    BACKUP_TS=$(jq -r '.timestamp // ""' "$BACKUP_FILE" 2>/dev/null)
+    BACKUP_EPOCH=0
+    if [ -n "$BACKUP_TS" ]; then
+      BACKUP_EPOCH=$(date -j -f "%Y-%m-%dT%H:%M:%SZ" "$BACKUP_TS" +%s 2>/dev/null \
+        || date -d "$BACKUP_TS" +%s 2>/dev/null \
+        || echo "0")
+    fi
+    if [ "$BACKUP_EPOCH" -gt "$FILE_MTIME" ]; then
+      COMPACT_NOTE="
+--- PRE-COMPACT SNAPSHOT ($BACKUP_TS) ---
+Context was compacted. This snapshot may contain decisions or progress not yet in working memory.
+
+$BACKUP_MEMORY
+"
+    fi
+  fi
+fi
+
 STALE_WARNING=""
 if [ "$AGE" -gt 3600 ]; then
   HOURS=$(( AGE / 3600 ))
@@ -62,7 +88,18 @@ fi
 # Build context string
 CONTEXT="${STALE_WARNING}--- WORKING MEMORY (from previous session) ---
 
-${MEMORY_CONTENT}
+${MEMORY_CONTENT}"
+
+# Insert accumulated patterns between working memory and git state
+if [ -n "$PATTERNS_CONTENT" ]; then
+  CONTEXT="${CONTEXT}
+
+--- PROJECT PATTERNS (accumulated) ---
+
+${PATTERNS_CONTENT}"
+fi
+
+CONTEXT="${CONTEXT}
 
 --- CURRENT GIT STATE ---
 Branch: ${GIT_BRANCH}
@@ -75,6 +112,11 @@ Uncommitted changes:
 ${GIT_STATUS}"
 fi
 
+if [ -n "$COMPACT_NOTE" ]; then
+  CONTEXT="${CONTEXT}
+${COMPACT_NOTE}"
+fi
+
 # Output as additionalContext JSON envelope (Claude sees it as system context, not user-visible)
 jq -n --arg ctx "$CONTEXT" '{
   "hookSpecificOutput": {

package/scripts/hooks/stop-update-memory.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 
 # Working Memory: Stop Hook
-# Spawns a background process to update .docs/WORKING-MEMORY.md asynchronously.
+# Spawns a background process to update .memory/WORKING-MEMORY.md asynchronously.
 # The session ends immediately — no visible edit in the TUI.
 # On failure: does nothing (stale memory is better than fake data).
 
@@ -16,21 +16,25 @@ if ! command -v jq &>/dev/null; then exit 0; fi
 
 INPUT=$(cat)
 
-# Only activate in projects with .docs/ directory (DevFlow-initialized projects)
+# Resolve project directory — bail if missing
 CWD=$(echo "$INPUT" | jq -r '.cwd // ""' 2>/dev/null)
-if [ -z "$CWD" ] || [ ! -d "$CWD/.docs" ]; then
+if [ -z "$CWD" ]; then
   exit 0
 fi
 
+# Auto-create .memory/ and ensure .gitignore entries (idempotent after first run)
+SCRIPT_DIR_EARLY="$(cd "$(dirname "$0")" && pwd)"
+source "$SCRIPT_DIR_EARLY/ensure-memory-gitignore.sh" "$CWD" || exit 0
+
 # Logging (shared log file with background updater; [stop-hook] prefix distinguishes)
-MEMORY_FILE="$CWD/.docs/WORKING-MEMORY.md"
-LOG_FILE="$CWD/.docs/.working-memory-update.log"
+MEMORY_FILE="$CWD/.memory/WORKING-MEMORY.md"
+LOG_FILE="$CWD/.memory/.working-memory-update.log"
 log() { echo "[$(date -u '+%Y-%m-%dT%H:%M:%SZ')] [stop-hook] $1" >> "$LOG_FILE"; }
 
 # Throttle: skip if stop hook was triggered within the last 2 minutes
 # Uses a marker file touched BEFORE spawning the updater — prevents race condition
 # where multiple hooks see stale WORKING-MEMORY.md mtime and all bypass throttle.
-TRIGGER_MARKER="$CWD/.docs/.working-memory-last-trigger"
+TRIGGER_MARKER="$CWD/.memory/.working-memory-last-trigger"
 if [ -f "$TRIGGER_MARKER" ]; then
   if stat --version &>/dev/null 2>&1; then
     MARKER_MTIME=$(stat -c %Y "$TRIGGER_MARKER")

package/shared/skills/ambient-router/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: ambient-router
+description: >-
+  Classify user intent and response depth for ambient mode. Auto-loads relevant
+  skills without explicit command invocation. Used by /ambient command and
+  always-on UserPromptSubmit hook.
+user-invocable: false
+allowed-tools: Read, Grep, Glob
+---
+
+# Ambient Router
+
+Classify user intent and auto-load relevant skills. Zero overhead for simple requests, skill injection for substantive work, workflow nudges for complex tasks.
+
+## Iron Law
+
+> **PROPORTIONAL RESPONSE**
+>
+> Match effort to intent. Never apply heavyweight processes to lightweight requests.
+> A chat question gets zero overhead. A 3-file feature gets 2-3 skills. A system
+> refactor gets a nudge toward `/implement`. Misclassification in either direction
+> is a failure.
+
+---
+
+## Step 1: Classify Intent
+
+Determine what the user is trying to do from their prompt.
+
+| Intent | Signal Words / Patterns | Examples |
+|--------|------------------------|---------|
+| **BUILD** | "add", "create", "implement", "build", "write", "make" | "add a login form", "create an API endpoint" |
+| **DEBUG** | "fix", "bug", "broken", "failing", "error", "why does" | "fix the auth error", "why is this test failing" |
+| **REVIEW** | "check", "look at", "review", "is this ok", "any issues" | "check this function", "any issues with this?" |
+| **PLAN** | "how should", "design", "architecture", "approach", "strategy" | "how should I structure auth?", "what's the approach for caching?" |
+| **EXPLORE** | "what is", "where is", "find", "show me", "explain", "how does" | "where is the config?", "explain this function" |
+| **CHAT** | greetings, meta-questions, confirmations, short responses | "thanks", "yes", "what can you do?" |
+
+**Ambiguous prompts:** Default to the lowest-overhead classification. "Update the README" → BUILD/STANDARD. Git operations like "commit this" → QUICK.
+
+## Step 2: Classify Depth
+
+Determine how much enforcement the prompt warrants.
+
+| Depth | Criteria | Action |
+|-------|----------|--------|
+| **QUICK** | CHAT intent. EXPLORE with no analytical depth ("where is X?"). Git/devops operations (commit, push, merge, branch, pr, deploy, reinstall). Single-word continuations. | Respond normally. Zero overhead. Do not state classification. |
+| **STANDARD** | BUILD/DEBUG/REVIEW/PLAN intent (any word count). EXPLORE with analytical depth ("analyze our X", "discuss how Y works"). | Read and apply 2-3 relevant skills from the selection matrix below. State classification briefly. |
+| **ESCALATE** | Multi-file architectural change, system-wide scope, > 5 files. Detailed implementation plan (100+ words with plan structure). | Respond at best effort + recommend: "This looks like it would benefit from `/implement` for full lifecycle management." |
+
+## Step 3: Select Skills (STANDARD depth only)
+
+Based on classified intent, read the following skills to inform your response.
+
+| Intent | Primary Skills | Secondary (if file type matches) |
+|--------|---------------|----------------------------------|
+| **BUILD** | test-driven-development, implementation-patterns | typescript (.ts), react (.tsx/.jsx), frontend-design (CSS/UI), input-validation (forms/API), security-patterns (auth/crypto) |
+| **DEBUG** | test-patterns, core-patterns | git-safety (if git operations involved) |
+| **REVIEW** | self-review, core-patterns | test-patterns |
+| **PLAN** | implementation-patterns | core-patterns |
+
+**Excluded from ambient** (review-command-only): review-methodology, complexity-patterns, consistency-patterns, database-patterns, dependencies-patterns, documentation-patterns, regression-patterns, architecture-patterns, accessibility.
+
+See `references/skill-catalog.md` for the full skill-to-intent mapping with file pattern triggers.
+
+## Step 4: Apply
+
+- **QUICK:** Respond directly. No preamble, no classification statement.
+- **STANDARD:** State classification briefly: `Ambient: BUILD/STANDARD. Loading: test-driven-development, implementation-patterns.` Then read the selected skills and apply their patterns to your response. For BUILD intent, enforce RED-GREEN-REFACTOR from test-driven-development.
+- **ESCALATE:** Respond with your best effort, then append: `> This task spans multiple files/systems. Consider \`/implement\` for full lifecycle (exploration → planning → implementation → review).`
+
+---
+
+## Transparency Rules
+
+1. **QUICK → silent.** No classification output.
+2. **STANDARD → brief statement.** One line: intent, depth, skills loaded.
+3. **ESCALATE → recommendation.** Best-effort response + workflow nudge.
+4. **Never lie about classification.** If uncertain, say so.
+5. **Never over-classify.** When in doubt, go one tier lower.
+
+## Edge Cases
+
+| Case | Handling |
+|------|----------|
+| Mixed intent ("fix this bug and add a test") | Use the higher-overhead intent (BUILD > DEBUG) |
+| Continuation of previous conversation | Inherit previous classification unless prompt clearly shifts |
+| User explicitly requests no enforcement | Respect immediately — classify as QUICK |
+| Prompt references specific DevFlow command | Skip ambient — the command has its own orchestration |

package/shared/skills/ambient-router/references/skill-catalog.md

@@ -0,0 +1,64 @@
+# Ambient Router — Skill Catalog
+
+Full mapping of DevFlow skills to ambient intents and file-type triggers. The ambient-router SKILL.md references this for detailed selection logic.
+
+## Skills Available for Ambient Loading
+
+These skills may be loaded during STANDARD-depth ambient routing.
+
+### BUILD Intent
+
+| Skill | When to Load | File Patterns |
+|-------|-------------|---------------|
+| test-driven-development | Always for BUILD | `*.ts`, `*.tsx`, `*.js`, `*.jsx`, `*.py` |
+| implementation-patterns | Always for BUILD | Any code file |
+| typescript | TypeScript files in scope | `*.ts`, `*.tsx` |
+| react | React components in scope | `*.tsx`, `*.jsx` |
+| frontend-design | UI/styling work | `*.css`, `*.scss`, `*.tsx` with styling keywords |
+| input-validation | Forms, APIs, user input | Files with form/input/validation keywords |
+| security-patterns | Auth, crypto, secrets | Files with auth/token/crypto/password keywords |
+
+### DEBUG Intent
+
+| Skill | When to Load | File Patterns |
+|-------|-------------|---------------|
+| test-patterns | Always for DEBUG | Any test-related context |
+| core-patterns | Always for DEBUG | Any code file |
+| git-safety | Git operations involved | User mentions git, rebase, merge, etc. |
+
+### REVIEW Intent
+
+| Skill | When to Load | File Patterns |
+|-------|-------------|---------------|
+| self-review | Always for REVIEW | Any code file |
+| core-patterns | Always for REVIEW | Any code file |
+| test-patterns | Test files in scope | `*.test.*`, `*.spec.*` |
+
+### PLAN Intent
+
+| Skill | When to Load | File Patterns |
+|-------|-------------|---------------|
+| implementation-patterns | Always for PLAN | Any planning context |
+| core-patterns | Architectural planning | System design discussions |
+
+## Skills Excluded from Ambient
+
+These skills are loaded only by explicit DevFlow commands (primarily `/code-review`):
+
+- review-methodology — Full review process (6-step, 3-category classification)
+- complexity-patterns — Cyclomatic complexity, deep nesting analysis
+- consistency-patterns — Naming convention, pattern deviation detection
+- database-patterns — Index analysis, query optimization, migration safety
+- dependencies-patterns — CVE detection, license audit, outdated packages
+- documentation-patterns — Doc drift, stale comments, missing API docs
+- regression-patterns — Lost functionality, broken exports, behavioral changes
+- architecture-patterns — SOLID analysis, coupling detection, layering issues
+- accessibility — WCAG compliance, ARIA roles, keyboard navigation
+- performance-patterns — N+1 queries, memory leaks, caching opportunities
+
+## Selection Limits
+
+- **Maximum 3 skills** per ambient response (primary + up to 2 secondary)
+- **Primary skills** are always loaded for the classified intent
+- **Secondary skills** are loaded only when file patterns match conversation context
+- If more than 3 skills seem relevant, this is an ESCALATE signal

package/shared/skills/docs-framework/SKILL.md

@@ -32,10 +32,14 @@ All generated documentation lives under `.docs/` in the project root:
 │   ├── {timestamp}.md
 │   ├── compact/{timestamp}.md
 │   └── INDEX.md
-├── swarm/                              # Swarm operation state
-│   ├── state.json
-│   └── plans/
-└── WORKING-MEMORY.md                   # Auto-maintained by Stop hook (overwritten)
+└── swarm/                              # Swarm operation state
+    ├── state.json
+    └── plans/
+
+.memory/
+├── WORKING-MEMORY.md                   # Auto-maintained by Stop hook (overwritten)
+├── PROJECT-PATTERNS.md                 # Accumulated patterns (merged across sessions)
+└── backup.json                         # Pre-compact git state snapshot
 ```
 
 ---
@@ -92,7 +96,7 @@ source .devflow/scripts/docs-helpers.sh 2>/dev/null || {
 | Agent | Output Location | Behavior |
 |-------|-----------------|----------|
 | Reviewer | `.docs/reviews/{branch-slug}/{type}-report.{timestamp}.md` | Creates new |
-| Working Memory | `.docs/WORKING-MEMORY.md` | Overwrites (auto-maintained by Stop hook) |
+| Working Memory | `.memory/WORKING-MEMORY.md` | Overwrites (auto-maintained by Stop hook) |
 
 ### Agents That Don't Persist
 
@@ -120,7 +124,7 @@ When creating or modifying persisting agents:
 
 This framework is used by:
 - **Review agents**: Creates review reports
-- **Working Memory hooks**: Auto-maintains `.docs/WORKING-MEMORY.md`
+- **Working Memory hooks**: Auto-maintains `.memory/WORKING-MEMORY.md`
 
 All persisting agents should load this skill to ensure consistent documentation.
 

package/shared/skills/test-driven-development/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: test-driven-development
+description: >-
+  Enforce RED-GREEN-REFACTOR cycle during implementation. Write failing tests before
+  production code. Distinct from test-patterns (which reviews test quality) — this
+  skill enforces the TDD workflow during code generation.
+user-invocable: false
+allowed-tools: Read, Grep, Glob
+activation:
+  file-patterns:
+    - "**/*.ts"
+    - "**/*.tsx"
+    - "**/*.js"
+    - "**/*.jsx"
+    - "**/*.py"
+  exclude:
+    - "node_modules/**"
+    - "dist/**"
+    - "**/*.test.*"
+    - "**/*.spec.*"
+---
+
+# Test-Driven Development
+
+Enforce the RED-GREEN-REFACTOR cycle for all implementation work. Tests define the design. Code satisfies the tests. Refactoring improves the design without changing behavior.
+
+## Iron Law
+
+> **TESTS FIRST, ALWAYS**
+>
+> Write the failing test before the production code. No exceptions. If you catch
+> yourself writing production code without a failing test, stop immediately, delete
+> the production code, write the test, watch it fail, then write the minimum code
+> to make it pass. The test IS the specification.
+
+---
+
+## The Cycle
+
+### Step 1: RED — Write a Failing Test
+
+Write a test that describes the behavior you want. Run it. Watch it fail. The failure message IS your specification.
+
+```
+Describe what the code SHOULD do, not how it does it.
+One behavior per test. One assertion per test (ideally).
+Name tests as sentences: "returns error when email is invalid"
+```
+
+**Checkpoint:** The test MUST fail before proceeding. A test that passes immediately proves nothing.
+
+### Step 2: GREEN — Write Minimum Code to Pass
+
+Write the simplest production code that makes the failing test pass. No more, no less.
+
+```
+Hardcode first if that's simplest. Generalize when the next test forces it.
+Don't write code "you'll need later." Write code the test demands NOW.
+Don't optimize. Don't refactor. Don't clean up. Just pass the test.
+```
+
+**Checkpoint:** All tests pass. If any test fails, fix it before moving on.
+
+### Step 3: REFACTOR — Improve Without Changing Behavior
+
+Now clean up. Extract helpers, rename variables, simplify logic. Tests stay green throughout.
+
+```
+Run tests after every refactoring step.
+If a test breaks during refactor, undo immediately — you changed behavior.
+Apply DRY, extract patterns, improve readability.
+```
+
+**Checkpoint:** All tests still pass. Code is clean. Repeat from Step 1 for next behavior.
+
+---
+
+## Rationalization Prevention
+
+These are the excuses developers use to skip TDD. Recognize and reject them.
+
+| Excuse | Why It Feels Right | Why It's Wrong | Correct Action |
+|--------|-------------------|---------------|----------------|
+| "I'll write tests after" | Need to see the shape first | Tests ARE the shape — they define the interface before implementation exists | Write the test first |
+| "Too simple to test" | It's just a getter/setter | Getters break, defaults change, edge cases hide in "simple" code | Write it — takes 30 seconds |
+| "I'll refactor later" | Just get it working now | "Later" never comes; technical debt compounds silently | Refactor now in Step 3 |
+| "Test is too hard to write" | Setup is complex, mocking is painful | Hard-to-test code = bad design; the test is telling you the interface is wrong | Simplify the interface first |
+| "Need to see the whole picture" | Can't test what I haven't designed yet | TDD IS design; each test reveals the next piece of the interface | Let the test guide the design |
+| "Tests slow me down" | Faster to just write the code | Faster until the first regression; TDD is faster for anything > 50 lines | Trust the cycle |
+
+See `references/rationalization-prevention.md` for extended examples with code.
+
+---
+
+## Process Enforcement
+
+When implementing any feature under ambient BUILD/STANDARD:
+
+1. **Identify the first behavior** — What is the simplest thing this feature must do?
+2. **Write the test** — Describe that behavior as a failing test
+3. **Run the test** — Confirm it fails (RED)
+4. **Write minimum code** — Just enough to pass (GREEN)
+5. **Refactor** — Clean up while tests stay green (REFACTOR)
+6. **Repeat** — Next behavior, next test, next cycle
+
+### File Organization
+
+- Test file lives next to production file: `user.ts` → `user.test.ts`
+- Follow project's existing test conventions (Jest, Vitest, pytest, etc.)
+- Import the module under test, not internal helpers
+
+### What to Test
+
+| Test | Don't Test |
+|------|-----------|
+| Public API behavior | Private implementation details |
+| Error conditions and edge cases | Framework internals |
+| Integration points (boundaries) | Third-party library correctness |
+| State transitions | Getter/setter plumbing (unless non-trivial) |
+
+---
+
+## When TDD Does Not Apply
+
+- **QUICK depth** — Ambient classified as QUICK (chat, exploration, trivial edits)
+- **Non-code tasks** — Documentation, configuration, CI changes
+- **Exploratory prototyping** — User explicitly says "just spike this" or "prototype"
+- **Existing test suite changes** — Modifying tests themselves (test-patterns skill applies instead)
+
+When skipping TDD, never rationalize. State clearly: "Skipping TDD because: [specific reason from list above]."
+
+---
+
+## Integration with Ambient Mode
+
+- **BUILD/STANDARD** → TDD enforced. Every new function/method gets test-first treatment.
+- **BUILD/QUICK** → TDD skipped (trivial single-file edit).
+- **BUILD/ESCALATE** → TDD mentioned in nudge toward `/implement`.
+- **DEBUG/STANDARD** → TDD applies to the fix: write a test that reproduces the bug first, then fix.

package/shared/skills/test-driven-development/references/rationalization-prevention.md

@@ -0,0 +1,111 @@
+# TDD Rationalization Prevention — Extended Examples
+
+Detailed code examples showing how each rationalization leads to worse outcomes.
+
+## "I'll write tests after"
+
+### What happens:
+
+```typescript
+// Developer writes production code first
+function calculateDiscount(price: number, tier: string): number {
+  if (tier === 'gold') return price * 0.8;
+  if (tier === 'silver') return price * 0.9;
+  return price;
+}
+
+// Then "writes tests after" — but only for the happy path they remember
+test('gold tier gets 20% off', () => {
+  expect(calculateDiscount(100, 'gold')).toBe(80);
+});
+// Missing: negative prices, unknown tiers, zero prices, NaN handling
+```
+
+### What TDD would have caught:
+
+```typescript
+// Test first — forces you to think about the contract
+test('returns error for negative price', () => {
+  expect(calculateDiscount(-100, 'gold')).toEqual({ ok: false, error: 'NEGATIVE_PRICE' });
+});
+// Now the interface includes error handling from the start
+```
+
+## "Too simple to test"
+
+### What happens:
+
+```typescript
+// "It's just a config getter, no test needed"
+function getMaxRetries(): number {
+  return parseInt(process.env.MAX_RETRIES || '3');
+}
+// 6 months later: someone sets MAX_RETRIES="three" and prod crashes with NaN retries
+```
+
+### What TDD would have caught:
+
+```typescript
+test('returns default when env var is not a number', () => {
+  process.env.MAX_RETRIES = 'three';
+  expect(getMaxRetries()).toBe(3); // Forces validation logic
+});
+```
+
+## "Test is too hard to write"
+
+### What happens:
+
+```typescript
+// "I can't test this easily because it needs database + email + filesystem"
+async function processOrder(orderId: string) {
+  const db = new Database();
+  const order = await db.find(orderId);
+  await sendEmail(order.customerEmail, 'Your order is processing');
+  await fs.writeFile(`/invoices/${orderId}.pdf`, generateInvoice(order));
+  await db.update(orderId, { status: 'processing' });
+}
+// Result: untestable monolith, test would need real DB + email + filesystem
+```
+
+### What TDD forces:
+
+```typescript
+// Hard-to-test = bad design. TDD forces dependency injection:
+async function processOrder(
+  orderId: string,
+  deps: { db: OrderRepository; emailer: Emailer; invoices: InvoiceStore }
+): Promise<Result<void, OrderError>> {
+  // Now trivially testable with mocks
+}
+```
+
+## "I'll refactor later"
+
+### What happens:
+
+```typescript
+// Sprint 1: "just get it working"
+function handleRequest(req: any) {
+  if (req.type === 'create') { /* 50 lines */ }
+  else if (req.type === 'update') { /* 50 lines */ }
+  else if (req.type === 'delete') { /* 30 lines */ }
+  // Sprint 2-10: more conditions added, function grows to 500 lines
+  // "Refactor later" never comes because nobody wants to touch it
+}
+```
+
+### What TDD enforces:
+
+Step 3 (REFACTOR) happens every cycle. The function never grows beyond what's clean because you clean it every 5-10 minutes.
+
+## "Tests slow me down"
+
+### The math:
+
+| Approach | Time to write | Time to first bug | Time to fix bug | Total (1 month) |
+|----------|:---:|:---:|:---:|:---:|
+| No TDD | 2h | 4h | 3h (no repro test) | 9h+ |
+| TDD | 3h | Caught in test | 15min (test pinpoints) | 3h 15min |
+
+TDD is slower for the first 30 minutes. It's faster for everything after that.

package/src/templates/managed-settings.json

@@ -5,6 +5,15 @@
       "Bash(rm -rf ~*)",
       "Bash(rm -rf .*)",
       "Bash(* rm -rf /*)",
+      "Bash(rm -r /*)",
+      "Bash(rm -r ~*)",
+      "Bash(rm -r .*)",
+      "Bash(rm -fr /*)",
+      "Bash(rm -fr ~*)",
+      "Bash(rm -fr .*)",
+      "Bash(rm -f /*)",
+      "Bash(rm -f ~*)",
+      "Bash(rm -f .*)",
       "Bash(dd if=*)",
       "Bash(dd*of=/dev/*)",
       "Bash(mkfs*)",
@@ -85,12 +94,17 @@
       "Bash(crontab*)",
       "Bash(rm /var/log*)",
       "Bash(rm -rf /var/log*)",
+      "Bash(rm -r /var/log*)",
+      "Bash(rm -f /var/log*)",
+      "Bash(rm -fr /var/log*)",
       "Bash(> /var/log*)",
       "Bash(truncate /var/log*)",
       "Bash(history -c*)",
       "Bash(history -w*)",
       "Bash(rm ~/.bash_history*)",
+      "Bash(rm -f ~/.bash_history*)",
       "Bash(rm ~/.zsh_history*)",
+      "Bash(rm -f ~/.zsh_history*)",
       "Bash(unset HISTFILE*)",
       "Bash(curl 169.254.169.254*)",
       "Bash(wget 169.254.169.254*)",