@dtt_siye/atool 1.2.0 → 1.3.0

package/skills/doc-standards-enforcer/SKILL.md

@@ -1,133 +1,190 @@
 ---
 name: doc-standards-enforcer
-description: Enforce documentation standards for document writing. Automatically validate when creating, modifying, or reviewing documentation files (.md). Use explicitly when context indicates documentation work, or via direct reference. Validates: file naming (<3-digit-id>-<slug>.md), hundreds-based directory structure, mandatory frontmatter (doc_id, title, status, owner, last_updated, related_docs), valid status values (draft|review|approved|deprecated), required sections (Purpose/Scope, Content, Version History), cross-document references, and version history tables. 
-version: 1.0.0
-allowed-tools: Read, Write, Edit, Bash
+description: "Enforce documentation standards and route to specialized skills. 在创建/修改文档时自动验证格式、结构、内容质量。自动路由：300→requirements-writer、400→software-architecture、500→ui-ux-pro、700→code-review。三级验证：L1 格式 → L2 结构 → L3 内容质量。"
+version: 2.0.0
+category: documentation
 ---
 
-# Documentation Standards Enforcer
+# Documentation Standards Enforcer v2.0
 
-Enforce compliance with the project's documentation standards defined in `100-standards/101-documentation-standards.md`.
+文档标准验证与专业 Skill 路由。在创建或修改文档时自动验证格式、结构、内容质量，并根据文档类型建议对应的专业 Skill。
 
 > **aTool Compatibility Note:** This skill governs documentation within the `docs/` directory and
 > follows a numbered naming convention (`<id>-<slug>.md`). It does **not** apply to aTool-managed
-> files such as `CLAUDE.md`, `README.md`, `COMPONENT.md`, or `UI_STYLE.md` at the project root.
-> These root-level files follow aTool's own template conventions.
+> files such as `CLAUDE.md`, `README.md`, `COMPONENT.md`, or `UI_STYLE.md` at the project root,
+> nor to `atool-analysis/` output files. These follow aTool's own conventions.
 
-## Purpose
+## 触发条件
 
-Ensure all documentation in this repository follows consistent standards for:
-- File naming and directory structure
-- Frontmatter completeness
-- Document structure and required sections
-- Cross-document references
-- Version history tracking
+自动触发：
+- 在 `docs/` 目录下创建或修改 `.md` 文件
+- 上下文涉及文档撰写（PRD、设计文档、需求文档等）
+- 其他 Skill 生成文档后调用验证
 
-## When This Skill Activates
+手动触发：
+- "validate documentation standards"、"检查文档规范"
+- "check doc format"、"文档格式检查"
 
-This skill activates automatically when:
-- Creating new `.md` files in the repository
-- Modifying existing documentation
-- Context indicates documentation work (PRD, design docs, requirements, etc.)
-- Explicitly invoked via "validate documentation standards" or similar phrases
+---
 
-## Validation Checklist
+## 目录体系（v2.0）
+
+| 编号 | 目录名 | 文档类型 | 专业 Skill 路由 |
+|------|--------|---------|----------------|
+| 100 | `100-governance/` | 标准、规范、流程定义、团队协议 | — |
+| 200 | `200-business/` | 商业分析、项目章程、利益相关者分析、商业论证 | — |
+| 300 | `300-requirements/` | PRD、SRS、用户故事、验收标准、功能需求 | **requirements-writer** |
+| 400 | `400-architecture/` | 系统架构(HLD/LLD)、技术设计、ADR、部署架构 | **software-architecture** |
+| 500 | `500-design/` | UI/UX 设计、交互规范、视觉规范、原型说明 | **ui-ux-pro** |
+| 600 | `600-data/` | 数据模型、数据字典、ER 图、数据流、数据迁移 | project-analyze data-model 模板 |
+| 700 | `700-quality/` | 测试策略、测试用例、安全审计、代码质量报告 | **code-review** |
+| 800 | `800-engineering/` | 开发规范、API 文档、集成指南、编码标准 | **{stack}-conventions** |
+| 900 | `900-operations/` | 部署文档、运维手册、监控配置、SLA | — |
+| 950 | `950-project/` | 项目计划、会议纪要、变更管理、风险登记 | — |
+| 990 | `990-archive/` | 历史归档（已废弃文档） | — |
+
+### 目录命名规则
+- 格式：`<3位编号>-<slug>/`
+- slug：英文 kebab-case（如 `300-requirements`）
+- 子目录可用更细分编号（如 `300-requirements/310-prd/`、`300-requirements/330-user-stories/`）
+
+### 与旧目录的映射
+| 旧目录 | 新目录 | 说明 |
+|--------|--------|------|
+| 200-product/ | 200-business/ | "产品文档"拆分：PRD 移到 300，商业分析留 200 |
+| 400-design/ | 500-design/ | UI/UX 设计独立为 500 |
+| 500-data/ | 600-data/ | 编号顺延 |
+| 600-architecture/ | 400-architecture/ | 与旧 400 合并，架构统一在 400 |
+| 700-engineering/ | 800-engineering/ | 编号顺延 |
+| 800-operations/ | 900-operations/ | 编号顺延 |
+| 900-project-mgmt/ | 950-project/ | 编号调整 |
 
-When creating or modifying documentation, verify:
+---
 
-### 1. File Naming
-- [ ] Pattern: `<3-digit-id>-<slug>.md` (e.g., `201-project-brief.md`)
-- [ ] Lowercase with kebab-case (no spaces, no Chinese characters)
-- [ ] Three-digit ID matches directory structure (e.g., files in `200-product/` start with `2`)
+## 文档路由规则
 
-### 2. Directory Structure
-- [ ] Located in appropriate hundreds-based directory
-- [ ] Directories follow pattern: `<hundreds>-<slug>/`
+当检测到用户在某个目录下创建文档时，**主动建议**对应的专业 Skill：
 
-### 3. Frontmatter (Required)
-```yaml
----
-doc_id: <DOC_ID>
-title: <Title>
-status: draft|review|approved|deprecated
-owner: <Role/Person>
-last_updated: YYYY-MM-DD
-related_docs:
-  - <path or doc_id>
----
 ```
+检测到在 docs/300-requirements/ 创建文件
+→ "建议使用 /requirements-writer 确保 PRD 覆盖率达到按钮级标准（用户故事+验收标准+UI 交互定义）"
 
-### 4. Status Values
-- `draft`: Initial draft version
-- `review`: Under review
-- `approved`: Approved, can serve as delivery basis
-- `deprecated`: Deprecated (must reference replacement)
+检测到在 docs/400-architecture/ 创建文件
+→ "建议使用 /software-architecture 确保架构决策完整（风格选型+NFR+ADR）"
 
-### 5. Required Sections
-- [ ] Purpose/Scope (目的/范围)
-- [ ] Main Content (主体内容)
-- [ ] Version History (版本历史)
+检测到在 docs/500-design/ 创建文件
+→ "建议使用 /ui-ux-pro 确保交互规范完整（线框图+状态定义+无障碍）"
 
-### 6. Version History Table
-```markdown
-| Version | Date | Owner | Change |
-|---|---|---|---|
-| v0.1 | YYYY-MM-DD | Name | Initial version |
+检测到在 docs/600-data/ 创建文件
+→ "数据文档应包含 ER 图+字段约束表+枚举定义。参考 project-analyze 的 data-model.md 模板"
+
+检测到在 docs/700-quality/ 创建文件
+→ "建议使用 /code-review 确保质量维度覆盖（8 维度分析+重构方案）"
+
+检测到在 docs/800-engineering/ 创建文件
+→ "API 文档应包含请求/响应 Schema+错误码表+curl 示例。参考对应 {stack}-conventions"
 ```
 
-### 7. Cross-Document References
-- [ ] Use relative paths from repository root
-- [ ] Include context explaining "why reference"
-- [ ] Example: `See docs/500-data/502-data-dictionary.md (field definitions)`
+### 路由时机
 
-## How to Use
+1. **创建新文件时**：在用户开始写内容前，先建议专业 Skill
+2. **Review 现有文件时**：验证后，如果 L2 结构不合格，建议对应 Skill 补齐
+3. **其他 Skill 生成文档后**：作为最后一步验证格式合规
 
-### Automatic Mode
-When creating documentation, this skill automatically activates to guide you through compliance.
+---
 
-### Explicit Invocation
-Reference this skill by:
-- Mentioning "follow documentation standards"
-- Saying "validate against doc standards"
-- Running validation scripts directly
+## 三级验证
+
+### Level 1: 格式验证（所有文档必须通过）
+
+- [ ] **文件命名**：`<3位编号>-<slug>.md`（如 `301-prd-user-management.md`）
+- [ ] **目录归属**：文件编号与目录编号一致（300 开头的文件在 `300-*/` 下）
+- [ ] **Frontmatter 完整**（必填 6 个字段）：
+  ```yaml
+  ---
+  doc_id: <DOC_TYPE>-<MODULE>-<SEQ>   # 如 PRD-USER-001, ADR-AUTH-003
+  title: <文档标题>
+  status: draft|review|approved|deprecated
+  owner: <负责人角色/姓名>
+  last_updated: YYYY-MM-DD
+  related_docs:
+    - <相关文档路径或 doc_id>
+  ---
+  ```
+- [ ] **必填节**：Purpose/Scope + 主体内容 + Version History
+- [ ] **版本历史表**存在且格式正确
+
+### Level 2: 结构验证（按文档类型检查）
+
+| 目录 | 必须包含的结构要素 |
+|------|-----------------|
+| 300-requirements/ | 用户故事(As a...)、验收标准(AC-)、功能需求编号(FR-)、非功能需求(NFR-) |
+| 400-architecture/ | 架构图(Mermaid/ASCII)、组件说明、ADR(决策/替代/理由)、NFR 约束 |
+| 500-design/ | 页面/组件列表、交互流程、状态定义(加载/空/错误/正常)、无障碍要求 |
+| 600-data/ | ER 图(Mermaid erDiagram)、字段约束表、枚举定义、关联关系 |
+| 700-quality/ | 测试用例表(ID/场景/步骤/预期)、覆盖率目标、风险评估 |
+| 800-engineering/ | API Schema(请求/响应)、错误码表、调用示例、版本兼容性 |
+
+### Level 3: 内容质量验证（可选，调用专业 Skill）
+
+| 目录 | 质量检查内容 | 委托 Skill |
+|------|------------|-----------|
+| 300-requirements/ | PRD 覆盖率检查表（按钮级/字段级/场景级）| requirements-writer |
+| 400-architecture/ | 架构原则合规、NFR 可行性 | software-architecture |
+| 500-design/ | 交互完整性、无障碍合规 | ui-ux-pro |
+| 700-quality/ | 测试覆盖率、安全审计完整性 | code-review |
+| 800-engineering/ | 技术术语准确性、代码示例可运行 | {stack}-conventions |
+
+**Level 3 触发条件**：文档 `status` 从 `draft` 变为 `review` 或 `approved` 时建议执行。
 
-### Validation Scripts
+---
 
-Run validation scripts from repository root:
+## 被调用协议
 
-```bash
-# Main validation
-python skills/doc-standards-enforcer/scripts/validate_doc_standards.py <file.md>
+其他 Skill 在生成文档后应调用 doc-standards-enforcer 验证。调用方式：
 
-# Check references
-python skills/doc-standards-enforcer/scripts/check_references.py <file.md>
+```
+在你的 Skill 输出步骤末尾添加：
 
-# Fix common issues (interactive)
-python skills/doc-standards-enforcer/scripts/fix_common_issues.py <file.md> --interactive
+"文档已生成。建议运行 doc-standards-enforcer 验证格式合规：
+ - Level 1 格式验证（命名/frontmatter/必填节）
+ - Level 2 结构验证（按文档类型检查必须要素）"
 ```
 
-## Document Templates
+### 各 Skill 的调用点
 
-### Standard Document Template
+| Skill | 调用时机 | 验证级别 |
+|-------|---------|---------|
+| project-analyze Phase 4 | 生成 atool-analysis/ 文档后（如用户将文档移到 docs/）| L1 |
+| requirements-writer Phase 3 | Review & Stitch 阶段 | L1 + L2 |
+| software-architecture | 生成 ADR/HLD 后 | L1 + L2 |
+| code-review | 生成 CODE_REVIEW.md 后（如移到 docs/） | L1 |
+| doc-coauthoring | 协作完成的文档 | L1 + L2 + L3 |
+
+---
+
+## 文档模板
+
+### 通用模板
 
 ```markdown
 ---
-doc_id: XXX-XXX-0100
-title: Document Title
+doc_id: XXX-MODULE-001
+title: 文档标题
 status: draft
 owner: Your Name
 last_updated: YYYY-MM-DD
 related_docs:
-  - docs/100-standards/101-documentation-standards.md
+  - docs/100-governance/101-documentation-standards.md
 ---
 
 ## Purpose
 
-Describe the purpose and scope of this document.
+描述本文档的目的和范围。
 
 ## Main Content
 
-Your document content here.
+文档正文。
 
 ## Version History
 
@@ -136,155 +193,78 @@ Your document content here.
 | v0.1 | YYYY-MM-DD | Name | Initial version |
 ```
 
-### User Story Template
-
-```markdown
----
-doc_id: US-XXX-3301
-title: User Story Title
-status: draft
-owner: PM
-last_updated: YYYY-MM-DD
-related_docs:
-  - docs/300-requirements/300-index.md
-us_id: US-IA-0001
-module: IA
-priority: P1
----
-
-## User Story
-
-As a [role], I want [feature], so that [benefit].
-
-## Acceptance Criteria
-
-- [ ] Criterion 1
-- [ ] Criterion 2
-
-## Version History
+### doc_id 命名规则
 
-| Version | Date | Owner | Change |
-|---|---|---|---|
-| v0.1 | YYYY-MM-DD | PM | Initial version |
 ```
-
-## Integration for Other Skills
-
-Other skills can depend on this documentation standards skill:
-
-### Automatic Triggering
-When your skill creates documentation, this skill automatically activates to ensure compliance.
-
-### Explicit Reference
-Mention "follow documentation standards" or "validate against 101-standards" in your skill.
-
-### Workflow Integration
-If your skill creates documentation:
-1. Let doc-standards-enforcer activate automatically
-2. Follow the provided templates
-3. Run validation scripts before completing
-4. Fix any reported issues
-5. Update `log.md` and create commit (per 109-agent-llm-guidelines.md)
-
-### Example Pattern
-
-```markdown
-When creating documentation for your feature:
-
-1. Invoke doc-standards-enforcer skill
-2. Use the provided frontmatter template
-3. Run: `python skills/doc-standards-enforcer/scripts/validate_doc_standards.py <file>`
-4. Fix validation errors
-5. Update log.md
-6. Commit changes
+格式：<TYPE>-<MODULE>-<SEQ>
+
+TYPE 可选值：
+  PRD  — 产品需求文档
+  SRS  — 软件需求规格
+  US   — 用户故事
+  FR   — 功能需求
+  NFR  — 非功能需求
+  ADR  — 架构决策记录
+  HLD  — 高层设计
+  LLD  — 低层设计
+  DM   — 数据模型
+  DD   — 数据字典
+  TP   — 测试计划
+  TC   — 测试用例
+  SA   — 安全审计
+  API  — API 文档
+  DP   — 部署文档
+  RM   — 运维手册
+  PP   — 项目计划
+  CR   — 变更请求
+
+MODULE：模块/功能缩写（如 USER, ORDER, AUTH）
+SEQ：3 位序号（001, 002...）
+
+示例：PRD-USER-001, ADR-AUTH-003, TC-ORDER-012
 ```
 
-## Common Mistakes to Avoid
-
-1. **Invalid filenames**: Using `test.md` instead of `201-project-brief.md`
-2. **Missing frontmatter**: Documents without YAML frontmatter block
-3. **Invalid status**: Using `in-progress` instead of `draft|review|approved|deprecated`
-4. **No version history**: Forgetting the version history table
-5. **Broken references**: Links to non-existent documents
-6. **Chinese in filenames**: Using Chinese characters in `.md` file names
-7. **Mixed concerns**: Combining business requirements with technical implementation
-
-## Content Accuracy Check (Optional)
-
-Beyond format validation, technical documents should have accurate content. This is a **recommended but optional** step:
-
-### Tech-Stack Terminology Validation
-
-When the document contains technical content (API definitions, code examples, architecture descriptions):
-
-1. **Detect the project tech stack** — check for `CLAUDE.md`, `package.json`, `pom.xml`, `Cargo.toml`, etc.
-2. **Reference the conventions skill** — identify `{stack}-conventions` skill for naming conventions and patterns
-3. **Verify technical claims** — ensure code examples compile/run, API paths match routes, class names follow naming conventions
-
-### Architecture Document Validation
-
-For architecture documents (system design, ADRs, deployment guides):
+---
 
-1. **Reference `software-architecture` skill** — validate that architectural decisions follow its principles
-2. **Check consistency** — ensure diagrams match described architecture, component names are consistent
-3. **Verify feasibility** — NFR claims should be realistic for the described architecture style
+## 验证脚本（可选）
 
-### Integration Pattern
+> **注意**：主路径为 AI 读取上方规则直接验证。以下脚本为可选的自动化辅助工具。
 
-```markdown
-After structural validation passes, for technical documents:
-1. Check tech-stack conventions alignment
-2. Verify code examples against conventions skill rules
-3. For architecture docs, cross-reference software-architecture principles
+```bash
+# Bash 快速检查（无 Python 依赖）
+# 检查文件命名规范
+find docs/ -name "*.md" | grep -vE '^docs/[0-9]{3}-[a-z].*/' && echo "WARN: 文件不在编号目录中"
+
+# 检查 frontmatter 存在
+for f in docs/**/*.md; do
+  head -1 "$f" | grep -q "^---" || echo "MISSING frontmatter: $f"
+done
 ```
 
-## Related Standards
-
-- **Full standards**: `100-standards/101-documentation-standards.md`
-- **Agent workflow**: `100-standards/109-agent-llm-guidelines.md`
-- **Repository guide**: `CLAUDE.md`
-
-## Quick Reference
-
-### Valid Status Values
-- `draft` - Draft version
-- `review` - Under review
-- `approved` - Approved
-- `deprecated` - Deprecated
-
-### Directory Structure
-- `100-standards/` - Project standards
-- `200-product/` - Product documentation
-- `300-requirements/` - Requirements
-- `400-design/` - Design documents
-- `500-data/` - Data documentation
-- `600-architecture/` - Architecture
-- `700-engineering/` - Engineering standards
-- `800-operations/` - Operations
-- `900-project-mgmt/` - Project management
-- `990-archive/` - Historical archives
+Python 脚本仍可用（`scripts/validate_doc_standards.py`），但不是必须的。
 
-### Required Frontmatter Fields
-- `doc_id` - Document identifier
-- `title` - Document title
-- `status` - Status (draft|review|approved|deprecated)
-- `owner` - Responsible role/person
-- `last_updated` - Date (YYYY-MM-DD)
-- `related_docs` - List of related documents
-
-## Error Handling
+---
 
-Validation scripts provide clear error messages:
+## 常见错误
 
-```
-[ERROR] FILE_NAMING: File 'test.md' doesn't match pattern <3-digit-id>-<slug>.md
-[ERROR] FRONTMATTER: Missing required field: doc_id
-[ERROR] STATUS: Invalid status 'in-progress'. Use: draft|review|approved|deprecated
-[ERROR] VERSION_HISTORY: Version history table not found
-```
+1. **文件放错目录**：PRD 放在 200-business/ 而非 300-requirements/
+2. **编号不匹配**：文件名 301-xxx.md 但放在 400-architecture/ 目录下
+3. **缺少 frontmatter**：文档没有 YAML frontmatter 块
+4. **无效 status**：使用 `in-progress` 而非 `draft|review|approved|deprecated`
+5. **无版本历史**：忘记 Version History 表
+6. **模糊需求**：PRD 中使用"快速"、"易用"等不可度量描述
+7. **缺少交叉引用**：文档间的依赖关系未声明
 
-## Version History
+---
 
-| Version | Date | Owner | Change |
-|---|---|---|---|
-| v1.0.0 | 2026-01-09 | Claude Code | Initial skill implementation |
+## Skill 协作
+
+| 协作 Skill | 触发条件 | 交互方式 |
+|-----------|---------|---------|
+| requirements-writer | 300-requirements/ 文档创建/验证 | L2 结构不合格时建议调用 |
+| software-architecture | 400-architecture/ 文档创建/验证 | L2 结构不合格时建议调用 |
+| ui-ux-pro | 500-design/ 文档创建/验证 | L2 结构不合格时建议调用 |
+| code-review | 700-quality/ 文档创建/验证 | L2 结构不合格时建议调用 |
+| {stack}-conventions | 800-engineering/ 文档验证 | L3 内容质量检查时调用 |
+| doc-coauthoring | 协作文档完成后 | 调用 L1+L2+L3 全量验证 |
+| project-analyze | Phase 4 文档生成后 | 调用 L1 格式验证 |

package/skills/doc-standards-enforcer/examples/valid-document-example.md

@@ -5,8 +5,8 @@ status: approved
 owner: PM
 last_updated: 2026-01-09
 related_docs:
-  - docs/200-product/200-index.md
-  - docs/100-standards/101-documentation-standards.md
+  - docs/200-business/200-index.md
+  - docs/100-governance/101-documentation-standards.md
 ---
 
 ## Purpose
@@ -54,9 +54,9 @@ The Inspection Agent project aims to develop a comprehensive inspection system t
 
 ## References
 
-- Technical specifications: See docs/400-design/401-system-design.md (architecture overview)
-- Data model: Refer to docs/500-data/501-data-model.md (entity definitions)
-- API documentation: See docs/700-engineering/701-api-reference.md (endpoint specifications)
+- Technical specifications: See docs/500-design/401-system-design.md (architecture overview)
+- Data model: Refer to docs/600-data/501-data-model.md (entity definitions)
+- API documentation: See docs/800-engineering/701-api-reference.md (endpoint specifications)
 
 ## Version History
 

package/skills/doc-standards-enforcer/references/101-standards-summary.md

@@ -5,7 +5,7 @@ status: approved
 owner: PM
 last_updated: 2026-01-09
 related_docs:
-  - ../100-standards/101-documentation-standards.md
+  - ../100-governance/101-documentation-standards.md
 ---
 
 # Documentation Standards Quick Reference
@@ -40,15 +40,15 @@ Quick reference guide for the Inspection Agent project's documentation standards
 ### Hundreds-Based Directories
 ```
 docs/
-├── 100-standards/      # Project standards
-├── 200-product/        # Product documentation
+├── 100-governance/     # Project standards & governance
+├── 200-business/       # Business & product documentation
 ├── 300-requirements/   # Requirements
-├── 400-design/         # Design documents
-├── 500-data/           # Data documentation
-├── 600-architecture/   # Architecture
-├── 700-engineering/    # Engineering standards
-├── 800-operations/     # Operations
-├── 900-project-mgmt/   # Project management
+├── 400-architecture/   # Architecture
+├── 500-design/         # Design documents (UI/UX)
+├── 600-data/           # Data documentation
+├── 800-engineering/    # Engineering standards
+├── 900-operations/     # Operations
+├── 950-project/        # Project management
 └── 990-archive/        # Historical archives
 ```
 
@@ -58,13 +58,13 @@ docs/
 ```
 
 ### Examples
-- ✓ `100-standards/`
-- ✓ `200-product/`
+- ✓ `100-governance/`
+- ✓ `200-business/`
 - ✓ `300-requirements/`
 
 ### File-Directory Matching
 Files should match their directory's hundreds digit:
-- Files in `200-product/` start with `2` (e.g., `201-*.md`)
+- Files in `200-business/` start with `2` (e.g., `201-*.md`)
 - Files in `300-requirements/` start with `3` (e.g., `301-*.md`)
 
 ## Frontmatter Template
@@ -78,7 +78,7 @@ status: draft
 owner: Your Name
 last_updated: 2026-01-09
 related_docs:
-  - docs/100-standards/101-documentation-standards.md
+  - docs/100-governance/101-documentation-standards.md
 ---
 ```
 
@@ -172,7 +172,7 @@ Table tracking all changes.
 Use relative paths from repository root:
 
 ```markdown
-See docs/500-data/502-data-dictionary.md (field definitions)
+See docs/600-data/502-data-dictionary.md (field definitions)
 ```
 
 ### Rules
@@ -181,12 +181,12 @@ See docs/500-data/502-data-dictionary.md (field definitions)
 - **Clear descriptions**: Add parenthetical context
 
 ### Good Examples
-- ✓ `See docs/500-data/502-data-dictionary.md (field definitions)`
+- ✓ `See docs/600-data/502-data-dictionary.md (field definitions)`
 - ✓ `As defined in docs/100-standards/106-engineering-standards.md (tech stack)`
 - ✓ `Refer to docs/300-requirements/310-prd.md (business requirements)`
 
 ### Bad Examples
-- ✗ `See docs/500-data/502-data-dictionary.md` (no context)
+- ✗ `See docs/600-data/502-data-dictionary.md` (no context)
 - ✗ `Check the data dictionary` (ambiguous)
 
 ## Common Mistakes
@@ -270,7 +270,7 @@ status: draft
 owner: Your Name
 last_updated: 2026-01-09
 related_docs:
-  - docs/100-standards/101-documentation-standards.md
+  - docs/100-governance/101-documentation-standards.md
 ---
 
 ## Purpose