Merge Documents main into IAM U4 role authority

Why: U4 must sync main before stage 7 acceptance; main carries 21 newer commits (renderer, regulations and two-trees documents). Evidence: git merge-tree reported no conflicts; no content resolved by hand. Impact: U4 documents now sit on main 5bb4877. Refs: Dev card feature-iam-u4-role-authority
Merge the EXT-20 shared regulations extension point proposal
2026-10-18 14:03:41 +00:00 · 2026-10-18 10:04:17 +00:00 · 2026-10-18 10:03:29 +00:00 · 2026-10-18 09:57:34 +00:00 · 2026-10-18 09:52:14 +00:00 · 2026-10-17 19:56:44 +00:00
26 changed files with 1856 additions and 0 deletions
@@ -0,0 +1,150 @@
+name: governance
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+jobs:
+  governance:
+    runs-on: ubuntu-latest
+    env:
+      GOPROXY: https://goproxy.cn,direct
+    steps:
+      - name: Checkout
+        env:
+          TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          SUBMODULE_TOKEN: ${{ secrets.SUBMODULE_TOKEN }}
+        run: |
+          set -euo pipefail
+          # 只物化两个治理 gitlink（Guidelines 与 deps/development-manager），非递归；
+          # 其它 gitlink 不物化、不取回。凭据只以 URL 限定的 extraheader 存在于本进程树内。
+          python3 - <<'PY_CHECKOUT'
+          import os
+          from pathlib import Path
+          import re
+          import subprocess
+          import sys
+          from urllib.parse import urlsplit
+
+          # 服务端基址取运行器注入的 GITHUB_SERVER_URL（平台控制、候选 PR 不可影响）。
+          SERVER = os.environ.get("GITHUB_SERVER_URL", "").rstrip("/")
+          parsed_server = urlsplit(SERVER)
+          if parsed_server.scheme not in {"http", "https"} or not parsed_server.netloc:
+              sys.exit("Checkout server must be the platform-injected http(s) URL")
+          SSH = "ssh://git@git-ssh.u1680832.nyat.app:31411/weichen/"
+          # 审查过的白名单，独立于候选 .gitmodules：仅列出两个治理 gitlink。
+          REPOSITORIES = {
+              "deps/development-guidelines": "Development-Guidelines",
+              "deps/development-manager": "Development-Manager",
+          }
+          TARGET = "weichen/Agent-System-Documents"
+          root_token = os.environ.pop("TOKEN", "")
+          component_token = os.environ.pop("SUBMODULE_TOKEN", "")
+          if not root_token or not component_token:
+              sys.exit("Checkout requires TOKEN and SUBMODULE_TOKEN")
+          if os.environ.get("GITHUB_REPOSITORY") != TARGET:
+              sys.exit("Checkout repository is outside the reviewed allowlist")
+          sha = os.environ.get("GITHUB_SHA", "")
+          if not re.fullmatch(r"[0-9a-fA-F]{40}", sha):
+              sys.exit("Checkout requires a fixed commit SHA")
+
+          # 丢弃继承的 Git 追踪/配置/SSH 钩子；凭据只存在于单个 Git 进程树的精确 URL 头中。
+          clean_env = {k: v for k, v in os.environ.items() if not k.startswith("GIT_")}
+          clean_env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_SYSTEM="/dev/null",
+                           GIT_CONFIG_GLOBAL="/dev/null", GIT_TERMINAL_PROMPT="0")
+          config = {
+              "core.hooksPath": "/dev/null", "core.fsmonitor": "false",
+              "init.templateDir": "", "credential.helper": "",
+              "fetch.recurseSubmodules": "false", "submodule.recurse": "false",
+              "http.followRedirects": "false", "protocol.allow": "never",
+              "protocol." + urlsplit(SERVER).scheme + ".allow": "always",
+          }
+
+
+          def git(repo, *args, extra=None):
+              values = config | (extra or {})
+              env = clean_env | {"GIT_CONFIG_COUNT": str(len(values))}
+              for index, (key, value) in enumerate(values.items()):
+                  env[f"GIT_CONFIG_KEY_{index}"] = key
+                  env[f"GIT_CONFIG_VALUE_{index}"] = value
+              return subprocess.run(["git", "-C", str(repo), *args], env=env,
+                                    check=True, stdout=subprocess.PIPE).stdout
+
+
+          def materialize_governance(root):
+              # -r 列出任意深度的 gitlink，但不进入 submodule 内部；其它 gitlink 只记录、从不取回。
+              links = {}
+              for entry in git(root, "ls-tree", "-rz", "HEAD").split(b"\0"):
+                  if not entry:
+                      continue
+                  metadata, path = entry.split(b"\t", 1)
+                  mode, kind, commit = metadata.decode().split()
+                  if mode == "160000":
+                      links[path.decode()] = commit
+              for name in REPOSITORIES:
+                  if name not in links:
+                      raise ValueError("Governance gitlink is missing from the fixed commit")
+              raw = git(root, "config", "--no-includes", "--blob", "HEAD:.gitmodules", "--null", "--list")
+              entries = {}
+              for item in raw.split(b"\0"):
+                  if not item:
+                      continue
+                  key, value = item.decode().split("\n", 1)
+                  match = re.fullmatch(r"submodule\.(.+)\.(path|url)", key)
+                  if not match:
+                      continue
+                  name, field = match.groups()
+                  if name not in REPOSITORIES:
+                      continue
+                  if field in entries.setdefault(name, {}):
+                      raise ValueError("Duplicate candidate .gitmodules setting")
+                  entries[name][field] = value
+              # 先整体校验两个治理条目，再进行任何带凭据的取回。
+              for name, repository in REPOSITORIES.items():
+                  fields = entries.get(name, {})
+                  if fields.get("path") != name:
+                      raise ValueError("Governance submodule path is outside the reviewed allowlist")
+                  trusted_url = f"{SERVER}/weichen/{repository}.git"
+                  if fields.get("url") not in {SSH + repository + ".git", trusted_url}:
+                      raise ValueError("Governance submodule URL is outside the reviewed allowlist")
+              for name, repository in REPOSITORIES.items():
+                  url = f"{SERVER}/weichen/{repository}.git"
+                  # 仅持久化审查过的公开 URL，使 Git 在进程级配置消失后仍识别该 submodule。
+                  git(root, "config", f"submodule.{name}.url", url)
+                  git(root, "submodule", "update", "--init", "--checkout", "--", name,
+                      extra={f"submodule.{name}.url": url,
+                             f"submodule.{name}.update": "checkout",
+                             f"http.{url}.extraheader": "AUTHORIZATION: token " + component_token})
+                  child = root / name
+                  if git(child, "rev-parse", "HEAD").decode().strip() != links[name]:
+                      raise ValueError("Materialized governance gitlink does not match the fixed SHA")
+
+
+          try:
+              root = Path.cwd()
+              # 必须是干净的临时工作区；不复用既有 Git 状态。
+              if (root / ".git").exists():
+                  raise ValueError("Checkout requires a fresh workspace")
+              git(root, "init", "-q")
+              url = f"{SERVER}/{TARGET}.git"
+              git(root, "remote", "add", "origin", url)
+              git(root, "fetch", "--depth=1", "origin", sha,
+                  extra={f"http.{url}.extraheader": "AUTHORIZATION: token " + root_token})
+              git(root, "checkout", "-q", "--detach", "FETCH_HEAD")
+              materialize_governance(root)
+          except (ValueError, OSError, subprocess.CalledProcessError) as error:
+              sys.exit(f"Checkout refused: {error}")
+          print("Checkout complete; credentials were not persisted in Git configuration")
+          PY_CHECKOUT
+          unset TOKEN SUBMODULE_TOKEN
+      - name: Install Go 1.27.1
+        run: |
+          set -euo pipefail
+          curl -fsSL -o "$RUNNER_TEMP/go.tgz" https://mirrors.aliyun.com/golang/go1.27.1.linux-amd64.tar.gz
+          tar -C /usr/local -xzf "$RUNNER_TEMP/go.tgz"
+          ln -sfn /usr/local/go/bin/go /usr/local/bin/go
+          ln -sfn /usr/local/go/bin/gofmt /usr/local/bin/gofmt
+      - name: Validate agent execution configuration
+        run: scripts/agent-exec validate --repo .
+      - name: Governance check
+        run: scripts/dm governance check --repo .
@@ -0,0 +1,6 @@
+[submodule "deps/development-guidelines"]
+	path = deps/development-guidelines
+	url = ssh://git@git-ssh.u1680832.nyat.app:31411/weichen/Development-Guidelines.git
+[submodule "deps/development-manager"]
+	path = deps/development-manager
+	url = ssh://git@git-ssh.u1680832.nyat.app:31411/weichen/Development-Manager.git
@@ -0,0 +1,57 @@
+# Agent-System-Documents 采纳 development-governance-v2 治理套件 任务卡
+
+任务主记录：[Agent-System-Documents PR #110](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/110)（本文件随 PR 描述维护）。
+状态：已完成（闭合随本 PR 合入；合入以平台记录为准）；owner：weichen。
+
+## 基线与授权
+
+- 权威仓：weichen/Agent-System-Documents；root_target：main；immediate_target：main
+- branch_kind：initiative；initiative_id：governance-adoption-Agent-System-Documents
+- R0（initial_main_sha）：da4d016ee1dee6a418411ed0f8b45911fe9aab02；工作区：/home/weichen/projects/Agent-System-Documents-wt-feature-governance-adoption（worktree）；分支：feature/governance-adoption
+- 父任务信息（仅子任务填写）：无
+- accepting_requirements：false（单仓采纳 initiative，范围固定为下列十步，不接收新需求）
+- 需求分流：verdict=NEW；selected_initiative=无；候选=无；理由=development-governance-v2 Phase 6 每个正式仓库独立 initiative；triage 收据=无（本仓采纳前尚无 triage 入口）
+- 授权与交付终点：owner 已授权 development-governance-v2 全部实施（Agent-System-Dev 主记录 docs/superpowers/plans/2026-10-16-development-governance-v2-master.md）；终点为本 PR 合入 main 且采纳状态 active。分支保护与 tag 由用户执行。
+- 实施执行：agent-per-unit（配置：AGENT-EXECUTION.md；外部 Agent 一单元一新进程/会话/工作区）
+
+## 目标与非目标
+
+目标（Phase 6 十步）：固定 Guidelines SHA（deps/development-guidelines @ 2688fd2be6a52c0bf110e7e6366b6f291ab5e4eb）；增加 AGENT-EXECUTION.md；增加共享执行器薄入口（deps/development-manager @ bd3a7de57a3a9e1a4495b94c5fa5c08d71e7be8c + scripts/dm、scripts/agent-exec、scripts/task）；四条路由（implementation/repair/test/review）；任务卡模板与分支元数据；CI 中启用 schema 校验（.gitea/workflows/governance.yml：agent-exec validate + governance check）；一次正例运行；负例（缺配置、坏收据、越界路径、未知副作用）；独立 Review + CI；采纳状态 active。
+
+非目标：不改业务代码与既有测试；不改分支保护（由用户执行）；不发布 tag。
+
+引导说明：AGENT-EXECUTION.md 由 host 以固定版本治理套件（dm-server governance init @ bd3a7de57a3a9e1a4495b94c5fa5c08d71e7be8c）生成并作为引导配置提交（执行器运行前必须存在有效配置；沿用 DM 采纳先例）；其余文件由实施单元生成。
+
+## Agent 实施收据
+
+| 单元 ID | 预期范围 | 角色 | 候选顺序 | attempt | CLI/模型 | 终态 | transport | fallback | 源码外收据路径 |
+|---|---|---|---|---|---|---|---|---|---|
+| governance-adoption-Agent-System-Documents-r1 | 13 个允许路径（治理文件 + 两个 gitlink） |  | implementation | cursor→antigravity→pi | run 3a6bdcf3（dm-server pinned，attempts=1） | cursor / not-observable | failed-unknown | 无（apply 快进） | 否 | /tmp/gov-receipt-Agent-System-Documents-r1.json |
+| 对账（r1） | 规范 worktree 仍为 d259242 且干净；无 transport ref。worker 自报外部副作用：并行 worker 共用固定文件 /tmp/gov-scratch-path.txt 记录 scratch 路径，该文件被覆盖后误删非本单元创建的仓外临时目录 /tmp/tmp.2FlZqPmOJM（不可恢复；各单元私有工作区不在该路径，已完成单元收据均为 success） | — | — | — | — | — | failed-unknown 对账完成；单元包追加禁止固定共享 /tmp 路径约束后全新运行 r2 | — | — | — |
+| governance-adoption-Agent-System-Documents-r2 | 13 个允许路径（治理文件 + 两个 gitlink） | cf44b1ed | implementation | cursor→antigravity→pi | run 8348cbe4（dm-server pinned，attempts=1） | cursor / not-observable | success | fd13a266777b（apply 快进） | 否 | /tmp/gov-receipt-Agent-System-Documents-r2.json |
+| governance-adoption-Agent-System-Documents-repair-r1 | PROJECT.md、policy/guidelines-adoption.md | repair | cursor→antigravity→pi | run cddbee35（attempts=1） | cursor / not-observable | success | 31daf7f76493（apply 快进） | 否 | /tmp/gov-receipt-Agent-System-Documents-repair-r1.json |
+
+## 同步记录
+
+| 节点 | sync_base_sha | tested_head_sha | checked_at | 结果 |
+|---|---|---|---|---|
+| 启动 | da4d016ee1dee6a418411ed0f8b45911fe9aab02 | da4d016ee1dee6a418411ed0f8b45911fe9aab02 | 2026-10-17T07:16:27Z | 一致 |
+| 请求审核 | da4d016ee1dee6a418411ed0f8b45911fe9aab02 | 6a1308c2510e | 2026-10-17T08:47:50Z | 已含 origin/main |
+
+## 结果与验证（完成后填写）
+
+- 结果：治理套件已采纳——Guidelines 与 Development-Manager gitlink 固定、AGENT-EXECUTION.md 四条路由、共享执行器薄入口、pre-commit admit、governance CI；采纳状态 active 随本 PR 合入生效。
+- 验证：见下表（命令输出由 /tmp/gov-neg/ev.sh 写入 .task/evidence/governance-adoption/，SELF 除非另注）。
+- 复现：正负例脚本冻结副本 Agent-System-Dev `docs/superpowers/plans/evidence/governance-adopt-cases.py`（sha256 3aa1bf6ea1cd48f3f59c0a307620e4112389a93fe21a113006f54e62eb8f0d06），用法 `python3 governance-adopt-cases.py <仓库根>`；它经本仓 `scripts/agent-exec` 运行假 CLI，不访问网络。
+- 影响与剩余项：不改业务代码；本地启用钩子需由人执行 `git config core.hooksPath scripts/hooks`；将 governance 检查设为分支保护必需项属用户双钥匙事项（命令见 Agent-System-Dev 治理主记录）。
+
+| 时间(UTC) | 命令 | 被测 HEAD | exit | 来源 | 摘要/位置 |
+|---|---|---|---|---|---|
+| 20261017T074046Z | `scripts/dm governance check --repo .` | fd13a266777b | 0 | SELF | ok fixtures；[输出](../evidence/governance-adoption/00-20261017T074046Z.log) sha256:0ff0ec3150c5162e |
+| 20261017T074046Z | `scripts/agent-exec validate --repo .` | fd13a266777b | 0 | SELF | validate: ok；[输出](../evidence/governance-adoption/01-20261017T074046Z.log) sha256:7ba43b8b1d0ee152 |
+| 20261017T074046Z | `python3 /tmp/gov-neg/adopt_cases.py .` | fd13a266777b | 0 | SELF | [verdict] ALL PASS cases=5；[输出](../evidence/governance-adoption/02-20261017T074046Z.log) sha256:b63c5ee476cd94f5 |
+| 20261017T084129Z | `scripts/dm governance check --repo .` | 31daf7f76493 | 0 | SELF | ok fixtures；[输出](../evidence/governance-adoption/03-20261017T084129Z.log) sha256:809536ab8a8d1caa |
+| 20261017T084129Z | `scripts/agent-exec validate --repo .` | 31daf7f76493 | 0 | SELF | validate: ok；[输出](../evidence/governance-adoption/04-20261017T084129Z.log) sha256:3d3cf541ce4c6560 |
+| 2026-10-17T08:47:50Z | CI `governance / governance (pull_request)` | 6a1308c2510e | 0 | GATE | success；[运行](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/actions/runs/3593/jobs/5686) |
+| — | 候选 HEAD CI | 9d4582a47f4f | 0 | GATE | success governance / governance (pull_request)=success（/weichen/Agent-System-Documents/actions/runs/3611/jobs/5709） |
+| — | 独立 Review | 9d4582a47f4f | 0 | REPLAY | cursor-agent-stable --mode ask 全新只读会话（fresh_session=true，session id not-observable）闭合重审 VERDICT: APPROVE（对象 9d4582a，与 HEAD 仅 .task/ 不同） |
@@ -0,0 +1,19 @@
+command: scripts/dm governance check --repo . 
+cwd: /home/weichen/projects/Agent-System-Documents-wt-feature-governance-adoption
+head: fd13a266777b4c794acb879190c49ee980db38af
+exit: 0
+utc: 20261017T074046Z
+---
+ok gitlink deps/development-guidelines
+ok gitlink deps/development-manager
+ok agent-execution
+ok file AGENTS.md
+ok file PROJECT.md
+ok file policy/guidelines-adoption.md
+ok file .task/templates/task-card.md
+ok executable scripts/agent-exec
+ok executable scripts/hooks/pre-commit
+ok executable scripts/dm
+ok executable scripts/task
+ok adoption status
+ok fixtures
@@ -0,0 +1,7 @@
+command: scripts/agent-exec validate --repo . 
+cwd: /home/weichen/projects/Agent-System-Documents-wt-feature-governance-adoption
+head: fd13a266777b4c794acb879190c49ee980db38af
+exit: 0
+utc: 20261017T074046Z
+---
+validate: ok
@@ -0,0 +1,13 @@
+command: python3 /tmp/gov-neg/adopt_cases.py . 
+cwd: /home/weichen/projects/Agent-System-Documents-wt-feature-governance-adoption
+head: fd13a266777b4c794acb879190c49ee980db38af
+exit: 0
+utc: 20261017T074046Z
+---
+[object] Agent-System-Documents-wt-feature-governance-adoption HEAD=fd13a266777b4c794acb879190c49ee980db38af
+PASS positive-run-apply: run exit=0 terminal=success apply exit=0 head=876e934a0187
+PASS missing-config: run exit=2 terminal=invalid-config validate exit=2
+PASS bad-receipt: apply exit=4 head_unchanged=True msg=apply: no local integrity record: changed paths do not match the transport diff
+PASS out-of-scope-path: run exit=5 terminal=scope-expansion transport=False
+PASS unknown-side-effect: run exit=4 terminal=failed-unknown transport=False
+[verdict] ALL PASS cases=5
@@ -0,0 +1,19 @@
+command: scripts/dm governance check --repo . 
+cwd: /home/weichen/projects/Agent-System-Documents-wt-feature-governance-adoption
+head: 31daf7f7649334ddcc385ce4ba46aaca88f2f3b5
+exit: 0
+utc: 20261017T084129Z
+---
+ok gitlink deps/development-guidelines
+ok gitlink deps/development-manager
+ok agent-execution
+ok file AGENTS.md
+ok file PROJECT.md
+ok file policy/guidelines-adoption.md
+ok file .task/templates/task-card.md
+ok executable scripts/agent-exec
+ok executable scripts/hooks/pre-commit
+ok executable scripts/dm
+ok executable scripts/task
+ok adoption status
+ok fixtures
@@ -0,0 +1,7 @@
+command: scripts/agent-exec validate --repo . 
+cwd: /home/weichen/projects/Agent-System-Documents-wt-feature-governance-adoption
+head: 31daf7f7649334ddcc385ce4ba46aaca88f2f3b5
+exit: 0
+utc: 20261017T084129Z
+---
+validate: ok
@@ -0,0 +1,30 @@
+# feature/regulations-kb-ext20-proposal 任务卡
+
+任务主记录：本文件随 PR 描述维护。
+状态：已完成（合入前闭合）；owner：weichen。PR：https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/113
+
+## 基线与授权
+
+- 权威仓：ssh://git@git-ssh.u1680832.nyat.app:31411/weichen/Agent-System-Documents.git；root_target：main；immediate_target：main
+- branch_kind：standalone；跨仓总任务：Agent-System-Dev `feature/regulations-kb`（[Dev PR #614](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/614)）
+- R0（initial_main_sha）：e2f5729；工作区：/home/weichen/projects/Agent-System-Documents-wt-feature-regulations-kb-u9；分支：feature/regulations-kb-ext20-proposal
+- 授权与交付终点：用户 2026-10-18 /goal 指示按法规知识库计划实现全部内容；本任务登记 U9 的 EXT-20 扩展点提案（与 Backend `feature/regulations-kb-ext20` 实现一致），经 PR 合入 main。
+- 实施执行：agent-per-unit（配置：AGENT-EXECUTION.md）。此前分支 `feature/regulations-kb-u9-contract` 上的提案由 host 直接撰写且未经准入钩子，作废不合入，收口时删除该远端分支。
+
+## 目标与非目标
+
+- 目标：`docs/proposals/2026-10-18-ext-20-regulations-provider.md` 与 `docs/proposals/INDEX.md` 收录条目；内容与 Backend 实现的公开符号逐一一致。
+- 非目标：实现代码（Backend/KB/RDM 各自任务）。
+
+## Agent 实施收据
+
+| 单元 ID | 预期范围 | 角色 | 候选顺序 | attempt | CLI/模型 | 终态 | transport | fallback | 源码外收据路径 |
+|---|---|---|---|---|---|---|---|---|---|
+| documents-ext20-proposal | docs/proposals/2026-10-18-ext-20-regulations-provider.md、docs/proposals/INDEX.md | implementation | cursor, antigravity, pi | 1 | cursor-agent-stable / auto（session not-observable，新进程） | success | apply 快进 e4aa3c6..52d77f6 | 否 | /tmp/regkb-u9doc-receipt.json |
+
+## 结果与验证（完成后填写）
+
+- 结果：EXT-20 提案（场景、现有扩展点不可组合理由、全部公开符号与 DTO 字段、基座强制行为、兼容、验收映射、分工）与 INDEX 收录条目。
+- 验证（SELF，host 于 52d77f6）：`git diff --check` 通过；`scripts/dm governance check --repo .` ok。
+- Review：host 主模型对照 Backend `pkg/extension/regulations.go`、`internal/app/regulations.go`（PR #212 合入 56a7f9f）逐项核对，无阻塞项。
+- 影响与剩余项：仅文档。
@@ -0,0 +1,66 @@
+# <任务标题> 任务卡
+
+任务主记录：<Issue/PR 链接，或注明"本文件随 PR 描述维护">。
+状态：<进行中 / 待审核 / 已合入 / 已放弃>；owner：<填写>。
+
+## 基线与授权
+
+- 权威仓：<仓 URL 或逻辑 ID>；root_target：main；immediate_target：<main 或 feature/initiative>
+- branch_kind：<initiative | child | standalone>；initiative_id：<稳定 ID，普通任务为空>
+- R0（initial_main_sha）：<完整 SHA>；工作区：<路径>（worktree / clone）；分支：<feature|fix|hotfix/...>
+- 父任务信息（仅子任务填写）：parent_branch=<父分支>；parent_head_sha=<SHA>；parent_pr=<父 PR>
+- accepting_requirements：<true | false>（仅 initiative 可为 true；冻结后为 false）
+- 需求分流：verdict=<JOIN | NEW>；selected_initiative=<分支或无>；候选=<分支@HEAD 列表或无>；理由=<不适配/适配依据>；triage 收据=<源码外路径与摘要>
+- 授权与交付终点：<本次允许的动作与终点；未授权事项写明>
+- 实施执行：agent-per-unit（配置：AGENT-EXECUTION.md；外部 Agent 一单元一新进程/会话/工作区）
+
+## 目标与非目标
+
+<预期结果、受影响入口/模块/契约；明确不做什么。>
+
+## Agent 实施收据
+
+按根目录 AGENT-EXECUTION.md 路由；外部 Agent 一单元一新进程/会话/隔离工作区。实施、修复与测试必须通过登记的候选执行；未配置或候选安全耗尽停在 unavailable/blocked，禁止 host 隐式代写。
+
+| 单元 ID | 预期范围 | 角色 | 候选顺序 | attempt | CLI/模型 | 终态 | transport | fallback | 源码外收据路径 |
+|---|---|---|---|---|---|---|---|---|---|
+| 待定义 | — | NOT_RUN | NOT_RUN | NOT_RUN | NOT_RUN | NOT_RUN | NOT_RUN | NOT_RUN | — |
+
+## 复用材料（task-start 自动检索结果摘录）
+
+- 相关近期提交：<git log -- <paths> 命中；无则写无>。
+- 相关经验条目：<检索命中；无则写无>。
+
+## 同步记录
+
+| 节点 | sync_base_sha | tested_head_sha | checked_at | 结果 |
+|---|---|---|---|---|
+| 启动 | <R0> | <HEAD> | <日期时间> | <一致/已同步> |
+| 验收前 | <填写> | <填写> | <填写> | <填写> |
+
+字段没有发生的写"无"，不省略。本卡与 PR 描述同源：开 PR 时将"目标与非目标、结果与验证、影响与剩余项"复制进 PR 描述，不另写第二份。
+
+## 交付调度（有多个就绪任务时）
+
+- 调度记录 / entry_id / 当前 attempt_id：<平台或调度服务链接及标识；未入队写无>。
+- 入队源 HEAD / owner / 依赖：<完整 SHA、身份、依赖或无>。
+- 固定候选引用：<调度尝试中的 base/head、组件与配置；未固定写无>。
+- 窗口、最终 CI、Review 与真实合入结果：<引用调度记录及原始证据，不复制全队列>。
+
+定义见 [合入调度与 CI 分配](../standards/merge-queue.md)。本段在候选固定前整理；固定后先使用源码之外的记录保存运行结果，再按项目闭合流程回填。
+
+## 结果与验证（完成后填写）
+
+- 结果：<交付了什么；未发生写无>。
+- 验证：<结论性摘要：PASS/FAIL/SKIP/NOT_RUN 逐项；逐条证据见下表，来源标注与写入规则见 [按影响选择验证与证据](../standards/verification.md)>。
+- 影响与剩余项：<影响面、遗留风险、后续任务>。
+
+| 时间(UTC) | 命令 | 被测 HEAD | exit | 来源 | 摘要/位置 |
+|---|---|---|---|---|---|
+| <时间> | <命令；由项目 evidence 工具写入，无工具时附命令+对象 SHA+输出 digest 并标 SELF> | <HEAD> | <exit> | GATE/REPLAY/SELF | <摘要/位置> |
+
+## 回收（task-finish）
+
+- 合入核对：<分支已包含于目标分支的核对输出>。
+- 未跟踪/ignored 文件处置：<归档/可再生/存疑 逐项；无则写无>。
+- 回收动作：<worktree remove、分支删除、prune；放弃路径注明原因>。
@@ -0,0 +1,67 @@
+# Project Agent Execution Configuration
+# 项目工程 Agent 执行路由配置
+
+适用范围：定义本项目中由 AI / Agent 主导的代码实施、修复、测试与审阅所调用的 Agent CLI 路由。
+解析器识别正文中唯一一个 ```agent-execution 代码块。正文外的说明文字可根据项目需要调整。
+
+通用硬规则见 Development-Guidelines 的 [Agent 执行与协作契约](deps/development-guidelines/standards/agent-execution.md)。
+本配置为项目本地路由权威，声明具体的候选 profile、尝试次数上限、超时、集成入口与豁免路径；
+代码块须通过 `deps/development-guidelines/templates/schemas/agent-execution.schema.json` 校验后才能登记为 active。
+`fallback_to_host` 只能为 `never`；旧值 `all-unavailable` 仅供迁移工具读取，不能通过准入。
+下例的 CLI 名称、命令与路径均为占位，按项目实际执行器替换。
+
+```agent-execution
+schema: agent-execution/v1
+
+execution:
+  fresh_process_per_unit: true
+  permission: run-everything
+  fallback_to_host: never
+  max_parallel: 3
+  timeout_seconds: 7200
+  idle_timeout_seconds: 600
+  summary_bytes: 16384
+  raw_output_bytes: 10485760
+  max_attempts_per_profile: 3
+  emergency_profile: codex
+
+roles:
+  implementation: [cursor, antigravity, pi]
+  repair: [cursor, antigravity, pi]
+  test: [pi, antigravity, cursor]
+  review: [pi, antigravity, cursor, codex]
+
+profiles:
+  cursor:
+    adapter: cursor
+    executable: "cursor-agent-stable"
+    model: auto
+    enabled: true
+
+  antigravity:
+    adapter: antigravity
+    executable: agy
+    model: auto
+    enabled: true
+
+  pi:
+    adapter: pi
+    executable: pi
+    model: auto
+    enabled: true
+
+  codex:
+    adapter: codex
+    executable: codex
+    model: auto
+    enabled: true
+
+integration:
+  exempt_paths: [".task/**", "docs/superpowers/specs/**", "docs/superpowers/plans/**"]
+  transport:
+    command: "scripts/agent-exec apply"
+  admission:
+    command: "scripts/agent-exec admit"
+  cleanup:
+    command: "scripts/agent-exec cleanup"
+```
@@ -34,3 +34,23 @@
 - **SSH key**：`~/.ssh/home_gitea`（ED25519，公钥指纹
  `SHA256:GYXaOXIMeloQ1fKSfdJ/ndgPQzs/Ix7Hk62ekfkfQ20`，Gitea 侧密钥名 GMKtec）；
  `~/.ssh/config` 已有 `git-ssh.u1680832.nyat.app` 主机条目，克隆/推送直接可用。
+
+## Agent 执行与新项目准入（强制）
+
+### 新项目准入（强制）
+
+1. 缺 Guidelines 固定版本（`deps/development-guidelines` gitlink 未就绪或 HEAD 不符）时，Agent 只能只读分析，不得实施。
+2. 缺有效 `AGENT-EXECUTION.md`（`scripts/dm governance check` 未通过）时禁止 AI 实施。
+3. 缺共享执行器（`scripts/agent-exec` 或 `deps/development-manager` 不可用）时，状态为 `blocked/unavailable`，不得改由 host 替代。
+4. 不允许 host 代写实施单元；实施、修复与测试必须经 `AGENT-EXECUTION.md` 登记的候选执行。
+5. 人类直接开发按其自身授权与项目规则进行，不受本条款约束。
+6. 分支保护与规范 tag 由用户负责设置与维护，Agent 不得代为设置。
+
+入口：
+
+- 需求分流：`scripts/task triage discover|decide|verify`
+- 任务启动：`scripts/task start …`
+- PR 检查：`scripts/task pr-check …`
+- Agent 执行：`scripts/agent-exec run|apply|admit|validate`
+
+AI 实施单元仅通过 `scripts/agent-exec run` 按 AGENT-EXECUTION.md 运行，并经 `scripts/agent-exec apply` 集成。
@@ -17,3 +17,8 @@

 本仓没有可编译程序或独立业务测试套件。跨仓固定组合在 Dev 仓运行 `make test`；
 过程记录中的命令和环境须按当次任务核实，不能机械重放旧运维命令。
+
+治理检查（CI `.gitea/workflows/governance.yml` 同步执行）：
+
+- `scripts/agent-exec validate --repo .`：校验 AGENT-EXECUTION.md 的唯一 `agent-execution` 配置块，须输出 `validate: ok`。
+- `scripts/dm governance check --repo .`：只读核验治理文件与 gitlink，须只输出 ok 行。
@@ -0,0 +1,393 @@
+# Focused Role and Permission System Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Deliver the requested single-effective-role position model and enforce system, role, and per-project permissions from one server-side action catalog.
+
+**Architecture:** Backend owns roles, the single active user binding, the permission catalog, system grants, and role defaults/caps. RDM consumes that public authority while retaining project membership, project overrides, creator ownership, and existing document duties. Frontend uses Backend role APIs for the single-role and matrix views and uses RDM only for project-scoped configuration.
+
+**Tech Stack:** Go 1.27, SQLite, PostgreSQL, HTTP JSON APIs, compiled extension Host contracts, React 19, TypeScript, Vitest, Playwright.
+
+**Spec:** `docs/proposals/2026-10-15-iam-focused-role-permission-spec.md`
+
+## Global Constraints
+
+- One user has at most one effective role; one role may be assigned to many users.
+- Role and user stable IDs never change when display data changes.
+- System administrators do not gain implicit access to project business content.
+- A project creator can manage only the project they created.
+- Unknown actions, missing providers, stale versions, disabled accounts, and disabled roles fail closed.
+- Role defaults never exceed role caps; project allows never exceed role or platform caps.
+- UI configuration uses a draft, preview, and atomic batch commit; hidden rows do not lose draft edits.
+- Account recovery, multi-role bindings, Agent permissions, workflow redesign, production migration, and deployment remain outside this plan.
+
+## Review Focus
+
+- Reassigning a user while two administrators submit concurrently must leave exactly one active binding and return one conflict.
+- Disabling a role between preview and commit must reject the commit without partial writes.
+- A project creator switching from project A to B must not retain A-derived management authority in B.
+- A filtered matrix batch must contain explicit action IDs and must not apply to hidden or newly registered actions.
+- RDM provider absence or version mismatch must deny authorization and must not fall back to the legacy local role table.
+
+---
+
+### Task 1: Backend action catalog and role schema
+
+**Files:**
+- Create: `Agent-System-Backend/internal/authz/catalog.go`
+- Create: `Agent-System-Backend/internal/store/role_policy.go`
+- Modify: `Agent-System-Backend/internal/store/migrate.go`
+- Test: `Agent-System-Backend/internal/store/role_policy_migration_test.go`
+- Test: `Agent-System-Backend/internal/authz/catalog_test.go`
+
+**Interfaces:**
+- Produces: `authz.Descriptor`, `authz.DescriptorByID(string) (Descriptor, bool)`, `store.RoleRecord`, `store.RoleBinding`, and schema v35 tables.
+- Consumes: existing `users(id, owner, enabled, state_version)` and migration transaction machinery.
+
+- [ ] **Step 1: Add failing catalog tests**
+
+```go
+func TestCatalogRejectsUnknownAndProtectsManagementActions(t *testing.T) {
+    if _, ok := DescriptorByID("invented.action"); ok { t.Fatal("unknown action registered") }
+    got, ok := DescriptorByID("system.roles.manage")
+    if !ok || got.Scope != ScopeSystem || !got.Protected { t.Fatalf("descriptor=%+v", got) }
+    create, ok := DescriptorByID("project.create")
+    if !ok || create.Scope != ScopeSystem || create.Protected { t.Fatalf("project.create=%+v", create) }
+}
+```
+
+- [ ] **Step 2: Run the focused test and confirm the missing package failure**
+
+Run: `GOWORK=off go test ./internal/authz -run TestCatalogRejectsUnknownAndProtectsManagementActions -count=1`
+Expected: FAIL because `internal/authz` does not exist.
+
+- [ ] **Step 3: Implement the fixed action catalog**
+
+```go
+type Scope string
+const ( ScopeSystem Scope = "system"; ScopeProject Scope = "project" )
+type Descriptor struct { ActionID, Label, Description, Group string; Scope Scope; Protected bool }
+func DescriptorByID(id string) (Descriptor, bool)
+func Catalog() []Descriptor
+```
+
+Register only the system and project actions listed in the spec. Return copies so callers cannot mutate the registry.
+
+- [ ] **Step 4: Add schema v35 and migration tests for both dialects**
+
+Create `roles`, `role_permissions`, `user_role_bindings`, `system_grants`, `authority_state`, and `policy_receipts`. Enforce one active binding per user with a unique `user_id` key; preserve inactive history through versioned replacement rows in the same transaction. Use the existing boolean representation per dialect and foreign keys to `users(id)`.
+
+Run: `GOWORK=off go test ./internal/store -run 'TestRolePolicyMigration|TestMigrate' -count=1`
+Expected: PASS on SQLite; the existing PG migration suite later verifies PostgreSQL.
+
+- [ ] **Step 5: Commit the schema and catalog**
+
+```bash
+git add internal/authz/catalog.go internal/authz/catalog_test.go internal/store/role_policy.go internal/store/role_policy_migration_test.go internal/store/migrate.go
+git commit -m "Add the role permission catalog and schema"
+```
+
+### Task 2: Atomic role, binding, and permission store
+
+**Files:**
+- Modify: `Agent-System-Backend/internal/store/role_policy.go`
+- Test: `Agent-System-Backend/internal/store/role_policy_test.go`
+- Test: `Agent-System-Backend/internal/store/role_policy_pg_test.go`
+
+**Interfaces:**
+- Consumes: `authz.DescriptorByID`, current account state, store transaction helpers.
+- Produces:
+  - `CreateRole(actor string, in RoleCreate) (RoleRecord, error)`
+  - `PatchRole(actor, roleID string, expected int64, patch RolePatch) (RoleRecord, error)`
+  - `ReplaceRolePermissions(actor, roleID string, expected int64, changes []RolePermissionChange, key string) (PolicyReceipt, error)`
+  - `AssignUserRole(actor, userID, roleID string, expectedState int64, key string) (RoleBinding, error)`
+  - `RoleForUser(userID string) (RoleBindingView, error)`
+  - `ReplaceSystemGrants(actor, userID string, expectedEpoch int64, actions []string, key string) (PolicyReceipt, error)`
+
+- [ ] **Step 1: Write failing transaction and concurrency tests**
+
+```go
+func TestAssignUserRoleKeepsOneEffectiveBinding(t *testing.T) {
+    first := mustAssign(t, st, admin, userID, engineerID, 1, "assign-1")
+    second := mustAssign(t, st, admin, userID, reviewerID, first.UserStateVersion, "assign-2")
+    if second.RoleID != reviewerID { t.Fatalf("binding=%+v", second) }
+    if got := countActiveBindings(t, st, userID); got != 1 { t.Fatalf("active=%d", got) }
+}
+```
+
+Also test two concurrent replacements with the same expected state, duplicate idempotency keys, disabled users, disabled roles, unknown actions, `allowed=true/capAllowed=false`, stale role versions, a multi-change batch containing one invalid item, and rejection when a system-grant batch removes the final effective `system.permissions.manage` holder.
+
+- [ ] **Step 2: Run tests and confirm missing methods fail**
+
+Run: `GOWORK=off go test ./internal/store -run 'TestAssignUserRole|TestReplaceRolePermissions' -count=1`
+Expected: FAIL with undefined store methods.
+
+- [ ] **Step 3: Implement transaction-scoped mutations**
+
+Lock the actor, target account, role, and `authority_state` in the existing account-before-policy lock order. Validate the complete batch before any write. Increment `role_version` and `authority_epoch` once per successful transaction and persist one `policy_receipts` row per idempotency key.
+
+- [ ] **Step 4: Verify SQLite and PostgreSQL behavior**
+
+Run SQLite: `GOWORK=off go test ./internal/store -run 'Role|Policy|Binding' -count=1`
+Run PostgreSQL through the isolated PG harness after it creates the mode-0600 DSN file: `AGENT_SYSTEM_TEST_PG_DSN_FILE=/tmp/iam-u4-role-policy-pg-dsn GOWORK=off go test ./internal/store -run 'Role|Policy|Binding' -count=1`
+Expected: both pass with identical conflict and rollback assertions.
+
+- [ ] **Step 5: Commit the store service**
+
+```bash
+git add internal/store/role_policy.go internal/store/role_policy_test.go internal/store/role_policy_pg_test.go
+git commit -m "Add atomic role and binding policies"
+```
+
+### Task 3: Backend authorization service and HTTP API
+
+**Files:**
+- Create: `Agent-System-Backend/internal/authz/service.go`
+- Create: `Agent-System-Backend/internal/server/roles.go`
+- Modify: `Agent-System-Backend/internal/server/server.go`
+- Modify: `Agent-System-Backend/internal/server/accounts.go`
+- Test: `Agent-System-Backend/internal/server/roles_test.go`
+- Test: `Agent-System-Backend/internal/server/role_authorization_test.go`
+
+**Interfaces:**
+- Consumes: Task 2 store methods and existing authenticated actor resolution.
+- Produces: the HTTP endpoints in the spec and `Service.AuthorizeSystem(actor, actionID string) Decision`.
+
+- [ ] **Step 1: Write failing authorization and HTTP tests**
+
+```go
+func TestRoleManagerCannotGrantProtectedPermission(t *testing.T) {
+    cookie := loginAs(t, h, "role-manager")
+    rec := do(h, "PUT", "/api/admin/roles/"+roleID+"/permissions",
+        `{"expectedRoleVersion":1,"idempotencyKey":"p1","changes":[{"actionId":"system.permissions.manage","allowed":true,"capAllowed":true}]}`, cookie)
+    if rec.Code != http.StatusForbidden { t.Fatalf("status=%d body=%s", rec.Code, rec.Body.String()) }
+}
+```
+
+Cover role description create/edit, exact and fuzzy role search, status/action filtering, pagination, one role assigned to two users, user reassignment, stale versions, fixed-ID batches, disabled role assignment, system-grant listing/replacement, final permission-manager protection, and account profile fields remaining outside authorization.
+
+- [ ] **Step 2: Run tests and confirm routes are absent**
+
+Run: `GOWORK=off go test ./internal/server -run 'Role|PermissionCatalog|UserRole' -count=1`
+Expected: FAIL with 404 or missing handlers.
+
+- [ ] **Step 3: Implement service authorization and handlers**
+
+Protected actions require explicit `system_grants`; `project.create` may also use the current enabled role permission. Provide `GET/PUT /api/admin/users/{userId}/system-grants` with expected epoch and idempotency key. Replace `requireAdmin` only for the new role endpoints in this task; existing unrelated admin endpoints remain unchanged until their explicit action is wired in Task 4.
+
+- [ ] **Step 4: Wire account management actions without changing recovery**
+
+Map account list/create/profile/state handlers to `system.users.view/create/edit/disable`. Do not touch recovery routes or credential behavior. Preserve first-admin bootstrap as the protected root recovery path.
+
+- [ ] **Step 5: Run server and full Backend tests**
+
+Run: `GOWORK=off go test ./internal/authz ./internal/server ./internal/store -count=1`
+Run: `GOWORK=off go test ./... -count=1`
+Expected: PASS.
+
+- [ ] **Step 6: Commit the Backend API**
+
+```bash
+git add internal/authz/service.go internal/server/roles.go internal/server/server.go internal/server/accounts.go internal/server/roles_test.go internal/server/role_authorization_test.go
+git commit -m "Expose role and system permission APIs"
+```
+
+### Task 4: Public role provider for RDM
+
+**Files:**
+- Modify: `Agent-System-Backend/pkg/extension/extension.go`
+- Modify: `Agent-System-Backend/internal/app/hostcaps.go`
+- Test: `Agent-System-Backend/internal/app/role_provider_test.go`
+- Create: `Agent-System-RDM/internal/perms/role_provider.go`
+- Modify: `Agent-System-RDM/internal/rdmapp/perms_api.go`
+- Test: `Agent-System-RDM/internal/rdmapp/role_provider_test.go`
+
+**Interfaces:**
+- Produces public `extension.RolePolicyProvider` methods `RolePolicyForActor(actor string)`, `RolePolicyForUser(userID string)`, and `CheckRoleAction(userID, actionID string)` returning versioned, non-secret snapshots.
+- Consumes the actual request actor from the trusted Host; caller-supplied actor fields never select authority.
+
+- [ ] **Step 1: Add provider contract tests on both sides**
+
+Backend tests verify stable user IDs, enabled state, role version, action default/cap, authority epoch, and rejection when the Host has no authenticated actor. RDM tests verify provider missing, wrong version, disabled role, and unknown action all deny without consulting the legacy tables.
+
+- [ ] **Step 2: Run the contract tests red**
+
+Run Backend: `GOWORK=off go test ./internal/app -run RoleProvider -count=1`
+Run RDM: `GOWORK=off go test ./internal/rdmapp -run RoleProvider -count=1`
+Expected: FAIL with missing public provider.
+
+- [ ] **Step 3: Implement the public interface and RDM adapter**
+
+The provider returns only role and permission metadata needed for authorization. It must not return user contact fields. RDM's evaluator must use the provider whenever a role binding exists; absence is a denial after migration readiness is enabled.
+
+- [ ] **Step 4: Run both component suites**
+
+Run Backend: `GOWORK=off go test ./... -count=1`
+Run RDM with the reviewed Backend module overlay during development: `GOWORK=off go test ./... -count=1`
+Expected: PASS; overlay evidence remains SELF until a trusted Backend tag is published.
+
+- [ ] **Step 5: Commit each repository separately**
+
+Backend commit: `Expose the role policy provider`.
+RDM commit: `Consume the Backend role authority`.
+
+### Task 5: RDM migration adapter and creator-only project management
+
+**Files:**
+- Create: `Agent-System-RDM/internal/perms/role_migration.go`
+- Modify: `Agent-System-RDM/internal/perms/roles.go`
+- Modify: `Agent-System-RDM/internal/rdmapp/perms_api.go`
+- Modify: `Agent-System-RDM/plugins/rdm/plugin.go`
+- Test: `Agent-System-RDM/internal/perms/role_migration_test.go`
+- Test: `Agent-System-RDM/internal/rdmapp/project_creator_permissions_test.go`
+- Test: `Agent-System-RDM/plugins/rdm/roles_test.go`
+
+**Interfaces:**
+- Consumes Task 4 provider and Backend import endpoint/command.
+- Produces a versioned export manifest for existing RDM roles and a compatibility forwarding layer for `rdm.role.*` writes.
+
+- [ ] **Step 1: Write migration and cross-project denial tests**
+
+```go
+func TestCreatorCannotManageAnotherCreatorsProject(t *testing.T) {
+    projectA := createProjectAs(t, "alice")
+    projectB := createProjectAs(t, "bob")
+    requireAllowed(t, setProjectPermission("alice", projectA, "carol", ActDocRead, "allow"))
+    requireDenied(t, setProjectPermission("alice", projectB, "carol", ActDocRead, "allow"))
+}
+```
+
+Also assert role IDs, descriptions, bindings, defaults, caps, disabled state, and counts survive export/import; once provider readiness is set, legacy local writes and fallback reads are rejected.
+
+- [ ] **Step 2: Implement export and forwarding without production migration**
+
+Add dry-run export and compare functions. Forward `rdm.role.create/action/assign/disable/list` to Backend through the trusted Host. Keep old tables read-only for verification; do not delete them.
+
+- [ ] **Step 3: Tighten project management to immutable creator ownership**
+
+For member, permission, and duty configuration, load the actual project and compare its immutable `created_by` to the authenticated actor before applying role and platform caps. Do not add delegated project-manager behavior.
+
+- [ ] **Step 4: Run RDM tests**
+
+Run: `GOWORK=off go test ./internal/perms ./internal/rdmapp ./plugins/rdm -count=1`
+Run: `GOWORK=off go test ./... -count=1`
+Expected: PASS.
+
+- [ ] **Step 5: Commit the RDM consumer**
+
+```bash
+git add internal/perms/role_migration.go internal/perms/roles.go internal/rdmapp/perms_api.go plugins/rdm/plugin.go internal/perms/role_migration_test.go internal/rdmapp/project_creator_permissions_test.go plugins/rdm/roles_test.go
+git commit -m "Move RDM role writes to the Backend authority"
+```
+
+### Task 6: Frontend role API and shared draft model
+
+**Files:**
+- Modify: `Agent-System-Frontend/src/api.ts`
+- Create: `Agent-System-Frontend/src/rolePermissions.ts`
+- Test: `Agent-System-Frontend/test/role-permissions.test.ts`
+
+**Interfaces:**
+- Consumes Backend HTTP endpoints from Task 3.
+- Produces `RoleRecord`, `PermissionDescriptor`, `RolePermissionDraft`, `mergeRoleDraft`, `visiblePatch`, and typed API methods.
+
+- [ ] **Step 1: Write failing draft-model tests**
+
+Test that filtered rows retain edits, `visiblePatch` includes only explicit action IDs, single-role and matrix edits produce identical changes, stale server refresh does not replace a newer draft generation, and `allowed=true/capAllowed=false` is rejected before submit.
+
+- [ ] **Step 2: Implement the typed API and pure draft helpers**
+
+```ts
+export type RolePermissionValue = { allowed: boolean; capAllowed: boolean }
+export type RolePermissionDraft = Record<string, RolePermissionValue>
+export function visiblePatch(draft: RolePermissionDraft, visibleActionIds: string[]): RolePermissionChange[]
+```
+
+- [ ] **Step 3: Run tests and build**
+
+Run: `npx vitest run test/role-permissions.test.ts`
+Run: `npm run build`
+Expected: PASS.
+
+- [ ] **Step 4: Commit the client contract**
+
+```bash
+git add src/api.ts src/rolePermissions.ts test/role-permissions.test.ts
+git commit -m "Add the role permission client model"
+```
+
+### Task 7: Single-role and matrix configuration UI
+
+**Files:**
+- Create: `Agent-System-Frontend/src/components/RolePermissionsPanel.tsx`
+- Modify: `Agent-System-Frontend/src/components/AdminZone.tsx`
+- Modify: `Agent-System-Frontend/src/components/AccountUsersPanel.tsx`
+- Modify: `Agent-System-Frontend/src/styles.css`
+- Test: `Agent-System-Frontend/test/role-permissions-ui.test.tsx`
+- Test: `Agent-System-Frontend/test/design-guard.test.ts`
+
+**Interfaces:**
+- Consumes Task 6 API and draft helpers plus existing `@ui` components and tokens.
+- Produces the “角色与权限” system-management section and one-role assignment in user details.
+
+- [ ] **Step 1: Re-read Dev `DESIGN.md` and add failing interaction tests**
+
+Cover exact/fuzzy role search, state filtering, description edit, binding count, single-role edit, matrix edit, grouped paging, hidden-row draft retention, diff preview, conflict preservation, one user role replacement, system-grant editing with final-manager protection, and a late response discarded after switching roles.
+
+- [ ] **Step 2: Implement the panel using existing design tokens**
+
+Use `Collapsible` from `@ui`; consume `@ui/tokens.css` and `@ui/motion.css`; do not add raw colors, private keyframes, `<details>`, or inline font sizes. Keep one request sequence owner for list/detail/preview/commit results.
+
+- [ ] **Step 3: Replace the RDM role admin entry**
+
+Change the section label from “RDM 角色权限” to “角色与权限” and bind it to Backend APIs. Keep RDM project permission and document-duty components in project settings.
+
+- [ ] **Step 4: Add the user role selector**
+
+Display the current role and explicit system grants in account details. Allow role replacement only when the server advertises `system.roles.assign`; submit stable `userId`, `roleId`, expected state version, and idempotency key. Allow system-grant editing only with `system.permissions.manage`, using the server epoch and fixed action IDs.
+
+- [ ] **Step 5: Run Frontend and design checks**
+
+Run: `npm test`
+Run: `npm run build`
+Run paired UI: `npm test` in `Agent-System-UI`.
+Expected: all pass with no design-guard regression.
+
+- [ ] **Step 6: Commit the UI**
+
+```bash
+git add src/components/RolePermissionsPanel.tsx src/components/AdminZone.tsx src/components/AccountUsersPanel.tsx src/styles.css test/role-permissions-ui.test.tsx
+git commit -m "Add role and permission configuration views"
+```
+
+### Task 8: Fixed-combination verification
+
+**Files:**
+- Modify: `Agent-System-Dev/modules/backend`
+- Modify: `Agent-System-Dev/modules/rdm`
+- Modify: `Agent-System-Dev/modules/frontend`
+- Modify: `Agent-System-Dev/modules/ui`
+- Test evidence: `Agent-System-Dev/.task/feature-iam-u4-role-authority.md`
+
+**Interfaces:**
+- Consumes reviewed component commits and trusted published tags where required.
+- Produces one fixed Dev combination and requirement-to-evidence map.
+
+- [ ] **Step 1: Run component verification on exact commits**
+
+Backend: full SQLite, isolated PostgreSQL, migration rollback/retry, build.
+RDM: full tests/build against the reviewed Backend public version.
+Frontend/UI: full tests/build and design guards.
+
+- [ ] **Step 2: Run a real browser scenario on an isolated database**
+
+Create two ordinary users, one “软件工程师” role with a description, assign both users, replace one user's role, configure `project.create`, create projects A and B under different creators, and verify A's creator cannot manage B. Verify an unassigned system administrator cannot read either project's business content. Exercise exact/fuzzy search, filters, single-role edit, matrix edit, preview, conflict, and draft retention.
+
+- [ ] **Step 3: Run the Dev combination**
+
+Run: `make test`
+Expected: PASS on the exact component SHAs recorded by `make evidence`.
+
+- [ ] **Step 4: Record remaining boundaries**
+
+Mark production migration, deployment, account recovery, multi-role, Agent permissions, and workflow changes `NOT_RUN / out of scope`. Do not claim them from component tests.
@@ -0,0 +1,136 @@
+---
+title: 聚焦版角色与分层权限系统规格
+date: 2026-10-15
+type: feature
+status: approved
+approved_at: 2026-10-15
+supersedes_scope: 2026-10-13-identity-role-permission-plan.md U4-U7 中超出本文的部分
+---
+
+# 聚焦版角色与分层权限系统规格
+
+## 目标
+
+实现用户要求的角色与权限系统，不引入账号恢复、多职位、Agent 授权或新的工作流能力。
+
+首期角色等同企业职位。角色与用户分离：同一角色可分配给多个用户，每个用户同时只有一个生效角色。角色包含稳定 `roleId`、名称、可选描述、启用状态和版本。用户继续使用稳定 `userId`，姓名、电话、邮箱、工号、部门和备注均为可选资料，不参与授权主键。
+
+权限分为三个配置面，但使用同一服务端动作目录和判定结果：
+
+1. 系统权限控制系统设置、账号管理、角色管理、权限上限和项目创建。
+2. 角色权限描述一个职位默认可以执行的动作及其上限，例如创建项目、查看获准目录信息。
+3. 项目权限只在一个项目内生效，由该项目创建者维护；A 项目的管理权不能用于 B 项目。
+
+系统管理员负责账号、角色和平台权限上限。系统管理员没有他人项目业务内容的隐式访问权，读取项目正文、原件、草稿、业务审计或导出仍需该项目的明确授权。
+
+## 范围
+
+### 角色与用户
+
+- `Role`：`roleId`、名称、描述、状态、`roleVersion`、创建者、修改者和时间。
+- `UserRoleBinding`：`bindingId`、`userId`、`roleId`、状态、版本、任命者和任命时间。
+- 一个用户最多一条有效 binding；同一角色允许任意多个有效用户 binding。
+- 改名、编辑描述和停用角色不改变用户、项目或历史记录的稳定 ID。
+- 停用角色时保留 binding 和审计记录，但其角色授权立即失效；不回落到更宽的默认权限。
+- 任命停用角色、未知角色或停用账号均拒绝。
+
+### 权限目录与三层授权
+
+动作目录由受信注册表定义 `actionId`、中文名、说明、scope、分组、风险级别和是否受保护。请求不能通过动作字符串或请求体自行声明 scope。
+
+首期系统动作至少包括：
+
+| 分组 | 动作 |
+|---|---|
+| 系统设置 | `system.settings.read`、`system.settings.write` |
+| 用户管理 | `system.users.view`、`system.users.create`、`system.users.edit`、`system.users.disable` |
+| 角色管理 | `system.roles.view`、`system.roles.manage`、`system.roles.assign` |
+| 权限管理 | `system.permissions.view`、`system.permissions.manage` |
+| 项目入口 | `project.create` |
+
+受保护的角色、权限和管理员管理动作只能来自明确系统授权，普通角色配置不能授予。`project.create` 可以来自明确系统授权或当前有效角色的允许项，但仍受平台上限约束。
+
+项目动作至少包括 `project.settings`、`project.members.manage`、`project.permissions.manage`、`document.duties.assign`、`document.read`、`document.author`、`document.review`、`document.approve`。项目动作必须同时满足：账号有效、项目关系有效、当前角色有效、角色动作允许且未超过角色上限、平台未禁止、项目未明确拒绝、资源关系和文档状态允许。
+
+项目创建者只获得自己项目的管理默认，且仍受平台和角色上限约束。创建者关系不授予其他项目权限，也不自动授予项目业务内容读取或代签能力。
+
+### 角色权限
+
+每个角色的动作配置包含 `allowed` 与 `capAllowed`：
+
+- `allowed=true` 表示该角色默认允许动作。
+- `capAllowed=false` 表示该角色不能通过项目覆盖获得该动作。
+- `allowed=true && capAllowed=false` 是非法配置，服务端拒绝。
+- 未知动作和未配置动作默认拒绝。
+- 角色默认和上限不得写入超出操作者可委派范围的受保护动作。
+
+首期一个用户只有一个有效角色，因此一次判定只使用该 binding，不进行跨角色动作或范围拼接。
+
+### 项目权限和文档三权
+
+RDM 保留项目成员、项目创建者、项目内覆盖和现有文档三权的领域权威。Backend 负责角色、binding、系统动作和平台／角色上限。
+
+项目覆盖使用 `inherit | allow | deny`：`allow` 不能突破平台或角色上限，`deny` 明确阻断。项目创建者只能修改自己创建项目的成员、权限和文档三权。
+
+文档编制、审核、批准继续使用现有 RDM 三权记录；分配候选必须是该项目有效成员，账号和角色有效，并具有对应动作上限。角色只提供资格，不能代替具体文档职责。
+
+## 服务端接口
+
+Backend 成为角色和系统权限的唯一写入权威，提供版本化接口：
+
+- `GET /api/admin/permissions/catalog`
+- `GET /api/admin/roles`，支持名称精确／模糊搜索、状态和动作过滤、分页
+- `POST /api/admin/roles`
+- `GET /api/admin/roles/{roleId}`
+- `PATCH /api/admin/roles/{roleId}`，使用 `expectedRoleVersion`
+- `PUT /api/admin/roles/{roleId}/permissions`，批量提交固定 actionId 列表和 `expectedRoleVersion`
+- `PUT /api/admin/users/{userId}/role`，替换该用户唯一有效角色，使用用户状态版本和幂等键
+- `GET /api/admin/users/{userId}/role`
+- `GET /api/admin/users/{userId}/system-grants`
+- `PUT /api/admin/users/{userId}/system-grants`，批量提交明确系统动作并使用 `expectedAuthorityEpoch` 和幂等键
+- `GET /api/authz/explain`，仅解释调用者自己或其有权管理的对象
+
+批量权限修改在单库事务内全部成功或全部失败；任一未知动作、越权、越上限或版本冲突不得部分写入。响应返回新版本、实际差异和审计回执标识。
+
+RDM 通过公开、固定版本的 Backend 角色读取／判定契约消费角色数据。RDM 原 `rdm.role.*` 写命令在迁移期转发 Backend；切换完成后不得继续写 RDM 旧角色表。读取失败、提供者缺失或版本不兼容时拒绝权限动作。
+
+## 配置界面
+
+系统管理区增加“角色与权限”入口：
+
+- 角色列表显示名称、描述、状态和绑定人数，支持精确搜索、模糊搜索和状态过滤。
+- 单角色视图编辑名称、描述、状态及权限。
+- 角色矩阵以角色为行、权限为列，按权限分组和分页展示。
+- 单角色视图与矩阵使用同一草稿模型和同一批量接口。
+- 过滤隐藏的单元格不丢失草稿；全选只作用于当前明确显示的固定 actionId 集合。
+- 提交前显示差异；冲突保留草稿并要求刷新，不逐格即时写库。
+
+用户详情显示当前角色和明确系统授权来源，并允许有 `system.roles.assign` 权限的操作者从有效角色中选择。有 `system.permissions.manage` 权限的操作者可以编辑目标用户的系统授权，但不能撤销最后一个有效权限管理者。用户可选资料继续用于展示、搜索和辨识，不参与权限计算。
+
+项目设置继续使用现有成员和权限入口，显示角色默认、角色上限、项目覆盖及最终允许／拒绝原因。项目创建者无法切换到其他项目后沿用原项目管理权。
+
+## 迁移与兼容
+
+1. 导出 RDM 当前角色、动作配置和账号单角色绑定，包含来源版本与摘要。
+2. 以原 `roleId` 导入 Backend；为每个账号生成一个稳定 binding。
+3. 对角色数量、绑定数量、动作默认／上限和引用逐项比对。
+4. 在迁移窗口内禁止双主写；RDM 写入口改为转发 Backend。
+5. 切换消费者后保留旧表只读，确认无回退依赖后再另行批准清理。
+
+迁移失败不得启用部分角色数据；恢复时保留已撤销、停用和拒绝事实，不能复活旧权限。
+
+## 验收条件
+
+- 创建“软件工程师”角色并分配给两个用户，两人保留各自稳定 userId。
+- 同一用户第二次任命替换原生效角色，不产生两个同时有效的 binding。
+- 角色描述可编辑，用户可选资料全空仍合法。
+- 未知动作、默认超过上限、停用角色任命、无授权角色管理和最后系统权限管理者撤销均拒绝。
+- 普通角色可被授予 `project.create`，但不能因此修改系统设置、用户、角色或权限上限。
+- A 项目创建者管理 A 的成员、项目权限和文档三权成功；操作 B 全部拒绝。
+- 系统管理员未获项目授权时不能读取 A 或 B 的业务内容。
+- 单角色配置和角色矩阵产生等价的固定 actionId 批量 patch；过滤和分页不丢草稿。
+- SQLite 与 PostgreSQL 的版本冲突、事务回滚和迁移结果一致。
+
+## 明确排除
+
+本增量不实现一人多职、账号恢复、SSO／组织树、Agent 权限、工作流重建、新的文档审签流程、生产迁移或部署。现有文档三权只接入新的角色资格和项目权限判定。
@@ -0,0 +1,368 @@
+---
+title: IAM U4 Stage 7-10 Delivery - Plan
+type: feat
+date: 2026-10-15
+artifact_contract: ce-unified-plan/v1
+product_contract_source: specialized-project-spec
+execution: code
+origin: docs/proposals/2026-10-15-iam-focused-role-permission-spec.md
+---
+
+# IAM U4 Stage 7-10 Delivery - Plan
+
+## Goal Capsule
+
+- **Objective:** The approved IAM U4 role and permission behavior is accepted in a real browser, merged through each protected repository at reviewed commits, and closed with traceable evidence and clean workspaces.
+- **Means:** Use the repository's existing Playwright stack against an isolated RDM product composition, then deliver Backend, Frontend, Documents, RDM, and Dev in dependency order with exact-head review and CI. (KTD1–KTD5)
+- **Authority:** The focused specification approved at Documents `e9ce9a5` owns behavior; this plan owns delivery mechanics; `Agent-System-Dev/policy/delivery.md` and `policy/merge-queue.md` own stage and merge gates; the task card owns current evidence.
+- **Execution profile:** The agent prepares and performs testing, review, PRs, conflict resolution, CI checks, merges, and cleanup. The user retains stage 7 and stage 10 decisions and personally publishes any trusted tag.
+- **Stop conditions:** Stop on a changed requirement, cross-project access success, stale or mismatched candidate SHA, unresolved browser or CI failure, a conflicting merge window, a mismatched existing tag, or any request to touch production data or deployment.
+
+---
+
+## Product Contract
+
+### Summary
+
+Stage 7 proves the implemented role model and permission boundaries through the real React interface and live Backend/RDM authorization path.
+Stages 8–10 then carry the same behavior through component PRs, a trusted Backend release tag, RDM pins, the Dev fixed combination, protected-branch CI, and safe task closure.
+
+### Problem Frame
+
+The implementation candidate has passed SQLite, isolated PostgreSQL, RDM overlay, Frontend/UI, and Dev combination checks, but those checks do not prove browser behavior or protected-repository delivery.
+The repositories also move independently: RDM consumes a published Backend extension contract, while Dev pins Backend, Frontend, UI, and Documents but does not pin RDM.
+Delivery must preserve those dependency and evidence boundaries without turning production migration or deployment into an implied part of acceptance.
+
+### Requirements
+
+**Candidate identity and formal acceptance**
+
+- DR1. Stage 7 starts only after each task branch is synchronized with its current `origin/main` and the tested component commits are recorded together.
+- DR2. Formal browser acceptance runs on a fresh isolated data root and random loopback ports, never on a registered or production service.
+- DR3. Browser evidence uses the existing Frontend Playwright stack against the exact Backend, RDM, Frontend, and UI sources under review.
+- DR4. Every acceptance result records the command, component SHAs, environment shape, exit code, sanitized screenshots or traces where applicable, and evidence source. Browser credentials are synthetic; artifacts use owner-restricted external storage and expire after stage 10.
+- DR5. Stage 7 requires user review of the requirement-to-evidence map before any component merge begins.
+
+**Role, user, and permission behavior**
+
+- DR6. The browser creates and edits a role with a description while its stable `roleId` remains unchanged. Before disabling a role, the UI names it, shows the bound-user count and authorization impact, supports cancellation without a request, and sends one versioned request only after confirmation; success preserves a usable selection, while conflict or failure preserves context for retry.
+- DR7. Two users can share one role, one user can be moved to another role, and the system never exposes two active roles for one user.
+- DR8. Name, phone, email, staff number, department, and notes remain optional and searchable without becoming authorization identifiers.
+- DR9. Exact and fuzzy role search, status and action filters, pagination, single-role editing, matrix default/cap editing, visible-page batch changes, preview, and 409 rebasing work through the rendered UI. Drafts are keyed by `roleId`: permission grouping/paging, role filters, role paging, and single/matrix switching preserve them; switching roles never transfers a draft; leaving the administration area or refreshing requires an explicit save/discard decision; a 409 rebases only the same role's draft.
+- DR10. Delegated system actions expose only their permitted user, role, or permission controls; a manager without view authority cannot replace data with an empty set. Loading, stale, empty, partial-failure, retry, and success states are distinct; destructive controls remain unavailable without authoritative data. The core flow works by keyboard with named controls, announced status changes, stable focus after save/conflict/error, and a usable narrow viewport including matrix navigation.
+- DR11. `project.create` works only through an explicit system grant or an enabled role default within its cap.
+- DR12. Project A's creator can manage A's members, overrides, and document duties, but A's creator relation and an untrusted owner label never authorize project B. A separate valid B-side membership, current role grant, cap, and project override continue to authorize only the B actions they explicitly allow.
+- DR13. System administrator identity alone cannot read another user's project business content, private conversations, originals, drafts, controlled document bodies, business audit records, or exports, and cannot create a business-content export artifact.
+- DR14. Document author, reviewer, and approver assignments require current account and role eligibility, and approval remains separate from document publication.
+- DR15. Missing providers, incompatible schemas, stale authority epochs, disabled accounts, disabled roles, unknown actions, and out-of-cap overrides fail closed. Version-conflict, unknown-action, and out-of-cap batch updates perform zero partial writes, with the same resulting state and migration outcome on SQLite and PostgreSQL.
+
+**Protected delivery**
+
+- DR16. Component branches merge in dependency order; a downstream pin never points to an unmerged commit or unpublished required tag.
+- DR17. Backend's trusted tag is created only by the user after the reviewed Backend PR merge commit is verified on `origin/main`; an existing tag is never rewritten.
+- DR18. RDM updates its pins only after Backend and Frontend commits are merged, then builds the product from committed Git objects or a strictly clean tracked/untracked/ignored source tree, records digests of the copied content as well as Git SHAs, and replays affected acceptance. Dirty or untracked source must fail before packaging.
+- DR19. Dev enters the manual merge queue only after all component dependencies are merged and the final gitlinks point to their authoritative commits.
+- DR20. Dev merge requires exact-head `test`, `test-pg`, and `svc-realcombo` GATE success, current Review, no conflicting main advance, and an explicit queue claim.
+- DR21. Task closure records the actual merge commits and retains every failed, skipped, and not-run result at its real evidence level. Any source, base, pin, candidate manifest, or test-definition change after stage 7 updates the manifest, replays affected evidence, and requires a renewed stage 7 conclusion before the first component merge.
+
+### Actors
+
+- A1. **System administrator:** manages platform accounts, roles, explicit system grants, and platform permission ceilings.
+- A2. **Delegated manager:** holds a selected subset of system actions and sees only the matching administration controls.
+- A3. **Project creator:** manages only the project identified by immutable creation metadata.
+- A4. **Project member:** receives project behavior from the current professional role, project override, resource relation, lifecycle state, and document duty.
+- A5. **Delivery agent:** executes tests, review, PRs, CI checks, merges, and cleanup within the approved scope.
+- A6. **User reviewer:** approves stage 7 evidence, personally publishes a trusted tag, and approves stage 10 cleanup.
+
+### Key Decisions
+
+- **One effective role remains the product model.** The delivery does not introduce multi-role assignment. Governs DR7.
+- **System administration does not grant business-content access.** Project and resource authorization remain explicit. Governs DR12–DR15.
+- **Production migration and deployment remain outside this delivery.** The migration machinery is tested only on isolated databases. Governs DR2, DR21.
+
+### Key Flows
+
+- F1. **Formal acceptance**
+  - **Trigger:** The synchronized component candidate is fixed.
+  - **Actors:** A1–A5.
+  - **Steps:** Build the isolated composition; seed accounts and projects; drive role, user, system grant, project, and document flows in Chromium; capture traces and API decisions; replay SQLite, PostgreSQL, and component suites.
+  - **Outcome:** DR6–DR15 have exact-candidate evidence or stage 7 stops.
+  - **Covers:** DR1–DR15.
+
+- F2. **Serial protected delivery**
+  - **Trigger:** The user approves stage 7.
+  - **Actors:** A5, A6, Gitea.
+  - **Steps:** Merge Backend; publish and verify its tag; merge Frontend and Documents; update and merge RDM pins; fix the Dev gitlinks; claim the Dev queue window; pass exact-head CI; merge and verify; finish registered worktrees; close the task card through its own reviewed PR.
+  - **Outcome:** Every protected branch contains the reviewed behavior and the task record identifies the actual commits.
+  - **Covers:** DR16–DR21.
+
+### Acceptance Examples
+
+- AE1. **Shared position:** Given two enabled users and one enabled software-engineer role, assigning both users succeeds; replacing one user's role leaves one active binding for each user and the original role still has one member. Covers DR7.
+- AE2. **Fine-grained manager:** Given `system.users.view` without role or permission view, the manager opens user details without a failing role request and cannot edit roles or grants. Covers DR10.
+- AE3. **Draft conflict:** Given a local matrix draft and a concurrent role update, saving returns 409, reloads the latest role version, replays the local draft against it, and never applies role A's draft to role B. Covers DR9.
+- AE4. **Creator isolation:** Given projects A and B with different creators, A's creator can change A's members, overrides, and author/reviewer/approver duties. With no valid B-side management grant, the same actor is denied for all three mutation families in B and B remains unchanged, even if the actor is a B member or carries an untrusted owner label. A separate fixture proves that a valid B-side grant authorizes only its declared B actions. Covers DR12, DR14.
+- AE5. **Administrator privacy:** Given an administrator with no project content grant, direct authenticated requests to B's private conversations, originals, drafts, controlled bodies, business-audit list/detail, and export create/status/download routes are denied with no payload or export artifact. A separately authorized project actor supplies positive controls for the same routes. Covers DR13.
+- AE6. **Fail-closed refresh:** Given an allowed cached role snapshot, tightening the role cap changes the authority epoch; the next project or knowledge read consumes the current Backend snapshot and denies the old permission. Covers DR15.
+- AE7. **Migration rehearsal:** Given a provenance-recorded frozen v35 fixture and oracle covering active and disabled roles, inactive bindings, revoked grants, explicit denies, owner mappings, and orphan/reference failures, a trusted non-production harness invokes the real Backend/RDM stores to freeze legacy writes, stage stable IDs and full owner-to-role mappings, compare source hashes and expected results, and activate by epoch. Compare mismatch or a concurrent legacy write blocks activation; a lost success response can be retried without duplicate bindings. SQLite and PostgreSQL produce the same final state. Covers DR2, DR15, DR21.
+
+### Scope Boundaries
+
+Included:
+
+- Repeatable UI and live-composition browser acceptance for the approved U4 requirements.
+- Test-only adjustments needed to make that acceptance deterministic and reviewable.
+- Component sync, PRs, CI, Backend tag handoff, RDM pin updates, Dev queue delivery, and task cleanup.
+
+Excluded:
+
+- Production schema migration, legacy-role cutover, deployment, or 8788 service changes.
+- Account recovery, password flows beyond isolated fixture setup, multi-role support, Agent permissions, organization trees, SSO, and workflow redesign.
+- Branch-protection changes, tag rewriting, runner changes, or merge-queue automation.
+
+---
+
+## Planning Contract
+
+### Key Technical Decisions
+
+- KTD1. **Use repository-native Playwright as the formal browser gate.** `Agent-System-Frontend/playwright.config.ts` and the existing `e2e/` suite already define the project's real-browser contract. `agent-browser` may add an exploratory visible smoke when installed, but its absence does not replace or invalidate the repeatable Playwright run.
+- KTD2. **Run two browser layers.** Deterministic routed tests cover UI permission combinations, pagination, draft retention, and response ordering; a live isolated RDM product covers authentication, storage, Backend policy, RDM project boundaries, and embedded Frontend behavior.
+- KTD3. **Freeze evidence by component SHA and environment.** A branch sync, pin change, test-harness change, or target-main advance invalidates only the affected results; no receipt is copied to a different object.
+- KTD4. **Deliver dependencies serially.** Backend merges and receives a trusted tag before RDM updates its Backend pin. Frontend and Documents merge before RDM fixes its product pins. Dev pins only merged component commits and enters its final queue window last.
+- KTD5. **Keep high-consequence operations dual-keyed.** The agent prepares and verifies the proposed Backend tag command; the user executes tag publication. Production migration and deployment have no execution unit in this plan.
+- KTD6. **Treat missing component CI honestly.** Backend, RDM, and Dev consume their repository workflows. Frontend and Documents use their repository verification plus downstream Dev GATE when no repository-local workflow exists; they are not labeled GATE without a real platform run.
+
+### High-Level Technical Design
+
+The diagrams are delivery guidance rather than implementation specifications.
+
+```mermaid
+flowchart TB
+  BE[Backend reviewed commit] --> BET[User-published Backend tag]
+  BET --> RP[RDM Backend pin]
+  FE[Frontend reviewed commit] --> RP
+  UI[UI commit already on main] --> RP
+  DOC[Documents plan/spec commit] --> DEV[Dev final gitlinks]
+  BE --> DEV
+  FE --> DEV
+  UI --> DEV
+  RP --> RDM[RDM protected main]
+  DEV --> DCI[Dev test + test-pg + svc-realcombo]
+  DCI --> DM[Dev protected main]
+```
+
+```mermaid
+sequenceDiagram
+  participant Agent as Delivery agent
+  participant Browser as Playwright Chromium
+  participant Product as Isolated RDM product
+  participant User as User reviewer
+  participant Gitea as Protected repositories
+  Agent->>Product: Build exact component composition
+  Agent->>Browser: Run deterministic and live U4 scenarios
+  Browser->>Product: Role, user, grant, project, and duty requests
+  Product-->>Browser: Current policy decisions and rendered results
+  Agent->>User: Stage 7 requirement-to-evidence map
+  User-->>Agent: Stage 7 conclusion
+  Agent->>Gitea: Review, CI, and serial component PR merges
+  Agent->>User: Exact Backend merge commit and tag command
+  User-->>Gitea: Publish trusted tag
+  Agent->>Gitea: RDM pins, Dev queue CI, merge, and verification
+```
+
+### Sequencing
+
+1. Fix and accept the synchronized stage 7 candidate.
+2. Complete stage 7 browser and database evidence and obtain the user's conclusion.
+3. Re-review any files changed by acceptance work.
+4. Merge Backend, then complete the user-owned tag gate.
+5. Merge Frontend and Documents.
+6. Sync RDM, update pins, replay the product and browser gates, then merge RDM.
+7. Fix Dev gitlinks, claim the manual queue window, run exact-head CI, and merge Dev.
+8. Verify merged content, preserve receipts, clean registered worktrees, and then close the task card through its own reviewed PR after stage 10 approval.
+
+### Risks and Dependencies
+
+- Backend, RDM, Documents, and Dev main may advance before their windows. Each affected branch must sync once at its delivery boundary and rerun affected evidence.
+- RDM currently trails its authoritative main substantially. Conflict resolution must preserve upstream behavior and may invalidate the pre-sync RDM review.
+- Browser execution requires the repository Playwright runtime and Chromium. If the runtime cannot launch, stage 7 stops with the launch error; another browser stack is not substituted.
+- The recommended Backend version is `v0.6.0` because U4 adds public surface 2.15 and schema v36. If that remote tag exists or the release convention has changed, stop for a new user-selected version and never rewrite the ref.
+- Gitea API or Actions may fail transiently. A retry is allowed only after reading the actual PR/run state; unknown results are reconciled before resubmission.
+- The current Dev merge queue has no active window after the recorded release of the workbench visual task. This fact must be re-read immediately before U8 claims a new window.
+
+---
+
+## Implementation Units
+
+### U1. Record approval and fix the stage 7 candidate
+
+- **Goal:** Record the user's stage 6 approval and produce one synchronized candidate manifest for formal acceptance.
+- **Requirements:** DR1, DR4, DR5.
+- **Files:** `Agent-System-Dev/.task/feature-iam-u4-role-authority.md`, `Agent-System-Documents/docs/proposals/2026-10-15-iam-u4-stage7-10-delivery-plan.md`, `Agent-System-Documents/docs/proposals/INDEX.md`.
+- **Approach:** Update the stage table with the approved component versions and date. Run the required task sync in each branch before its evidence is treated as current. Record base, head, component commits, test definitions, and browser-harness commit in one candidate manifest.
+- **Test scenarios:** A clean same-base sync leaves the candidate unchanged; a moving target updates the manifest and invalidates affected evidence; a dirty or drifting component stops the unit.
+- **Verification:** Dev precheck/task-resume receipt, `make task-sync` evidence, recursive worktree verification, and Documents `git diff --check`.
+- **Dependencies:** None.
+
+### U2. Add the repeatable IAM browser acceptance slice
+
+- **Goal:** Make DR6–DR15 reproducible in the existing browser-test stack without production services.
+- **Requirements:** DR2–DR4, DR6–DR15.
+- **Files:** `Agent-System-Frontend/e2e/iam-role-authority.playwright.ts`, `Agent-System-RDM/scripts/iam-u4-role-acceptance.sh`, and only the smallest supporting test fixtures required by those files.
+- **Approach:** Add deterministic route-driven cases for fine-grained navigation, filters, matrix edits, role-scoped draft lifetime, 409 rebasing, pagination, late-response rejection, role-disable impact confirmation, and independently loading role/permission data. Cover keyboard operation, focus, accessible names and announcements, and a narrow viewport with horizontal matrix navigation. Add a live harness that materializes exact committed candidate sources into a temporary build root, builds the embedded RDM product, initializes a fresh SQLite database, starts on loopback random ports, and runs the same Playwright file in live mode. Synthetic credentials and activation material remain in the temporary root and are deleted on exit; traces and screenshots are sanitized before owner-restricted retention.
+- **Execution note:** Add failure-first cases for the previously reviewed permission combinations and race paths before changing the harness or UI assertions.
+- **Test scenarios:** Roles-only viewer; users-only viewer; permissions viewer without manager; permissions manager without view; shared-role assignment and reassignment; exact/fuzzy/action/status filters; multi-page role selection; matrix default/cap and visible-page batch edits; draft-preserving and explicit-discard transitions; concurrent 409 rebase; stale response after role switch; role-disable cancel/success/conflict/failure; initial loading; filtered and catalog-empty states; independent role-list and permission-catalog failure; failed create/save retry; keyboard-only core flow; narrow viewport; current epoch denial; isolated service startup failure and cleanup.
+- **Verification:** Focused Playwright run with trace retention, Frontend unit tests/build/design guard, harness shell check, and a clean-process check after success and failure.
+- **Dependencies:** U1.
+
+### U3. Execute stage 7 formal acceptance
+
+- **Goal:** Produce the requirement-to-evidence map the user can approve without reading implementation details.
+- **Requirements:** DR2–DR15.
+- **Files:** `Agent-System-Dev/.task/feature-iam-u4-role-authority.md`; screenshots, traces, and receipts remain outside source and are linked by digest or durable run URL.
+- **Approach:** Run deterministic Playwright and the live isolated product. Replay Backend SQLite and isolated PostgreSQL role-policy tests, RDM full tests against the fixed Backend, Frontend/UI suites, and Dev combination tests. Exercise migration through an isolated cross-component harness that calls the real trusted Backend/RDM store path for freeze, stage, compare, activate, failure, and retry against the frozen v35 fixture and oracle. Record each DR-ID as PASS, FAIL, SKIP, or NOT_RUN against the exact candidate.
+- **Test scenarios:** AE1–AE7 plus missing provider, incompatible schema, disabled account/role, final permission-manager protection, project-override cap, document-duty cap, administrator audit/export denial, dirty product-source rejection, and SQLite/PostgreSQL batch failures for version conflict, unknown action, and out-of-cap change with zero partial writes.
+- **Verification:** Evidence receipts and browser artifacts match the candidate manifest; an independent replay covers the minimum critical set; the user records the stage 7 conclusion in the task card.
+- **Dependencies:** U2.
+
+### U4. Re-review and prepare component PRs
+
+- **Goal:** Turn the stage 7 candidate into current, reviewable component branches without changing accepted behavior.
+- **Requirements:** DR4, DR16, DR21.
+- **Files:** Component diffs and task records in Backend, Frontend, Documents, and RDM.
+- **Approach:** Sync each component with its current main at its own delivery boundary. Resolve conflicts without weakening authorization. If source, base, dependency pin, candidate manifest, or test definition changes, update the manifest, rerun the affected U2/U3 evidence, and obtain a renewed stage 7 conclusion before any component merge. Then simplify only changed code, conduct independent code review, push the branch, and create a draft PR with the final behavior and evidence.
+- **Test scenarios:** Clean sync; source conflict; changed public surface; changed Frontend API type; changed RDM provider contract; target advance after review.
+- **Verification:** Each PR identifies base/head, component dependencies, review findings and closure, and current applicable CI or explicit absence of repository-local CI.
+- **Dependencies:** U3 and stage 7 user approval.
+
+### U5. Merge Backend and publish its trusted tag
+
+- **Goal:** Establish the authoritative public role-policy contract RDM can consume.
+- **Requirements:** DR16, DR17.
+- **Files:** Backend PR and release tag; no production service files.
+- **Approach:** Confirm Backend PR HEAD contains current main, public surface 2.15, schema v36, staged migration, and the reviewed tests. Require the `vet-and-test` GATE on that exact HEAD, complete agent Review, merge without force, and verify the merge commit on `origin/main`. Prepare an annotated `v0.6.0` command bound to that merge commit; the user executes it. Read the remote peeled tag before proceeding.
+- **Test scenarios:** CI failure; main advance; merge conflict; tag absent; tag already exists at the same commit; tag exists at another commit; push result unknown.
+- **Verification:** PR merge URL, exact merge SHA, successful exact-head CI, remote annotated tag and peeled commit equality.
+- **Dependencies:** U4. The user-owned tag action is an internal completion gate after the Backend merge.
+
+### U6. Merge Frontend and Documents
+
+- **Goal:** Land the accepted administration UI and its authoritative records before RDM fixes product pins.
+- **Requirements:** DR3, DR6–DR10, DR16, DR21.
+- **Files:** Frontend PR, Documents PR, `Agent-System-Documents/docs/proposals/INDEX.md`.
+- **Approach:** Sync and revalidate Frontend, including the IAM Playwright slice, then merge the reviewed PR. Sync Documents, verify links and claims, and merge its PR. UI requires no U4 PR when `e295cae` remains on authoritative main.
+- **Test scenarios:** Frontend main changes affecting AdminZone, styles, API types, or test harness; Documents link drift; UI main no longer contains the expected token commit.
+- **Verification:** Frontend tests/build/Playwright and platform status, Documents `git diff --check`, merged commits on each main, and UI ancestry check.
+- **Dependencies:** U4; Backend may merge before or during this unit, but RDM pinning waits for both U5 and U6.
+
+### U7. Update and merge the RDM composition
+
+- **Goal:** Replace the development overlay with authoritative merged pins and prove the real product composition.
+- **Requirements:** DR12–DR18, DR21.
+- **Files:** `Agent-System-RDM/pins/agent-system-backend`, `pins/agent-system-frontend`, `pins/agent-system-ui`, public-contract references, product manifest, and RDM task evidence.
+- **Approach:** Sync the RDM branch with current main and resolve its known divergence. Pin Backend to the verified tagged merge commit, Frontend to its merged commit, and UI to current authoritative main. Remove reliance on the temporary `go.work` overlay. Harden product assembly so it materializes committed Git objects, or rejects any tracked, untracked, or relevant ignored drift before copying, and records copied-content digests in addition to Git SHAs. Run the full RDM suite, product build, product smoke, migration rehearsal, and live IAM Playwright acceptance; review the resulting pin diff and merge the RDM PR after `build-and-test` succeeds.
+- **Test scenarios:** Pin mismatch; tag/commit mismatch; tracked, untracked, or ignored source drift; copied-content digest mismatch; missing embedded assets; migration staging failure; source-hash mismatch; provider schema mismatch; browser regression after real pins.
+- **Verification:** `PRODUCT_MANIFEST.json` matches the three gitlinks, RDM HEAD, and actual copied-content digests; a dirty-source negative test fails before packaging; full local receipts and exact-head RDM CI pass; merged RDM main contains the reviewed pins.
+- **Dependencies:** U5, U6.
+
+### U8. Deliver the final Dev combination through the manual queue
+
+- **Goal:** Merge one Dev candidate that pins only authoritative component commits and carries current evidence.
+- **Requirements:** DR16, DR19, DR20, DR21.
+- **Files:** `Agent-System-Dev/modules/backend`, `modules/frontend`, `modules/ui`, `modules/documents`, task card, PR, and merge-queue issue #518.
+- **Approach:** Re-read #518 and claim the only Dev main window. Run `make task-sync`, update gitlinks to merged component commits, fix the candidate, and store final receipts outside source. Run local `make test` and `make build`, complete final independent Review, push the Dev branch, and require `test`, `test-pg`, and `svc-realcombo` on the exact PR HEAD. Recheck main/head immediately before a non-force PR merge, then read back main and the component tree.
+- **Test scenarios:** Active competing window; main advance after CI; component SHA drift; CI transient failure within retry budget; repeated failure; unknown merge response; merged main content mismatch.
+- **Verification:** Queue claim/release entries, current base/head, three successful GATE jobs, review receipt, PR merge URL, final main SHA, and exact `git ls-tree` component values.
+- **Dependencies:** U7 and merged component records from U5–U6.
+
+### U9. Verify, close, and clean the task
+
+- **Goal:** Leave authoritative records and no abandoned IAM workspaces or branches.
+- **Requirements:** DR21.
+- **Files:** Dev task card and archive entry; component task records where applicable.
+- **Approach:** Verify actual merged contents and component ancestry. Record browser, SQLite, PostgreSQL, component CI, Dev CI, tag, PR, and merge evidence with their real source levels, then request stage 10 approval. Preserve cleanup receipts outside the worktree; after all writers have exited, run `TASK_WRITERS_STOPPED=1 make task-finish` from the registered task worktree. Then run `make task-close` from clean main and deliver its card-close PR through the applicable queue, Review, CI, merge, and readback path. Never force-delete a refused cleanup.
+- **Test scenarios:** Uncommitted or untracked file; live writer; unmerged local or remote commit; missing task-card PR link; cleanup refusal; post-merge content mismatch.
+- **Verification:** Stage 10 conclusion, archived task card on main, clean recursive state, merged ancestry, removed task worktrees, and preserved external receipts.
+- **Dependencies:** U8. Stage 10 approval is an internal gate before cleanup.
+
+---
+
+## Verification Contract
+
+| Gate | Command or platform check | Applies to | Done signal |
+|---|---|---|---|
+| Backend SQLite | `GOWORK=off go test ./... -count=1` | U3, U5 | All packages pass at the recorded Backend HEAD |
+| Backend PostgreSQL | Isolated PostgreSQL 16 with `AGENT_PG_TEST_DSN`, then role, migration, delegation, and lock-order store tests | U3, U5 | No skips in the selected PG set; container removed |
+| Cross-database atomicity | Force version-conflict, unknown-action, and out-of-cap batch failures against SQLite and isolated PostgreSQL | U3 | Both stores retain identical pre-request state with zero partial writes |
+| Migration oracle | Trusted isolated Backend/RDM store harness against the frozen v35 fixture and expected oracle | U3, U7 | Freeze/stage/compare/activate/failure/retry results match on SQLite and PostgreSQL; mismatches block activation |
+| Frontend unit/build | `npm test && npm run build && node scripts/check-knip.mjs` | U2, U3, U6 | Tests pass, build succeeds, knip stays within baseline |
+| UI | `npm test` plus the design guard through the Frontend/Dev suite | U3, U6 | UI tests and design guard pass at the fixed UI commit |
+| Browser deterministic | `npm run e2e -- e2e/iam-role-authority.playwright.ts` with isolated preview | U2, U3, U6 | Required scenarios pass; failure traces retained |
+| Browser live product | `scripts/iam-u4-role-acceptance.sh` with exact source SHAs | U3, U7 | Embedded product scenarios pass on a fresh data root; screenshot and manifest digests recorded |
+| RDM overlay | `GOWORK=<fixed overlay> go test ./... -count=1` | U3 | Development contract passes before authoritative pins exist |
+| RDM pinned product | Dirty-source negative test, then `make test`, `make product`, and `make product-smoke` from committed sources | U7 | Drift is rejected; full suite, embedded product, copied-content digests, and manifest smoke pass without overlay |
+| Documents | `git diff --check` plus link and version review | U1, U6 | No malformed diff or stale reference |
+| Dev local combination | `make test && make build` after `make task-sync` | U3, U8 | Exact fixed combination passes and builds |
+| Component CI | Backend `vet-and-test`; RDM `build-and-test`; current platform-required Frontend/Documents checks when present | U5–U7 | Each available GATE is successful on the merged candidate HEAD |
+| Dev CI | Gitea `test`, `test-pg`, `svc-realcombo` | U8 | All three jobs succeed on the same final PR HEAD |
+| Merge integrity | PR head/base readback, non-force merge, `origin/main` and component tree readback | U5–U8 | Actual protected main matches the reviewed candidate |
+| Cleanup | External receipt preservation; guarded `task-finish`; then `task-close` PR Review/CI/merge/readback | U9 | No writer, unique file, unmerged commit, active lock, or cleanup result is lost |
+
+Evidence rules:
+
+- Local commands remain `SELF` unless an independent reviewer replays them.
+- Gitea Actions counts as `GATE` only when the run identity, job, exact SHA, and result are recorded.
+- A Playwright screenshot or trace proves only the scenario and build identified by its receipt.
+- `SKIP` and `NOT_RUN` remain visible; they are never converted to PASS by another layer's test.
+- Any source, base, pin, manifest, or test-definition change updates the named candidate and reruns the gates it affects. A post-stage-7 change also requires a renewed stage 7 conclusion before component merge; a final Dev HEAD change invalidates its three required CI jobs.
+
+---
+
+## Definition of Done
+
+Global completion requires all of the following:
+
+- DR1–DR21 all have PASS evidence. These delivery requirements are mandatory; SKIP, NOT_RUN, and exclusions block completion.
+- The user has approved stage 7 and stage 10 on named candidate versions.
+- Independent final Review has no unresolved Critical or Important finding.
+- Backend, Frontend, Documents, RDM, and Dev PRs are merged in dependency order at the recorded commits.
+- The trusted Backend tag exists remotely and peels to the reviewed Backend merge commit.
+- RDM's product manifest uses authoritative merged pins and no development overlay.
+- Dev's final PR HEAD has successful `test`, `test-pg`, and `svc-realcombo` jobs.
+- Actual protected main branches and Dev gitlinks match the reviewed candidates.
+- Production migration and deployment remain NOT_RUN unless separately authorized.
+- Failed experiments, temporary build roots, credentials, processes, branches, and worktrees are removed or retained with an explicit reason; no abandoned attempt code remains in the diffs.
+- Task cards are archived through the guarded workflow and external receipts remain available.
+
+Per-unit completion:
+
+| Unit | Completion signal |
+|---|---|
+| U1 | Stage 6 approval and synchronized candidate manifest are recorded |
+| U2 | Repeatable deterministic and live IAM browser slices exist and pass locally |
+| U3 | User approves the exact stage 7 requirement-to-evidence map |
+| U4 | Current component PR candidates have valid review and applicable checks |
+| U5 | Backend is merged and the user-published tag is verified |
+| U6 | Frontend and Documents are merged; UI ancestry remains valid |
+| U7 | RDM is merged with authoritative pins and a matching product manifest |
+| U8 | Dev is merged through an exclusive queue window with three exact-head GATE jobs |
+| U9 | Stage 10 is approved, records are archived, and guarded cleanup succeeds |
+
+---
+
+## Appendix
+
+### Sources
+
+- `docs/proposals/2026-10-15-iam-focused-role-permission-spec.md`
+- `docs/proposals/2026-10-15-iam-focused-role-permission-implementation-plan.md`
+- `Agent-System-Dev/.task/feature-iam-u4-role-authority.md`
+- `Agent-System-Dev/policy/delivery.md`
+- `Agent-System-Dev/policy/merge-queue.md`
+- `Agent-System-Dev/.gitea/workflows/ci.yaml`
+- `Agent-System-Backend/.gitea/workflows/ci.yml`
+- `Agent-System-RDM/.gitea/workflows/ci.yml`
+- `Agent-System-RDM/scripts/build-product.sh`
+- `Agent-System-Frontend/playwright.config.ts`
+- `Agent-System-Frontend/e2e/rdm-duties.playwright.ts`
@@ -0,0 +1,88 @@
+# 分层分支交付与规范精简 r1
+
+- 状态：已批准实施（2026-10-18 用户指示按计划实施）；推进中
+- 负责人：weichen（需求与批准）
+- 实施：Dev 治理大任务 `feature/delivery-model-v3`
+- 适用范围：Agent-System-Dev 开发流程与规范
+- 更新时间：2026-10-18
+
+## 1. 背景
+
+用户提出的需求：
+
+- 减少合入 Dev main 的次数，让其他分支不必反复同步、反复跑 CI。
+- L2 合入 L1 要轻；按任务类别分别处理，修复优先。
+- 测试、验收、审批放在合适的层级，不在每一层重复。
+- 去掉 Agent 的长时间 sleep 等待；精简膨胀的规范。
+
+2026-10-18 只读基线（均为 **SELF** 观察）：
+
+- main 推进：14 天共 410 次（first-parent），峰值 85 次/天。按 PR 标题粗分，闭合任务卡约 40%、功能约 30%、组件 pin 约 20%、修复约 6%。
+  10-14 启用合入窗口后仍约 17 次/天，闭合 PR 仍占约 40%。
+- 分层使用：近期 291 个已合入 PR 中 288 个 base 为 main，initiative/child 模型只用过一次。
+- CI：3.3 天跑了 200 次，单次中位 8.3 分钟；闭合相关运行约占 31% 机时；main 的 push CI 有 95% 在复测与 PR head 完全相同的树；每个 PR 平均 2.4 次 CI。
+- 等待：Git 远端往返约 0.35 秒。长等待来自 Agent 手写 `sleep N; curl` 轮询 CI，以及串行克隆 105 个嵌套子模块（实际只有 13 个不同仓；并行 `--jobs 8` 实测约 26 秒）。
+- 规范体量：日常必读规范约 4.6 万字符；同一段 Agent 路由规则写了 7 处；归档任务卡中位 113 KB，原因是证据工具把完整 JSON 收据写进了卡。
+
+结论：频繁触发的主因不是层级不够，而是记账类改动也在推进 main，加上每一层都执行同样重的门禁。
+
+## 2. 目标与成功标准
+
+- 任务卡在合入前随 PR 折叠闭合，不再单独开闭合 PR。
+- 统一一个阻塞式的 CI 等待入口，按精确 SHA 等待结果。
+- 完整门禁只在进入 main 时执行；L2 合入 L1 只做轻量检查。
+- 任务分通道：修复直接进 main 并优先；其他类别按主题聚合进 L1。
+- 规范单一权威、更精简；任务卡变小。
+
+成功标准：采纳两周后按本次基线复测。main 推进次数、CI 次数与机时、每 PR 平均 CI 次数均下降；闭合 PR 数降到零（存量清理除外）。
+
+## 3. 方案要点
+
+### 3.1 固定两级分支
+
+- L1 大任务：从 main 切出，最终一次合入 main。L2 子任务：从 L1 切出，合入 L1。
+- L2 内部用 agent-exec 单元控制上下文长度，单元不开 PR，是最轻的一层。
+- 不再加深层级：main 的推进次数只取决于根层交付次数；每多一层就多一条同步链，集成也被推迟；现行 Guidelines 与工具只定义了两级。
+- 太大时横向拆：L1 超过约 2 周或 6–8 个子任务时拆成多个并列 L1；L2 太大就拆成兄弟 L2 或更多单元。
+
+### 3.2 L1 章程
+
+- 章程写在 L1 任务卡顶部：用途与目标、接纳范围与非目标、方案和计划链接、子任务登记、分级测试策略、验收条件、追加的领域规则、生命周期。
+- 建 L1 时立即开一个 base 为 main 的 [WIP] PR，用于分流发现，评论区同时作为仓外调度记录。
+- L1 不追 main，只在三种情况下合入最新 main：最终交付窗口；需要 main 上的某个修复；长周期 L1 到达里程碑或每周一次。
+
+### 3.3 任务通道
+
+- 修复：`fix/` 直接进 main 并优先排队；P0 用 `hotfix/`。
+- 完善：按领域放进“完善列车” L1。
+- 扩展：加入（JOIN）同主题的在途 L1。
+- 新增：新建 L1 并写章程。
+- 治理与规范：集中在一个治理 L1 中。
+- 记录类改动不单独推进 main；组件 pin 跟随用到它的 L1 一起推进。
+
+### 3.4 按层级分配门禁
+
+- 单元合入 L2：worker 自检，host 做最小直接检查。
+- L2 合入 L1：先同步 L1 头，跑受影响模块的测试，由一个全新会话做独立 Review，轻量 CI 作为 GATE。
+  不排合入窗口，不需要分流收据、三段证据和人工审批。
+- L1 的 WIP PR：完整 CI 照常运行，作为不阻塞任何人的提前预警。
+- L1 或修复合入 main：合入窗口、完整 CI、整体 Review、三段证据，以及一次用户专属验收。
+- 人工审批只保留三处：L1 章程确认、L1 最终的用户专属验收、高后果双钥匙操作。
+
+## 4. 阶段与关联任务
+
+| 阶段 | 内容 | 状态 |
+|---|---|---|
+| R | 本主记录、PROJECT.md 链接、治理 L1 及其 WIP PR | 推进中 |
+| P1 | 合入前折叠闭合并清理存量卡；`make ci-wait` 与等待规则；子模块并行物化 | 待实施 |
+| P2 | CI 按 PR base 区分完整与轻量；L2 免分流、免合入窗口、免三段证据；三种卡模板；通道写入 delivery.md | 待实施 |
+| P3 | 规范精简：AGENTS.md 改为入口；delivery.md 作为单一权威并并入 merge-queue；矩阵与采纳记录改为引用；证据摘要入卡、完整收据出卡 | 待实施 |
+| M | 采纳两周后按本次基线复测 | 待执行 |
+
+实时进度以 Dev 治理大任务的任务卡和 PR 为准；本记录只在阶段完成时更新。
+
+## 5. 未纳入与限制
+
+- 分支保护等平台设置不在本方案范围内；如需变更，由用户按双钥匙规则亲手执行。
+- 不引入自动合入队列、合入列车或调度服务。
+- 基线数字按 PR 标题粗分，只用于判断方向；实际效果以复测结果为准。
@@ -0,0 +1,276 @@
+# EXT-20：共享法规检索与网络证据扩展点
+
+状态：**已获用户授权（2026-10-18）**；owner：weichen；主任务：Dev 仓 initiative `feature/regulations-kb`。
+来源计划：Dev 仓 `docs/superpowers/plans/2026-10-18-regulations-knowledge-base-plan.md` 的 KTD1、KTD14 与 U9（本文是 U9 的基座公开契约）。
+规范依据：[扩展面兼容与演进](2026-10-01-extension-compat-policy.md)（§6 扩展点申请模板）；同类先例：EXT-19 账号目录（受信插件注册、Host 可选接口消费）。
+实现位置：Backend 分支 `feature/regulations-kb-ext20`（`pkg/extension/regulations.go`、`internal/app/regulations.go`、`internal/app/compiled.go`；本文核对的提交为 `499ad47`，SELF·源码级）。
+撰写日期：2026-10-18。
+
+## 1. 申请四要素（compat-policy §6）
+
+- **场景**：Agent-System-RDM 处理涉及法规、标准或审评指导原则的问题时，必须同时查询受控法规语料库和真实网络搜索（双源核验），
+  并把每条法规结论绑定到固定语料修订、法规版本、条款节点与原文片段。当前两条腿都走不通：
+  共享法规库没有公开检索入口；RDM 现有网络腿由模型提出 URL 和摘录后再抓取比对，无法证明真实搜索发生过，基座也没有搜索能力。
+- **希望符号**：`pkg/extension` 新增可选能力 `RegulationsHost`（分发 Host 侧消费）、`RegulationsRegistrar`（进程内 Registry 侧注册）、
+  提供方接口 `RegulationsProvider`、请求/结果 DTO、状态常量、`RegulationsSchemaVersion` 与 `ErrRegulationsUnavailable`。
+  `Host` 接口本身不加方法。
+- **为何现有注册点组合不出来**：见第 2 节。
+- **兼容**：纯加法的可选能力；`SurfaceVersion` 由 `2.14.0-experimental` 升为 `2.15.0-experimental`，见第 5 节。
+
+## 2. 为何现有扩展点组合不出来
+
+| 现有扩展点 | 不能承载的原因 |
+|---|---|
+| `Host.KnowledgeSearch` / `KnowledgeWrite` | owner 作用域的项目知识检索，返回 `core.RetrievalHit`。共享法规不属于任何 owner：写进每个 owner 的知识库会复制语料、失去修订不可变性；其返回类型没有语料修订、法规/版本/节点稳定 ID、原文哈希、定位与披露状态，加字段也改变不了 owner 隔离语义。计划 KTD14 明确禁止经它承载共享法规 |
+| 项目作用域知识（`projectID` 参数、项目授权） | 共享法规访问不应随项目扩大或缩小；借项目 ID 访问会让项目成员关系变成法规访问面，也让同一条款在不同项目下出现不同可见性 |
+| `AccountDirectoryRegistrar` | 机制相同（受信插件注册、Host 可选接口消费），但语义专用于账号目录候选判定，不能复用为法规检索 |
+| 通用工具 / 命令总线 / KV / 后台任务 / 审计 | 都不能让一个插件把只读能力安全地提供给另一个插件：没有可归属的真实搜索记录，也不在发往外网前做查询最小化；证据无法钉住语料修订；任何插件都可以注册同名命令冒充提供方，不存在“单一受信提供方” |
+| 下游直接导入法规仓 | 绕过基座的调用方身份、查询最小化与审计边界，违反 RDM“只经基座公开扩展”的约束 |
+
+因此需要一个新扩展点同时满足四点：共享的非项目语料；可归属、做过查询最小化的真实网络搜索；钉住语料修订的不可变证据；单一受信提供方。
+
+## 3. 公开符号（`pkg/extension/regulations.go`）
+
+### 3.1 常量与错误
+
+- `RegulationsSchemaVersion = 1`：基座唯一接受的请求 schema；其他值在到达提供方前被拒绝。
+- 法规检索状态：`RegulationsStateOK = "ok"`、`RegulationsStateEmpty = "empty"`、`RegulationsStateDegraded = "degraded"`、`RegulationsStateUnavailable = "unavailable"`。
+- 法规披露级别：`RegulationDisclosureFull = "full"`、`RegulationDisclosureExcerpt = "excerpt"`、`RegulationDisclosureMetadataOnly = "metadata_only"`、`RegulationDisclosureWithheld = "withheld"`。
+- 网络搜索状态：`WebSearchStateOK = "ok"`、`WebSearchStateEmpty = "empty"`、`WebSearchStateUnavailable = "unavailable"`、`WebSearchStateRateLimited = "rate_limited"`、`WebSearchStateRejected = "rejected"`、`WebSearchStateError = "error"`。
+- 网页抓取状态：`WebCaptureStateCaptured = "captured"`、`WebCaptureStateRejected = "rejected"`、`WebCaptureStateFailed = "failed"`。
+- 网页留存级别：`WebRetentionFull = "full"`、`WebRetentionExcerpt = "excerpt"`、`WebRetentionMetadataOnly = "metadata_only"`。
+- `ErrRegulationsUnavailable`（`"extension: regulations provider unavailable"`）：能力不可用。调用方不得回退到 `KnowledgeSearch`。
+
+### 3.2 接口
+
+```go
+// 由受信的法规知识插件（插件 ID "kbreg"）实现并注册；基座不内置实现。
+type RegulationsProvider interface {
+    SearchRegulations(context.Context, RegulationsCaller, RegulationsSearchRequest) (RegulationsSearchResult, error)
+    ResolveRegulationEvidence(context.Context, RegulationsCaller, RegulationEvidenceRequest) (RegulationEvidence, error)
+    SearchWeb(context.Context, RegulationsCaller, WebSearchRequest) (WebSearchResult, error)
+    CaptureWeb(context.Context, RegulationsCaller, WebCaptureRequest) (WebCapture, error)
+}
+
+// 编译进程内 Registry 的可选能力；只有插件 ID "kbreg" 可注册，且只能注册一次。
+type RegulationsRegistrar interface {
+    RegisterRegulationsProvider(RegulationsProvider) error
+}
+
+// 分发 Host 句柄的可选能力（类型断言获取）；缺失即不可用，调用方不得回退到 KnowledgeSearch。
+type RegulationsHost interface {
+    SearchRegulations(context.Context, RegulationsSearchRequest) (RegulationsSearchResult, error)
+    ResolveRegulationEvidence(context.Context, RegulationEvidenceRequest) (RegulationEvidence, error)
+    SearchWeb(context.Context, WebSearchRequest) (WebSearchResult, error)
+    CaptureWeb(context.Context, WebCaptureRequest) (WebCapture, error)
+}
+```
+
+`RegulationsHost` 与 `RegulationsProvider` 方法一一对应，区别只在 Host 侧没有 `RegulationsCaller` 参数：调用方身份由基座填写，调用方无法注入。
+
+### 3.3 DTO 字段
+
+JSON 名为 camelCase。下表“必出”指没有 `omitempty`、零值也会序列化的字段，其余字段均为 `omitempty`。
+最小 `WebSearchRequest{SchemaVersion: 1, Query: "q"}` 序列化为 `{"schemaVersion":1,"query":"q"}`。
+
+**`RegulationsCaller`**（基座从可信分发上下文填写）
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `PluginID` | `pluginId`（必出） | 发起调用的插件 ID（消费方，例如 `rdm`），不是提供方 ID |
+| `Actor` | `actor` | 本次分发的操作主体 |
+| `Owner` | `owner`（必出） | 本次分发的 owner |
+
+刻意不含项目 ID：共享法规访问既不随项目扩大，也不随项目缩小。
+
+**`RegulationsSearchRequest`**
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `SchemaVersion` | `schemaVersion`（必出） | 必须等于 `RegulationsSchemaVersion` |
+| `Query` | `query`（必出） | 检索文本 |
+| `CorpusRevision` | `corpusRevision` | 要检索的语料修订；空表示当前已发布修订，结果回显实际检索的修订 |
+| `Kinds` | `kinds` | 文献类别过滤（法规、标准、指导原则等，取值由提供方定义） |
+| `CurrentOnly` | `currentOnly` | 只返回现行版本 |
+| `DocNo` | `docNo` | 按文号过滤 |
+| `ClauseNo` | `clauseNo` | 按条款号过滤 |
+| `Limit` | `limit` | 结果数上限，由提供方解释 |
+
+**`RegulationsSearchResult`**
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `CorpusRevision` | `corpusRevision`（必出） | 实际检索的语料修订 |
+| `State` | `state`（必出） | `ok` / `empty` / `degraded` / `unavailable` |
+| `DegradedReasons` | `degradedReasons` | 降级原因（例如向量索引不可用） |
+| `Hits` | `hits`（必出） | 命中列表 `[]RegulationHit` |
+
+**`RegulationHit`**
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `RegulationID` / `EditionID` / `NodeID` | `regulationId` / `editionId` / `nodeId`（必出） | 法规、版本、条款节点的稳定 ID，重新建索引后不变 |
+| `DocNo` / `Title` | `docNo` / `title` | 文号与标题 |
+| `EditionLabel` / `LegalStatus` | `editionLabel` / `legalStatus` | 版本标签与法律效力状态（现行、废止等） |
+| `ClauseNo` / `HeadingPath` | `clauseNo` / `headingPath` | 条款号与章节标题路径 |
+| `Excerpt` / `ExcerptStart` / `ExcerptEnd` | `excerpt` / `excerptStart` / `excerptEnd` | 按披露级别允许返回的原文片段及其偏移 |
+| `NodeSHA256` / `SourceAssetSHA256` | `nodeSha256` / `sourceAssetSha256` | 节点文本哈希与来源资产（原件）哈希 |
+| `PageStart` / `PageEnd` | `pageStart` / `pageEnd` | 原件页码定位 |
+| `Disclosure` | `disclosure`（必出） | `full` / `excerpt` / `metadata_only` / `withheld` |
+| `WithheldReason` | `withheldReason` | 不披露原文的原因（例如来源权利限制） |
+| `IsSummary` | `isSummary` | 命中的是摘要而不是原文 |
+| `MatchKinds` | `matchKinds` | 命中方式（全文、向量、编号等，取值由提供方定义） |
+| `Score` | `score` | 相关度分数 |
+
+**`RegulationEvidenceRequest`**（取回钉住修订的节点原文片段）
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `SchemaVersion` | `schemaVersion`（必出） | 必须等于 `RegulationsSchemaVersion` |
+| `CorpusRevision` | `corpusRevision`（必出） | 证据所钉住的语料修订 |
+| `NodeID` | `nodeId`（必出） | 条款节点 ID |
+| `Start` / `End` | `start` / `end` | 可选的片段偏移 |
+
+**`RegulationEvidence`**
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `CorpusRevision` | `corpusRevision`（必出） | 证据所属修订 |
+| `RegulationID` / `EditionID` | `regulationId` / `editionId` | 法规与版本 ID |
+| `NodeID` | `nodeId`（必出） | 条款节点 ID |
+| `ClauseNo` | `clauseNo` | 条款号 |
+| `Excerpt` / `Start` / `End` | `excerpt` / `start` / `end` | 原文片段与偏移 |
+| `NodeSHA256` / `SourceAssetSHA256` | `nodeSha256` / `sourceAssetSha256` | 节点文本哈希与来源资产哈希 |
+| `PageStart` / `PageEnd` | `pageStart` / `pageEnd` | 页码定位 |
+| `Disclosure` | `disclosure`（必出） | 同 `RegulationHit.Disclosure` |
+| `WithheldReason` | `withheldReason` | 不披露原因 |
+| `HashVerified` | `hashVerified`（必出） | 提供方报告的哈希校验结果；基座原样透传，不自行校验 |
+
+**`WebSearchRequest`**（真实网络搜索）
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `SchemaVersion` | `schemaVersion`（必出） | 必须等于 `RegulationsSchemaVersion` |
+| `Query` | `query`（必出） | 发往外网的搜索词；基座先去首尾空白再校验 |
+| `Exclusions` | `exclusions` | 调用方声明的机密词（项目名、编号、人员等）；查询含任一词即由基座拒绝 |
+| `PreferOfficial` | `preferOfficial` | 优先官方来源 |
+| `Limit` | `limit` | 结果数上限，由提供方解释 |
+
+**`WebSearchResult`**
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `Provider` | `provider` | 实际使用的搜索提供方 |
+| `SentQuery` | `sentQuery` | 实际发往外网的查询 |
+| `SearchedAt` | `searchedAt`（必出） | 搜索时间 |
+| `State` | `state`（必出） | `ok` / `empty` / `unavailable` / `rate_limited` / `rejected` / `error` |
+| `Reason` | `reason` | 非 `ok` 状态的原因 |
+| `Results` | `results` | 排序结果 `[]WebSearchHit` |
+
+**`WebSearchHit`**：`Rank`（`rank`，必出，排名）、`URL`（`url`，必出）、`Title`（`title`）、`Snippet`（`snippet`，搜索摘要，不是已核验证据）、`Publisher`（`publisher`，发布机构）、`Official`（`official`，是否被提供方判定为官方来源）。
+
+**`WebCaptureRequest`**（抓取先前 `SearchWeb` 找到的页面）
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `SchemaVersion` | `schemaVersion`（必出） | 必须等于 `RegulationsSchemaVersion` |
+| `URL` | `url`（必出） | 要抓取的地址 |
+| `SearchProvider` / `SearchQuery` / `SearchRank` | `searchProvider` / `searchQuery` / `searchRank` | 关联的来源搜索（提供方、查询与排名），用于证据溯源 |
+
+**`WebCapture`**
+
+| 字段 | JSON | 含义 |
+|---|---|---|
+| `CaptureID` | `captureId` | 抓取记录 ID |
+| `FinalURL` | `finalUrl` | 跟随重定向后的最终地址 |
+| `FetchedAt` | `fetchedAt`（必出） | 抓取时间 |
+| `ContentType` / `ByteSize` / `SHA256` | `contentType` / `byteSize` / `sha256` | 内容类型、字节数与内容哈希 |
+| `Retention` | `retention` | `full` / `excerpt` / `metadata_only` |
+| `Text` | `text` | 页面全文，仅当来源权利允许全文留存时出现 |
+| `Candidates` | `candidates` | 从页面解析出的条款候选 `[]WebClauseCandidate` |
+| `State` | `state`（必出） | `captured` / `rejected` / `failed` |
+| `Reason` | `reason` | 非 `captured` 状态的原因 |
+
+**`WebClauseCandidate`**：`ClauseNo`（`clauseNo`）、`Excerpt`（`excerpt`，必出）、`Start` / `End`（`start` / `end`，必出，片段在抓取文本中的偏移）。
+
+## 4. 基座强制行为（`internal/app/regulations.go`、`compiled.go`）
+
+### 4.1 注册
+
+1. 只有插件 ID 为 `kbreg` 的编译进程内插件可注册提供方；其他插件 ID 或 `nil` 提供方返回错误。
+2. 只能注册一次：重复注册返回错误，已注册的第一个提供方保持不变。
+3. 声明式 Registry（`compiledRegistry`）一律拒绝 `RegisterRegulationsProvider`。
+4. 宿主未装配提供方槽时，注册返回“registration unavailable”错误；带清单记录的包装 Registry（`recordRegistry`）只把注册转发给内层 `RegulationsRegistrar`。
+
+### 4.2 每次 Host 调用
+
+按以下顺序执行，四个方法一致：
+
+1. 先做账号有效性守卫（`requireEffective`）；停用等无效账号直接返回守卫错误，提供方不会被调用。
+2. 没有已注册提供方或没有审计存储时返回 `ErrRegulationsUnavailable`。调用绝不在无审计的情况下执行；这类不可用调用不写审计。
+3. `RegulationsCaller` 由基座填写为 `{PluginID: 调用插件, Actor: 分发主体, Owner: 分发 owner}`，不含项目 ID。
+4. `SchemaVersion != RegulationsSchemaVersion` 时拒绝并返回错误，提供方不会被调用；写一条 `state=invalid` 的审计。
+5. 只有 `SearchWeb` 做查询最小化校验：
+   - 先去掉 `Query` 首尾空白，提供方收到的是去空白后的查询；
+   - 去空白后为空、不是合法 UTF-8 或超过 256 个 rune 时返回错误（`1-256` 按 rune 计，不按字节计），写 `state=invalid` 审计；
+   - 查询包含任一 `Exclusions` 词时（每个词先去首尾空白，空词忽略，按小写子串匹配，大小写不敏感），基座直接返回
+     `WebSearchResult{State: "rejected", Reason: "query contains an excluded term"}` 且 error 为 nil，提供方不会收到该查询，审计记 `state=rejected`。
+6. 提供方返回的 `State`、`Disclosure`、`Retention`、`DegradedReasons`、`HashVerified` 等全部字段原样透传；基座不把 `degraded`、`withheld`、`rejected`、`rate_limited` 或失败包装成成功，提供方返回的 error 原样返回。
+7. `CaptureWeb` 在基座侧不校验 URL：抓取安全控制（私有/保留地址、重定向、大小、权利留存）属于提供方职责（计划 U5）。
+
+### 4.3 审计
+
+每次到达 schema 校验的调用恰好写一条基座审计事件：owner 为分发 owner，Actor 为 `plugin:<调用插件>`，Target 为 `kbreg`。
+
+| 方法 | 动作 | `revision` | `count` | `state` | `querySha256` |
+|---|---|---|---|---|---|
+| `SearchRegulations` | `regulations.search` | 成功时为结果修订，否则为请求修订 | `len(Hits)` | 提供方 `State` | `Query` 原文的 SHA-256 |
+| `ResolveRegulationEvidence` | `regulations.evidence` | 结果修订非空时取结果，否则为请求修订 | 成功为 1 | 成功为 `ok` | 不记 |
+| `SearchWeb` | `web.search` | 不记 | `len(Results)` | 提供方 `State`，或基座的 `rejected` | 去空白后查询的 SHA-256 |
+| `CaptureWeb` | `web.capture` | 不记 | `len(Candidates)` | 提供方 `State` | 去空白后 `SearchQuery` 的 SHA-256 |
+
+- 审计证据 JSON 只有 `revision`、`count`、`state`、`querySha256` 四个字段（`revision` 与 `querySha256` 为空时省略）；查询明文、法规片段、搜索摘要与网页全文都不进审计。
+- 失败时 `state` 取 `invalid`（schema 或查询校验失败）或 `error`（提供方返回 error），`count` 为 0。
+- 提供方 error 优先返回；调用成功但审计写入失败时，结果被扣留并返回审计错误。
+
+## 5. 兼容
+
+- **可选能力**：`RegulationsHost` 与 `RegulationsRegistrar` 都经类型断言获取，`Host` 与 `Registry` 接口没有新增方法；旧插件、第三方 fake Host 与旧 Registry 实现照常编译。断言失败即能力不可用。
+- **纯加法**：新增 3 个接口、12 个 DTO、20 个状态常量、`RegulationsSchemaVersion` 与 `ErrRegulationsUnavailable`；`surface.txt` 快照同步增加这些顶层名与接口方法。按 compat-policy“每次加法升次版本号”，`SurfaceVersion` 由 `2.14.0-experimental` 升为 `2.15.0-experimental`。
+- **不改 `KnowledgeSearch`**：owner 作用域项目知识检索的签名与语义不变；法规能力缺失时调用方不得回退到它。
+- **组合方式**：法规插件以编译进程内插件注册（`extension.RegisterCompiled`，插件 ID `kbreg`），与 RDM 同二进制组合。当前只有进程内 `inprocHost` 实现 `RegulationsHost`；sidecar `/host/v1` HTTP 路由不在本扩展范围，出现真实需求再申请。
+- **请求演进**：请求 schema 以 `RegulationsSchemaVersion` 显式版本化；新增可选字段一律带 `omitempty`，不兼容的请求变更须升 schema 版本并另行申请。
+
+## 6. 验收（对应 Backend 测试）
+
+| 验收条件 | 测试 |
+|---|---|
+| 能力可选：空 Host/Registry 不暴露能力；schema 版本为 1；错误值已定义；下游仅凭 `pkg/extension` 即可实现提供方 | `pkg/extension` `TestRegulationsContractIsOptional` |
+| 状态常量的线上取值固定；可选字段省略；`RegulationsCaller` 序列化不含 project | `pkg/extension` `TestRegulationsWireNames` |
+| 无提供方或无提供方槽时四个方法都返回 `ErrRegulationsUnavailable`，且不写审计 | `internal/app` `TestRegulationsUnavailableWithoutProvider` |
+| 只有 `kbreg` 可注册；`nil` 被拒；重复注册被拒且不替换；无槽时注册被拒 | `TestRegulationsRegistrationOnlyTrustedKbregOnce` |
+| 声明式 Registry 拒绝注册；记录型包装 Registry 转发 `kbreg` 注册 | `TestRegulationsDeclarativeRegistrationRejected` |
+| 提供方收到的 Caller 由分发上下文填写 | `TestRegulationsCallerFilledFromDispatchContext` |
+| schema 版本 0 与 2 被拒，提供方不被调用 | `TestRegulationsRejectsOtherSchemaVersions` |
+| 空查询、纯空白查询、257 rune 查询被拒；256 rune 查询通过且提供方收到去空白后的查询 | `TestRegulationsWebQueryBounds` |
+| 含排除词（大小写不敏感）的查询返回 `rejected`、提供方不被调用、审计不含该词；空排除词不拦截 | `TestRegulationsExclusionRejectedBeforeProvider` |
+| 提供方的 `degraded`、`withheld`、`metadata_only`、`rate_limited`、`rejected` 与 error 原样透传 | `TestRegulationsProviderStatesPassThroughUnchanged` |
+| 每次调用一条审计，只含 revision、count、state、querySha256，不含查询明文、片段或网页文本 | `TestRegulationsAuditEvidenceOmitsQueryAndText` |
+| 账号无效时四个方法返回守卫错误，提供方不被调用 | `TestRegulationsRequireEffectiveAccount` |
+| 只用 `pkg/extension` 的测试插件以 `kbreg` 经编译插件路径注册，冒充插件注册失败，另一编译插件经 Host 断言调用成功并留下基座审计 | `TestRegulationsCompiledPluginCompatibility` |
+| 未编入提供方时消费方命令不会提交成功 | `TestRegulationsCompiledConsumerWithoutProvider` |
+
+另需 `pkg/extension` 的 surface 快照测试通过（`surface.txt` 与导出面一致）。
+
+## 7. 分工
+
+- **Backend（本扩展，计划 U9）**：只负责公开契约、基座强制行为与兼容测试；不内置提供方、不实现搜索或抓取、不实现 RDM 适配器。
+- **`Agent-System-KB-Regulations`（计划 U2–U5）**：实现并以插件 ID `kbreg` 注册 `RegulationsProvider`，负责语料修订、检索、披露级别、真实搜索提供方适配、网页抓取安全控制与权利留存。
+- **Agent-System-RDM（计划 U6/U7）**：经 `RegulationsHost` 消费本能力，把语料检索与网络搜索作为两条独立证据腿做双源核验；负责项目授权、引用渲染与业务审计投影。能力不可用时必须显式降级，不得回退到 `KnowledgeSearch`，也不得宣称完成双源核验。
+- **Dev（计划 U8）**：组合 pin 与组合验证。
+
+## 8. 不在本文范围
+
+- sidecar `/host/v1` HTTP 路由与远程提供方形态。
+- 搜索提供方选择、实网联调与费用（需用户另行确认提供方与凭据）。
+- RDM 证据批次模型、引用展示与篡改检测记录（计划 U6/U7）。
@@ -4,11 +4,21 @@
 本索引负责导航与差异提示，规划正文、批准范围和验收条件仍以链接的主记录及其批准版本为准。
 合入授权不批准新方向、不调整里程碑范围、不启动新的业务任务。

+[分层分支交付与规范精简 r1](2026-10-18-delivery-model-v3.md)：2026-10-18 经用户批准实施；
+由 Dev 治理大任务 `feature/delivery-model-v3` 推进，实时进度见该任务卡与 PR。
+
+[EXT-20 共享法规检索与网络证据扩展点](2026-10-18-ext-20-regulations-provider.md)：法规知识库计划 U9 的基座公开契约；
+2026-10-18 经用户授权，由 Dev initiative `feature/regulations-kb` 推进，实时进度见该任务卡与 PR。
+
 待评审（收录不是批准）：[svc 插件组合部署（--with）方案 r1](2026-10-14-svc-plugin-compose-deploy.md)；
 [分层 Python 环境方案 r1](2026-10-15-layered-python-env.md)（8788 无法生成 docx 的环境层；白名单自动批准，其余审批）。

 ## 先看哪一份

+- [IAM U4 阶段 7–10 验收与交付计划](2026-10-15-iam-u4-stage7-10-delivery-plan.md)：
+  基于已批准的聚焦角色权限实现，安排真实浏览器验收、跨仓 Review/PR/CI、Backend 受信 tag、RDM 权威 pin、Dev 手工合入窗口及安全收口。
+  生产迁移、部署、多角色、账号恢复、Agent 权限和工作流改造不在本计划内。
+
 - [IAM I1 权限边界与公开扩展合同 r1](2026-10-13-iam-i1-permission-contract.md)：
  依据已批准的[用户、职位角色与分层权限统一方案 r1](2026-10-13-identity-role-permission-plan.md)
  （Documents `a088809`）冻结系统／项目／资源边界、管理员无业务 bypass、创建者 cap、独立 `audit.read` 与公开扩展四要素。
@@ -0,0 +1,38 @@
+# 通用规范采纳记录
+
+- 项目/负责人：Agent-System-Documents / weichen
+- 状态：active
+- 规范位置：`deps/development-guidelines`（gitlink，见下方版本权威）
+- 规范性文档目录：`policy/`（本仓当前仅含本采纳记录，无其他规范性文档；项目规则与制度放此处）
+- 过程文档位置：过程记录保存在本仓 `docs/` 固定目录，不另设独立过程仓库：实施记录 `docs/records/`、设计方案与计划 `docs/proposals/`（索引 `docs/proposals/INDEX.md`）、测试报告 `docs/reports/`、使用报告与插件开发指南 `docs/guides/`，目录入口见 `README.md`（仓内固定目录的登记见下方项目差异表）；`.task/` 仅为治理交付流程的任务卡与证据位置（随 PR 维护），任务主记录在 PR 描述中
+- 版本权威：本仓 gitlink `deps/development-guidelines` @ `2688fd2be6a52c0bf110e7e6366b6f291ab5e4eb`（可读标签：无，固定提交的 VERSION 为 0.1.0-draft.12）
+- 批准/生效依据：`feature/governance-adoption` PR（Agent-System-Documents）
+- 替代范围和迁移说明：无。既有 AGENTS.md、PROJECT.md、AGENT-EXECUTION.md、docs/ 与 .task/ 全部保留，不替代、不迁移历史记录。
+
+| 规范/工作流 | 适用条件与范围 | 采纳或不适用理由 | 执行方式/证据 |
+|---|---|---|---|
+| core/baseline.md | 本仓全部工作（文档、治理与任务交付） | 适用：所有变更遵循其强度与授权定义 | manual；AGENTS.md 入口 |
+| workflows/delivery.md、debugging.md、handoff.md | 交付（任务卡 + PR）、排障、跨会话交接 | 适用：交付经 `.task/` 任务卡与 PR 进行；交接状态写入任务主记录 | manual；AGENTS.md 与 `.task/feature-governance-adoption.md` |
+| standards/collaboration.md | 并行共同起点、两级分支、节点同步与陈旧候选拒绝 | 适用：AGENTS.md 启动门禁要求从权威 origin/main 固定起点并同步 | manual；AGENTS.md 启动门禁与任务卡同步记录 |
+| standards/merge-queue.md | 多个就绪任务同一目标分支的串行交付调度 | 不适用：本仓不单独维护同一目标分支的多任务交付队列，本仓自身的交付不经队列调度。本仓存放的合入调度试行记录 [docs/records/2026-10-14-merge-queue-trial.md](../docs/records/2026-10-14-merge-queue-trial.md) 与实施计划 [docs/proposals/2026-10-13-merge-queue-implementation-plan.md](../docs/proposals/2026-10-13-merge-queue-implementation-plan.md) 记录的是 Agent-System-Dev 的调度（依据 Dev 仓 `policy/merge-queue.md` 与 Dev #518），本仓仅以文档形式保存 | 不适用 |
+| standards/agent-execution.md | 工程 Agent CLI 执行路由、会话隔离与受控集成 | 适用：允许 AI 协助文档与治理变更，必须采纳；配置见 AGENT-EXECUTION.md | AGENT-EXECUTION.md + scripts/agent-exec（validate / admit）；证据：governance check 与 CLI 正负例（`.task/feature-governance-adoption.md`） |
+| standards/verification.md | 验证与结论 | 适用：本仓无可编译程序，验证以文档检查与治理检查为主 | `git diff --check`、`scripts/dm governance check --repo .`、`scripts/agent-exec validate --repo .`（PROJECT.md 验证节）；`.gitea/workflows/governance.yml` |
+| standards/documentation.md | 文档结构、相对链接、版本与引用一致性 | 适用：本仓即系统文档仓（docs/ 与 README 目录） | manual；PROJECT.md 验证节 |
+| standards/multi-repo.md | 跨仓 gitlink 与组合验证 | 适用：Development-Guidelines 与 Development-Manager 以 gitlink 挂载，gitlink 变更须经 Dev 仓组合验证后推进 | manual；AGENTS.md 仓内规则 |
+| standards/security.md | 凭证与秘密不入仓 | 适用：AGENTS.md 规定 token 不入仓、不回显、不写入产出物 | manual；AGENTS.md Gitea 访问事实节 |
+| workflows/design-verification.md、standards/testability.md、standards/failure-containment.md | 功能增量的设计/验证、模块测试与故障控制 | 不适用：本仓不含产品代码、运行服务或业务测试套件（见 PROJECT.md 验证节） | 不适用 |
+| standards/module-contracts.md、observability.md、data-reliability.md、release-operations.md、configuration.md、tool-adaptation.md | 业务模块契约、观测、数据可靠性、发布运维、运行配置、工具适配 | 不适用：本仓无业务模块、运行服务、发布制品或运行配置；模块边界如出现时再启用 | 不适用 |
+
+## 项目差异
+
+| 原规则/章节 | 项目采用方式 | 原因与风险 | 负责人/复查条件 |
+|---|---|---|---|
+| standards/documentation.md 过程记录位置 | 登记为仓内固定目录豁免：过程记录保存于 `docs/records/`、`docs/proposals/`、`docs/reports/`、`docs/guides/`（按 `README.md` 目录），任务卡与证据保存于 `.task/`；不另设独立过程仓库 | 本仓即系统文档与过程记录仓（见 `README.md`），过程记录本身是其内容，拆出独立仓会使文档与其引用的实施记录分离。风险：规范文档与过程记录同仓，需依靠目录边界与 `docs/proposals/INDEX.md` 区分 | weichen；复查条件：建立独立过程仓库，或 Development-Guidelines 固定版本变更过程记录位置规则时复查 |
+
+默认做法差异说明理由；硬边界冲突须有明确有效决策，不能用此表自授权。建议不采用无需登记。
+
+## 本次升级或首次接入验证
+
+本次为首次接入，采用 `governance init --adopt` 固定 Development-Guidelines `2688fd2be6a52c0bf110e7e6366b6f291ab5e4eb` 与 Development-Manager `bd3a7de57a3a9e1a4495b94c5fa5c08d71e7be8c`。既有 AGENTS.md、PROJECT.md、AGENT-EXECUTION.md 保留，新增治理文件见 `scripts/`、`.gitea/workflows/governance.yml`、`.task/templates/task-card.md`。正负例与 `governance check`、`agent-exec validate` 的输出证据记录于 `.task/feature-governance-adoption.md`。
+
+回退方式：删除两个 gitlink（`deps/development-guidelines`、`deps/development-manager`）、`.gitmodules`、`scripts/`、`.gitea/workflows/governance.yml`、`.task/templates/task-card.md` 与本记录，并撤销 AGENTS.md 与 PROJECT.md 中新增的段落。回退前须确认不再有任务依赖 `scripts/agent-exec` 路由。
@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+# 共享 Agent 执行器薄入口：转调 scripts/dm 的 agent-exec 子命令（validate / run / apply / admit / cleanup）。
+set -euo pipefail
+exec "$(dirname "$0")/dm" agent-exec "$@"
@@ -0,0 +1,55 @@
+#!/usr/bin/env bash
+# 共享 dm-server 薄入口：读取 deps/development-manager 的 gitlink 钉住提交，
+# 按该提交构建并缓存 dm-server，再 exec 其子命令（agent-exec、task、governance）。执行语义与退出码以该二进制为准。
+set -euo pipefail
+
+root=$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd -P)
+dm="$root/deps/development-manager"
+
+die() { echo "dm: $*" >&2; exit 2; }
+
+# git 钩子会导出仓库本地变量（GIT_DIR、GIT_INDEX_FILE 等），它们会让 `git -C "$dm"` 解析到外层仓库。
+# 所有针对 DM 检出的 git 与 go 调用都在清除这些变量后执行；读取外层 gitlink 与最终 exec 仍保留继承环境。
+dm_local_env="GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE GIT_PREFIX GIT_OBJECT_DIRECTORY GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_GRAFT_FILE GIT_NAMESPACE GIT_CONFIG GIT_CONFIG_PARAMETERS GIT_CONFIG_COUNT GIT_SHALLOW_FILE GIT_IMPLICIT_WORK_TREE $(git rev-parse --local-env-vars 2>/dev/null || true)"
+dm_clean_env() { for v in $dm_local_env; do unset "$v"; done; }
+dmgit() ( dm_clean_env; git -C "$dm" "$@" )
+
+# 1. 钉住版本只来自索引中的 gitlink（mode 160000），不读取工作区文件。
+entry=$(git -C "$root" ls-files -s -- deps/development-manager 2>/dev/null || true)
+[ -n "$entry" ] || die "索引中缺少 deps/development-manager 的 gitlink，无法确定钉住的 DM 版本"
+read -r mode pin _stage _path <<<"$entry"
+[ "$mode" = 160000 ] || die "deps/development-manager 不是 gitlink（mode=$mode）"
+[[ "$pin" =~ ^[0-9a-f]{40}$ ]] || die "gitlink 提交格式无效：$pin"
+
+# 2. 检出必须存在且确为 DM 独立仓库（避免 git -C 误解析到外层仓库），HEAD 必须等于钉住提交。
+[ -e "$dm/.git" ] || die "deps/development-manager 未检出；请按钉住提交 $pin 检出该 gitlink"
+top=$(dmgit rev-parse --show-toplevel 2>/dev/null || true)
+[ -n "$top" ] && [ "$top" = "$(cd "$dm" && pwd -P)" ] \
+  || die "deps/development-manager 不是独立检出；请按钉住提交 $pin 检出该 gitlink"
+head=$(dmgit rev-parse HEAD 2>/dev/null || true)
+[ "$head" = "$pin" ] \
+  || die "deps/development-manager HEAD（${head:-未知}）与钉住提交 $pin 不一致；请按钉住提交检出"
+
+# 3. 检出工作树必须干净（忽略嵌套 submodule 状态）。
+dirty=$(dmgit status --porcelain --ignore-submodules=all) \
+  || die "无法读取 deps/development-manager 的工作树状态"
+[ -z "$dirty" ] || die "deps/development-manager 存在未提交改动，拒绝运行（请先清理该检出）"
+
+# 4. 二进制按钉住提交缓存；缺失时在缓存目录内临时构建，完成后原子改名，避免留下半成品。
+cache="${DM_CACHE:-${XDG_CACHE_HOME:-$HOME/.cache}/development-manager/dm-server}"
+bin="$cache/dm-server-$pin"
+if [ ! -x "$bin" ]; then
+  command -v go >/dev/null 2>&1 || die "缺少 go，无法构建 dm-server（$pin）"
+  mkdir -p "$cache"
+  cache=$(cd "$cache" && pwd -P)
+  bin="$cache/dm-server-$pin"
+  work=$(mktemp -d "$cache/build-$pin.XXXXXX")
+  if ! (dm_clean_env; cd "$dm" && GOWORK=off go build -trimpath -o "$work/dm-server" ./cmd/dm-server); then
+    rm -rf "$work"
+    die "构建 dm-server 失败（$pin）"
+  fi
+  mv -f "$work/dm-server" "$bin"
+  rm -rf "$work"
+fi
+
+exec "$bin" "$@"
@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+# 本地检查（pre-commit）：集成分支直提拒绝 + 分支命名 + 本地完整性核对。权威准入在 PR（baseline.md:26）。
+branch=$(git rev-parse --abbrev-ref HEAD)
+case "$branch" in
+  main|master)
+    echo "pre-commit: 拒绝——集成分支 ${branch} 不得直接提交，走 feature 分支 + PR（collaboration.md）" >&2
+    exit 1 ;;
+esac
+echo "$branch" | grep -qE '^(feature|fix|hotfix|release)/[A-Za-z0-9._-]+$' || {
+  echo "pre-commit: 拒绝——分支名须为 feature|fix|hotfix|release/<slug>，当前：${branch}" >&2
+  exit 1
+}
+root=$(git rev-parse --show-toplevel)
+# admit 只是本地完整性/篡改证据（SELF）：同一 OS 用户可读取本地 HMAC 密钥并绕过本钩子，
+# 它不是 GATE，也不是可信身份。缺失或无效的本地记录仍拒绝；交付信任来自精确 HEAD 的 CI 或独立 REPLAY。
+"$root/scripts/agent-exec" admit --repo "$root"
@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+# 通用任务入口：转调 scripts/dm 的 task 子命令（triage / start / pr-check）。
+set -euo pipefail
+exec "$(dirname "$0")/dm" task "$@"
Author	SHA1	Message	Date
weichen	0b16daf14a	Merge Documents main into IAM U4 role authority governance / governance (pull_request) Successful in 17s Details Why: U4 must sync main before stage 7 acceptance; main carries 21 newer commits (renderer, regulations and two-trees documents). Evidence: git merge-tree reported no conflicts; no content resolved by hand. Impact: U4 documents now sit on main `5bb4877`. Refs: Dev card feature-iam-u4-role-authority	2026-10-18 14:03:41 +00:00
weichen	5bb487795c	Merge the EXT-20 shared regulations extension point proposal governance / governance (push) Successful in 14s Details Why: Register the U9 public contract proposal. Evidence: CI success on `3a3904fe` (governance). Impact: Documentation only. Refs: .task/feature-regulations-kb-ext20-proposal.md	2026-10-18 10:04:17 +00:00
weichenandCursor	3a3904fea6	Close the EXT-20 proposal task card before merge governance / governance (pull_request) Successful in 15s Details Why: Card closes in the same PR per delivery rules. Evidence: Card only. Impact: None. Refs: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/113 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-18 10:03:29 +00:00
agent-exec-transport	52d77f6834	agent-exec transport 236440f7dd8706d5e75570537e655d7a/1584524c456c governance / governance (pull_request) Successful in 14s Details	2026-10-18 09:57:34 +00:00
weichenandCursor	e4aa3c6d99	Open the EXT-20 proposal task card Why: Register the U9 public contract proposal through the governed path. Evidence: Card only. Impact: None. Refs: Agent-System-Dev feature/regulations-kb Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-18 09:52:14 +00:00
weichen	e2f5729e8f	Merge pull request 'Record the layered delivery and spec slimming proposal' (#112 ) from feature/delivery-model-v3-record into main governance / governance (push) Successful in 13s Details Record the layered delivery and spec slimming proposal (#112)	2026-10-17 19:56:44 +00:00
agent-exec-transport	c1b0b35352	agent-exec transport c40e652385634327f58e6f1946d49604/5001e4ce8764 governance / governance (pull_request) Successful in 14s Details	2026-10-17 19:55:36 +00:00
weichen	6c04eb24f4	Merge pull request 'Adopt the shared governance kit (development-governance-v2)' (#110 ) from feature/governance-adoption into main governance / governance (push) Successful in 23s Details	2026-10-17 09:25:26 +00:00
weichen	acaaaa67e0	Close and archive the governance adoption card governance / governance (pull_request) Successful in 20s Details Why: the adoption PR is reviewed and its candidate HEAD passed CI; the card closure is folded into the PR so no separate close PR is needed. Evidence: CI GATE on 9d4582a47f4f4c887afd2fafb3ad507f20716f8d; independent Review REPLAY (cursor-agent-stable --mode ask 全新只读会话（fresh_session=true，session id not-observable）闭合重审 VERDICT: APPROVE（对象 9d4582a，与 HEAD 仅 .task/ 不同）). Impact: task card only (moved to .task/archive/). Refs: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/110	2026-10-17 09:22:10 +00:00
weichen	9d4582a47f	docs(task): complete the card for review (sync, CI, results) governance / governance (pull_request) Successful in 23s Details	2026-10-17 08:47:52 +00:00
weichen	6a1308c251	docs(task): record review repair run and evidence governance / governance (pull_request) Successful in 17s Details Why: independent Review blocked the adoption; the repair unit ran through the shared executor and was integrated with agent-exec apply. Evidence: .task/evidence/governance-adoption/ (SELF): governance check and agent-exec validate on the repaired head. Impact: task card and evidence logs only. Refs: .task/feature-governance-adoption.md	2026-10-17 08:41:29 +00:00
agent-exec-transport	31daf7f764	agent-exec transport cddbee3518698a94ceaaac4d563e14d9/c95307af4fb6	2026-10-17 08:39:06 +00:00
weichen	c51ae06b4d	Record the adoption unit run and positive/negative evidence governance / governance (pull_request) Successful in 18s Details Why: Phase 6 requires one positive executor run and the negative cases (missing config, bad receipt, out-of-scope path, unknown side effect) before adoption becomes active. Evidence: .task/evidence/governance-adoption/ (SELF): governance check, agent-exec validate and adoption cases; this commit passed the generated pre-commit hook (admit). Impact: task card and evidence logs only. Refs: .task/feature-governance-adoption.md	2026-10-17 07:40:47 +00:00
agent-exec-transport	fd13a26677	agent-exec transport 8348cbe4ac5d7604985d8d0f38187573/1df0d292eafb	2026-10-17 07:40:26 +00:00
weichen	cf44b1ed04	Record the failed first attempt and its reconciliation Why: the r1 attempt ended failed-unknown (invalid terminal record); fail-stop requires reconciliation before a fresh attempt. Evidence: receipt /tmp/gov-receipt-Agent-System-Documents-r1.json; worktree clean, no transport ref (SELF). Impact: task card only. Refs: .task/feature-governance-adoption.md	2026-10-17 07:37:54 +00:00
weichen	d259242849	Bootstrap AGENT-EXECUTION.md and the governance adoption card Why: development-governance-v2 Phase 6 adopts the shared governance kit in every formal repository; the executor needs a valid AGENT-EXECUTION.md before any implementation unit can run. Evidence: generated by dm-server governance init at Development-Manager bd3a7de57a3a9e1a4495b94c5fa5c08d71e7be8c; dm-server agent-exec validate passes. Impact: configuration and task card only; no code or CI change yet. Refs: Agent-System-Dev docs/superpowers/plans/2026-10-16-development-governance-v2-master.md	2026-10-17 07:16:27 +00:00
weichen	da4d016ee1	Merge pull request 'Record the layered Python environment proposal' Reviewed against the layered environment plan. Required CI on the current head passed where this repository runs CI.	2026-10-15 14:24:47 +00:00
weichen	c0611814aa	Merge remote-tracking branch 'origin/main' into feature/iam-u4-role-authority	2026-10-15 06:03:14 +00:00
weichen	bcdb30cc55	Plan IAM U4 acceptance and protected delivery Why: The approved role and permission implementation needs a focused, reviewable path through browser acceptance, component delivery, and guarded closure. Evidence: Structural audit confirms DR1-DR21, U1-U9, and KTD1-KTD6; git diff --check passes; six-lens document review findings are incorporated. Impact: Adds the stage 7-10 plan, records the focused specification approval, and indexes the plan without authorizing production migration or deployment. Refs: feature/iam-u4-role-authority	2026-10-15 03:53:10 +00:00
weichen	e251c4bd62	Merge authoritative main before stage 7 planning Why: base the IAM delivery plan on the current Documents main. Evidence: fetched origin/main=87b88018b9236434b97ff6781655d625901d4090. Impact: integrates documentation-only upstream changes before adding the U4 delivery plan. Refs: feature/iam-u4-role-authority	2026-10-15 03:26:15 +00:00
weichen	e9ce9a539e	Plan the focused role and permission implementation Why: The approved scope spans Backend authority, RDM project enforcement, and Frontend configuration and needs exact contracts and verification boundaries. Evidence: The plan was checked against every specification section, fixed interface names, failure cases, and placeholder rules. Impact: Implementation is limited to one effective role, system and project authorization, and the requested configuration views. Refs: Focused role and permission system spec	2026-10-14 16:42:24 +00:00
weichen	d77c6425bc	Define the focused role and permission system Why: The implementation scope must match the requested single-role position model and three permission layers without carrying unrelated IAM work. Evidence: The spec was checked for placeholders, internal contradictions, and whitespace errors. Impact: Backend becomes the role authority while RDM retains project permissions and document duties. Refs: IAM role and permission system	2026-10-14 16:37:01 +00:00