role-os 2.7.1 → 2.9.0

package/README.md

@@ -89,9 +89,22 @@ Runs persist to disk (`.claude/runs/`), so interrupted sessions resume cleanly.
 
 Role OS can consult a local **Token Budget Analyst** for each dispatch step and attach an advisory spend forecast to the manifest — opt-in (`ROLEOS_BUDGET_CONSULT`), advisory (it never blocks a dispatch), and fail-open to a deterministic baseline. Off by default; the forecast is local and free to run. See the [handbook](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/).
 
+## Tool-call oversight
+
+Role OS verifies and gates tool calls at the `PreToolUse` seam — deterministically, with no model on the hot path:
+
+- **Conformance watcher** (advisory, fail-open) — a deterministic schema + computable-contract floor checks a proposed call against its catalogued tool-contract and attaches an advisory verdict on a *proven* nonconformant call; it never blocks. An opt-in LLM ceiling (`ROLEOS_CONFORMANCE_CONSULT`) handles the genuinely-semantic residue.
+- **Capability gate** (fail-closed, opt-in `ROLEOS_CAPABILITY_GATE`, default OFF) — deterministic least-privilege on *irreversible* actions (npm/PyPI publish, `gh release`, `git push`, repo edits, Pages deploy). A gated action is denied unless the director granted its capability in `.claude/role-os/capabilities.json`, so a wrong step — an honest mistake or an injected one — can't trigger an unauthorized irreversible action. The preventive complement to the named-compensator rule. See the [handbook](https://mcp-tool-shop-org.github.io/role-os/handbook/).
+
+## Crew dossier
+
+Every role has a **dossier** — a character sheet that doubles as run-time config. Six aptitudes (Rigor, Pace, Range, Skepticism, Autonomy, Candor) map to real dispatch knobs; an eight-archetype **disposition** layer (Skeptic, Builder, Investigator, Maverick…) carries a behavioral instruction; and each role has a painted portrait and a grade. Browse the whole crew as a gallery (`dossier/dossier.html`) — each role's radar shows its tuned build against its canonical ideal.
+
+When a role has a dossier, dispatch injects an **Operating Posture** — the disposition's behavioral instruction plus a posture line from the role's aptitudes — so the sheet actually configures the role. Opt-in and additive: roles without a dossier behave exactly as before. See the [handbook](https://mcp-tool-shop-org.github.io/role-os/handbook/crew-dossier/).
+
 ## Org rollout state
 
-Org-wide rollout state (queue, decisions, audit records, per-repo lock packets) lives in a separate private repo: [`role-os-rollout`](https://github.com/mcp-tool-shop-org/role-os-rollout). This repo is the product; that repo is operational state.
+Org-wide rollout state (queue, decisions, audit records, per-repo lock packets) lives in a separate **private**, org-internal repo (`role-os-rollout`). This repo is the product; that repo is operational state.
 
 ## Memory and continuity
 

package/README.pt-BR.md

@@ -89,9 +89,22 @@ As execuções são persistidas em disco (`.claude/runs/`), para que as sessões
 
 O Role OS pode consultar um **analista de orçamento de tokens** local para cada etapa de despacho e anexar uma previsão de gastos consultiva ao manifesto — opcional (`ROLEOS_BUDGET_CONSULT`), consultiva (nunca bloqueia um despacho) e com fallback para uma linha de base determinística. Desativado por padrão; a previsão é local e gratuita. Consulte o [manual](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/).
 
+## Supervisão das chamadas de ferramentas
+
+O Role OS verifica e controla as chamadas de ferramentas no ponto `PreToolUse` — de forma determinística, sem nenhum modelo no caminho crítico:
+
+- **Monitor de conformidade** (aconselhamento, falha aberta) — um esquema determinístico + verificações de contrato computável avaliam uma chamada proposta em relação ao seu contrato de ferramenta catalogado e anexam um parecer consultivo sobre uma chamada *comprovadamente* não conforme; nunca bloqueia. Um limite opcional do LLM (`ROLEOS_CONFORMANCE_CONSULT`) lida com o resíduo genuinamente semântico.
+- **Controle de capacidade** (falha fechada, opcional `ROLEOS_CAPABILITY_GATE`, padrão DESLIGADO) — privilégio mínimo determinístico em ações *irreversíveis* (publicação no npm/PyPI, `gh release`, `git push`, edições do repositório, implantação de Páginas). Uma ação controlada é negada, a menos que o administrador tenha concedido sua capacidade em `.claude/role-os/capabilities.json`, portanto, um passo errado — um erro honesto ou um erro intencional — não pode acionar uma ação irreversível não autorizada. O complemento preventivo da regra de compensação nomeada. Consulte o [manual](https://mcp-tool-shop-org.github.io/role-os/handbook/).
+
+## Dossiê da equipe
+
+Cada função tem um **dossiê** — uma ficha de personagem que também serve como configuração para o tempo de execução. Seis aptidões (Rigor, Ritmo, Alcance, Ceticismo, Autonomia, Franqueza) correspondem a parâmetros reais de distribuição; uma camada de **disposição** com oito arquétipos (Cético, Construtor, Investigador, Rebelde…) contém uma instrução comportamental; e cada função tem um retrato pintado e uma classificação. Veja toda a equipe como uma galeria (`dossier/dossier.html`) — o radar de cada função mostra sua configuração ajustada em relação ao seu ideal canônico.
+
+Quando uma função tem um dossiê, a distribuição injeta uma **Postura Operacional** — a instrução comportamental da disposição mais uma linha de postura das aptidões da função —, para que a ficha configure efetivamente a função. Opcional e aditivo: as funções sem um dossiê se comportam exatamente como antes. Consulte o [manual](https://mcp-tool-shop-org.github.io/role-os/handbook/crew-dossier/).
+
 ## Estado de implantação em toda a organização
 
-O estado de implantação em toda a organização (fila, decisões, registros de auditoria, pacotes de bloqueio por repositório) está armazenado em um repositório privado separado: [`role-os-rollout`](https://github.com/mcp-tool-shop-org/role-os-rollout). Este repositório é o produto; aquele repositório é o estado operacional.
+O estado do lançamento em toda a organização (fila de tarefas, decisões, registos de auditoria, pacotes de bloqueio por repositório) está armazenado num repositório **privado** e interno da organização (`role-os-rollout`). Este repositório é o produto; esse repositório contém o estado operacional.
 
 ## Memória e continuidade
 

package/README.zh.md

@@ -13,16 +13,16 @@
   <a href="https://mcp-tool-shop-org.github.io/role-os/"><img src="https://img.shields.io/badge/Landing_Page-live-brightgreen" alt="Landing Page"></a>
 </p>
 
-一种多 Claude 操作系统，它对员工进行管理、分配任务、验证并执行工作，通过 61 个专门的角色合同进行。它创建任务包，从经过评分的角色匹配中组建合适的团队，在执行之前检测中断的任务链，当工作被阻止或拒绝时自动进行恢复，并且要求在每个结论中提供结构化的证据。它包括用于处理大规模任务的动态调度——一个包含 10 个组件的仓库自动变为 28 个审计步骤，而不是 6 个。
+一种多 Claude 操作系统的解决方案，它对员工进行管理、分配任务、验证结果并执行工作，通过 61 个专门的角色合同来完成。它创建任务包，从经过评分的角色匹配中组建合适的团队，在执行之前检测出流程中的问题，当工作被阻止或拒绝时自动调整恢复方案，并且要求在每次决策中提供结构化的证据。它包括动态调度功能，可用于处理大规模的任务——一个包含 10 个组件的仓库会自动扩展到 28 个审核步骤，而不是 6 个。
 
-## 它的作用
+## 它的作用是什么？
 
-角色操作系统是使用多 Claude 的专业方法。它可以防止通用 AI 工作流程产生的一些特定问题：
+角色操作系统是使用多 Claude 的专业方法。它可以防止通用 AI 工作流程中出现的一些特定问题：
 
-- **漂移**——角色保持在各自的领域内。产品不会重新设计。前端不会重新定义范围。后端不会决定产品方向。
-- **虚假完成**——“完成”的定义是具体的。隐藏漏洞、跳过验证或解决不同问题的任务将被拒绝。
-- **污染**——分支或继承的项目会带有身份残留。角色操作系统检测并拒绝项目中术语、视觉效果和思维模式的跨项目漂移。
-- **基于感觉的进度**——每次交接都是结构化的。每个结论都与证据相关联。“感觉完成了”不是一个有效状态。
+- **偏离**——各个角色各司其职。产品不会重新设计。前端不会重新定义范围。后端不会决定产品的方向。
+- **虚假完成**——“完成”的定义是明确的。那些掩盖漏洞、跳过验证或解决不同问题的任务将被拒绝。
+- **污染**——分叉或继承的项目会带有身份残留。角色操作系统检测并拒绝项目中术语、视觉效果和思维模式方面的差异。
+- **基于感觉的进度**——每次交接都有结构化的流程。每个决策都与证据相关联。“感觉完成了”不是一个有效状态。
 
 ## 它的工作原理
 
@@ -44,13 +44,13 @@ roleos start "something completely novel"
 
 **备用方案：**
 
-1. **任务**——当任务与经过验证的重复工作流程（错误修复、处理、功能发布、文档、安全、研究、头脑风暴、深度审计、内部测试）匹配时。已知的角色链、工件流程、升级分支和明确的部分定义。
-2. **包**——当任务属于已知类别但不是完整的任务时。10 个经过校准的团队包，具有自动选择和不匹配保护功能。
-3. **自由路由**——当任务是新的、混合的或不确定的。对所有 61 个角色根据任务包的内容进行评分，并组建一个动态链。
+1. **任务**——当任务与经过验证的重复性工作流程（bug 修复、治疗、功能发布、文档、安全、研究、头脑风暴、深度审核、内部测试）匹配时。已知的角色链、工件流程、升级分支和明确的部分定义。
+2. **包**——当任务属于已知类别，但不是完整的任务形式时。10 个经过校准的团队包，具有自动选择和不匹配保护功能。
+3. **自由路由**——当任务是新的、混合的或不确定的。对 61 个角色中的所有角色根据任务内容进行评分，并组建一个动态链。
 
-该系统绝不会强行将工作通过错误的抽象层进行。它会解释为什么选择每个级别，并提供替代方案。
+该系统绝不会强行将工作通过错误的抽象层执行。它会解释为什么选择每个级别，并提供替代方案。
 
-**一个命令即可激活执行：**
+**只需一条命令即可开始执行：**
 
 ```bash
 roleos run "fix the crash in save handler"
@@ -67,7 +67,7 @@ roleos report                  # Generate completion report
 roleos friction                # Measure operator touches
 ```
 
-**当出现问题时进行干预：**
+**当出现问题时采取的措施：**
 
 ```bash
 roleos retry 0                 # Retry a failed step
@@ -77,52 +77,65 @@ roleos block 2 "waiting for API spec"
 roleos reopen 0 "found issue in review"
 ```
 
-运行结果会持久保存到磁盘（`.claude/runs/`），因此中断的会话可以干净地恢复。每个步骤都包含操作员指导：要生成的内容、必需的部分和停止条件。
+运行结果会持久保存到磁盘（`.claude/runs/`），因此中断的会话可以干净地恢复。每个步骤都包含操作员指导：需要生成的内容、必需的部分和停止条件。
 
-**路由完成后：**
+**在路由完成后：**
 
-1. **每个角色都会生成一个交接**——结构化的输出，其中包含证据项目，以减少对下一个角色的歧义。
-2. **审核者根据合同进行审核**——基于结构化的证据（而不是印象）进行接受、拒绝或阻止。
-3. **恢复路由自动进行**——被阻止或拒绝的工作会被路由到正确的解决者，并附带原因、恢复类型和必需的工件。
+1. **每个角色都会产生一个交接结果**——结构化的输出，其中包含证据项目，以减少下一个角色的歧义。
+2. **审核者根据合同进行审查**——基于结构化证据（而非印象），接受、拒绝或阻止。
+3. **恢复路由自动进行**——被阻止或拒绝的工作会被路由到正确的解决者处，并附带原因、恢复类型和所需的工件。
 
 ## 考虑预算的调度
 
-角色操作系统可以在每个调度步骤中咨询本地**令牌预算分析师**，并将建议的支出预测附加到清单中——可以选择启用（`ROLEOS_BUDGET_CONSULT`），为建议性（它绝不会阻止调度），并回退到确定性的基线。默认情况下禁用；预测是本地的并且可以免费运行。请参阅[手册](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/)。
+角色操作系统可以在每个调度步骤中咨询本地“令牌预算分析师”，并将建议的支出预测附加到清单中——可以选择启用（`ROLEOS_BUDGET_CONSULT`），为建议性功能（它绝不会阻止调度），并且在默认情况下会回退到确定性的基线。默认禁用；预测是本地的，并且可以免费运行。请参阅[手册](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/)。
+
+## 工具调用监督
+
+角色操作系统会在 `PreToolUse` 阶段验证并控制工具调用——以确定性的方式进行，并且不会在关键路径上使用模型：
+
+- **一致性观察器**（建议性，允许失败）——一个确定性的模式 + 可计算的合同下限，检查提出的调用是否符合其编目的工具合同，并附加关于*已证明*不一致调用的建议性结果；它绝不会阻止。可选的 LLM 上限（`ROLEOS_CONFORMANCE_CONSULT`）处理真正具有语义残留的情况。
+- **能力门控**（失败时关闭，可选 `ROLEOS_CAPABILITY_GATE`，默认关闭）——对*不可逆*操作进行确定性的最小权限控制（npm/PyPI 发布、`gh release`、`git push`、仓库编辑、Pages 部署）。除非主管在 `.claude/role-os/capabilities.json` 中授予了该操作的能力，否则会拒绝已门控的操作，因此错误的步骤——无论是诚实的错误还是注入的错误——都无法触发未经授权的不可逆操作。这是命名补偿规则的预防性补充。请参阅[手册](https://mcp-tool-shop-org.github.io/role-os/handbook/)。
+
+## 船员档案
+
+每个角色都有一个**档案**——一份角色信息表，同时也是运行时配置。六种能力（严谨性、速度、范围、怀疑精神、自主性、坦诚度）对应着实际的调度参数；一种包含八种类型的**性格**层（怀疑者、建设者、调查员、特立独行者……），其中包含行为指令；并且每个角色都有一个绘制的肖像和一个等级。将整个船员团队以画廊的形式浏览（`dossier/dossier.html`）——每个角色的雷达图显示其当前的配置与理想状态之间的差异。
+
+当某个角色拥有档案时，调度系统会注入一个**运行姿态**——即该性格的行为指令加上来自该角色能力的一行姿态描述——因此，该信息表实际上用于配置该角色。可以选择启用或添加：没有档案的角色将表现得与之前完全相同。请参阅[手册](https://mcp-tool-shop-org.github.io/role-os/handbook/crew-dossier/)。
 
 ## 组织推广状态
 
-组织范围的推广状态（队列、决策、审计记录、每个仓库的锁定包）存储在单独的私有仓库中：[`role-os-rollout`](https://github.com/mcp-tool-shop-org/role-os-rollout)。这个仓库是产品；那个仓库是运行状态。
+整个组织范围内的部署状态（队列、决策、审计记录、每个仓库的锁定数据包）都存储在一个独立的**私有**组织内部仓库中（`role-os-rollout`）。这个仓库是产品；那个仓库是运行状态。
 
 ## 内存和连续性
 
-角色操作系统不拥有或复制内存层。在 Claude 项目内存存在的地方，它就是规范的连续性系统——仓库事实、决策、未完成的任务和处理历史记录都存储在那里。
+角色操作系统不拥有或复制内存层。在 Claude 项目的内存存在的地方，它就是规范的连续性系统——仓库事实、决策、未完成的任务和治疗历史都存储在那里。
 
-角色操作系统与 Claude 项目内存集成。它不会取代它。
+角色操作系统与 Claude 项目的内存集成。它不会取代它。
 
-## 完整的处理和发布检查
+## 完整的治疗和发布检查
 
-完整的处理是 Claude 项目内存中定义的规范的 7 阶段协议（`memory/full-treatment.md`）。角色操作系统使用角色合同、交接和审核门来路由和审核处理——它不会重新定义协议。
+完整的治疗是 Claude 项目内存中定义的规范的 7 个阶段协议（`memory/full-treatment.md`）。角色操作系统使用角色合同、交接和审核门控来路由和审查治疗过程——它不会重新定义该协议。
 
-**发布检查**是在完整处理之前运行的 31 项质量门。在开始任何处理之前，必须通过 A-D 强制门。规范参考：`memory/shipcheck.md`。
+**发布检查**是在进行完整治疗之前运行的包含 31 个项目的质量闸。在开始任何治疗之前，必须通过 A-D 这四个硬性闸。规范参考：`memory/shipcheck.md`。
 
-顺序：首先进行发布检查，然后进行完整处理。如果没有通过强制门，则不能发布 v1.0.0。
+顺序：首先进行发布检查，然后进行完整的治疗。如果没有通过硬性闸，则不能发布 v1.0.0 版本。
 
 ## 10 个包中的 61 个角色
 
 | 包 | 角色 |
 |------|-------|
-| **Core** (3) | 协调者、产品策略师、审核者 |
-| **Engineering** (7) | 前端开发人员、后端工程师、测试工程师、重构工程师、性能工程师、依赖性审核员、安全审核员 |
-| **Design** (2) | UI 设计师、品牌守护者 |
-| **Marketing** (1) | 发布文案撰写者 |
-| **Treatment** (7) | 仓库研究员、仓库翻译员、文档架构师、元数据管理员、覆盖率审核员、部署验证员、发布工程师 |
-| **Product** (3) | 反馈综合者、路线图优先级排序者、规范撰写者 |
-| **Research** (4) | 用户体验研究员、竞争分析师、趋势研究员、用户访谈综合者 |
-| **Growth** (4) | 发布策略师、内容策略师、社区经理、支持优先级排序负责人 |
-| **Deep Audit** (4) | 组件审核员、测试真值审核员、接缝审核员、审核综合者 |
-| **Swarm** (7) | 蜂群协调员、蜂群后端代理、蜂群桥接代理、蜂群测试代理、蜂群基础设施代理、蜂群前端代理、蜂群综合者 |
-
-每个角色都有完整的合同：任务、何时使用、何时不使用、预期输入、必需输出、质量标准和升级触发器。每个角色都可以进行路由——`roleos route` 可以根据任务包的内容推荐任何角色。
+| **Core** (3) | 协调员、产品战略家、审核者 |
+| **Engineering** (7) | 前端开发人员、后端工程师、测试工程师、重构工程师、性能工程师、依赖关系审计员、安全审查员 |
+| **Design** (2) | UI 设计师，品牌守护者 |
+| **Marketing** (1) | 发布文案撰写员 |
+| **Treatment** (7) | 仓库研究员、仓库翻译员、文档架构师、元数据管理员、覆盖审计员、部署验证员、发布工程师 |
+| **Product** (3) | 反馈综合分析员、路线图优先级排序者、规范编写者 |
+| **Research** (4) | 用户体验研究员、竞争对手分析师、趋势研究员、用户访谈结果综合分析员 |
+| **Growth** (4) | 发布策略制定者、内容策略制定者、社区经理、支持问题分流负责人 |
+| **Deep Audit** (4) | 组件审计员、测试真实性审计员、接口审计员、审计综合分析员 |
+| **Swarm** (7) | 蜂群协调员、蜂群后端代理、蜂群桥接代理、蜂群测试代理、蜂群基础设施代理、蜂群前端代理、蜂群综合分析员 |
+
+每个角色都有完整的合同：任务、适用时机、不适用时机、预期输入、所需输出、质量标准和升级触发条件。每个角色都可以通过 `roleos route` 命令进行路由，系统可以根据数据包内容推荐任何一个角色。
 
 ## 快速入门
 
@@ -163,56 +176,56 @@ roleos mission list
 roleos packs list
 ```
 
-## 何时不使用角色操作系统
+## 何时不使用 Role OS
 
-- 单行修复、错别字或明显的错误
-- 没有明确输出的探索性研究
-- 可以在 5 分钟内在一个人的脑海中完成的工作
-- 需要在审查流程完成之前发布的紧急补丁
-- 你希望速度比结构更重要的项目
+- 单行修复、拼写错误或明显的 bug
+- 探索性研究，没有明确的输出
+- 可以一个人在 5 分钟内完成的工作
+- 需要在审查流程完成后立即发布的紧急补丁
+- 您希望速度优先于结构的项目
 
 ## 证据
 
-Role OS 已在两个结构不同的仓库中的三个测试环境中得到验证：
+Role OS 已在两个具有不同结构的仓库中的三个试验中得到验证：
 
-**测试 001 — 功能开发**（人员筛选、星际货运）
-- 7 个角色链，45 个测试场景，0 个角色冲突
-- 防止来自分支祖先的污染，捕获内联发明，发现真实的障碍
+**试验 001 — 功能开发**（Crew Screen、Star Freight）
+- 7 个角色的链条，45 个测试场景，0 个角色冲突
+- 防止来自分支祖先的污染，发现内联发明，揭示了实际的障碍
 
-**测试 002 — 集成工作**（CampaignState 连接，星际货运）
-- 5 个角色链，解决了架构缝隙，没有使用备用方案
-- 反备用方案测试证明了实时路径是真实的，而不是占位符
+**试验 002 — 集成工作**（CampaignState 连接、Star Freight）
+- 5 个角色的链条，解决了架构接口问题，而无需使用虚假信息
+- 反向回退测试证明了实时路径是真实的，而不是占位符
 
-**测试 003 — 身份工作**（污染清除，星际货运）
-- 6 个角色链，51 个测试场景，包括持久的 CI 污染防御
-- 修复了继承的虚构漂移，而没有导致广泛的重新设计
+**试验 003 — 身份工作**（污染清除、Star Freight）
+- 6 个角色的链条，51 个测试场景，包括持久的 CI 污染防御
+- 修复了继承的虚假信息漂移，而不会导致广泛的重新设计
 
-**可移植性测试**（角色一致性，传感器幽默）
-- 相同的核心，不同的语言/领域/堆栈
-- 仅采用上下文更改——没有核心合同修改
+**可移植性试验**（角色一致性、sensor-humor）
+- 相同的骨干结构，不同的语言/领域/堆栈
+- 只需进行上下文更改即可采用，无需修改核心合同
 
 **完整处理 FT-001**（portlight-desktop）
-- 7 个阶段的 staffed 处理，使用处理包角色
-- 已验证 Shipcheck 门控，零角色冲突
+- 使用 Treatment Pack 角色的 7 个阶段的 staffed 处理流程
+- 已证明 Shipcheck 门控有效，没有角色冲突
 
 **完整处理 FT-002**（studioflow）
-- 相同的处理包，结构不同的仓库（创意工作区与游戏）
-- 处理包可移植——无需合同修改
+- 使用相同的 Treatment Pack，但仓库结构不同（创意工作区与游戏）
+- Treatment Pack 可移植——无需修改合同
 
-**头脑风暴黄金测试**（MCP 服务器市场主题）
-- 9 个角色链，4 个分析师并行工作，交叉审查 + 反驳争议图
-- 提出了 4 个挑战，缩小了 3 个主张，1 个未解决——健康的压力，而不是僵局
-- 16+ 个跟踪链接，从渲染的工件追溯到真相层原子
-- 已验证完整的责任链：真相 → 原子 → 争议 → 综合 → 扩展 → 评估 → 渲染 → 跟踪
+**头脑风暴黄金流程**（MCP 服务器市场主题）
+- 9 个角色的链条，4 名分析师并行工作，交叉检查 + 反驳争议图
+- 提出了 4 个挑战，缩小了 3 个主张范围，1 个未解决——健康的压力，而不是僵局
+- 16+ 条追溯链接，从渲染的工件追溯到真相层原子
+- 已证明完整的责任链：真相 → 原子 → 争议 → 合成 → 扩展 → 判断 → 渲染 → 追溯
 
 ## 核心属性
 
-这些是不可谈判的。如果更改削弱了任何一个，请拒绝它。
+这些是不可谈判的。如果任何更改削弱了它们，请拒绝该更改。
 
-- 角色边界保持
+- 角色边界保持不变
 - 审查具有约束力
 - 升级过程保持诚实
-- 数据包保持可测试
+- 数据包可以进行测试
 - 可移植性需要上下文调整，而不是核心手术
 
 ## 项目结构
@@ -255,54 +268,54 @@ role-os/
 
 ## 安全性
 
-Role OS 仅在**本地**运行。它复制 Markdown 模板并将数据包/判决文件写入到你的仓库的 `.claude/` 目录。它不访问网络、处理密钥或收集遥测数据。没有危险的操作——所有文件写入默认使用“如果存在则跳过”。有关完整策略，请参阅 [SECURITY.md](SECURITY.md)。
+Role OS **仅在本地运行**。它会复制 Markdown 模板并将数据包/结果文件写入到您的仓库的 `.claude/` 目录中。它不会访问网络、处理密钥或收集遥测数据。没有危险的操作——所有文件写入默认使用“如果存在则跳过”的方式。有关完整策略，请参阅 [SECURITY.md](SECURITY.md)。
 
 ## 操作系统
 
-| 层 | 它的作用 | 状态 |
+| 层级 | 它的作用是什么？ | 状态 |
 |-------|-------------|--------|
 | **Routing** | 根据数据包内容对所有 61 个角色进行评分，解释建议，评估置信度 | ✓ 已发布 |
-| **Chain builder** | 从评分后的角色中组装出按阶段排序的链，偏向于数据包类型，而不是模板锁定 | ✓ 已发布 |
+| **Chain builder** | 从已评分的角色中组装出按阶段排序的链条，侧重于数据包类型，而不是模板锁定 | ✓ 已发布 |
 | **Conflict detection** | 四次验证：硬冲突、序列、冗余、覆盖差距。修复建议。 | ✓ 已发布 |
-| **Escalation** | 自动将阻塞/拒绝/拆分的工作路由到正确的解决者，并提供理由 + 所需的工件 | ✓ 已发布 |
-| **Evidence** | 具有角色意识的结构化证据，包含在判决中。充分性检查。12 种证据类型。 | ✓ 已发布 |
-| **Dispatch** | 为 multi-claude 生成执行清单。每个角色的工具配置文件、系统提示、预算。 | ✓ 已发布 |
-| **Trials** | 完整的测试已完成：30/30 个黄金任务 + 5/5 个负面测试。7 个包测试已完成。 | ✓ 已完成 |
-| **Team Packs** | 10 个经过校准的包，具有自动选择、不匹配保护和自由路由备用方案。 | ✓ 已发布 |
-| **Outcome calibration** | 记录运行结果，根据结果调整包/角色权重，调整置信度阈值。 | ✓ 已发布 |
+| **Escalation** | 自动将被阻止/拒绝/拆分的工作路由到正确的解决者，并提供理由 + 所需的工件 | ✓ 已发布 |
+| **Evidence** | 基于角色的结构化证据，包含在结果中。充分性检查。12 种证据类型。 | ✓ 已发布 |
+| **Dispatch** | 生成用于 multi-claude 的执行清单。每个角色的工具配置文件、系统提示和预算。 | ✓ 已发布 |
+| **Trials** | 完整的角色阵容已得到验证：30/30 个黄金任务 + 5/5 个负面测试。7 个包试验完成。 | ✓ 已完成 |
+| **Team Packs** | 10 个经过校准的包，具有自动选择、不匹配保护和自由路由回退功能。 | ✓ 已发布 |
+| **Outcome calibration** | 记录运行结果，根据结果调整包/角色权重，并调整置信度阈值。 | ✓ 已发布 |
 | **Mixed-task decomposition** | 检测复合工作，将其拆分为子数据包，分配包，并保留依赖关系。 | ✓ 已发布 |
-| **Composite execution** | 以依赖顺序运行子数据包，并进行工件传递、分支恢复和综合。 | ✓ 已发布 |
-| **Adaptive replanning** | 在运行过程中，范围更改、发现或新的需求会更新计划，而无需重新启动。 | ✓ 已发布 |
-| **Session spine** | `roleos init claude` 创建 CLAUDE.md、/roleos-route、/roleos-review、/roleos-status。`roleos doctor` 验证连接。路由卡证明参与度。 | ✓ 已发布 |
+| **Composite execution** | 按照依赖顺序运行子数据包，进行工件传递、分支恢复和综合处理。 | ✓ 已发布 |
+| **Adaptive replanning** | 在运行时对范围更改、发现或新需求进行更新，而无需重新启动计划。 | ✓ 已发布 |
+| **Session spine** | `roleos init claude` 会生成 CLAUDE.md、/roleos-route、/roleos-review、/roleos-status 文件。`roleos doctor` 验证连接。路由卡证明参与度。 | ✓ 已发布 |
 | **Hook spine** | 5 个生命周期钩子（SessionStart、PromptSubmit、PreToolUse、SubagentStart、Stop）。建议性强制执行：路由卡提醒、写入工具门控、子代理角色注入、完成审计。 | ✓ 已发布 |
-| **Artifact spine** | 每个角色的工件合同。包交接合同。结构验证。链完整性检查。下游角色永远不会猜测他们收到了什么。 | ✓ 已发布 |
-| **Mission library** | 9 个命名任务（feature-ship、bugfix、treatment、docs-release、security-hardening、research-launch、brainstorm、deep-audit、dogfood-swarm）。每个任务都声明包、角色链、工件流程、升级分支、诚实的部分定义。 | ✓ 已发布 |
-| **Mission runner** | 创建运行，逐步执行，并使用跟踪状态完成/失败，并进行诚实报告。阻塞步骤传播、链外升级警告、最后步骤重新打开。 | ✓ 已发布 |
-| **Unified entry** | `roleos start` 自动决定任务与包或自由路由。具有置信度分数、替代方案和复合检测的备用方案。 | ✓ 已发布 |
-| **Persistent runs** | `roleos run` 创建基于磁盘的运行。`resume`、`next`、`explain`、`complete`、`fail`。干预措施：重新路由、升级、重试、阻止、重新打开。步骤本地指导。摩擦测量。 | ✓ 已发布 |
-| **Brainstorm** | 双层架构：真相（角色原生模式、来源原子、交叉审查争议图）+ 渲染（5 种不同的声音、词汇禁令、辩论记录）。跟踪链接证明每个渲染的声明都映射到真相原子。黄金测试已完成。 | ✓ 已发布 |
-| **Deep Audit** | 清单驱动的代码仓库审计：将代码仓库分解为组件，从依赖关系图中调度 N 名审计员 + M 名测试真实性审计员 + K 名接口审计员，并将结果综合成排序后的结论和行动计划。动态调度会根据代码仓库的大小进行调整（公式为 2N + K + 3）。在每个步骤中，都会进行运行器原生验证。 | ✓ 已发布 |
-| **Dogfood Swarm** | 多阶段收敛：三个健康阶段（漏洞/安全 → 积极改进 → 人性化），然后进行功能交付。独占的文件所有权，在每个阶段之后进行构建门控，用户检查点。领域自动检测会生成清单。证据桥接至内部测试实验室。 | ✓ 已发布 |
+| **Artifact spine** | 每个角色的工件合同。包交接合同。结构验证。链完整性检查。下游角色永远不会猜测他们收到的内容。 | ✓ 已发布 |
+| **Mission library** | 9 个命名的任务（功能发布、错误修复、处理、文档发布、安全加固、研究启动、头脑风暴、深度审计、内部测试）。每个任务都声明了包、角色链、工件流程、升级分支以及诚实的部分定义。 | ✓ 已发布 |
+| **Mission runner** | 创建运行，逐步执行并跟踪状态，完整/失败时进行诚实的报告。阻塞步骤的传播、链外升级警告、最后一步的重新打开。 | ✓ 已发布 |
+| **Unified entry** | `roleos start` 会自动决定任务与包或自由路由之间的关系。带有置信度评分、替代方案和组合检测的回退层级。 | ✓ 已发布 |
+| **Persistent runs** | `roleos run` 创建基于磁盘的运行。`resume`（恢复）、`next`（下一步）、`explain`（解释）、`complete`（完成）、`fail`（失败）。干预措施：重新路由、升级、重试、阻止、重新打开。步骤本地指导。摩擦力测量。 | ✓ 已发布 |
+| **Brainstorm** | 双层架构：真相（角色原生模式、来源原子、交叉审查争议图）+ 渲染（5 个不同的声音、词汇禁令、辩论记录）。跟踪链接证明每个渲染的声明都映射到一个真相原子。黄金运行已验证。 | ✓ 已发布 |
+| **Deep Audit** | 基于清单的代码仓库审计：将代码仓库分解为组件，分派 N 个审核员 + M 个测试真相审核员 + K 个接口审核员，从依赖关系图中进行合成，生成排序后的结论和行动计划。动态分派的规模与代码仓库的大小成比例（公式为 2N + K + 3）。在每个步骤中都进行工件验证，并且是针对运行器的原生支持。 | ✓ 已发布 |
+| **Dogfood Swarm** | 多阶段收敛：三个健康阶段（错误/安全 → 主动 → 人性化），然后是功能发布。独占的文件所有权、每个阶段后的构建门控、用户检查点。领域自动检测生成清单。证据桥接至内部测试实验室。 | ✓ 已发布 |
 
 ## 9 个任务
 
 | 任务 | 包 | 角色 | 何时使用 |
 |---------|------|-------|-------------|
-| `feature-ship` | 功能 | 5 | 完整的功能交付：范围 → 规范 → 实现 → 测试 → 审查 |
-| `bugfix` | 错误修复 | 4 | 诊断根本原因，修复，测试，验证 |
-| `treatment` | 处理 | 4 | 代码检查 + 优化 + 文档 + CI 验证 + 审查 |
+| `feature-ship` | 功能发布 | 5 | 完整的特性交付：范围 → 规范 → 实现 → 测试 → 审查 |
+| `bugfix` | 错误修复 | 4 | 诊断根本原因、修复、测试、验证 |
+| `treatment` | 处理 | 4 | 代码检查 + 润色 + 文档 + CI 验证 + 审查 |
 | `docs-release` | 文档 | 2 | 编写/更新文档，发布说明 |
-| `security-hardening` | 安全 | 4 | 威胁建模，审计，修复漏洞，重新审计，验证 |
-| `research-launch` | 研究 | 4 | 提出问题，进行研究，记录发现，做出决定 |
-| `brainstorm` | 头脑风暴 | 9 | 结构化的多视角探究，具有可追溯的异议和结论 |
-| `deep-audit` | 深度审计 | 5（等级） | 清单驱动的代码仓库审计——工作者数量根据代码仓库图通过动态调度进行调整 |
-| `dogfood-swarm` | 集群 | 8（等级） | 多阶段收敛：健康 A → 健康 B → 健康 C → 功能 → 最终综合 |
+| `security-hardening` | 安全 | 4 | 威胁建模、审计、修复漏洞、重新审计、验证 |
+| `research-launch` | 研究 | 4 | 提出问题、进行研究、记录发现、决定 |
+| `brainstorm` | 头脑风暴 | 9 | 结构化的多视角探究，具有可追溯的意见分歧和结论。 |
+| `deep-audit` | 深度审计 | 5（等级） | 基于清单的代码仓库审计——工作者数量通过动态分派与代码仓库图成比例。 |
+| `dogfood-swarm` | 内部测试 | 8（等级） | 多阶段收敛：健康 A → 健康 B → 健康 C → 功能 → 最终合成 |
 
-每个任务都包含诚实且部分完成的定义——当工作停滞时，系统会记录已完成的内容和剩余内容，而不是虚报完成情况。
+每个任务都包含诚实的部分定义——当工作停滞时，系统会记录已完成的内容和剩余内容，而不是虚报完成情况。
 
 ### 头脑风暴任务
 
-不是“AI 头脑风暴”。头脑风暴任务是**在法律框架下的专业角色，具有可追溯的异议和产生结论的输出。**
+不是“AI 头脑风暴”。头脑风暴任务是**在法律框架下的专业角色，具有可追溯的意见分歧和产生结论的输出。**
 
 ```bash
 roleos run "explore product directions for a developer tool discovery platform"
@@ -310,19 +323,19 @@ roleos run "explore product directions for a developer tool discovery platform"
 #   Chain: 4 Analysts (parallel) → Normalize → Cross-Examine → Rebut → Synthesize → Expand → Judge
 ```
 
-**使其与众不同之处：**
+**它与众不同之处：**
 
-- **第一层（真相）：** 四位分析师输出角色相关的模式（上下文图、用户价值图、机制图、定位图）——而不是共享的散文。每个角色都强制执行盲点：禁止的短语、禁止的主张类型、过滤的输入分区。原子携带来源信息。定向的交叉询问图会产生有针对性的挑战。原始分析师在压力下进行辩护、缩小范围或撤回。
+- **第一层（真相）：** 四位分析师发出角色原生模式（上下文图、用户价值图、机制图、定位图），而不是共享的散文。每个角色都强制执行盲点：禁止使用的短语、禁止的主张类型、过滤后的输入分区。原子携带来源信息。一个有向的交叉审查图生成针对性的挑战。原始分析师在压力下进行辩护、缩小范围或撤回。
 
-- **第二层（呈现）：** 五种不同的声音（边界备忘录、现场笔记、系统草图、主张摘要、交叉询问记录），并具有词汇限制，以防止声音融合。综合会消耗真相，而不是呈现的散文。两层始终可用。
+- **第二层（渲染）：** 五个不同的声音（边界备忘录、现场笔记、系统草图、主张摘要、交叉审查记录），并带有词汇禁令，以防止声音融合。合成消耗真相，而不是渲染的散文。两层始终可用。
 
-- **责任链：** 每个呈现的句子都可以追溯到真相层中的原子。综合方向引用原子。交叉询问的目标是真实的声明 ID。争议图是产品，而不是散文。
+- **责任链：** 每个渲染的句子都可以追溯到真相层的原子。合成方向引用原子。交叉审查的目标是真实的声明 ID。争议图是产品，而不是散文。
 
-**已验证：** v0.4 黄金运行——已验证完整的责任链。有关完整工件链，请参见 [`examples/golden-run.md`](examples/golden-run.md)。
+**已验证：** v0.4 黄金运行——完整的责任链已验证。请参阅 [`examples/golden-run.md`](examples/golden-run.md) 以获取完整的工件链。
 
 ### 深度审计任务
 
-不是表面扫描。深度审计任务**将代码仓库分解为有界组件，并根据代码仓库自身的依赖关系图调度专门的审计员。**
+不是表面扫描。深度审计任务**将代码仓库分解为有界组件，并根据代码仓库自身的依赖关系图分派专家审核员。**
 
 ```bash
 roleos run "deep audit this repo" --manifest=audit-manifest.json
@@ -330,19 +343,19 @@ roleos run "deep audit this repo" --manifest=audit-manifest.json
 #   Steps: Component Auditor ×6 + Test Truth Auditor ×6 + Seam Auditor ×8 + Synthesizer + Action Plan + Critic = 23 steps
 ```
 
-**使其与众不同之处：**
+**它与众不同之处：**
 
-- **动态调度**——工作者数量不是固定的。一个包含 10 个组件和 5 个边界集群的代码仓库会产生 28 个步骤（2×10 + 5 + 3）。一个包含 3 个组件的代码仓库会产生 12 个步骤。缩放公式为 `2N + K + 3`，其中 N = 组件，K = 边界。
-- **清单驱动的包**——`audit-manifest.json` 定义组件（包含文件路径、行数、描述）和边界（从/到，包含接口描述）。每个审计员仅接收其包。
-- **四种角色原型**——组件审计员（每个模块的代码真相）、测试真实性审计员（证明测试与现有测试）、接口审计员（来自依赖关系图的集成边界）、审计综合器（来自所有包的排序结论 + 行动计划）。
-- **在每个步骤中进行工件验证**——`validateArtifact()` 在两个执行路径中的每个步骤完成后都会触发。结果附加到步骤对象。系统知道每个工件是否满足其合同。
-- **诚实且部分完成**——当预算或范围阻止完成时，每个组件的发现都是单独有效的。系统会根据已完成的内容进行综合，而不是虚报完全覆盖。
+- **动态分派：** 工作者数量不是固定的。一个包含 10 个组件和 5 个边界集群的代码仓库会产生 28 个步骤（2×10 + 5 + 3）。一个包含 3 个组件的代码仓库会产生 12 个步骤。缩放公式为 `2N + K + 3`，其中 N = 组件数，K = 边界数。
+- **基于清单的包：** 一个 `audit-manifest.json` 定义了组件（带有文件路径、行数、描述）和边界（从/到，带有接口描述）。每个审核员只收到自己的包。
+- **四种角色原型：** 组件审核员（每个模块的代码真相）、测试真相审核员（证明的测试与存在的测试）、接口审核员（来自依赖关系图的集成边界）、审计合成器（所有包的排序结论 + 行动计划）。
+- **在每个步骤中进行工件验证：** `validateArtifact()` 在两个执行路径中的每个步骤完成后都会触发。结果附加到步骤对象。系统知道每个工件是否满足其合同。
+- **诚实的部分：** 当预算或范围阻止完成时，每个组件的发现都是单独有效的。系统会从已完成的内容中进行合成，而不是虚报完整的覆盖范围。
 
-**已验证：** 运行器原生证明运行——针对真实清单进行了 18 个测试，并验证了完整的生命周期，包括升级重新打开和部分失败。已验证 3/6/10/15 组件清单的缩放公式。
+**已验证：** 针对运行器的原生证明运行——对真实的清单进行了 18 个测试，并验证了包括升级重新打开和部分失败在内的完整生命周期。缩放公式已针对 3/6/10/15 组件的清单进行验证。
 
-### 内部测试集群任务
+### 内部测试任务
 
-不是一次性代码检查器。内部测试集群任务**运行一个多阶段收敛协议，该协议通过三个健康阶段和迭代的功能交付，将代码仓库从“可用”状态转变为“生产就绪”状态。**
+这不是一个单次检查的静态代码分析工具。该“蜂群”任务**运行一个多阶段收敛协议，通过三个健康阶段和迭代的功能交付，将仓库从“可工作”状态提升到“生产就绪”状态。**
 
 ```bash
 roleos swarm
@@ -351,20 +364,20 @@ roleos swarm
 #   Domain agents: 3-5 parallel per wave (exclusive file ownership)
 ```
 
-**使其与众不同之处：**
+**它与众不同之处：**
 
-- **三阶段健康检查**——第一阶段修复漏洞和安全问题（循环执行，直到 0 个 CRITICAL 级别 + 0 个 HIGH 级别的问题）。第二阶段应用主动加固措施（用户审核结果）。第三阶段优化代码库——提供帮助用户的错误消息、重新连接反馈、加载状态和可访问性。每个阶段都是一个独立的视角，而不是重复的扫描。
-- **独占文件所有权**——每个域代理通过 `swarm-manifest.json` 拥有特定的文件。没有两个代理编辑同一个文件。没有合并冲突。没有协调开销。
-- **构建门禁**——每次迭代后，必须通过代码风格检查、类型检查和测试。系统自动检测构建系统（Node、Rust、Python、Go），并运行相应的命令。
-- **用户检查点**——健康检查 B 阶段和功能测试阶段需要在执行前获得明确的用户批准。系统呈现结果，用户决定构建什么。
-- **迭代收敛**——各阶段与迭代循环交替进行，直到满足退出条件或达到最大迭代次数。每个迭代都从头开始重新审核，以发现之前修复引入的回归问题。
-- **域自动检测**——`roleos swarm manifest --generate` 检测仓库类型（CLI、Web、桌面应用、MCP、单仓库），并生成不重叠的域分配。
+- **三阶段健康检查**——第一阶段修复错误和安全问题（循环直到 0 个 CRITICAL + 0 个 HIGH）。第二阶段应用主动加固措施（用户审查结果）。第三阶段使代码库更人性化——提供帮助用户的错误消息、重新连接反馈、加载状态、可访问性。每个阶段都是一个不同的视角，而不是重复相同的扫描。
+- **独占文件所有权**——每个领域代理通过 `swarm-manifest.json` 拥有特定的文件。没有两个代理编辑相同的文件。不会发生合并冲突。无需协调开销。
+- **构建门禁**——每次迭代后，必须通过代码风格检查 + 类型检查 + 测试。系统自动检测构建系统（Node、Rust、Python、Go），并运行相应的命令。
+- **用户检查点**——健康检查 B 阶段和功能交付需要明确的用户批准才能执行。系统会呈现结果，用户决定要构建的内容。
+- **迭代收敛**——各阶段与迭代循环交替进行，直到满足退出条件或达到最大迭代次数。每个迭代都会从头开始重新审核，以捕获先前修复引入的回归问题。
+- **领域自动检测**——`roleos swarm manifest --generate` 检测仓库类型（CLI、Web、桌面应用、MCP、单体仓库），并生成不重叠的领域分配。
 
-**已验证：** claude-collaborate（2026-03-28）——35 个测试增加到 129 个，修复了 106 个健康问题，发布了 v1.1.0 版本。协议 v2.0，包含 9 个阶段。
+**已验证：** claude-collaborate (2026-03-28) — 35→129 个测试，修复了 106 个健康问题，发布了 v1.1.0 版本。协议 v2.0 包含 9 个阶段。
 
 ## 状态
 
-稳定且已发布。请参阅 [CHANGELOG](CHANGELOG.md)，以获取完整的版本历史记录以及每个版本中发生的变化。
+稳定且已发布。请参阅 [CHANGELOG](CHANGELOG.md) 以获取完整的版本历史记录以及每个版本中发生的变化。
 
 ## 许可证
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "role-os",
-  "version": "2.7.1",
+  "version": "2.9.0",
   "description": "Role OS — a multi-Claude operating system where 61 specialized roles execute work through contracts, conflict detection, escalation, and structured evidence. 10 team packs, 9 missions including dogfood swarm (multi-pass convergence), deep audit with manifest-scaled dynamic dispatch, and brainstorm with traceable disagreement.",
   "homepage": "https://mcp-tool-shop-org.github.io/role-os/",
   "bugs": {

package/src/dispatch.mjs

@@ -18,6 +18,7 @@ import { join, resolve } from "node:path";
 import { resolveBlocked, resolveRejected } from "./escalation.mjs";
 import { TOOL_PROFILES } from "./tool-profiles.mjs";
 import { renderKnowledgeBlock, knowledgeManifestSummary } from "./knowledge/render-knowledge-block.mjs";
+import { renderDossierBlock } from "./dossier-block.mjs";
 
 // ── Default role config ─────────────────────────────────────────────────────
 
@@ -45,6 +46,7 @@ export const EXEC_STATES = [
 
 function buildRolePrompt(roleName, packetContent, chainContext, packetKnowledge) {
   const knowledgeBlock = renderKnowledgeBlock(packetKnowledge);
+  const dossierBlock = renderDossierBlock(roleName);
 
   return `You are operating as ${roleName} in a Role-OS managed chain.
 
@@ -58,7 +60,7 @@ ${packetContent}
 You are step ${chainContext.stepNumber} of ${chainContext.totalSteps} in this chain.
 ${chainContext.previousRole ? `Previous role: ${chainContext.previousRole} (${chainContext.previousStatus})` : "You are the first role in this chain."}
 ${chainContext.nextRole ? `Next role: ${chainContext.nextRole}` : "You are the last role before Critic review."}
-${knowledgeBlock ? `\n${knowledgeBlock}\n` : ""}
+${knowledgeBlock ? `\n${knowledgeBlock}\n` : ""}${dossierBlock ? `\n${dossierBlock}\n` : ""}
 ## Handoff Requirements
 When you finish, produce a structured handoff:
 1. Summary of what you did

package/src/dossier-block.mjs

@@ -0,0 +1,74 @@
+/**
+ * dossier-block.mjs — opt-in "Operating Posture" prompt block from a role's dossier.
+ *
+ * Mirrors render-knowledge-block.mjs: a pure function returning string | null. When a role
+ * has a dossier (src/role-dossiers.json, compiled by dossier/build-runtime.mjs), it injects
+ * that role's disposition behavioral instruction + a posture line derived from its tuned
+ * six-axis aptitudes. No dossier -> null -> the prompt is byte-identical to before. This is
+ * how a role's character sheet actually configures the role at dispatch time.
+ */
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+import { readFileSafe } from "./fs-utils.mjs";
+
+const HERE = dirname(fileURLToPath(import.meta.url));
+const AXES = ["rigor", "pace", "range", "skepticism", "autonomy", "candor"];
+
+const HIGH = {
+  rigor: "reads exhaustively and demands quoted evidence",
+  pace: "moves fast with few iterations",
+  range: "explores divergent options",
+  skepticism: "challenges hard and withholds acceptance until proof is shown",
+  autonomy: "runs to completion before escalating",
+  candor: "explains its reasoning and frames choices contrastively",
+};
+const LOW = {
+  rigor: "works at a deliberate skim",
+  pace: "works deliberately, iterating",
+  range: "converges and executes the brief as given",
+  skepticism: "extends good faith and takes the contract at face value",
+  autonomy: "escalates early when uncertain",
+  candor: "stays terse and results-only",
+};
+
+let _dossiers = null;
+function loadDossiers() {
+  if (_dossiers) return _dossiers;
+  const raw = readFileSafe(join(HERE, "role-dossiers.json"));
+  if (!raw) { _dossiers = {}; return _dossiers; }
+  try { _dossiers = JSON.parse(raw); } catch { _dossiers = {}; }
+  return _dossiers;
+}
+
+function toId(roleName) {
+  return String(roleName || "").toLowerCase().replace(/[^a-z0-9]+/g, "-").replace(/^-|-$/g, "");
+}
+
+function postureLine(aptitudes) {
+  if (!aptitudes) return "";
+  const parts = [];
+  for (const ax of AXES) {
+    const v = aptitudes[ax];
+    if (v >= 4) parts.push(HIGH[ax]);
+    else if (v <= 1) parts.push(LOW[ax]);
+  }
+  return parts.join("; ");
+}
+
+/**
+ * Render the Operating Posture block for a role, or null if it has no dossier.
+ * @param {string} roleName  display name, e.g. "Backend Engineer"
+ * @returns {string|null}
+ */
+export function renderDossierBlock(roleName) {
+  const d = loadDossiers()[toId(roleName)];
+  if (!d) return null;
+  const dispo = d.disposition || {};
+  const lines = ["## Operating Posture"];
+  if (dispo.active && dispo.prompt_delta) {
+    lines.push(`Disposition — **${dispo.active}**: ${dispo.prompt_delta}`);
+  }
+  const posture = postureLine(d.aptitudes);
+  if (posture) lines.push(`Tuned profile: ${posture}.`);
+  return lines.length > 1 ? lines.join("\n") : null;
+}