Fullstack4TraeV7 — 全栈文档驱动开发技能包工作原理

📁 V7 项目目录结构（交互式）

点击文件夹展开/折叠 · 红色 = 核心锚点 · 蓝色 = 文档类 · 青色 = 契约类 · 绿色 = 规格/变更 · 灰色 = 归档

▶ 📦 项目根/ PROJECT ROOT

▶ 📂 docs/ DOC FIRST 锚点

📄 modules/{module}.md 核心锚点

▶ 🗺️ CODEMAPS/ 架构地图

🏛️ ARCHITECTURE.md

🧭 00-reasonix-native.md

▶ 🎨 prototypes/ 项目级原型

📋 README.md

🖼️ dashboard.md

▶ 📜 contracts/ 公共协议

📐 domain-models.md

🔌 api-contracts.md

⚡ event-contracts.md

▶ 🧪 test-plan/ 测试方案

📝 strategy.md

▶ 🗃️ archive/ 归档区

📤 out/ 过时 Spec

✅ done/ 已完成

▶ 🚀 specs/ 变更工作区

⚙️ config.yaml

🎛️ .state-card.md 项目级 Cockpit

▶ 🔄 changes/ 活跃变更

▶ 📁 01-user-auth/ in-progress

🎛️ .state-card.md per-change 状态卡

📋 proposal.md

📝 specs/{capability}/spec.md BDD 场景

🖼️ prototypes/ 施工图纸

📜 contracts/ 协议先行

🏛️ design.md

✅ tasks.md

🏆 acceptance-scorecard.md 打分卡

▶ 📂 .trae/ 规则与技能

▶ 📜 rules/ 行为宪法

📄 项目核心.md

🔒 strict.md

🔍 gitnexus-铁律.md

🖼️ 原型设计.md

🤝 agent协调协议.md

🎯 视觉验收.md

💎 编码心法.md

🧪 测试避坑.md

▶ 📂 src/ 源代码

⚛️ components/

🗄️ store/

🔷 types/

🐍 shuxia/ Python 业务

🎯 五位一体方法论

方法论核心：DOC FIRST + Contract-First + Spec-Driven + TDD + Cockpit

📄

DOC FIRST

文档是项目唯一事实来源。冲突时以文档为准，不以代码为准。

🔗

Contract-First

先定接口契约再写实现。契约 approved 后不可单方面更改。

📋

Spec-Driven

用 BDD 场景描述行为。代码必须通过所有 WHEN-THEN-SHALL 场景。

🧪

TDD

红→绿→重构循环。覆盖率 > 80%，关键路径 100%。

🎛️

Cockpit

双层状态卡：项目级仪表盘 + per-change 工位状态。禁止假性完成。

🏭 生产流水线 — 9 Agent + 反馈回流

点击阶段卡片查看详细门禁条件 · 蓝色=前期 / 青色=中期 / 绿色=DOC SYNC / 橙色=后期

00

cockpit

驾驶舱定位

→

00

intake

去重+定位

→

00

proposal

方案撰写

→

00

spec

BDD 场景

⚡ 圆桌会议 roundtable（可选）

01

contract

4 文件契约

→

★ DOC SYNC #1

硬触发，不可跳过

→

10

design

架构设计

→

20

implement

TDD 实现

★ DOC SYNC #2（硬触发）

40

review

7 维度打分

→

40

accept

验收交付

🔄 反馈回流闭环

发现漂移 → 输出 Drift Report → 回流对应 Agent → 重新走下游流程
不静默迁就代码，改 spec 不是改代码

🏆 量化验收 — 7 维度加权打分卡

拖动滑块调整各维度得分，实时查看总分和门禁状态

加权总分

4.20 / 5.0

✅ 验收通过

验收门禁： 总分 < 4.0 → 不交付｜任一维度 < 3.0 → 不交付｜安全 < 4.0 → 一票否决

🔄 反馈回流 — 4 种漂移强制回流

运行时免疫系统：发现偏离立即停下，不静默迁就

📋

Spec 漂移 → 回流 spec-writer

代码行为与 BDD 场景不一致。修正 spec 后重新走 contract → design → TDD 下游。

行为不一致场景遗漏

🔗

契约漂移 → 回流 contract-writer

实现与 contracts/ 不一致。走 ADDITIVE / BREAKING 变更流程，不可单方面改实现。

接口不匹配模型变更 ADDITIVE/BREAKING

📄

文档漂移 → 回流 doc-updater

模块文档与代码不一致。DOC SYNC GATE 硬触发，模块文档必须反映最新变更。

DOC SYNC GATE 知识回流

🎯

目标漂移 → 回流 proposal-writer

偏离 proposal.md 原始目标。≥ 90% 继续 / 70-89% 用户确认 / < 70% 强制回流。

≥90% 正常 70-89% 确认 <70% 强制回流

🌲 自动加载决策链（自动驾驶）

收到编程请求时，系统自动按决策树路由到正确的技能包和 Agent

收到任何编程/修改请求

用户提及自动驾驶？

① 查 CAPABILITY_INDEX.md ② 查 codemaps/00-reasonix-native.md

新功能 / 需求 → fullstack 完整链

intake → proposal → spec → doc-updater → planner → implementer → reviewer

修改已有代码

① GitNexus impact 分析 ② intake 评估契约变更 ③ ponytail + fullstack

Bug / 报错

① GitNexus 追踪调用链 ② fullstack debugger ③ 检查根因是否涉及契约

审查代码

① fullstack reviewer（7 维度打分 + 契约漂移检测）② ponytail-review

架构 / 重构

① GitNexus 全量 context ② fullstack planner ③ ponytail 消除过度抽象

/goal 目标追逐 → goal-mode（严格执法）

三大铁律 + 六步审计门禁：DERIVE → PRESERVE → IDENTIFY → INSPECT → JUDGE → PROVE

🔄 发现漂移 → feedback-loop（强制回流）

spec 错 → spec-writer ｜契约错 → contract-writer ｜代码错 → implementer ｜目标错 → proposal-writer

🔒 十五条铁律

硬约束，不可协商、不可跳过、不可"以后再说"

铁律 01

NO INTAKE NO PROPOSAL

定位+去重未完成不进入 proposal

铁律 02

NO PROPOSAL NO SPEC

proposal 未确认不进入 spec

铁律 03

NO APPROVED SPEC NO CONTRACT

spec 未 approved 不进入 contract

铁律 04

NO CONTRACT NO DESIGN

契约未 approved 不进入 design

铁律 05

NO DOC SYNC NO CODE

文档未同步不编码

铁律 06

NO SPECS PATH IN PERSISTENT DOCS

持久化文档禁止引用 specs/changes/

铁律 07

NO FAILING TEST NO PRODUCTION CODE

TDD 红绿重构是唯一实现方式

铁律 08

NO QUANTITATIVE SCORE NO APPROVAL

没有打分卡不批准验收

铁律 09

NO VERIFICATION NO COMPLETION

验收不通过不算完成

铁律 10

NO DRIFT UNCHECKED

发现漂移必须回流，不静默迁就

铁律 11

STATE CARD ALWAYS HONEST

新会话必须自检真实进度

铁律 12

SPEC OVERLAP MUST MERGE

重叠 > 30% 必须合并

铁律 13

REPORT FOR GROWTH

技能通过 report 自我进化

铁律 14

GITNEXUS FIRST

代码分析前必须先更新索引

铁律 15

NO DEGRADING FALLBACK

禁止 ||/?? 降级兼容写法