/no-no-debug

name: no-no-debug
description: >
  Self-evolution system for AI coding assistants. Six integrated mechanisms:
  (1) Real-time logging of errors, corrections, and failures to error_log.md,
  (2) Silent 3-gate checkpoint before every code change, (3) periodic error review
  that scans error_log.md and updates a categorized tracker, (4) rule accumulation
  loop that adds new error types automatically and marks cured ones, (5) confirmation
  gate requiring user approval before new features, DB/env/deploy changes, external
  publishing, or new directions, (6) auto hooks configured on install for passive
  capture. Triggers on "error review", "错误追踪", "进化报告", "evolution report",
  or automatically when review interval has elapsed.
user-invocable: true

no-no-debug — Self-Evolution System for AI Coding Assistants

Overview

Six mechanisms work together to eliminate repeated mistakes permanently:

• **Mechanism 1**: Real-time logging — errors, corrections, and failures auto-appended to `~/.claude/memory/error_log.md`
• **Mechanism 2**: Silent 3-gate checkpoint before every code change (no output when all clear)
• **Mechanism 3**: Periodic review that reads error_log.md, classifies errors, updates a persistent tracker
• **Mechanism 4**: Rule accumulation — new error types auto-added, repeat offenses strengthen gates, 4 clean periods = cured
• **Mechanism 5**: Confirmation gate — must ask user before new features, DB/env/deploy changes, external publishing, or new directions
• **Mechanism 6**: Auto hooks — passive capture configured at install time

---

Configuration

| Setting | Default | Options | |---------|---------|---------| | Log file | `~/.claude/memory/error_log.md` | Any writable path | | Tracker file | `~/.claude/memory/error_tracker.md` | Any writable path | | Review frequency | 3 days | 1 / 3 / 7 days | | Language | Auto-detected | zh / en |

To change review frequency, add a comment to the top of `error_tracker.md`:

<!-- review_frequency: 1 -->

---

Mechanism 1 — Real-time Logging

**Always active. Runs passively. No user action required.**

Append a line to `~/.claude/memory/error_log.md` whenever any of the following occur:

Trigger conditions

| Event | Log type | |-------|----------| | Bash command exits with non-zero status | `BUILD_FAIL` or `RUNTIME_ERROR` | | Deploy or publish action fails | `DEPLOY_FAIL` | | Test run has failures | `TEST_FAIL` | | User corrects the AI with a second-person phrase (see Mechanism 6 for the exact pattern list) | `USER_CORRECTION` | | Same fix applied more than once | `REPEATED_FIX` | | Network or API connection times out | `CONNECTION_FAIL` | | Login or authentication fails | `AUTH_FAIL` |

Log format

[YYYY-MM-DD HH:MM] TYPE | description

Examples:

[2024-04-08 14:32] BUILD_FAIL | npm run build failed — cannot find module './utils/auth'
[2024-04-08 15:01] USER_CORRECTION | User said "wrong" — had used cached data instead of live fetch
[2024-04-08 16:45] REPEATED_FIX | Applied the same null-check fix to userProfile.ts for the second time
[2024-04-09 09:12] AUTH_FAIL | Login redirect broken after updating next.config.js

File initialization

If `~/.claude/memory/error_log.md` does not exist, create the directory and file with this header:

# Error Log
<!-- Auto-maintained by no-no-debug -->
<!-- Format: [YYYY-MM-DD HH:MM] TYPE | description -->

---

Mechanism 2 — Three-Gate Checkpoint (Silent)

**Always active. No output when all gates pass.**

Before ANY code change, file edit, configuration update, or deployment action, silently verify all three gates:

Gate 1 — Before Making the Change

• What exactly does this change affect?
• Could authentication or login break?
• Does this touch `.env`, database schema, connection strings, or credentials?
• Does this modify shared infrastructure used by other features?
• Is this a new feature or a bug fix? (If new feature → trigger Mechanism 5 first)

Gate 2 — After Making the Change

• Did I actually verify the result, or just check that a command ran without error?
• Did I verify using the **real production command string** (the exact hook/CLI/route handler users will hit), not a simplified test harness or sandbox invocation?
• Did I walk the flow as a real user would, end to end?
• Did I check the failure path, not just the success path?
• Does the output shown to the user match what is actually in the code?
• For shell/hook changes with multiple escape layers (JSON → shell → interpreter), did I run the exact string from settings.json rather than a locally-equivalent variant?

Gate 3 — Before Deploying or Publishing

• Did I test with a non-admin account?
• Is the permission table complete for all new routes and actions?
• Are all required database migrations included?
• Are there cache invalidation requirements?
• For changes reviewed by a second agent (e.g. another model, sandboxed reviewer): did I independently re-run the verification in my own environment rather than trusting the reviewer's "pass" report? A sandbox pass is not a real-environment pass.
• Does this publish to an external platform? (If yes → trigger Mechanism 5 first)

**Output rule**: Stay completely silent when all gates pass. When any gate raises a concern, surface it to the user before proceeding.

---

Mechanism 3 — Periodic Review

Auto-trigger condition

A `UserPromptSubmit` hook (`hooks/review_reminder.py`) checks `~/.claude/memory/error_tracker.md` for `Last Review Date` on each user message. If elapsed days since that date are greater than or equal to the configured review frequency (default: 3), the hook outputs a reminder. When you see this reminder, run the review automatically. A 4-hour cooldown prevents repeated reminders within the same session.

Manual trigger

User says any of: `error review`, `错误追踪`, `进化报告`, `evolution report`

Step 1 — Initialize files if missing

If `~/.claude/memory/error_log.md` does not exist, create