AI review without memory is just expensive déjà vu

AI tools forget context, can’t carry accountability, and repeat the same mistakes. That’s annoying when you ask them for an implementation plan. The sixth /replan on the same kind of routine still flags the same generic things and still misses the one rule that only matters in your project — that refund flows must read through db.replica, not db.primary. By the sixth time you’re either adding it to the plan by hand or letting it die in /recheck.

/replan v1.3 changes that. And it isn’t because the model got smarter. It’s because cheap layers were added around it that carry project context between turns.

Three things v1.2 added — and what v1.3 piled on top

Rules. claude-security-guidance.md is a shared config file. You write the things no generic model can know: that webhooks are verified via stripe.Webhook.construct_event and never manual HMAC, that SELECTs against customers go through replica, that the SSRF allowlist lives in acme.net.safe_request. The runtime plugin security-guidance reads it on every code edit, and /replan and /recheck read it in their reviews. One source of truth, read by all.

Memory. lessons.md is something the plugin gradually fills from /recheck. When /recheck finds a real slip, it asks whether you want to keep it as a lesson. If you say yes (or edit), it’s stored. The next /replan in the same project injects that file into each subagent’s prompt — explicitly framed as data, not instructions. Soft cap 4 KB. What you taught the plugin last week still holds today.

Audit trail. Every /replan and /recheck writes a record to docs/replan/audit/. Plan hash, model, agents, findings, outcome. /recheck writes it in two phases: findings at synthesis time, outcome appended after your decisions. The result: a verifiable on-disk history of who reviewed what — and in what order.

How the three plugins compose:

1. docu-optimizer scaffold security generates claude-security-guidance.md from a codebase scan. Stack-gated (Python / Node / Go / Ruby / Rust / Java), monorepo-aware.
2. security-guidance enforces it at runtime — regex pass on each Edit / Write, LLM diff review on Stop, agentic review across files on git commit.
3. /replan and /recheck Security agents detect that security-guidance is running and shift to complementary review. They don’t repeat the regex rules. They focus on what runtime checks can’t see — cross-file semantics, plan-context, places where the reviewer needs the intent of the plan, not just the resulting diff.

A concrete scenario: refund endpoint

One example to anchor the next five minutes. An e-commerce shop on Python, Stripe for payments, PostgreSQL with a read replica, Redis as queue. You want to add a refund endpoint — user clicks “request refund” in their account, the system checks policy, refunds via Stripe, records it in the ledger.

Day 1 — project rules

First move:

/docu-optimizer scaffold security

The command walks the codebase, finds DB calls, outbound HTTP, auth flows, deserialization, background jobs. Out drops a claude-security-guidance.md with rules only your project knows:

# Rules for [project]

- All SELECTs against `orders`, `customers`, `payment_history`
  MUST go through `db.replica`. `db.primary` is for writes only.
- Stripe webhooks are verified via `stripe.Webhook.construct_event`,
  not manual HMAC comparison.
- `requests.get(url)` with a user-controlled URL needs the SSRF
  allowlist wrapper from `lib.net.safe_request`.
- Background jobs in `jobs/` must not use a user session token;
  service-account credentials from `jobs.get_service_account()`.
- Refunds have a daily reconciliation script in `cron/reconcile.py`.
  Any API change must pass current scope through `--allow-stale-window 24h`.

Five concrete rules no universal security model knows. You commit the file into <project>/.claude/.

Day 2 — /replan for the refund endpoint

You write a plan: four steps, the model puts up the endpoint, validates the policy, calls Stripe, records. You run /replan. Five parallel agents. A minute later:

Critical: Plan reads orders via db.primary in Task 2.
          Project rule: orders MUST go through db.replica.
Critical: Task 3 calls stripe.Refund.create directly. No reconciliation
          hook into cron/reconcile.py. Will silently drift after 24h.
Important: refund_amount is parsed as float. PostgreSQL column is
          numeric(12,2). Use Decimal end-to-end.
Important: No idempotency key on stripe.Refund.create. Double-click on
          UI = double refund.

→ Plan updated with all findings.

The first two are findings that surfaced from the project rule. The other two are generic — Decimal vs float, idempotency. None of these is rocket science. None of these would land in a plan you wrote at 4am, either.

Day 5 — /recheck after implementation

Three days of coding against the updated plan. You merge. You run /recheck. Among the findings:

Important: refund_amount in receipts_email_template.py still uses
           float formatting. Decimal lost between API and email layer.

A small slip but a real one. You’d have shrugged past it in a manual review.

/recheck asks: Want to capture this as a lesson in lessons.md?

You write:

Refund amounts must stay Decimal end-to-end, including email templates.

Saved. The file is now one line longer.

One more thing on day 5: in v1.3 (Step 3b) /recheck also runs a full /code-review high pass when the diff contains real code changes. This isn’t a subagent — it’s the built-in /code-review skill invoked directly, with its own parallel agent fan-out intact. Its findings get synthesized against what the regular agents already surfaced, deduplicated, and folded into the same disposition. Trivial single-file edits and docs-only commits skip the pass — the reason is recorded in the audit record (code_review_pass.reason_skipped). The deep pass runs under the session model, so it’s worth running /recheck under a strong model (opus) when the deep pass matters.

Day 14 — the next refund-shaped plan

Two weeks later you’re adding a related routine: partial refund of a single line item in an order. You run /replan. The plan goes through the same five agents.

This time the Security agent also gets lessons.md in its prompt. Among the findings:

Critical: Plan formats refund_amount as float in API response
          in Task 4. Project lesson: refund amounts must stay
          Decimal end-to-end, including UI/email layers.

That’s the difference between generic review and review that knows your project. The plugin itself didn’t get smarter. Your project taught it.

Audit trail: small record, large value

After five days, docs/replan/audit/ looks like this:

audit/
  2026-05-21-replan-a3f9c1e.json
  2026-05-21-recheck-a3f9c1e.json
  2026-05-24-recheck-a3f9c1e.json

a3f9c1e is the plan hash (content-addressed). Same plan → same hash. That means /replan and /recheck pair to each other across days. A record looks roughly like this:

{
  "run_id": "2026-05-21-replan-a3f9c1e",
  "timestamp": "2026-05-21T09:14:22+02:00",
  "model": "claude-opus-4-7",
  "plan_hash": "a3f9c1e",
  "agents": ["codebase", "best-practices", "security", "fresh-perspective"],
  "findings": [
    { "severity": "critical", "agent": "security",
      "msg": "Plan reads orders via db.primary..." },
    ...
  ],
  "outcome": "plan_updated"
}

When your boss asks why the agent recommended splitting the refund endpoint into two steps, you have an answer. Plan, model, agents, finding with timestamp. It is not a compliance certification. It is an operational trace that nobody had until now.

For people dealing with the EU AI Act or internal governance: an operational trace is a precondition for auditability. Not an automatic, but the substrate.

What’s new if you already have the plugins

For existing /replan users on 1.1 or 1.2, the compact changelog through 1.3.1:

• Audit trail in docs/replan/audit/ (1.2.0) — fully opt-in via ${REPLAN_AUDIT_DIR}, defaults committable.
• Plan hash + plan_lineage (1.2.0) — /recheck finds its paired /replan automatically.
• lessons.md injection (1.2.0) — sanitized as data, soft cap 4 KB. Autonomous mode writes to lessons.proposed.md (quarantine).
• security-guidance awareness (1.2.0) — Security agent shifts to complement when the plugin is running. Detection through directory glob → log activity → env override.
• claude-security-guidance.md (1.2.0) — /replan and /recheck read the same files in the same locations (user / project / local), 8 KB cap, same truncation order.
• Per-skill model override (1.2.0, defaults changed in 1.2.1) — --model <id> or REPLAN_MODEL / RECHECK_MODEL env. Defaults are now version-agnostic aliases opus (/replan) and sonnet (/recheck) — Claude Code resolves them to the current generation, so defaults don’t go stale as new models ship. Pinned IDs and provider-specific forms (Bedrock / Vertex) are still accepted as explicit overrides.
• Deep code-review pass in /recheck (1.3.0) — on real code changes, /recheck runs a full /code-review high pass through the built-in skill (with its own parallel agent fan-out). Trivial single-file edits and docs-only commits skip — reason lands in the audit record (code_review_pass.reason_skipped).
• 1.3.1 hardening — /code-review no longer fires on a clean working tree (the common “commit, then /recheck” flow), schema extended with code_review_pass.reason_skipped (no-working-diff, skill-unavailable).
• Canonical audit schema at plugin/AUDIT_SCHEMA.md.

To update:

claude plugin marketplace update claude-replan
claude plugin update replan@claude-replan

For docu-optimizer v2.1:

• scaffold security target — new.
• Phase 1 ecosystem scan records claude-security-guidance.md at all three levels plus kill switches.
• Subagent E recommends scaffold when the plugin is installed and the project lacks rules.

What to do this week

1. Install (or update) all three. The claude-plugins-official marketplace for security-guidance, kojott/claude-docu-optimizer and kojott/claude-replan for the rest. Five minutes.

2. Scaffold the rules. Inside your project:

/docu-optimizer scaffold security --apply

It walks the codebase, drops <project>/.claude/claude-security-guidance.md. Review and commit.

3. First /replan on something non-trivial. Not a tutorial todo. Write a plan for something you’re actually working on right now and compare findings before tweaking the rules and after. That will tell you whether the scaffold fits.

4. After the first /recheck, accept the first lesson. When the review surfaces a real slip and asks “capture as a lesson?”, don’t auto-click yes. Rewrite the lesson so it generalizes past the specific bug. “Use Decimal in refunds” is more useful than “in refund_handler.py line 47 there was a float”.

If you have a team and want help wiring this onto your actual project — security rules, review loop, audit conventions — 1:1 AI mentoring is the right shape. We walk your workflow on your real repo, not on slides.

If your team is handling AI governance across multiple projects and needs the operational trace anchored in internal processes, an AI audit fits better. In 55 minutes we pick one integration, measure risk, and define the first step.

— Jirka

You might also like

• Why I never read the first plan from Claude Code
• 5 tools I built for Claude Code
• Claude Code /goal: Set the goal, grab a coffee, come back, it’s done
• Shift+Tab is a trap: Why your AI plan ignores half your codebase