用 PDLC 工作了几个月之后我在一个项目的 docs/ 目录里看到了这些文件：

docs/
├── architecture---.md
├── architecture---.md
├── architecture---.md
├── architecture---.md
└── architecture---.md

五份架构文档，每份都带日期。我不知道哪份是现在的架构。

产物形状设计错误一：没有区分两种完全不同的产物

形状？

痛点体验：

• "又来一份带日期的文件！到底哪份是最新版，"
• "团队规范文档改版后直接加v2、v3...现在全组都不知道该follow哪个版本"
• "关键决策被埋在堆积如山的历史文件中无法快速找到"

有一类产物，记录的是"发生了什么"。PRD、设计决策、会议纪要——每份都是历史证据，不能篡改，只能追加。你不会去改一份三个月前的 PRD 让它变成"最新的"，那会毁掉决策链。这类产物叫 ledger 型。

状态"。 架构总览、团队编码规范、API 契约——永远只有一份"现在有效的版本"。你维护它的方式是就地更新，而不是另存一份带日期的副本。这类产物叫 surface 型。

/pdlc-arch 新特性方法：

• /pdlc-arch 智能识别ledger/surface型产物并分流处理 - ledger型继续append-only模式 - surface型强制就地更新单一文件
• /docs/archive/ 自动归档机制避免目录污染： - 历史版本自动归入专用归档目录 - 主工作区保持单一现状文件

• /pdlc-standard add coding/style # 禁止带版本号或日期命名
  /pdlc-standard edit coding/style # 就地修改+自动记录修改时间

至于新指令，/pdlc-standard

规范文档管理痛点场景：

公司标准化流程经常出现这样的问题： 1. 新人不知道哪个是最新规范文档； 2. 开发人员因为找不到权威文档而各自为战； 3. 关键协议变更时无法快速传达到所有相关人员。需要一种既能确保唯一权威源头又能跟踪变更历史的管理方式。—— 某大厂技术总监反馈

/pdlc-standard add api/versioning # 添加语义化方法规范
/pdlc-standard edit api/versioning # 就地修改+自动追踪变更时间
/pdlc-standard archive api/v1-deprecated # 安全归档废弃内容但保留链接有效性
/pdlc-standard index # 输出当前所有有效规范索引表

说到错误二，feature之间互不相识导致协作混乱

再看新指令。/pdcl-relate set

$ /pdcl-relate impact feature/data-sync     

┌─────────────────┬───────┬─────────┐

│ Feature │ Type │ Reason │

├─────────────────┼───────┼─────────┤

│ feature/report │ depends│ realtime sync │

│ feature/security │ depends│ encryption key│

│ feature/cronjob │ relates│ schedule sync │

├─── via feature/logging ──┤ ├

│ feature/monitor | relates| metric reporting|

└─────────╴╴╴╴╴╴───┘ └───╴─╴<