产品控制论画像
案例：dsh-custom（装配层）
Product Portrait · 控制论画像dsh-custom
CASE
dsh-custom（dsh v0.2.1-alpha.2 + dsh-opencode-port 装配层）— Agent 控制论画像
由「preset 层 persona 15 节 + plan-mode section 覆写 + 三层触发规则（架构/需求/出图）+ 委派契约」共同承担，把 opencode 侧原本靠 instructions 文件承载的目标分解纪律，固化进 dsh 的 preset 声明层——设定值从「提示词约定」升级为「preset 声明」，三模式各自声明完整插件列表（cordis.patch.yml:9-1305）。
SP
设定值（Setpoint）——用户意图 → 可验证子目标
用户意图 → 可验证子目标承担角色：由「preset 层 persona 15 节 + plan-mode section 覆写 + 三层触发规则（架构/需求/出图）+ 委派契约」共同承担，把 opencode 侧原本靠 instructions 文件承载的目标分解纪律，固化进 dsh 的 preset 声明层——设定值从「提示词约定」升级为「preset 声明」，三模式各自声明完整插件列表（
cordis.patch.yml:9-1305）。关键机制
- persona 15 节固化设定值纪律：
~/.dsh/presets/opencode/persona.md（15 节 / 6524 字符 / 12066 B，v1.4 为 8018 字符 / 15403 B，:5-150）把「调度者定位 + 复杂度自评四维表（:11-22）」「委派判据（≥2 工具/联网/多步推理）」「子 Agent 只执行不委派（:44-48）」「留档 5 段模板（:85-92）」写进 preset 的persona.prefix，随模式激活自动注入。 - 复杂度自评（GATE 化用）：
persona.md:20-22保留 opencode 的 ≤12 常规 / ≥13 高档判据，但删除字面门控格式与变体切换（dsh 无变体概念，模型与推理档由 profileroute声明）——设定值纪律保留、其载体被诚实改写。 - plan-mode section 覆写：
cordis.patch.yml:219-235把内置 plan-mode section 从 2358 字符扩到 2515 字符，追加 3 行中文逐题访谈指引（一次只问一问，能自行探索的分支不反问用户），把 opencode 的 Plan 模式纪律落成 dsh 的 plan-mode 配置。 - 三层触发规则：架构类任务先答「规模三问」再定档（
cordis.patch.yml:131-148，门控级须走 skill→worker→gate 三步）；需求发现走机械定档（cordis.patch.yml:152-161，调check_tier_conditions.py，工具不可用须显式标 FAIL、不得凭感觉选档）；出图/视觉/PDF 各有归位规则（:163-167）。 - 委派契约：
cordis.patch.yml:54-61规定子 Agent 必须按固定 JSON 返回（status/summary/data/files_created/...），主 Agent 按success/partial/failed分派聚合策略——设定值以可解析契约跨 Agent 传递。 - 留档路径门控：
persona.md:90要求保存前校验路径符合Mission-file/{YYYY-MM}/{MMDD-任务名}/，不通过即拒绝保存。
控制论映射：KT-ctrl-002（设定值 r = 用户意图）/ KT-ctrl-045（规划-执行解耦，preset 声明即参考序列固化）/ KT-ctrl-041（分层时标，复杂度自评决定推理档）/ KT-ctrl-046（options/SMDP，三层触发规则把意图映射为动作原语）。
强——设定值纪律从「提示词文件」变成「preset 声明」，模式切换即生效；三层触发规则（架构/需求/出图）把模糊意图先物化为档位再执行；委派契约可解析。弱——设定值仍以 prompt 文本编码为主，复杂度自评是模型自报而非外部测量；persona 含本机绝对路径，设定值与环境强耦合（可移植性差）。
E
传感器 / 评估环（E 环）——测"当前执行是否达标"
评估/传感器承担角色：在官方 dsh「E 环近开环、无独立 critic」的基线上，装配层迁入 opencode 侧的领域级评估栈——
oc_architect+architecture-judgment（含 _private/gate_architecture.py ADR schema 门控）、oc_requirement+需求分层定档工具、oc_search 证据包与信源分级、criterion-design-validation。E 环由此从 2.0 升至 4.0（Δ+2.0，达反转阈值）——v1.4 的抑制项已被 run_gate 窄通道消解。关键机制
- 架构域自动门控：
architecture-judgment/_private/gate_architecture.py --kind adr|boundary对oc_architect产出做 schema + 知识图谱机检，PASS 前不得交付、FAIL 原样回传修正≤2 轮、不得降级为口头通过（cordis.patch.yml:143、:147）。 - 需求域定档工具：
requirement-discovery/_private/local-bindings.json:5绑定check_tier_conditions.py，机械定档而非「看难度」裁量；工具不可用必须标 FAIL（cordis.patch.yml:152-157）。 - 信源分级传感器：
persona.md:100-110规定依赖外部事实的结论必须先搜索并打开原始页面、区分「已验证事实/基于证据的推断/尚不确定」、重要结论 ≥2 独立来源交叉验证；oc_search（cordis.patch.yml:346-368，allowweb_search/web_fetch）把「外部信息是否可信」外包给专职 Agent 并输出结构化证据包。 - 判据可信度方法论：
criterion-design-validationskill（~/.dsh/skills/opencode/criterion-design-validation/）专治假绿/假跑/恒真判据——正是本轮第 11 项 FAIL 的处置依据。 - 验证优先纪律：
persona.md:59-64规定「没有新鲜的验证证据，不得声称完成」；cordis.patch.yml:160进一步规定「门控全绿/产物被验收/流程走完一律不得当作已达成」。 - 门控执行通道（v1.5 新增，ADR-010）：三 preset 各 +1 顶层
gate-runner行（本地插件dsh-opencode-gate-runner），注册模型可见的窄工具run_gate，为产出方恢复了门控脚本执行能力；参数面受限（脚本路径 + argv 数组，roots / 扩展名白名单，超时 120s / 600s，输出 16KB 封顶后 spill），负向用例 18→30 条。 - ✅ v1.4 抑制项已消解：v1.4 记「门控脚本依赖
bash，而 dsh 子 Agent 无bash工具（各 worker 的toolFilter.deny整条禁掉 shell，cordis.patch.yml:318等）→ 门控无法在子 Agent 内自跑，只能由主 Agent 串行执行且需danger-full-access档（:148）」——该抑制项已消解，E 环达反转阈值。对比 opencode 侧同名栈可自跑门控，这边 v1.5 亦判反转。
控制论映射：KT-ctrl-006（强校验降低对基座模型误差敏感）/ KT-ctrl-035（DOB 式在线评估外部偏移，
oc_search 交叉验证）/ KT-ctrl-012（观测噪声 R，信源分级=按可信度加权）/ KT-ctrl-001（E 环是闭环开关）。强——补上了官方最弱环的主要缺口：架构产出有 schema 自动门控、需求定档机械化、外部事实有专职核查管线与信源分级、判据本身有可信度方法论；v1.5 的
run_gate 窄通道更把「门控能不能在产出侧跑」这一硬缺口补回（含 30 条负向用例）。弱——①覆盖仍是领域级单点（架构/需求两域），无通用独立 Critic 对「语义是否达标」做强验证；②门控执行通道虽已恢复，但独立验证方（critic）未分离——产出与验证仍在同一 Agent 会话内；③信源分级是准则而非自动门控，执行仍靠自律。
T
执行器 / 工具环（T 环）——工具调用容错与安全约束
工具调用/执行器承担角色：在官方内核「三瀑布工具管线 + 超时看门狗 + spill + 审批仲裁」之上，装配层以「permission 5 档 + 工具面按 preset 收敛 + 各 worker
toolFilter 最小授权」做收口——不是扩容，而是把执行器边界按模式与角色重新划分。关键机制
- permission 5 档：
~/.dsh/profiles/web/cordis.patch.yml:240-264整表重述，新增opencode-plan（sandbox read-only）与opencode-build（sandbox workspace-write）两档，原有三档逐字保留；defaultPreset由read-only改为opencode-plan；新增两档是审批档（approval: ask）而非隔离档。 - 门控执行窄通道（v1.5 新增）：三 preset 顶层各 +1
gate-runner行，注册受限工具run_gate（脚本路径 + argv 数组、roots/扩展名白名单、超时 120s/600s、输出 16KB 封顶后 spill）——执行器面新增一条受约束的脚本执行通道，而非放开 shell。 - 工具面按 preset 收敛：内置
standard31 工具 /opencode-standard37（含 6 个oc_*）/ creator 40（+cordis_inspect_*+plugin_manager）/ ptc 1（仅run_code，PTC 呈现）。 plugin_manager三态收口：standard 硬禁（cordis.patch.yml:436-438disabled: true）、creator 条件启用（:867-869disabled: !!js "!ctx.get('profileContext')"）、ptc 硬禁（:1303-1305）；插件计数 188 → 191（三 preset 行enabled=true，fiberPhase=active）。- worker 工具隔离：7 个 worker 各自
toolFilter——oc_explore/oc_search走 allow 白名单（只读 + 检索），其余走 deny（禁 shell /todo_write/ask_user_question）；平台互斥的 shell deny 用!!js取字符串（写成数组会触发z.array(z.string())失败、整 preset 报 broken）。 - 内核继承的执行器护栏：三瀑布管线（pre/execute/post）、per-tool deadline 看门狗、spill 输出限幅、审批仲裁、协作式取消。
- 迁移相对损失：opencode 侧的命令级 bash deny 与
external_directory白名单未迁移（README §4#1/#5）——只剩档位级 sandbox，执行器精度下降一档。
控制论映射：KT-ctrl-034（硬约束限幅+看门狗）/ KT-ctrl-033（冗余与仲裁，permission 档与 worker 白名单分工）/ KT-ctrl-031（鲁棒稳定，默认档
opencode-plan + 沙箱 enforcement=full 下 read-only/workspace-write 真强制、不可用即 fail-closed）/ KT-ctrl-030（模型不确定性，approval: ask 为不确定动作留降级）。强——内核执行器本就最强，叠加 5 档 permission 与 worker 级最小授权后边界更清晰；工具面按模式收敛（37/40/1）使模式语义明确；
run_gate 以「窄参数面 + 负向用例」的方式补回脚本执行通道，未牺牲隔离。弱——①命令级 deny 与 external_directory 白名单在迁移中丢失（README §4#1/#5）；②MCP 生态为 0（对比 opencode-custom 侧 4 个，是净损失）。✅ v1.5 事实更正：v1.4 记「本机无沙箱后端 → read-only/workspace-write 一律 fail-closed、唯一可跑档是 danger-full-access」已证伪——bwrap 已装、链选中 bwrap、enforcement=full，read-only / workspace-write 在 shell + fs 双侧真强制。⚠️ 但这是环境事实更正，不是装配层新增隔离能力 ⇒ 沙箱维仍 4/4（Δ0），⛔ 不得计作装配层收益。
M
记忆 / 状态估计环（M 环）——会话记忆与跨会话长期记忆
记忆/状态估计承担角色：继承官方内核的事件溯源记忆栈（append-only session + 投影纯函数折叠 + token-meter + compaction），并在 v1.5 补上跨会话记忆层——R 环 R-A 载体落地（ADR-012，门控 6/6）：
~/.dsh/MEMORY.md 成为 dsh 侧的长期记忆正文载体，~/.dsh/reflection/candidates/ 成为候选池，dsh-reflection skill 承载零和预算 / 生命周期五件 / 容量口径。M 环由此 4.0 → 4.5（Δ+0.5，增强）。关键机制
- 内核记忆继承：事件溯源 session（
session-format v4代际迁移）、SessionProjectionRegistry投影折叠、dsh-token-meter回放感知计量、compaction-basic+tool-result-pruner压力压缩、session-query/FTS5 跨会话检索。 - 装配层的 compaction 配置：
cordis.patch.yml:236-252装配 compaction 组，tool-result-pruner设thresholdChars: 8192 / headChars: 4096 / tailChars: 1024（与 opencode 侧 3000 字符阈值不同，persona 第 15 节明确禁止照抄旧阈值）。 - 记忆纪律（v1.5 已改写）：
persona.md:94-98原规定全局记忆库~/.config/opencode/MEMORY.md只读、不常驻上下文（append-only 变化文件会让系统前缀反复变化、缓存失效，故按需read）——该纪律针对 opencode 侧资产，v1.5 下 dsh 侧已有自己的记忆正文~/.dsh/MEMORY.md（只记存在性与容量，正文不入快照、不入公开库，契约 §2.7③）。 - ✅ R-A 载体落地（v1.5，ADR-012，门控 6/6）：
~/.dsh/MEMORY.md存在（14 个§段 / 10815 B / 57 行 / 14 条[src:]签名）+~/.dsh/reflection/candidates/15 份候选 +archive/1 份 +dsh-reflectionskill 承载零和预算 / 生命周期五件 / 容量口径（memory_capacity_check.py）。写入链 = 候选 → 主 Agent 审阅 → 落库（显式链，非自动自省）。⇒ v1.4 的「装配层未新增跨会话记忆」「记忆只能读不能写」已被推翻。 - 配置正确性的一次修正：宿主
personaPrefix原写作persona:（不在dsh-system-prompt的 config schema 内）→ 等于从未生效；2026-10-10 改为personaPrefix:并改用会话日志取证验证（cordis.patch.yml:5-7）。
控制论映射：KT-ctrl-011（卡尔曼式预测-更新，投影=update、token-meter 压力=可观测性门）/ KT-ctrl-014（信息滤波/降维，结构化压缩与 tool-result 裁剪）/ KT-ctrl-010（状态估计，事件溯源折叠）。仍缺：KT-ctrl-013（分离性）与自动自省式学习（写入为显式人工审阅链，故不取 5.0）。
强——内核事件溯源提供极高状态保真度与可回放性，压缩参数与 dsh 实际阈值对齐（未照抄 opencode）；v1.5 补上跨会话长期记忆载体（
MEMORY.md + 候选池 + 退役/归档），使 M 环从「只读单向通道」变为可写闭环。弱——⚠️ 机制齐备但内容体量小（14 段 / 10.8 KB），且写入为「候选 → 主 Agent 审阅 → 落库」的显式链，非自动自省；R-A 载体仍处早期，覆盖度与陈旧引用治理依赖机检（memory_capacity_check.py）。
P
规划 / 分层环（P 环）——慢/快双速 + 专职 worker 编队
规划/分层控制承担角色：在官方「plan-mode 慢规划 + goal 滚动 + subagent 多级委派 + workflow/ralph」之上，装配层以「+7 专职 worker +
oc_* 别名 + delegation 编队（12 子行）+ 全局控制面」把通用委派升级为具名编队。关键机制
- 7 worker 与工具别名：
cordis.patch.yml:253-416（standard）定义 delegation 组 ——general→subagent、explore→oc_explore、architect-worker→oc_architect、requirement-discovery-worker→oc_requirement、search-worker→oc_search、reflection-worker→oc_reflection、pdf-worker→oc_pdf；worker persona 单一来源是~/.config/opencode/opencode.jsonc的agent.<name>.description。 - 全局控制面：
tool-subagent-control+list-agents（cordis.patch.yml:259-262）提供send_message/interrupt_agent/list_agents—— 父层对子层有持续干预通道（不止「一次性委派」）。 - 深度控制的双实现：worker 均省略
maxDepth（省略读 Host 默认 1，可被委派），「不可再往下委派」由各 worker 的toolFilter.deny（含subagent_fork与 6 个oc_*）承担。旧写法maxDepth: 0会让 worker「一调用即报错」，已修正并加三条负向用例（verify_bundle.py:366-398）。 - 编队规模：v1.4 报 standard 顶层 21 行 / 展开 34 行，creator 22/35，ptc 22/35；v1.5 三 preset 各 +1 顶层
gate-runner行（⇒ 顶层行数各 +1，展开子行数不变，verify_bundle展开后子行校验面仍为 43 行）。v1.5 现跑读数见1011-全面适配性迁移分析/evidence/r11-final-gates.out.txt（⛔ 本画像不自行推算顶层行数）。 - 模式化规划能力：ptc 模式下
workflow-ptc与tool-workflow双禁（cordis.patch.yml:1278-1285）——该模式的规划路径被刻意收窄为「单run_code+ 直接推理」。 - 内核 P 环继承：plan-mode（
exit_plan_mode提交计划）、goal/goal-round-driver（持久目标滚动）、workflow（JS 编排）、ralph、jobs、schedule。
控制论映射：KT-ctrl-042（多层递阶控制，主 Agent 编排 + 7 具名 worker + 全局控制面）/ KT-ctrl-044（MPC 滚动时域，goal-round 续跑 +
send_message 干预）/ KT-ctrl-043（时间尺度分离 ε，慢 plan / 快 build / worker 编队）/ KT-ctrl-046（options/SMDP，worker 即高层动作原语）。强——通用委派升级为具名编队（按任务性质选最贴合的 worker），全局控制面提供持续干预而非一次性委派，深度控制由 deny 而非有害的
maxDepth: 0 承担（含负向用例）。弱——仍是「一次切换 + 人工介入」，缺 MPC 式自动滚动重规划；编排拓扑靠 YAML 声明而非可视化约束；ptc 模式下编队被整体禁用，编队能力与模式强绑定。
R
反思 / 反馈闭环环（R 环）——R-A 载体落地，闭环已接通
反思/反馈闭环承担角色：官方 dsh 的 R 环本已中弱（3.0，以错误重试 / 提醒 / hook steer / 目标续跑为主，缺独立误差计算）。v1.4 记「装配层没有补强它，反而暴露了一处迁移损失（反思写入链在 dsh 侧整体缺席）」。v1.5 该结论已被推翻：ADR-012 落地 R-A 文件载体（门控 6/6），反思链由「断裂」变为「可用」——
oc_reflection 不再「只能分析、不能落库」，而是「分析 → 产出候选 → 主 Agent 审阅 → 落库」的显式闭环。R 环由此 3.0 → 4.0（Δ+1.0，增强）。关键机制
- ✅ 候选 → 审阅 → 落库显式链（v1.5，ADR-012）：
~/.dsh/reflection/candidates/（15 份候选）+archive/（1 份）→ 主 Agent 审阅 → 落库到~/.dsh/MEMORY.md（14 个§段 / 10815 B / 57 行 / 14 条[src:]签名）。v1.4 记「提供reflection_add/reflection_mark的dsh-reflection插件已于 2026-10-10 随批次移出 → persona 的 MEMORY/reflection 段在 dsh 侧不可用」——该断链已由载体层修复（不再是插件工具面，而是文件载体 + skill 方法论）。 - ✅ 零和预算 + 生命周期五件 + 容量口径：
dsh-reflectionskill 承载 —— 零和预算（新增必配平退役）、生命周期五件（准入去重 / 退役三态 / 陈旧引用机检 / Coverage-Citation 双机检 / 零和）、容量口径memory_capacity_check.py。 - 写入是显式链，不是自动自省：落库需主 Agent 审阅裁决（非模型自省后自动写入）——这是 R 环判「增强」而非更强的边界所在。
oc_reflection的语义：cordis.patch.yml:369-386定义oc_reflection；v1.4 记其 persona 声明「generates Memory/Skill entries」而实际「不能写记忆」= 声明与能力不一致——v1.5 下「产出候选」已是链路的第一段（候选目录真实存在），声明与能力的落差缩小但未归零（worker 仍不直接落库，落库归主 Agent）。- 内核 R 环继承（仍可用）：
llm-retry错误重试与退避、hooks的agent/turn-stoppingdeny→steer 强制续跑、repeat-tool-reminder同参重复提醒（只 enrich）、goal-round-driver状态变化驱动的迭代。 - 局部纠偏（非闭环）：架构门控 FAIL 回传修正≤2 轮（
cordis.patch.yml:147）属单点执行纠偏，未接入跨会话反思链路。 - 迁移状态机检：
verify_bundle第 19 项把「R 环载体」纳入迁移状态判据（E3 residue / 陈旧断言 / E7 互斥 / R 环载体），使「闭环是否真接通」成为可复算判据而非叙述。
控制论映射：KT-ctrl-002（负反馈闭环，hooks deny→steer = 实际 y 超限时强制校正）/ KT-ctrl-020~023（PID，仅存 P + 弱 D）。仍缺：KT-ctrl-021/I（积分项——无「反复犯同一错误」的自动跨会话累积补偿；零和预算提供了配平但非自动积分）/ KT-ctrl-004（独立算误差 e=r−y 环节仍不独立于产出方）/ KT-ctrl-025（稳态误差/超调验收）。
强——v1.5 最大的口径反转：R-A 载体（
MEMORY.md + 候选池 + 归档）使反思链从断裂变为接通，且配了零和预算 / 生命周期五件 / 容量机检，闭环有可复算判据（check 19）；内核侧 steer/retry 仍在。弱——闭环是「显式人工审阅链」而非自动自省：落库依赖主 Agent 裁决，无自动积分项；候选池 15 份、MEMORY.md 14 段（10.8 KB）体量仍小；oc_reflection 仍不直接落库（声明与能力的落差缩小但未归零）。Σ
七大核心环强弱总评
| 环 | 承担角色 | 强度 | 主控概念 |
|---|---|---|---|
| 设定值 | persona 15 节 + plan-mode 逐题访谈 + 三层触发规则 + 委派契约 + 命令注册（/arch /rd /reflection） | 最强（5.0；Δ+0.5 增强，已封顶） | KT-ctrl-045 规划-执行解耦 |
| E 评估 | oc_architect+gate_architecture.py / oc_requirement 定档 / oc_search 证据包 / 信源分级 / run_gate 门控通道 | 中（4.0；Δ+2.0 反转；门控已可自跑，但独立 critic 未分离） | KT-ctrl-035 扰动观测器 |
| T 执行 | permission 5 档（defaultPreset=opencode-plan）+ 工具面收敛（37/40/1）+ worker 最小授权 + run_gate 窄通道 | 最强（5.0；Δ0 持平，已封顶） | KT-ctrl-034 限幅/看门狗 |
| M 记忆 | 内核事件溯源 + 投影 + compaction + R-A 载体（~/.dsh/MEMORY.md 14 段 / 候选池 15 份 / 归档 1 份） | 次强（4.5；Δ+0.5 增强） | KT-ctrl-011 卡尔曼式滤波 |
| P 规划 | plan/goal 双速 + 7 具名 worker + 全局控制面 + 深度 deny | 最强（5.0；Δ+0.5 增强，已封顶） | KT-ctrl-042/044 递阶 + MPC |
| R 反思 | 内核 steer/retry + R-A 载体：候选 → 主 Agent 审阅 → 落库（零和预算 / 生命周期五件 / 容量口径） | 中（4.0；Δ+1.0 增强，闭环已接通；写入为显式链非自动自省） | KT-ctrl-002 负反馈闭环（已接通） |
★
控制论画像总结
整体范式：整体范式：在官方 dsh 的强执行器/强规划内核之上，把 opencode 的行为纪律、skill 库与角色编队整体搬进 preset 声明层，并在 v1.5 用「
run_gate 门控通道 + R-A 记忆载体 + dsh-config 能力包」把 v1.4 的两处掉队追平——SP/P/T 三环处 5.0 上限，E 环达反转（+2.0），M 环 4.5，R 环由「断裂」变为「接通」（4.0），形成「内核继承 + 装配层迁移 + 迁移损失二次追平」的装配控制器。- 最突出的环：T 环（执行器安全）与 P 环（具名编队）、SP 环（设定值）——三者均处 5.0 上限：T 环在官方三瀑布 + 看门狗之上叠加 5 档 permission 与 worker 级最小授权，v1.5 另加
run_gate窄通道（窄参数面 + 30 条负向用例）；P 环把通用委派升级为 7 具名 worker + 全局控制面（send_message/interrupt_agent/list_agents），并以toolFilter.deny（而非有害的maxDepth: 0）承担「不可再委派」；SP 环以 persona 15 节 + 命令注册（/arch/rd/reflection）把设定值入口显式化。 - 最弱环：R 与 E 并列 4.0——⚠️ v1.4 的「最弱环转移到 R」已被推翻：官方最弱环 E（2.0）经领域级门控 +
run_gate执行通道升到 4.0（Δ+2.0，反转）；R 经 R-A 载体由 3.0 升到 4.0（Δ+1.0）——不再存在单一最弱环。与opencode-custom（E/R 双反转）的对照结论也随之修正：同一装配层迁移到 dsh，v1.5 下 E 与 R 亦双双达反转/增强。 - 关键增强：SP / M / P / R 四环（Δ+0.5 / +0.5 / +0.5 / +1.0）——persona 15 节把 GATE/COMPLEXITY 自评、契约驱动委派、留档 5 段模板固化到 preset 层（设定值纪律从「提示词约定」变成「preset 声明」，模式切换即生效）；R-A 载体使 M 环从「只读单向通道」变为可写闭环。
- 关键反转：E 环（Δ+2.0）——迁入架构门控（
gate_architecture.pyADR schema）、需求分层定档、oc_search证据包与信源分级；v1.5 的run_gate窄通道（ADR-010）为产出方恢复了门控脚本执行能力，消解 v1.4 的抑制项「门控脚本依赖 bash 而子 Agent 无 bash」⇒ 达反转阈值。仍为领域级覆盖（架构 / 需求两域），且独立 critic 未分离，故不取 4.5+。 - 关键追平：R 环（Δ+1.0，由迁移损失变为已接通）——ADR-012 落地 R-A 文件载体：
~/.dsh/MEMORY.md（14 段 / 10815 B / 14 条[src:]）+~/.dsh/reflection/candidates/15 份候选 +archive/1 份 +dsh-reflectionskill（零和预算 / 生命周期五件 / 容量口径）。v1.4 的「反思写入链断裂、oc_reflection能分析不能落库」已推翻；写入链是显式链（候选 → 主 Agent 审阅 → 落库），非自动自省。 - 双层遮蔽的设定值治理：preset persona（12066 B / 6524 字符，v1.4 为 15403 B / 8018 字符）遮蔽宿主
personaPrefix（2790 字符），后者成为死配置——由 A12 三条命题 + 5/5 负向用例取证；代价是每次请求的 persona 税，且 PTC 模式下 persona §二 的工具清单成为空指向。 - 精装度 3.6 → 3.9（Δ+0.3）——8 维中 memory 一维提升（4→5，权重 10% ⇒ +0.10），skill 维维持 4（主根 45→49、模型可见 42→46，档位未变），其余六维与官方同值；口径诚实：v1.3 前的单点分 2.5 与本轮 8 维分不同源、不可相减；档位仍「成品化受限」，未跨档。封顶主因是不可移植的手动 bundle 与宿主 0 MCP 配置。⚠️ 沙箱维分值未变（4/4）——v1.4 的「本机无沙箱后端」断言已证伪，但那是环境事实更正、非装配层收益。