Summary

Closes #610.

When users ask Reasonix Code to audit its own architecture, the
existing "Cite or shut up" rule catches absence-style claims but not
the more common audit-mode failure: confident proposals built on
factually wrong premises about runtime behavior, invented quantities,
or recommendations that contradict pinned memory.

Adds a six-bullet # When auditing or reviewing this codebase
section right after "Cite or shut up". Placed there because both are
about evidence integrity for evaluative claims, and audit-mode is
the most common context where a model produces evaluative output.

The six rails:

1. Auto-preview is for locating, not auditing — long files come
   back as head + tail with the middle elided; re-read with
   range:"A-B" against the actual section before asserting what's
   there (covers runtime behavior, current architectural state, and
   doc freshness).
2. Flag → consumer trace — reading a type field is not
   understanding behavior; grep the flag's consumer first. For
   inventory claims ("which tools have flag F?"), grep — don't
   enumerate from memory.
3. No fabricated percentages — ground numbers in a cited
   measurement or hedge; never present unmeasured numbers as
   measured.
4. Schema cost is real — new-tool proposals must cover (a) which
   existing-tool composition fails, (b) description-token cost, (c)
   why a prompt change can't reach the same end.
5. MEMORY.md is part of the design space — recommendations
   contradicting loaded user feedback are wrong by construction.
6. User-facing ≠ model-facing ≠ library-facing — four action
   surfaces: slash commands (user), tools (model), UI (user),
   library exports (src/index.ts). Promoting a user-level feature
   to a model tool breaks user-control invariants; treating a
   library export as "dead code" because the CLI doesn't register
   it misreads the design.

Tightening pass (5093c79)

First real audit session against the original six rails surfaced
two failure modes the original wording didn't catch:

• Rail feat: event-log kernel — durable Event sidecar + replay-capable consumer #2's inventory clause was added after the model claimed 6
  file-system tools had stormExempt: true (only 2 actually do).
  The original rail covered the single-tool case; the inventory case
  needed its own clause.
• Rail log-frame: migrate plan-replay role from ink to frame #6's library-facing surface was added after the model
  labeled registerSubagentTool "dead code from CLI perspective" —
  it's a deliberate src/index.ts export consumed by embedders.

Broadening pass (cd60b80)

A second session against the tightened rails showed the same
head-only-then-conclude failure on a plan-doc file: the model read
the head of docs/plans/architecture-refactoring-roadmap.md, saw
"8 services still use singletons", and asserted the plan was stale
without checking the rest of the doc. Rail #1's "runtime behavior"
scope was inherited from the loop.ts dispatcher case from #610 —
broadened to cover doc freshness and architectural-state claims
too.

Test plan

• tests/code-prompt.test.ts extended with audit-rail asserts
  (now 8 assertions across the 6 rails) — anchored on stable
  phrases plus the concrete tool / param tokens (range:"A-B",
  parallelSafe?: boolean, 40-60% tokens, tighten prompt / existing tool, grep the flag, library exports (\src/index.ts`), current architectural state, whether
  a plan doc is still accurate`).
• npm run typecheck / npm run lint clean
• npx vitest run tests/code-prompt.test.ts — 25 pass
• npx vitest run tests/comment-policy.test.ts — 9 pass