fable

name	fable
description	Use at the START of any coding task (feature, bugfix, refactor, review, integration) and RETURN to between phases — ranked observable triggers that route to the Fable procedure gates. If a trigger below matches what you are about to do, read the named file BEFORE doing it.

Fable router

How to use this file: read it at task start, act only after checking your plan against the trigger list, and return to it at every phase boundary (plan→code, code→green, green→handoff). Triggers are ranked by how much quality is lost when missed — Tier 1 misses break production invisibly; Tier 3 misses cost polish. When in doubt whether a trigger fired, it fired.

Always-on laws (no routing; violating any of these invalidates the work)

1. Never edit a file you haven't fully read this session. Memory, diffs, greps, and docs are claims, not file state.
2. Green tests are the START of the audit, not the end of the task.
3. Scope is one sentence plus an exclusion list with reasons, written before code. Adjacent fixes become named follow-ups, never diff ridealongs.
4. Label all evidence EXECUTED (ran it this session) or TRACED (reasoned only). A mock you authored is TRACED evidence about the real system.
5. Every finding, exclusion, and UNVERIFIED flag reaches the final report with file:line, or it never happened.

TIER 1 — miss these and production breaks invisibly

T1.1 — Two facts about the code contradict each other (a value that shouldn't validate but does, a field written twice with different values, a constraint the code seems to violate). STOP EDITING → execution-loop.md §2. Cost of miss: "fixing" a load-bearing workaround (e.g. a DB-constraint placeholder) and breaking prod writes.

T1.2 — Your next typed token is a URL path, query/body param, header name or value, library option key, config key, CLI flag, version number, quota, or an import you haven't used this session → grounding-gate.md. Also fires when: you're about to claim an integration works and every test used a mock you wrote. Cost of miss: invented API surface — compiles, passes local tests, fails only in production.

T1.3 — The task verb is a metaphor (retry, sync, duplicate, restore, share, migrate), OR you cannot list the server's error responses, OR the feature touches anything consumed (quota, credits, uploads, slots), OR the new row carries a group key (batch_id/thread_id/parent_id), OR a branch in your plan references a field you haven't confirmed exists → contract-gate.md. Cost of miss: the feature is built to the wrong contract — double-charged quotas, corrupted group numbering, branches on prose.

T1.4 — You are about to add a fix at the place a symptom APPEARS (a render-time dedupe, an index key, a swallowed warning, a defensive null-check where the crash was) → debug-protocol.md §4-5 first. Cost of miss: the bug becomes invisible instead of fixed — negative value, because it also stops being findable.

TIER 2 — miss these and real bugs ship

T2.1 — All checks just went green and you feel done / are about to write the summary, commit, or a quality claim → self-audit.md. Run the passes; exit enumeration and boundary EXECUTION are mandatory even when rushed. Cost of miss (measured): a claimed 10/10 audited to 7.5 with one real boundary bug.

T2.2 — You are investigating any failure, test flake, or user-reported symptom — especially if the word "sometimes" appears → debug-protocol.md from §1. No edit before the written writer-list.

T2.3 — You are about to restructure working code ("clean up", "simplify", "reorganize", "extract"), or a diff hunk you wrote reorders conditionals or converts sequential awaits to Promise.all or swaps ||/?? → refactor-proof.md. Cost of miss (measured): a tidy-looking reorder changed user-visible output on 47% of the input domain while the full unit suite stayed green.

T2.4 — You are about to re-run a variant of something that just failed → stop-tripwire.md. Also fires when: you just weakened a test/assertion/timeout without announcing it; your fix exists to make a previous fix work; you caught a false success and kept going. Cost of miss: compounding doubled-down attempts that the eventual re-plan must also back out.

T2.5 — A verification check fails in code your diff does not touch → execution-loop.md §5: prove pre-existence (stash → re-run → restore), never fix out-of-scope, never silently skip the check.

TIER 3 — miss these and quality/velocity degrade

T3.1 — You are about to write code into an existing file, or create a file in a directory with siblings of its kind, or the feature verb feels like it "should" already exist → house-style.md. Grep the verb first — the cheapest outcome is finding it done.

T3.2 — You are designing a new function signature, or deciding how hardened code must be → quality-ladder.md. Signatures get designed for 10 even when bodies build to 8.

T3.3 — You are about to review a diff (yours or anyone's) → defect-triggers.md. Run the trigger list against the diff, not the taxonomy against the file.

T3.4 — You are writing tests, or just wrote branchy/parsing logic in a lib → test-writing.md. The throw-hunt and boundary triplets are mechanical; run them.

T3.5 — A failed exact-match edit ("string not found") → re-grep the file's CURRENT state before retrying; never rebuild the edit from the mental image that just failed. (Inline rule — no file needed.)

Phase checkpoints (return here at each)

• Task start: read execution-loop.md §1 (plus your own operator profile, if you keep one locally). Sweep Tier 1 triggers against the task description — T1.3's metaphor-verb check takes ten seconds and reshapes everything downstream.
• Before each code block: T1.2 fires per boundary token; T3.1/T3.2 fire per new file/function.
• First green: T2.1 is unconditional. Do not negotiate with it.
• Before handoff: T3.3 against the final diff; confirm law 5 (all flags in report); deploy checklist if your project has manual deploy steps.

Residual risk

These triggers work only when checked; in-flight noticing does not transfer as words. Compensate mechanically: the four checkpoints above are the sweep schedule — run them even when nothing feels wrong, ESPECIALLY when nothing feels wrong (confidence is what the audit exists to check). When a gate seems wrong for your edge case, it is compressed evidence you can't see — follow it or escalate; never silently override. Full evidence: references/ inside this skill folder.