业务架构
回答“为什么做”
- 处理对象
- 业务域、价值流、领域边界、跨域关系与核心业务不变量。
- 不处理
- 不复述鉴权、路由、部署等技术契约；技术机制归系统架构。
- 真相来源
.claude/arch/business/，以代码为锚，由srcHash保鲜。- 交付给
- 把“真实业务问题与边界”交给系统能力承接。
01
业务架构
意图与价值的真实世界
02
系统架构
能力与协作的技术世界
03
框架架构
规则与演进的控制世界
业务意图价值牵引
系统实现能力映射
框架控制约束与演进
01
三类架构，三种不同的真相
这里的“层”不是组织层级，而是三种不可互相替代的判断尺度。每类架构都回答不同问题、维护不同真相，并把明确的输入交给下一类架构。
系统架构
回答“做什么，如何约束”
- 处理对象
- 系统责任、组件关系、技术契约、质量属性、验证边界与诚实边界。
- 不处理
- 不复制业务领域真相，也不把框架控制机制重新发明一遍。
- 真相来源
.claude/arch/system/，每个规范域以独立架构制品承载设计。- 交付给
- 把“设计决定”翻译成工程可执行、机器可判断的契约。
框架架构
回答“如何持续地做好”
- 处理对象
- 最高原则、元治理、工作流、规范能力、强制机制与真实代码材料。
- 不处理
- 不代替具体业务设计，也不成为各系统规范的第二本账。
- 真相来源
.claude/harness-engineering.md，定义 L0–L5 控制系统。- 交付给
- 让架构跨会话、跨角色、跨端仍然保持一致并持续演进。
业务约束系统
系统验证业务
框架约束两者
业务定义真相 · 系统承诺能力 · 框架维持秩序
02
框架架构的
框架架构的
六层控制系统
从最高原则到底层代码，每一层都有明确职责。上层给下层边界，下层用真实证据反哺上层，形成可运行、可验证、可演进的控制闭环。
自上而下
原则 → 路径 → 判据 → 强制 → 代码
自下而上
事实 → 证据 → 复盘 → 演进
工作流是向导，L4 是传感器；
绕过流程，不等于绕过检测。
-
L0
宪法层
定义最高原则、治理拓扑与边界禁区，只做定性和导航，不把下层机制塞回最高法。
- 它处理
- 不可被下层改写的原则
- 主要载体
CLAUDE.md
-
L1
元治理层
治理规范、规则、架构制品与工作流自身的生命周期，让治理机制也被治理。
- 它处理
- 一致性、锁步、保鲜与安全演进
- 核心入口
/x-meta-dev
-
L2
工作流层
把开发、治理、发布与体检编排成可重复路径，明确谁在何时读取什么、产出什么。
- 它处理
- PLAN → IMPLEMENT → VERIFY → DEPLOY
- 核心入口
/x-feature-dev
-
L3
规范能力层
把设计决定写成条款，把条款落实为判据，再由统一检测引擎解释“什么算对”。
- 它处理
- 规则语义、机器判定与验证射程
- 核心载体
spec + rule + check
-
L4
强制层
在写前防手滑、写后记录事实、停止时运行真检测，让错误尽量在离开发动作最近的位置暴露。
- 它处理
- PreToolUse / PostToolUse / Stop
- 核心载体
guard.js
-
L5
代码层
承载 x-core 母本与各端真实运行材料。所有上层判断最终都必须在这里被兑现，而不是停在文档里。
- 它处理
- 真实结构、运行行为与发布材料
- 主要载体
x-core + 各端
03
一个决定，如何穿过整个系统
架构的价值不在“写完”，而在一项决定能否从业务意图一路抵达运行事实，并让真实反馈进入下一轮裁定。
-
01
业务意图
目标与边界明确为什么做、做什么，以及做到什么范围。
-
02
系统设计
责任与关系把业务意图转化为系统能力、边界与组件协作。
-
03
工程契约
条款与判据把设计决定翻译为写码时可执行、机器可判断的契约。
-
04
运行证据
检测与测试床用检测、回归与真实运行材料证明契约是否兑现。
-
05
演进反馈
变更史与再裁定基于事实复盘、修正边界，并把结论带入下一轮决策。
真实反馈进入下一轮决策
04
专业架构的四条底线
不论业务如何变化，HARNESS 始终坚持四条底线。它们决定一份架构能否被理解、被执行、被证明，并在变化后仍值得信任。
- 01单一真相源
每类关键事实只有一个权威来源，派生内容可以生成，但不能另起一份会漂移的账。
- 02边界可定位
每项能力都有明确归属、责任边界与不处理事项，问题出现时能定位，决策落下时能追责。
- 03证据可复现
所有关键判断都有可运行判据、测试床或人工守护说明，验证过程能回放，结论能复核。
- 04变更可追溯
每次架构变化都有理由、有影响面、有版本与历史，允许推翻旧结论，但不允许悄悄漂移。