Files
sjfhsjfh 3a22669f0a chore: scaffold monorepo with spec/ Lean project and governance docs
- spec/: freshly initialized Lean library project (lake init, v4.31.0), no deps
- .gitea/workflows/spec-check.yml: CI running lake build on spec/ (well-formedness gate, not a spec-to-impl gate)
- README.md: monorepo overview + the 5 "constitution" rules positioning spec/ as upstream semantic master
- CLAUDE.md: global agent manual
- spec/README.md: contract writing conventions (prose+type, PINNED/OPEN/ADR tags, no sorry)
- docs/adr/0001-0004: system-level decision records (retrieved from main)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-21 22:00:18 +08:00

1.4 KiB

CLAUDE.md —— agent 操作手册(全 repo)

本 repo 是 monorepo。先读根 README.md 的"宪法"5 条,那是一切工作的前提。本文件是给在这里干活的 coding agent 的纪律。

这个 repo 是什么

  • spec/ 是一份人机共识的契约(Lean 语义母本),是产品语义的上游参照。
  • 其余部件(将来的 spec/ 外文件夹)是spec/ 对齐的实现

纪律

  1. 不得用预训练先验脑补本领域。 这个领域很新,你没有相关先验。契约里 prose doc 注释是语义的唯一权威来源;契约没写的,就是没定的。

  2. 凡契约未写明者,不得假设。 遇到标了 OPEN 的地方,或契约根本没覆盖的地方,显式 surface 出来让开发者决定,绝不擅自替它选一个解。

  3. spec/ 必须保持其 lake build 通过。spec/ 目录下跑 lake build。新增声明必须带 /-- … -/ doc 注释和恰当标签(PINNED / OPEN / ADR-NNNN)。规范见 spec/README.md。不准用 sorry 把 build 糊绿。

  4. 实现向契约对齐;偏离必须 surface。 没有 CI gate 替你把关 spec↔实现的一致性(见宪法第 2 条)——这道对齐靠 review 和你巡逻 diff。发现实现与契约不一致时,报告它,不要默默让其中一边将就另一边。

  5. 写操作谨慎。 线上操作、git 写操作前与开发者确认(这是开发者的全局偏好)。