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>

docs/adr/0001-project-group-is-collaboration-space.md

@@ -0,0 +1,29 @@
+# ADR 0001: Feishu Project Group Is The Collaboration Space
+
+## Status
+
+Accepted.
+
+## Context
+
+Teachers need to work on multiple curriculum projects at the same time. The previous mental model tied a teacher to one active project session, which makes multi-open workflows awkward and turns "exit project" into a confusing concept.
+
+The revised product model is:
+
+- one project has one long-lived Feishu project group;
+- teachers discuss freely in the group;
+- Claude does not process every group message;
+- a teacher explicitly `@Claude` when Claude should join the current context and do work.
+
+## Decision
+
+Treat the project group as a long-lived collaboration space, not as a lock owner and not as a temporary processing session.
+
+The group can stay open while no Claude processing is active. A teacher leaving or muting a group is separate from project permissions and from Claude processing lifecycle.
+
+## Consequences
+
+- Multi-open is natural: a teacher participates in multiple project groups.
+- Normal group discussion does not occupy the project.
+- "Exit project" should not be the normal action in the group workflow.
+- Project rebinding or group archival needs explicit product rules, separate from run cancellation.