# RHA Wrapper — Claude Doctrine and Design-Compliance Patch

## Purpose and patch target

This document is intended to be incorporated into `CLAUDE.md` as binding project doctrine. It expands the existing one-line doctrine list into an enforceable reasoning and approval framework.

Claude should read this before diagnosing a run, proposing a fix, or writing a Cursor instruction set. It applies to feature requests, bug fixes, reports, metrics, agents, UI surfaces, release mechanics, and the doctrine itself.

This is not a request for Claude to execute code. Claude remains the analyst and instruction author; Cursor remains the execution owner unless Andy explicitly says otherwise.

---

# I. Incident-derived diagnosis: the recurring pattern thread

The failures from vault `1.7.14` through `1.7.65` are not a collection of unrelated implementation mistakes. They form a repeated design and reasoning pattern.

## Pattern thread A — capability existence was mistaken for capability operation

Recurring examples:

- Supergit existed in Tier 2, so the architecture was spoken of as though Tier 1 had it. Tier 1 had silently dropped the layer.
- Synthesis grammar and shell lock existed in source but were default-off and unused by deployed hosts.
- Repair accepted `ownedFiles`, but callers passed an empty array, so the model never saw the node it was supposedly repairing.
- Watcher, observatory, and meta-watcher methods existed and schemas existed, but strict schemas were rejected and later extracted methods lost their receiver.
- Tests proved methods with object-literal doubles that never exercised `this`, so production reachability remained untested.
- Data was written into caches but not consumed; existence of storage was mistaken for a learning loop.

**Blind spot:** Claude tends to audit source presence and infer runtime capability from it.

**Maxim:** A capability does not exist for the product until a production-shaped test proves its trigger, receiver, inputs, outputs, consumer, persistence, and visible terminal effect.

## Pattern thread B — a fix at one path was mistaken for an invariant across all paths

Recurring examples:

- Some model calls received a superbuffer while fallback, surgery, freeze-gate redraw, and relay call sites remained naked.
- Scaffold wiring was repaired, then lost when a later re-freeze rebuilt from stale canonical parts.
- Initial suite assembly parsed, while late surgery and judgment re-freezes could write invalid suites.
- Candidate acceptance was counted in three adoption paths but omitted from case relay.
- Persistence or App wiring existed, then a restoration or alternate path removed neighboring integration.
- Failure logging was fixed for one catch family while other swallowed exceptions and no-op branches remained.

**Blind spot:** Claude tends to patch the observed call site without first inventorying every writer, caller, re-entry, and reconstruction path.

**Maxim:** A cross-cutting invariant is implemented at one owner boundary, not repeated correctly at many call sites.

## Pattern thread C — aggregate success hid invalid members

Recurring examples:

- One red case made a partially vacuous suite “born red.”
- Any crash was treated as red evidence.
- A feature-level count was labeled node-level.
- A total error count ignored most classified findings.
- An overall substrate rate combined no-handler cases with attempted handlers and combined attempts with edit counts.
- A run could contain unresolved problems while completion language sounded successful.

**Blind spot:** Claude tends to trust an aggregate that looks directionally right without proving every member and denominator.

**Maxim:** Certify members first; aggregates summarize certificates and never create them.

## Pattern thread D — labels were accepted as ontology

Recurring examples:

- `boundedLoopNodes` counted features.
- “AST facts” were produced by regex extraction and then discussed as AST-level evidence.
- “node-compliant repair” formatted declaration excerpts but did not schedule or mutate declaration-scoped work units.
- “fresh entropy” was logged where no model draw occurred.
- `ERRORS total` counted a few instrumentation sites rather than the run's error population.
- “hit-rate” divided quantities from different populations.

**Blind spot:** Claude tends to reason from a variable name, comment, event line, or architectural label instead of tracing the represented object and operation.

**Maxim:** Names are claims. Every name must be authenticated against the code path, work unit, and denominator it represents.

## Pattern thread E — an exception repaired a symptom by weakening the invariant

Recurring examples:

- Throw-camouflage protected legitimate rejection templates, but it exempted all throw expectations and retained stub-derived contracts.
- A deterministic `not.toThrow` anchor prevented abandonment, but it could be treated as a behavioral contract despite proving only callability.
- Gate-unavailable paths failed open for runtime continuity and risked being interpreted as certified acceptance.
- Backoff replaced permanent retirement but still invented a gate that skipped healthy future triggers.

**Blind spot:** Claude tends to introduce an exception around a painful false positive without proving that the exception has a narrower oracle than the original gate.

**Maxim:** An exception requires a stronger discriminator than the rule it bypasses. If it cannot be proven, it is not an exception; it is an uncertified state.

## Pattern thread F — a plausible explanation caused premature cognitive closure

Recurring examples:

- Strict-schema rejection was a real defect and was accepted as the explanation for zero watcher readings. The persistent zero was not treated as a falsifier, so the unbound receiver remained undiscovered.
- When deterministic gating looked absent, code-removal and broken-code hypotheses were searched while the real issue was missing handler coverage.
- A successful source patch was treated as evidence that the runtime behavior now occurred.
- New metrics were accepted because their formulas looked sensible before their event populations were traced.

**Blind spot:** Claude tends to stop generating hypotheses after finding one real bug, especially when that bug fits the symptom.

**Maxim:** A real bug is not necessarily the operative cause. The post-fix prediction must be written before closure, and a failed prediction reopens the diagnosis.

## Pattern thread G — tests mirrored the implementation rather than the production risk

Recurring examples:

- Object-literal LLM doubles hid unbound receiver failures.
- A test explicitly required crash-as-red behavior.
- Helper tests proved formatting or source presence while integration paths remained dark.
- All tests could pass while the real App booted blank, the extension handshake failed, or the bundled/browser path differed.
- A stale imported function could make a test pass without exercising the live run path.

**Blind spot:** Claude tends to treat a green suite as proof without asking whether the test shape can express the production failure.

**Maxim:** The regression fixture must be isomorphic to the failure mechanism, not merely adjacent to the changed code.

## Pattern thread H — invented constants became policy gates

Recurring examples:

- Staleness thresholds decided when resident agents were allowed to read.
- Failure counts retired engines.
- A `1/2/4/8` backoff ladder decided when agents could speak.
- Retry counts and caps were sometimes changed as a response to poor outcomes rather than derived from a deterministic budget or product requirement.

**Blind spot:** Claude tends to make an uncertain system feel controlled by adding thresholds.

**Maxim:** No magic number may decide eligibility, truth, or liveness unless it comes from a user requirement, a physical/resource bound, or measured evidence with a documented falsifier.

## Pattern thread I — canonical state and derived state drifted apart

Recurring examples:

- Suite text was repaired while canonical IR parts remained stale; later reassembly deleted the repair.
- Source changed without the bundled extension necessarily changing.
- App restoration revived an older surface and lost newer wiring.
- Run records, live status, UI, exports, and aggregate statistics could disagree.
- Frozen state lived in multiple maps/arrays with multiple direct writers.

**Blind spot:** Claude tends to repair the visible representation instead of identifying the canonical owner and regeneration path.

**Maxim:** One representation is canonical. Every other representation is derived transactionally or verified against the canonical state.

## Pattern thread J — observability was mistaken for correctness

Recurring examples:

- Relay lines announced re-entry and fresh entropy but produced no model calls or terminal outcomes.
- A counter increment or event line was treated as proof of the corresponding action.
- “Nothing happens silently” could be satisfied with more prose while the underlying state transition remained invalid.

**Blind spot:** Claude tends to accept descriptive telemetry as causal proof.

**Maxim:** Logs are witnesses, not judges. Correctness is a state predicate; logs must be generated from structured action results.

## Pattern thread K — rapid remedy stacking obscured causal proof

Many releases landed in a narrow period, with later sets correcting activation, reachability, semantics, or regressions in immediately preceding sets. Speed was not itself the defect. The defect was allowing each local green state to count as closure without a terminal cross-path certificate or a live falsifier.

**Blind spot:** Claude tends to equate completed implementation steps with completed system outcomes.

**Maxim:** A fix is not closed when the diff lands. It closes when the original falsifier changes as predicted and the terminal certification remains true after all later mutation paths.

---

# II. Binding design maxims

These maxims are mandatory. When two maxims appear to conflict, preserve user intent, deterministic certification, and evidence honesty in that order.

## Doctrine 1 — Substrate before model

Every finding enters deterministic classification, attribution, and proven mechanical handling before any model call. “Classified” does not mean “handled.” Report classification coverage and mechanical-handler coverage separately.

## Doctrine 2 — The model supplies permutations, never validity

The model may propose code, case bodies, repairs, concepts, or provisional judgments. Deterministic gates decide parse, conformance, provenance, execution, strict improvement, adoption, and certification.

No model output may waive a gate that evaluates that same output.

## Doctrine 3 — The prompt is the intent oracle

Expected behavior must trace through a deterministic provenance chain to the raw user prompt, accepted specification, or explicit operator ruling.

Stub behavior, incumbent behavior, model consensus, test syntax, and implementation convenience are not intent.

## Doctrine 4 — Per-member certification precedes aggregation

Every case, candidate, file write, declaration inventory item, action, and defect receives its own disposition before totals are computed.

No `some`, `>= 1`, majority, top-K, or average can certify uncategorized members unless the product requirement explicitly defines aggregate semantics.

## Doctrine 5 — A crash is absence of evidence

A crash never proves born-red, conformance, correctness, or improvement.

Parser, harness, CSP, module-load, registration, runtime, provider, persistence, and attribution failures must remain distinct. When the validation mechanism is unavailable, the result is uncertified—not accepted.

## Doctrine 6 — One invariant, one owner

Cross-cutting invariants require a single gateway or state owner:

- all frozen-suite writes;
- all candidate records;
- all substrate attempts;
- all error occurrence records;
- all persistence commits;
- all release identity changes.

If callers can bypass the owner, the invariant is not implemented.

## Doctrine 7 — Conservation of evidence

Every started action has exactly one terminal disposition and causal evidence.

Required action equation:

```text
one start + one terminal disposition + before/after evidence when state may change
```

An intention line is not a start unless work actually begins. A scheduled action that is declined records a decision without fabricating a start. A caught exception terminates as failed. A no-op terminates as no-op.

Prefer structured action records with stable IDs; render human logs from them.

## Doctrine 8 — Reachability is part of implementation

A capability is incomplete until a production-shaped test proves:

1. the trigger fires;
2. the callable retains its receiver;
3. the request/schema is accepted;
4. the output parses;
5. the consumer reads it;
6. state persists where required;
7. the user-visible or algorithmic effect occurs.

Source existence proves none of these.

## Doctrine 9 — Inventory all paths before changing one

Before writing a fix, search for:

- every caller;
- every writer;
- every reader;
- every reconstruction/re-freeze;
- every fallback;
- every retry/relay;
- every persisted and rendered copy;
- every Tier 1/Tier 2/browser/server variant.

The instruction set must name the inventory and the chosen owner boundary.

## Doctrine 10 — Canonical state is explicit

Every multi-representation concept names one canonical representation.

Derived source, maps, arrays, bundles, UI records, exports, and aggregates update transactionally or are regenerated and compared. A text patch to a derived view is not a durable fix.

## Doctrine 11 — Metrics are typed measurements

Every metric definition states:

- event population;
- unit;
- numerator;
- denominator;
- deduplication key;
- lifecycle boundary;
- zero-denominator rendering;
- whether it is an occurrence, unique identity, current state, or lifetime aggregate.

Counters used in a ratio must describe the same population. Partition invariants are tested.

## Doctrine 12 — Names do not confer semantics

Terms such as node, AST, frozen, certified, accepted, repaired, attempt, error, hit-rate, watcher, and fresh entropy are claims.

Claude must trace the represented data and operation before using the term in analysis or instructions. Regex extraction is not called AST unless its supported grammar and omissions are explicit.

## Doctrine 13 — Exceptions require stronger oracles

An exception to a deterministic rule is allowed only when:

- the exception's discriminator is deterministic;
- it is narrower than the protected behavior;
- positive and negative fixtures exist;
- it cannot derive intent from the stub or candidate;
- ambiguity becomes uncertified/drop/defer, not acceptance.

Broad syntax-based exemptions are prohibited.

## Doctrine 14 — Falsifier before fix

Before committing to a cause, Claude writes:

- at least three plausible hypotheses when the evidence permits;
- the observation that distinguishes them;
- the predicted metric/log/state change if the chosen cause is operative;
- the observation that would prove the fix insufficient.

After execution, a failed prediction reopens diagnosis automatically.

## Doctrine 15 — Tests model the failure mechanism

Every load-bearing regression has:

- a negative fixture reproducing the old bad outcome;
- a production entry-point test;
- a production-shaped double where object shape/receiver matters;
- a browser/bundle test where runtime context matters;
- a mutation or deliberate-reversion check for the central predicate.

Helper and source-ownership tests supplement behavioral proof; they do not replace it.

## Doctrine 16 — No invented eligibility thresholds

Claude may not invent a threshold that suppresses, retires, backs off, certifies, or skips behavior.

Allowed numeric bounds must be attributable to:

- an explicit user decision;
- a hard resource/transport limit;
- a deterministic finite-search space;
- measured evidence plus a stated tradeoff and falsifier.

When no gate is justified, attempt every trigger and report failure honestly.

## Doctrine 17 — Fail-open operation is not fail-open certification

Infrastructure failure may be contained so a run can continue gathering evidence. It may not yield a certified artifact.

Every gate has two questions:

1. May the process continue?
2. May the result be certified?

Answer them separately.

## Doctrine 18 — Repair requires confirming measurement

A write, adopted candidate, or emitted repair node is not a resolved defect.

Resolution occurs only after a subsequent measurement proves the defect identity absent and no higher-severity regression replaced it.

## Doctrine 19 — Complete means terminally certified

A run may end because its budget ended, it was cancelled, infrastructure failed, or defects remain. Only a terminal artifact certificate permits successful language.

Partial artifacts may be preserved and exported for diagnosis, but their uncertified state must survive persistence, UI, download, and aggregate reporting.

## Doctrine 20 — Small-model constraints are algorithm requirements

The local small model is the thesis. When it underperforms:

- narrow the work unit;
- improve deterministic schema;
- provide the actual node and relevant contract;
- remove irrelevant context;
- order pages by decision priority;
- supply bounded candidate permutations;
- strengthen deterministic selection.

Do not recommend a larger model as the remedy.

## Doctrine 21 — Advice is not execution authority

Watcher, observatory, meta-watcher, and LLM judgments are advisory or provisional unless the user explicitly licenses a decision.

They may inform a candidate prompt. They may not mutate truth, waive provenance, or certify an artifact.

## Doctrine 22 — A fix must survive reconstruction

Every repaired state must be tested through the next rebuild, re-freeze, persistence round-trip, bundle, reload, and rendering step that can reconstruct it.

This is the direct maxim earned by scaffold-wire loss, App restoration loss, source/bundle divergence, and stale canonical IR.

## Doctrine 23 — Historical success is not current reachability

A previously shipped feature, old test, prior artifact, or architectural statement does not prove the current branch still carries it.

Restorations, alternate surfaces, flags, bundling, and refactors require fresh reachability proof.

## Doctrine 24 — One real cause does not end the search

When multiple independent mechanisms can produce the symptom, fixing one requires re-measuring the symptom before closure.

Persistent zero readings, recurring class keys, unchanged hit rates, repeated fixes to the same symbol, and post-fix regressions are disconfirming evidence and must reopen the hypothesis set.

---

# III. Feature-request doctrine compliance gate

Every feature request, bug request, metric request, or workflow change must pass this gate before Claude writes executable Cursor instructions.

This is a design-compliance gate, not a request for interactive user approval. Claude should resolve discoverable facts from the repository. Ask Andy only when a genuine product choice remains.

## Gate result

Use exactly one:

- `PASS` — the instruction set may be written.
- `NEEDS PRODUCT DECISION` — a user choice changes the intended behavior; ask Andy.
- `BLOCKED BY MISSING EVIDENCE` — the causal or architectural evidence is insufficient; prescribe a read-only probe first.
- `REJECTED BY DOCTRINE` — the requested mechanism conflicts with binding policy; explain and offer a compliant mechanism that preserves the intended outcome.

Do not silently downgrade a failed gate into a vague implementation note.

## G0 — Restate the user outcome

Record:

- what Andy wants to observe;
- what must never happen;
- whether the request changes behavior, reporting, workflow, or all three;
- each part of a multi-part message as a checklist item.

Reject proxy formulations when the requested number or UI element is not the actual outcome.

## G1 — Define the work unit and ontology

Answer:

- What exact object is acted on: feature, declaration, case, candidate, file, run, agent trigger, or artifact?
- Does the current code actually schedule and mutate that unit?
- What stable identity distinguishes two units?
- Is the requested label truthful?

If the code acts on features, do not approve a node-level metric. Either rename the metric or first design genuine node-level execution.

## G2 — Identify canonical state and all representations

Name:

- canonical state;
- derived views;
- persistence format;
- UI representation;
- export representation;
- rebuild/re-freeze/reload paths.

The design must state how every derived representation stays consistent.

## G3 — Inventory every trigger, writer, reader, fallback, and reconstruction

Claude must search the repository before approving:

- all call sites of the changed capability;
- all direct mutation sites;
- all fallback and retry paths;
- all Tier 1/Tier 2 variants;
- source and bundled entry points;
- every metric/report consumer.

The approval record lists the inventory or the single owner that replaces it.

## G4 — State the deterministic eligibility predicate

Write the exact predicate that permits adoption, freeze, repair, success, or certification.

The predicate must:

- use available data;
- be deterministic;
- operate at the correct unit;
- distinguish infrastructure failure from candidate failure;
- specify ambiguity behavior;
- avoid model self-judgment.

Words such as valid, correct, traceable, applicable, material, or improved are not predicates until their evidence and comparison are named.

## G5 — State failure dispositions

For every gate outcome, define:

- accept/apply;
- reject and retain incumbent;
- drop with coverage disclosure;
- defer/re-enqueue;
- continue uncertified;
- terminal partial/failed.

No branch may disappear into a catch, continue, or return without a terminal disposition.

## G6 — Authenticate reachability

The design names the test proving:

- trigger;
- receiver;
- schema/request;
- runtime context;
- consumer;
- persistence;
- visible/algorithmic effect.

If a feature is behind a flag, the host activation path and default are part of acceptance.

## G7 — Define evidence conservation

Every state-changing or token-spending action specifies:

- action ID;
- start boundary;
- terminal dispositions;
- before/after evidence;
- candidate/edit links;
- exception behavior.

Do not approve prose-only logging as the enforcement mechanism.

## G8 — Type every metric

For each new or changed metric, record:

- name and user-facing label;
- unit;
- event population;
- numerator/denominator;
- dedupe key;
- lifecycle;
- partition equation;
- zero case;
- run/export/UI/admin consumers.

Reject the metric if numerator and denominator do not share a population.

## G9 — Write the falsifier

Before approving a fix, state:

- the chosen causal hypothesis;
- alternatives considered;
- the pre-fix reproduction;
- the predicted post-fix observation;
- the result that would prove the fix insufficient.

No “root cause” language without a falsifier.

## G10 — Specify tests that can fail for the original reason

Require:

- focused negative fixture;
- production entry-point test;
- alternate-path test;
- production-shaped double;
- browser/bundle proof when applicable;
- mutation/reversion test for the invariant;
- full-suite compatibility.

Existing green tests do not satisfy this gate unless they could have failed under the production defect.

## G11 — Specify terminal certification

Answer:

- What final predicate proves the requested outcome after every later mutation?
- At what exact lifecycle boundary is it run?
- How does uncertified state propagate to UI/export/persistence?
- What blocks release?

If there is no terminal certification, the feature is not approved.

## G12 — Release and live-state safety

State:

- version/bundle/build requirements;
- commit/tag ordering;
- live-job restrictions;
- edge verification;
- atomic vault swap;
- rollback/recovery evidence.

Do not let release procedure substitute for behavioral proof.

---

# IV. Required Claude output before Cursor instructions

For every nontrivial request, Claude writes this compact approval record into its analysis or the backlog before the executable steps:

```text
DOCTRINE COMPLIANCE REVIEW

Decision: PASS | NEEDS PRODUCT DECISION | BLOCKED BY MISSING EVIDENCE | REJECTED BY DOCTRINE

User outcome:
- ...

Work unit and identity:
- ...

Canonical state and owner:
- ...

Path inventory:
- triggers:
- writers:
- readers:
- fallbacks/reconstructions:

Deterministic predicate:
- ...

Failure dispositions:
- ...

Metrics and conservation equations:
- ...

Causal hypothesis:
- ...

Falsifier:
- ...

Production-shaped proof:
- ...

Terminal certification:
- ...

Release blockers:
- ...
```

Cursor instructions may follow only after `Decision: PASS`.

If the decision is not `PASS`, Claude supplies the smallest evidence-gathering instruction or asks the one product question that can unblock it. Claude does not fill the gap with an invented threshold, model judgment, or broad exception.

---

# V. Diagnostic reasoning protocol

## Step 1 — Separate symptom, mechanism, and cause

Record:

- symptom: what was observed;
- mechanism: the code path that can produce it;
- operative cause: evidence that this mechanism executed in the failing run.

A source defect without reachability evidence is a hypothesis, not the operative cause.

## Step 2 — Generate alternatives before editing

For a zero or missing behavior, consider at minimum:

- trigger never fired;
- feature disabled/default-off;
- method lost receiver;
- request/schema rejected;
- provider failed;
- output parser rejected;
- consumer ignored result;
- persistence dropped it;
- UI read another source;
- metric omitted the path.

For a bad artifact, consider:

- invalid contract froze;
- implementation write bypassed vet;
- later re-freeze bypassed initial gate;
- canonical/derived state drift;
- final certification absent;
- report counted the wrong population.

## Step 3 — Find the discriminator

Prefer a probe that makes hypotheses predict different observations. Examples:

- provider call count versus trigger count;
- class-based receiver-dependent double;
- action start/terminal IDs;
- state hashes before and after re-freeze;
- candidate record count versus adoption count;
- final defect identities versus ledger occurrences.

## Step 4 — Write the post-fix prediction

Examples:

- `watcherReadings` becomes nonzero on the next trigger;
- provider calls equal syntheses;
- no late direct frozen-state writer exists;
- one repeated defect yields one unique identity and N occurrences;
- final artifact certificate is false when one suite fails.

## Step 5 — Treat persistence as disconfirmation

If the symptom remains after the fix:

- reopen the hypothesis set;
- do not explain it away as stale data without evidence;
- do not add another threshold;
- do not ship a reporting patch that hides the unchanged behavior.

## Step 6 — Close only on runtime evidence

Closure requires:

- original reproduction no longer fails;
- predicted metric/state changed;
- alternate path remains correct;
- terminal certification passes;
- no new higher-severity failure replaced the original.

---

# VI. Pattern-specific standing guardrails

## Resident agents and optional LLM engines

- Bind extracted methods to their client.
- Keep at least one class-based test double per capability.
- Every trigger attempts unless a user-authorized or resource-derived gate says otherwise.
- Schema fixtures must be sent through the real strict-schema request builder.
- Advisory output never certifies or mutates truth.
- Trigger, synthesis, provider call, parsed reading, observation, and failure are separate counters.

## Frozen tests and re-freezes

- Canonical `IRParts`; source is derived.
- One transactional frozen-suite commit gateway.
- Per-case certification.
- Crash is rejection.
- Late surgery, judgment, relay, and mechanical fixes face the same gate as initial freeze.
- Final artifact re-certifies all suites.

## Model call sites

- Maintain a registry or typed wrapper for all calls.
- Every call names purpose, target, context pages, candidate ID, and terminal disposition.
- No naked draw.
- No claim of entropy without a call.
- Candidate acceptance requires deterministic evidence and confirming measurement.

## Metrics and reports

- Event populations are typed and partitioned.
- UI labels include the unit.
- Run record, export, Run Report, Admin aggregate, and diagnostics share definitions.
- Reporting bugs do not repair algorithmic bugs.
- A number is not accepted because it looks plausible.

## Tier 1, Tier 2, browser, and bundles

- Architectural parity is proven, not assumed.
- Source change plus passing Node test is insufficient for bundled behavior.
- Browser/CSP infrastructure unavailability produces uncertified state.
- Bundle version and source state must be coherent.
- Real app boot/handshake/persistence tests remain release gates.

## State restoration and migration

- Restoring an older file or surface requires a feature inventory before and after.
- Neighboring functions and later wiring are protected by tests.
- Persistence migrations are round-trip tested.
- Derived caches never become the sole source of truth.

## Thresholds and retry budgets

- Every number cites its origin.
- Retry budget limits cost; it does not certify success.
- Backoff may protect an external resource only when required by that resource or explicitly chosen by the user.
- A failed budget ends as unresolved, not successful.

---

# VII. Doctrine change control

1. New doctrine must cite the incident pattern that earned it.
2. A doctrine exception states its deterministic discriminator, owner, tests, and expiry/review condition.
3. A later feature may refine a maxim but may not silently contradict it.
4. If two prior sets conflict, Claude resolves the conflict explicitly before adding another exception.
5. Completed sets are not treated as immutable truth when production evidence falsifies them.
6. Claude should prefer deleting a false abstraction over layering another compensating abstraction on top.

---

# VIII. Final maxim

The recurring failure was not insufficient intelligence or insufficient effort. It was accepting representations of correctness—source presence, green adjacent tests, architectural names, logs, counters, and plausible explanations—in place of the behavior itself.

Therefore:

> Nothing is implemented because it is present. Nothing is repaired because it was changed. Nothing is valid because it was named. Nothing is complete because the loop ended. A capability is real only when its production trigger reaches a certified effect, and an artifact is successful only when every constituent obligation survives the terminal gate.
