From 301322a6b0055a0cecdee0bb793bafded76a4727 Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Wed, 6 May 2026 22:28:25 +0200 Subject: [PATCH] promote no-pre-existing-excuse to a CLAUDE.md guardrail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Memory-only "if you encounter a failure, fix it first" advice keeps losing to the model's default scope-protection behaviour: when a test is red or analyze warns on entry, the safer-feeling option is to flag and continue rather than fix and continue. Promoting the rule into the load-bearing guardrails list makes it sit in the same register as "Flutter desktop is the host" — non-negotiable, not advisory. Pairs with the .githooks/pre-push gate landed alongside: that prevents broken state from being pushed in the first place; this prevents the next session from building on broken state if it slips through. Co-Authored-By: Claude --- .pql/pql-plan.json | 2 +- CLAUDE.md | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/.pql/pql-plan.json b/.pql/pql-plan.json index 300d3646..4753ca6b 100644 --- a/.pql/pql-plan.json +++ b/.pql/pql-plan.json @@ -1,5 +1,5 @@ { - "exported_at": "2026-05-06T20:28:15Z", + "exported_at": "2026-05-06T20:28:25Z", "decisions": [ { "id": "D-1", diff --git a/CLAUDE.md b/CLAUDE.md index 67fa93f6..d649b5fe 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -28,6 +28,7 @@ These are load-bearing. Violating any means the design is wrong, not the rule. - **Repo-is-the-workspace.** The git repo root is the workspace — no parallel "vault" concept. - **Ignore discipline.** Single knob: `ignore_files:` in `.pql/config.yaml`, ordered layering. See [`D-4`](decisions/architecture.md#d-4-ignore-file-strategy). - **Decision discipline.** All architectural choices live in `decisions/.md` as `D-NNN` records. Open questions as `Q-NNN`. Rejected alternatives as `R-NNN`. Claim new IDs via `pql decisions claim D "title"`. See [`decisions/README.md`](decisions/README.md). +- **No pre-existing excuse.** Solo-dev repo — every failure encountered is yours to fix, regardless of who introduced it. If `make test` is red, a golden is broken, or `flutter analyze` shows a warning when you start working, the order is: **fix it first, then your work**. If you genuinely can't fix it in scope (separate ticket, large sweep, missing context), stop and surface it before continuing — don't push on top of broken state. "It was already broken" is not a reason to add more on top. ## Repo layout