forked from EduCraft/curriculum-project-hub
sjfhsjfh
3a22669f0a
- 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>
43 lines
3.1 KiB
Markdown
43 lines
3.1 KiB
Markdown
# curriculum-project-hub
|
|
|
|
教研生产的数字化解决方案。核心思路:课程像 DAW / 剪辑软件那样有一个**结构化的工程文件**;coding agent 协助编辑它;一个 rule-based checker(类编译器)校验其合法性并给出 helpful fix hint。目标是把教研从一次性的文档,沉淀成**可累积、可校验、可复用的资产**。
|
|
|
|
这是一个 **monorepo**。它的组织方式本身就表达了一条原则:**`spec/` 是上游的语义母本,其余部件是向它对齐的实现。**
|
|
|
|
## 仓库布局
|
|
|
|
```
|
|
README.md ← 本文件:总览 + 宪法(下面 5 条)
|
|
CLAUDE.md ← 全局 agent 操作手册(管整个 repo)
|
|
docs/adr/ ← 系统级架构决策记录(跨部件,被 spec 契约引用)
|
|
spec/ ← Lean 语义母本(自包含的 Lean 工程)。见 spec/README.md
|
|
(hub/ checker/ …) ← 将来的各部件实现,平级于 spec/。尚未创建
|
|
```
|
|
|
|
`spec/` 与实现部件**物理分离、平级共存**:谁是上游、谁向谁对齐,一眼可见。
|
|
|
|
## 宪法
|
|
|
|
这 5 条是 `spec/` 这份语义母本的定位与约束,是本仓库一切工作的前提。
|
|
|
|
1. **角色 —— Lean 是研发侧的上游参照。**
|
|
`spec/` 用 Lean 编写,是开发者(领域专家)与 coding agent **共用**的 spec 工具,用来沉淀产品各部件的**语义**。它**不进入产品运行时**——产品里"站在 Lean 这个位置"的那个 checker 用什么技术实现,尚未决定;但那个东西的语义,先在 `spec/` 里固定下来。
|
|
|
|
2. **对齐机制 —— Lean 只做上游参照。**
|
|
不做 extract / codegen,不派生 conformance test,CI 里**没有** spec→实现的 gate。实现对齐 spec,由"开发者 review + agent 巡逻 diff"这个人肉环节承载。
|
|
(CI 里的 `spec check` 只验 spec **自身**能否 type-check,即契约内部良构,不是 spec↔实现的对齐检查。)
|
|
|
|
3. **资产性 —— 由 review 纪律承载,无机器兜底。**
|
|
这份仓库给你的是"精确、自洽、机器验内部良构的语义共识",**不是**"实现正确性保证"。spec 与实现之间那道缝,是我们自愿用人来守的——清醒地守,它就是资产;放任实现漂移而不回头同步,它就退化成最贵的过期文档。
|
|
|
|
4. **形态 —— 它是人机共识的契约。**
|
|
契约必须**自包含**:凡契约未明文规定的,开发者与 agent 双方都不该假设。这比"文档"严格——type checker 会逼这份契约在结构上无洞。
|
|
|
|
5. **深度判据 —— 只收录分歧点。**
|
|
一条语义该不该写进 Lean,取决于一句话:**"不写明,开发者与 agent 会不会各自做出不同假设?"** 会 → 进契约;显然的东西 / 纯 plumbing / 普通 CRUD 字段 → 不进(写进去只稀释信噪比、增加维护面)。
|
|
深度上限不是 Lean 的表达力,而是**你愿意在每次实现变更时手动回头同步的量**——写得比你能维护的更深,多出来的部分会率先过期、反过来误导实现。
|
|
|
|
## CI
|
|
|
|
`.gitea/workflows/spec-check.yml` 在每次 push / PR 时于 `spec/` 下跑 `lake build`,确保契约始终 type-check 通过(从第一天起就是"绿"的)。这是良构 gate,见宪法第 2 条。
|