用途
本技能用于对已有系统（brownfield，棕地项目）进行业务语境化，以便在其上以 AI-first 方式工作。在棕地项目中通常没有 PRD 或 backlog：系统实际做什么写在代码里，许多规则没有记录在其他地方。该技能的目标是用业务语言并附证据回答：系统今天做什么、依据什么规则、每个东西叫什么名字。
它覆盖功能语境（第 3 层和第 4 层）。技术语境由 ARCH 通过 contextualizar-repo 产出。
该技能不修改代码，也不提出新功能。它只收集信息、记录、提问，然后停下。
主要能力
- 构建能力地图（第 3 层）：按业务能力（而非文件或端点）分组，每项能力包含：用一句业务语言说明它允许做什么、谁使用它（角色）、证据（端点、界面、测试或文件:行）、状态（活跃 · 位于配置选项之后 · 已废弃）。
- 挖掘隐藏的业务规则（第 3 层）：在代码中查找影响用户可做之事的校验、限制、转换、权限和默认值。每条规则包含：业务语言表述（例如“文档创建时不能超过 100,000 个字符”）、文件:行证据、是否在其他地方有文档记录（是/否）、若歧义或疑似错误则转为业务问题而不自行解决。
- 构建术语表（第 4 层）：生成 docs/contexto/GLOSARIO.md，汇集界面、API 和代码中出现的领域术语。每个术语包含业务定义、同义词、代码中使用的不同名称（如有）、以及其标识符格式（如有）。“所在位置”一列由 ARCH 填写；若无 ARCH，则用证据填写并标记为待技术复核。若同一术语在不同地方含义不同，记录为冲突，不选择某一定义。
使用方式
输入：
- ARCH 的 docs/contexto/ARQUITECTURA.md（或“技术语境就绪”通知），指明从哪里查看。若不存在，询问 ARCH 是否先运行；仅在人类确认后才在无它的情况下继续，并提醒收集会更慢、更不精确。
- 已有的用户文档（如有）。
- 可选：运行中的应用，用于浏览界面。
工作流程：
- 来源：按顺序遍历描述系统行为的内容——公共接口（API 端点、界面、命令）、已有测试（用具体例子描述预期行为）、配置（改变用户行为的选项和标志）、用户文档、代码（用于确认并发现前面未出现的内容）。
- 能力地图（第 3 层）：按业务能力分组，使用 assets/capacidades-template.md。
- 隐藏的业务规则（第 3 层）：查找校验、限制、转换、权限和默认值。
- 术语表（第 4 层）：使用 assets/glosario-template.md 构建 docs/contexto/GLOSARIO.md。向 ARCH 发送“GLOSARIO: TÉRMINOS NUEVOS: <路径> — <术语数量>”。
- 写入：docs/contexto/CAPACIDADES.md（能力地图 + 业务规则 + 业务问题）和 docs/contexto/GLOSARIO.md（业务↔代码术语表）。若 AGENTS.md 已指向这些文件（由 ARCH 留下），则不动；否则建议添加链接。
- 自校验：重新打开每条引用的证据，确认其支持所述内容；确认没有能力或规则被写成新的或提议的；确认术语表中每个术语都有业务定义。
- 人工关卡：向业务方（理想为 PO）呈现摘要和业务问题，等待明确批准后才将功能语境视为完成。
与 ARCH 的协调：
- 开始前等待“技术语境就绪”（除非人类另有指示）。
- 当有术语在代码中无位置时，发送“GLOSARIO: TÉRMINOS NUEVOS”。
- 收到“GLOSARIO COMPLETO”后，检查每个位置是否对应业务定义；若不对应，退回具体差异。
- 同一分歧最多两轮；之后由人类决定。
适用场景
- 接手或维护已有系统（棕地项目），需要快速理解其当前业务行为。
- 在缺乏 PRD 或 backlog 的情况下，从代码和现有资料中还原业务能力与规则。
- 为 AI-first 工作准备功能语境，作为后续工作的基础。
- 需要建立业务与代码之间统一术语表的团队。
限制
- 不修改代码，也不修改 ARCH 的技术文档。
- 不提出新功能：只记录现有功能。
- 不解决歧义规则：将其转为问题。
- 未经人工批准，不将功能语境视为完成。
- 原则：一切以业务语言书写，技术证据放在旁边而非替代解释；没有证据的内容标记为“未验证”；代码所做的未必是业务想要的，疑似错误或歧义不修正、不解释，转为业务问题。