TL;DR

ERP Loop Engineering

관계는 규칙 하나로 선언한다

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

컴포넌트는 설계 명세를 구현한다.

하나의 문법이 네 가지 산출물을 다룬다

• Markdown: 파일, H1-H4 섹션
• Prisma: 데이터베이스 모델, 컬럼, 관계
• TypeScript: 타입, 함수, 프로퍼티
• Swagger: paths 아래의 각 오퍼레이션

코드가 명세를 인용한다

/**
 * @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>: 이 코드가 무엇을 구현하며, 왜 그런지.

인용이 없으면 빌드가 멈춘다

$ 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)

• 요구사항 하나당 에러 하나 → 에러 목록이 곧 작업 목록
• 타입 에러와 같은 빌드에서 함께 검사된다

100% 커버리지에도 거짓 인용이 섞인다

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

• 저렴한 모델은 존재하지 않는 사실을 적기도 한다
• 거짓 태그는 에러만 지울 뿐, 문제는 남긴다

인용이 붙으면 거짓 주장을 86-88%로 탐지하고, 오탐은 0이다 (2606.30689).

커버리지: 51.6–85.5% → 100%

Plain은 규모가 커질수록 커버리지가 떨어진다. Evidence는 100%를 유지한다.

토큰 사용량: 4.8–13.3배 절감

Plain은 파랑, Evidence는 주황.

단계별 원본 차트: https://ttsc.dev/docs/benchmark/evidence

ERP: 커버리지 100% · $4.96 · 14시간

검토 비중: 토큰의 90–95% → 15–41%

진한 색은 개발, 옅은 색은 검토. 각 칸이 그 과제 토큰의 100%다.

방법 A: 요구사항은 사람이 쓴다

• 사람은 docs/requirements를 직접 검토한다
• 설계 명세, 구현, 테스트는 전부 위임한다

방금 본 네 과제 모두 이 방법을 썼다.

방법 B: 요구사항까지 위임한다

• 아이디어 노트를 정리하지 않고 그대로 넘긴다
• 요구사항 작성부터 전부 위임한다
• 아이디어 노트가 하나라도 누락되면 즉시 빌드가 깨진다

사람은 원천 계층 하나만 준다.
그 아래는 그래프가 지킨다.

요구사항도 자신의 근거를 인용한다

## Coupon stacking limit {#coupon-stacking}

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

• 아이디어 노트 커버리지가 비면 요구사항 빌드가 깨진다
• 아이디어 노트, 인터뷰, 사내 문서가 한 계층을 이룬다
• 인용은 주석이라 렌더링된 문서는 깨끗하다

방법 D: 원칙만 건넨다

• 기존 프로젝트라 문서 계층 전체를 도입하기 어렵다
• 요구사항과 설계 명세는 위임하지 않고 직접 개발하고 싶다
• 그래프 전체를 설계할 준비는 아직 안 됐다

docs/principles.md 하나와 claim 하나로 시작한다.

모든 원칙을 반드시 준수한다

## 하드코딩하지 마라 {#no-hardcoding}
입력과 모델에서 동작을 도출하고 특정 사례를 예외 처리하지 않는다.

## 몽키 패칭하지 마라 {#no-monkey-patching}
공개된 확장 지점을 쓰고 프로토타입이나 모듈 상태를 바꾸지 않는다.

## 보편적인 정석으로 구현하라 {#conventional-solution}
측정 없는 과최적화를 피하고 표준 자료구조와 명료한 알고리즘을 우선한다.

## 문제를 본질적으로 해결하라 {#fix-the-root-cause}
눈앞의 실패 사례만 우회하지 말고 원인을 추적해 같은 부류의 문제 전체를 해결한다.

모든 함수가 모든 원칙에 답한다

• 선택된 함수마다 H2 원칙 전부를 확인한다
• 각 답에는 원칙을 지킨 방법과 이유를 남긴다
• "해당 없음"으로 빠져나가지 못하게 할 수 있다
• 한 항목이라도 답이 없으면 컴파일 에러가 된다

원칙을 하나 추가하면 모든 함수에 새 의무가 즉시 생긴다.

모든 답은 어떻게 지켰는지 설명한다

/**
 * @evidence docs/principles.md#no-hardcoding
 *   등록된 핸들러로 조회표를 만들며 특정 사례를 분기하지 않는다.
 * @evidence docs/principles.md#no-monkey-patching
 *   공개 어댑터를 쓰며 프로토타입이나 모듈 상태를 바꾸지 않는다.
 * @evidence docs/principles.md#conventional-solution
 *   표준 Map과 선형 순회를 쓰며 추측성 인덱스나 캐시를 두지 않는다.
 * @evidence docs/principles.md#fix-the-root-cause
 *   핸들러 등록 단계에서 잘못된 이름을 차단해 조회 실패만 재시도하지 않는다.
 */
export function resolveHandler(name: string): Handler;

대상과 비어 있지 않은 이유가 모두 필요하다. 하나라도 빠지면 빌드가 깨진다.

모든 계층이 앞선 원천을 전부 인용한다

간선마다 막는 이탈이 다르다

• 스토리라인, 시나리오, 원고 → 원칙: 문학적 목적
• 스토리라인, 시나리오, 원고 → 설정: 사실, 규칙, 지식
• 시나리오, 원고 → 스토리라인: 원인과 결과
• 원고 → 시나리오: 정확한 실행

왜 통하는가

• 제한된 컨텍스트 → 이 장면이 질 정확한 의무
• 그럴듯한 창작 → 명시적 계보와 검토
• 개고로 인한 이탈 → 영향받은 검토가 만료
• 잊힌 복선 → 100% 역방향 커버리지

엄격한 연속성 안에서 누리는 창작의 자유.

하나의 그래프로 모든 서사를

• 설정: 역사, 세계 규칙, 인물
• 인과: 복선, 동기, 결과
• 연속성: 지식, 서사 궤적, 개고
• 역사 소설, 판타지, SF, 미스터리, 드라마
• 나폴레옹: 원칙 25개, 설정 약속 350개, 장면 742개