# 领域文档

探索代码之前，工程技能应当怎么消费本仓库的领域文档。

## 探索之前先读

- 根目录的 **`CONTEXT.md`**；或者
- 根目录的 **`CONTEXT-MAP.md`**（若存在）：它指向每个上下文各一份 `CONTEXT.md`，只读与当前主题相关的那几份。
- **`docs/adr/`**：读与你要动的区域相关的 ADR。

这些文件不存在就**静默继续**：不要提示缺失，也不要提议先建它们。
`/domain-modeling`（经 `/grill-with-docs`、`/improve-codebase-architecture` 抵达）
会在术语或决策真正落地时按需创建。

## 文件结构

本仓库是**单上下文**：

```text
/
├── CONTEXT.md                          ← 术语表 / 领域模型（尚不存在，懒创建）
├── docs/adr/                           ← 决策记录（尚不存在，懒创建）
│   └── 0001-....md
├── BakNRet\BakNRet.psd1                         ← 公共模块：日志、清单解析、名录、归档布局、安全描述符
├── Backup.ps1                          ← 备份入口
├── Restore.ps1                         ← 恢复入口
├── BackupList.txt                      ← 唯一「要处理什么」的来源
├── SoftwareCatalog.psd1                ← 软件名 → Slot 组
├── BackupConfig.psd1                   ← 目录、空间阈值、加密、安全描述符
├── tests/                              ← Pester、零依赖、端到端、真实归档恢复演练
└── tools/                              ← 计划任务注册、归档改名、tools\lab 的 Hyper-V 测试环境
```

## 用词表里的词

输出里一旦出现领域概念（issue 标题、重构提案、假设、测试名），就用 `CONTEXT.md`
里定义的那个词，不要漂到它明确避开的同义词。

需要用的概念不在词表里，本身就是一个信号：要么你在发明项目不用的语言（重新想），
要么真的缺一条（记下来交给 `/domain-modeling`）。

## ADR 冲突要点名

如果你的输出与某条 ADR 矛盾，明确说出来，而不是悄悄覆盖：

> 与 ADR-0007（事件溯源订单）冲突，但值得重开，因为……