Parent
方案基线
jinjunnn/alpha-code#724 的 CLOSE_DECIDE(2026-08-17 关闭)§9 第 1 条。本票正文的「负责 / 边界 / 必修 / 退出」逐字取自该基线,未新增任何 AC 或准入条件。
证据基线:alpha@ec0890f6f1e6b41a1e1438177de9482e7bdbfde2(2026-08-15)。
为什么现在才建
#724 于 2026-08-17 关闭时写明「CODE/VERIFY 按文中 3+1 子票推进」,但这三张 CODE 票从未被创建。两条独立检索轴(标题检索 + Project 全量枚举)于 2026-08-25 确认:REQ-131 名下只有 #723 / #724 / #725 / #726。
后果是结构性的 —— #724 的关闭语义写着:
#723 只有在三个 CODE、#725 均关闭且 AC1–AC12 逐证据由验收人手工 PASS 后才可关闭。
⇒ 父需求的退出条件指向三个不存在的东西,REQ-131 按现状永远关不掉。
负责(基线原文)
三态 resolver、结构化 class/service/tool selector、cap/ask/approval 合成、账户/工作区/会话隔离、binding guard、版本/quarantine。
边界(基线原文)
共享 schema / core policy contract、V1 Permission/Config、config/managed.ts。
必修(基线原文)
packages/opencode/src/config/managed.ts:31-32 的 OPENCODE_TEST_MANAGED_CONFIG_DIR || systemManagedConfigDir() 不能再替换系统 managed 目录;测试目录只能 additive 且优先级更低,或仅经测试注入。负向闸必须证明「env 存在时系统 managed deny 仍生效」。
退出条件(基线原文)
真实 Permission 测试证明 always discharge ask、deny 不可突破;文档影响同步;bin/check 绿。
已实测的用户可观察缺陷(本票落地即应消失)
jinjunnn/alpha-code#1122(P1)—— #725 双咽喉取证量到:
- B13:会话 A 点「总是允许」后,会话 B 调同一工具不再询问(真 MCP server 的
tools/call 计数 1→2)。approved 不带 sessionID,住在 instance 级 InstanceState,同项目实例下所有会话共用。
- B9:先在
ask 态点「总是允许」,再把同一 identity 收紧成 deny,仍然放行。evaluate()(permission/index.ts:85-95)对 [...ruleset, ...approved] 取 findLast,approved 排在 ruleset 之后 ⇒ 赢过任何 deny 规则。
⚠️ #1122 不要单独打补丁。 基线 §2 明写「不另造第四种状态,也不另造第二个审批引擎」——症状级修复正好会撞上这条。它归本票的「cap/ask/approval 合成 + 会话隔离」。
Out of scope(基线 §10)
不重定义 #731 的 ToolIdentity/canonical/authority;不新增 alias 反解、URL identity 或第二 schema;不替换现有 read/edit/bash ability permission、web-search sovereignty/kill-switch 或服务端 entitlement(只能与它们取交集);不切引擎代次。
复杂度
M(基线已定方案,边界指名到文件)。
Parent
方案基线
jinjunnn/alpha-code#724的 CLOSE_DECIDE(2026-08-17 关闭)§9 第 1 条。本票正文的「负责 / 边界 / 必修 / 退出」逐字取自该基线,未新增任何 AC 或准入条件。证据基线:
alpha@ec0890f6f1e6b41a1e1438177de9482e7bdbfde2(2026-08-15)。为什么现在才建
#724于 2026-08-17 关闭时写明「CODE/VERIFY 按文中 3+1 子票推进」,但这三张 CODE 票从未被创建。两条独立检索轴(标题检索 + Project 全量枚举)于 2026-08-25 确认:REQ-131 名下只有#723/#724/#725/#726。后果是结构性的 ——
#724的关闭语义写着:⇒ 父需求的退出条件指向三个不存在的东西,REQ-131 按现状永远关不掉。
负责(基线原文)
三态 resolver、结构化 class/service/tool selector、cap/ask/approval 合成、账户/工作区/会话隔离、binding guard、版本/quarantine。
边界(基线原文)
共享 schema / core policy contract、V1 Permission/Config、
config/managed.ts。必修(基线原文)
packages/opencode/src/config/managed.ts:31-32的OPENCODE_TEST_MANAGED_CONFIG_DIR || systemManagedConfigDir()不能再替换系统 managed 目录;测试目录只能 additive 且优先级更低,或仅经测试注入。负向闸必须证明「env 存在时系统 managed deny 仍生效」。退出条件(基线原文)
真实 Permission 测试证明 always discharge ask、deny 不可突破;文档影响同步;
bin/check绿。已实测的用户可观察缺陷(本票落地即应消失)
jinjunnn/alpha-code#1122(P1)——#725双咽喉取证量到:tools/call计数 1→2)。approved不带sessionID,住在 instance 级InstanceState,同项目实例下所有会话共用。ask态点「总是允许」,再把同一 identity 收紧成deny,仍然放行。evaluate()(permission/index.ts:85-95)对[...ruleset, ...approved]取findLast,approved 排在 ruleset 之后 ⇒ 赢过任何 deny 规则。#1122不要单独打补丁。 基线 §2 明写「不另造第四种状态,也不另造第二个审批引擎」——症状级修复正好会撞上这条。它归本票的「cap/ask/approval 合成 + 会话隔离」。Out of scope(基线 §10)
不重定义
#731的ToolIdentity/canonical/authority;不新增 alias 反解、URL identity 或第二 schema;不替换现有 read/edit/bash ability permission、web-search sovereignty/kill-switch 或服务端 entitlement(只能与它们取交集);不切引擎代次。复杂度
M(基线已定方案,边界指名到文件)。