doslang-mirror/AGENTS.md

# doslang 작업 규칙

DOS/Windows용 시스템 프로그래밍 언어 Ferro와 그 컴파일러 `fec`. 규범 문서는
`SPEC.md`이며 이 파일은 그것을 구현할 때의 작업 규칙만 다룬다.

## 문서 지도

| 파일 | 역할 |
|---|---|
| `SPEC.md` | 언어 명세. 유일한 규범 문서 |
| `IR.md` | 중간 표현. 프론트엔드와 기계 사이 |
| `TODO.md` | 남은 작업, 미결 결정, 정해진 것 |
| `fec/tests/*/README.md` | 각 fixture 디렉터리가 무엇을 검사하는지 |

## 파이프라인

```
.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: 링커와 오브젝트 포맷을 새로 만들지 않는다.

## 검증

```powershell
uv run python tests/run.py     # 컴파일러가 프로그램에 대해 뭐라고 하는가
uv run python tests/exec.py    # 컴파일된 프로그램이 실제로 무엇을 하는가
uv run python tests/build.py <프로그램.fe>   # 하나만 빌드해서 돌려보기
```

- **두 스위트를 모두 통과해야 한다.** `run.py`만 보면 진단은 옳은데 코드가 안 나오는
  상태를 놓친다. 보고만 되고 방출되지 않는 경계 검사가 그 예다.
- 완료하려는 기능을 직접 검사하는 fixture가 통과해야 한다. 테스트가 증명하지 않는
  기능은 완료로 처리하지 않는다.
- 거부를 기대하는 fixture는 첫 줄에 `// ERROR:<줄>:<문구>` 마커를 둔다. 마커가 없으면
  파일 이름이 기대값이 된다 — `bad`로 시작하면 거부, 아니면 통과.
- 실행 프로그램은 첫 줄들에 `// EXIT:<코드>`, `// OUTPUT:<문구>`, `// NOCHECKS:<코드>`를
  둔다. 마지막 것은 `--no-checks`로 다시 빌드해서 다른 결과를 요구한다.
- 툴체인은 `.dosboxx/watcom`에 고정되어 있고, 없으면 오류로 멈춘다.

## 함정

- 표준 라이브러리는 프로그램이 아니라 컴파일러 옆에 있다. `--std=<디렉터리>`로
  넘기며, 그 디렉터리 안에 `std/`가 있어야 한다.
- 유닛 경로의 각 segment는 소문자로 시작하고 `a-z0-9_`만, **최대 8자**다.
  파일 경로와 정확히 대응한다 (`std.io` ↔ `<std>/std/io.fe`).
- `extern "c" fn`은 이름을 그대로 쓴다. 나머지는 `fe_<유닛>_<이름>`으로 맹글링하며
  어셈블러가 받지 않는 문자는 밑줄이 된다.
- 슬라이스 배치(포인터 다음 길이)와 wrapper 페이로드 위치는 각각 한 군데에만
  적혀 있다. 두 군데가 되면 어긋난다.

## 작업 흐름

- 명세 판단이 바뀌면 `SPEC.md`를 즉시 갱신한다. 구현이 명세와 다르면 둘 중 하나가
  틀린 것이므로 그 자리에서 결론을 낸다.
- 언어 규칙을 완화하려거든 먼저 프로그램 쪽을 고쳐본다. 규칙이 진짜 언어를 못 쓰게
  만들 때만 규칙을 건드리고, 무엇을 왜 바꿨는지 `TODO.md`에 남겨 사람이 판단하게
  한다.
- 코드는 컴파일러 단계로 나눈다. 마일스톤 단위 분할은 폐기했다.
- 검증된 단위마다 커밋한다. primary 브랜치는 `master`다.
- `.dosboxx/`의 다운로드, 실행 작업공간, 로그는 커밋하지 않는다.

## 현재 상태

두 스위트의 통과 수가 현재 상태다. 남은 작업은 `TODO.md`에 있다.