TL;DR

ERP Loop Engineering

One rule declares the relationship

type: "typescript",
files: ["src/components/**/*.tsx"], // sources
symbol: "function",
reference: {
  type: "markdown",
  files: ["docs/specifications/*.md"], // targets
  symbol: ["h2", "h3"],
},

Components implement specifications.

One grammar covers four artifact types

• Markdown: file, H1-H4 section
• Prisma: database model, columns, relation
• TypeScript: type, function, property
• Swagger: each operation under paths

Code cites the specification

/**
 * @evidence docs/specifications/discount.md#coupon-stacking
 *           Explains the stacking limit defined by this section.
 * @evidence POST:/orders/{orderId}/coupons
 *           Explains the rejection response from this endpoint.
 */
export function CouponStackingNotice(props: IProps): JSX.Element;

@evidence <target> <reason>: what this code implements, and why.

Without a citation, the build stops

$ npx ttsc
error TS16411: [evidence/graph]
  Missing acknowledgement for
  'docs/specifications/discount.md#coupon-stacking'
  (Markdown H2 'Coupon Stacking' at docs/specifications/discount.md:3)

• One error per requirement → the error list is the task list
• It runs alongside type errors in the same build

100% coverage can include false citations

/**
 * @evidence docs/specifications/discount.md#coupon-stacking
 *           Explains the per-issuer limit.
 */
export function CouponStackingNotice(props: IProps): JSX.Element;

• Inexpensive models sometimes write facts that do not exist
• A false tag removes the error, not the problem

Citations make the false claim detectable: 86-88%, no false positives (2606.30689).

Coverage: 51.6–85.5% → 100%

Plain coverage falls with scope. Evidence remains at 100%.

Token usage: 4.8–13.3× lower

Plain in blue. Evidence in orange.

Original charts by phase: https://ttsc.dev/docs/benchmark/evidence

ERP: 100% coverage · $4.96 · 14h

Review: 90–95% → 15–41% of tokens

Dark is development. Light is review. Each cell represents 100% of its tokens.

Method A: Humans write the requirements

• Humans review docs/requirements directly
• Specifications, implementation, and tests are fully delegated

The four subjects you just saw all used this method.

Method B: Delegate the requirements, too

• Hand over idea notes as-is, without organizing them
• Delegate everything, starting with writing the requirements
• If anything in the idea notes is omitted, the build breaks immediately

Humans provide one source layer.
The graph protects everything below it.

Even requirements cite their evidence

## Coupon stacking limit {#coupon-stacking}

<!-- @evidence docs/ideas/discount.md#discount-policy
     Carries over the per-issuer limit recorded in the idea notes. -->

• Missing idea-note coverage breaks the requirements build
• Idea notes, interviews, and internal documents share one layer
• Citations are comments, so the rendered document stays clean

Method D: Hand over principles only

• The project already exists, so a full document hierarchy is hard to introduce
• You want to develop directly instead of delegating requirements and specifications
• You are not ready to design the whole graph yet

Start with one docs/principles.md and one claim.

Every principle must be followed

## Do not hardcode {#no-hardcoding}
Derive behavior from inputs and models. Never special-case a fixture.

## Do not monkey patch {#no-monkey-patching}
Use public extension points. Never replace prototypes or module state.

## Use the conventional solution {#conventional-solution}
Avoid unmeasured optimization. Prefer standard structures and clear algorithms.

## Fix the root cause {#fix-the-root-cause}
Do not route around one visible failure. Trace the cause and solve the whole class.

Every function answers every rule

• Each selected function checks every H2 rule
• Every answer records how and why the rule was followed
• "Not applicable" can be closed as an escape hatch
• One missing answer becomes a compile error

Add one rule, and every function immediately gains one obligation.

Every answer explains how

/**
 * @evidence docs/principles.md#no-hardcoding
 *   Builds the lookup from registered handlers, with no case-specific branch.
 * @evidence docs/principles.md#no-monkey-patching
 *   Uses the public adapter without replacing prototypes or module state.
 * @evidence docs/principles.md#conventional-solution
 *   Uses a standard Map and linear pass, with no speculative index or cache.
 * @evidence docs/principles.md#fix-the-root-cause
 *   Rejects invalid names at registration instead of retrying failed lookups.
 */
export function resolveHandler(name: string): Handler;

Both the target and a non-empty reason are required. Miss one and the build breaks.

Every layer cites all prior sources

Each edge blocks a different drift

• Storylines, Scenarios, Manuscripts → Principles: literary purpose
• Storylines, Scenarios, Manuscripts → Settings: facts, rules, knowledge
• Scenarios, Manuscripts → Storylines: causes and consequences
• Manuscripts → Scenarios: exact execution

Why it works

• Limited context → exact obligations for this scene
• Plausible invention → explicit lineage and review
• Revision drift → affected reviews expire
• Forgotten promise → 100% reverse coverage

Creative freedom inside hard continuity.

One graph, any narrative

• Settings: history, world rules, character
• Causality: clues, motives, consequences
• Continuity: knowledge, arcs, revisions
• Historical fiction, fantasy, science fiction, mystery, drama
• Napoleon: 25 principles, 350 setting commitments, 742 scenes