docs: 완성된 상태에 맞춰 AGENTS 와 TODO 를 다시 쓴다

파이프라인이 끝에서 끝까지 도는 상태다. 검증이 두 스위트로 나뉜다 -- 컴파일러가
프로그램에 대해 뭐라고 하는가, 그리고 컴파일된 프로그램이 실제로 무엇을 하는가.
전자만 보면 진단은 옳은데 코드가 안 나오는 상태를 놓친다.

세션 중에 완화한 이동 규칙 두 곳을 TODO 맨 위에 사람의 판단을 기다리는
항목으로 적었다. 규칙을 건드리기 전에 프로그램 쪽을 먼저 고쳐보라는 것도
작업 흐름에 넣었다.

AGENTS.md

@@ -1,61 +1,69 @@
 # doslang 작업 규칙
 
-DOS용 시스템 프로그래밍 언어 Ferro와 그 컴파일러 `fec`. 규범 문서는 `SPEC.md`이며
-이 파일은 그것을 구현할 때의 작업 규칙만 다룬다.
+DOS/Windows용 시스템 프로그래밍 언어 Ferro와 그 컴파일러 `fec`. 규범 문서는
+`SPEC.md`이며 이 파일은 그것을 구현할 때의 작업 규칙만 다룬다.
 
 ## 문서 지도
 
 | 파일 | 역할 |
 |---|---|
-| `SPEC.md` | 언어 명세. 유일한 규범 문서. 구현 지시서와 표준 라이브러리 명세는 별도 문서 |
-| `TODO.md` | 남은 작업, 미결 결정, 순서 |
+| `SPEC.md` | 언어 명세. 유일한 규범 문서 |
+| `IR.md` | 중간 표현. 프론트엔드와 기계 사이 |
+| `TODO.md` | 남은 작업, 미결 결정, 정해진 것 |
 | `fec/tests/*/README.md` | 각 fixture 디렉터리가 무엇을 검사하는지 |
 
-테스트 명령과 플래그는 다음 CLI로 확인한다.
+## 파이프라인
 
-```powershell
-uv run python tests/run.py --help
+```
+.fe  →  fec  →  i386 asm  →  wasm  →  wlink  →  .exe
+        └ lexer parser resolve types own check  (프론트엔드)
+        └ lower                                 (IR)
+        └ x86                                   (백엔드)
 ```
 
-## 검증 규칙
+`wasm`과 `wlink`는 고정된 Open Watcom의 어셈블러와 링커다 (WebAssembly와 무관).
+`SPEC.md` §1 철학 6: 링커와 오브젝트 포맷을 새로 만들지 않는다.
 
-- 컴파일러는 현재 프런트엔드만 구현되어 있다. 범위: lexer/parser/types/own/check/resolve.
-- 코드 생성기(백엔드/IR/`lowering`)는 아직 없다.
-- 호스트 C 컴파일러는 구현/검증 대상이 아니다. 호스트는 편집, Git, 다운로드, 격리
-  작업공간 준비에만 쓴다.
+## 검증
+
+```powershell
+uv run python tests/run.py     # 컴파일러가 프로그램에 대해 뭐라고 하는가
+uv run python tests/exec.py    # 컴파일된 프로그램이 실제로 무엇을 하는가
+uv run python tests/build.py <프로그램.fe>   # 하나만 빌드해서 돌려보기
+```
+
+- **두 스위트를 모두 통과해야 한다.** `run.py`만 보면 진단은 옳은데 코드가 안 나오는
+  상태를 놓친다. 보고만 되고 방출되지 않는 경계 검사가 그 예다.
 - 완료하려는 기능을 직접 검사하는 fixture가 통과해야 한다. 테스트가 증명하지 않는
   기능은 완료로 처리하지 않는다.
-- `uv run python tests/run.py` 가 유일한 검증 엔트리다. 툴체인은 `.dosboxx/watcom`에
-  고정되어 있고, 없으면 오류로 멈춘다.
 - 거부를 기대하는 fixture는 첫 줄에 `// ERROR:<줄>:<문구>` 마커를 둔다. 마커가 없으면
-  "거부되기만 하면 통과"라 검증이 약하다.
-- 과거 VM 이미지나 호스트에 남은 바이너리는 완료 근거로 쓰지 않는다.
-- 실행해야만 검증되는 fixture는 `fec/tests/pending-backend/`에 두고 러너가 건너뛴다.
+  파일 이름이 기대값이 된다 — `bad`로 시작하면 거부, 아니면 통과.
+- 실행 프로그램은 첫 줄들에 `// EXIT:<코드>`, `// OUTPUT:<문구>`, `// NOCHECKS:<코드>`를
+  둔다. 마지막 것은 `--no-checks`로 다시 빌드해서 다른 결과를 요구한다.
+- 툴체인은 `.dosboxx/watcom`에 고정되어 있고, 없으면 오류로 멈춘다.
 
-## 빌드 함정
+## 함정
 
-- [백엔드 복귀 시 유효] 컴파일러는 16비트 large model로 빌드한다. small model은
-  메모리 부족으로 실패한다.
-- [백엔드 복귀 시 유효] 링크는 `*.obj` 와일드카드로 한다. DOS 명령줄 길이 제한 때문에
-  오브젝트를 개별 열거할 수 없다.
-- [백엔드 복귀 시 유효] M4 Watcom 테스트는 `-wx -wcd=202`를 쓴다. 생성 C의 보수적 미
-  사용 helper 때문에 W202만 끄고 나머지 경고는 오류로 유지한다.
-- [백엔드 복귀 시 유효] fixture는 DOS 8.3 이름으로 실행한다. 긴 이름은 registry에서
-  명시적으로 줄인다.
-- [백엔드 복귀 시 유효] `R:`은 읽기 전용 저장소, `W:`은 읽기 전용 Watcom이다.
-  빌드 산출물은 반드시 임시 `C:\FEC`에 쓴다.
-- [백엔드 복귀 시 유효] 실패 분석에는 임시 작업공간 보존이 필요하다. 그 플래그는
-  런처와 함께 사라졌으므로 다시 만들어야 한다.
+- 표준 라이브러리는 프로그램이 아니라 컴파일러 옆에 있다. `--std=<디렉터리>`로
+  넘기며, 그 디렉터리 안에 `std/`가 있어야 한다.
+- 유닛 경로의 각 segment는 소문자로 시작하고 `a-z0-9_`만, **최대 8자**다.
+  파일 경로와 정확히 대응한다 (`std.io` ↔ `<std>/std/io.fe`).
+- `extern "c" fn`은 이름을 그대로 쓴다. 나머지는 `fe_<유닛>_<이름>`으로 맹글링하며
+  어셈블러가 받지 않는 문자는 밑줄이 된다.
+- 슬라이스 배치(포인터 다음 길이)와 wrapper 페이로드 위치는 각각 한 군데에만
+  적혀 있다. 두 군데가 되면 어긋난다.
 
 ## 작업 흐름
 
 - 명세 판단이 바뀌면 `SPEC.md`를 즉시 갱신한다. 구현이 명세와 다르면 둘 중 하나가
   틀린 것이므로 그 자리에서 결론을 낸다.
+- 언어 규칙을 완화하려거든 먼저 프로그램 쪽을 고쳐본다. 규칙이 진짜 언어를 못 쓰게
+  만들 때만 규칙을 건드리고, 무엇을 왜 바꿨는지 `TODO.md`에 남겨 사람이 판단하게
+  한다.
 - 코드는 컴파일러 단계로 나눈다. 마일스톤 단위 분할은 폐기했다.
-- 검증된 단위마다 커밋한다. 푸시는 요청받았을 때만 한다.
-- primary 브랜치는 `master`다.
+- 검증된 단위마다 커밋한다. primary 브랜치는 `master`다.
 - `.dosboxx/`의 다운로드, 실행 작업공간, 로그는 커밋하지 않는다.
 
 ## 현재 상태
 
-`uv run python tests/run.py` 의 통과 수가 현재 상태다. 남은 작업은 `TODO.md`에 있다.
+두 스위트의 통과 수가 현재 상태다. 남은 작업은 `TODO.md`에 있다.