docs(review): clarify approval authority and reviewer separation

README.md

@@ -215,8 +215,11 @@ host-local projection.
   Experience, with optional Profile snapshots and Topic Memory, then applies a shared byte budget and returns `ready`
   content or `empty`. Recalled content is history, not an instruction authority: the receiving Agent still follows
   current instructions and checks live workspace state.
-- **Review before reuse.** Experience and Skill pass through a review decision that is terminal either way. The model
-  proposes rather than silently promoting its own output.
+- **Review before reuse.** Experience and Skill pass through a review decision that is terminal either way, and
+  approval writes an immutable Revision. With access control enforced, approval requires `scope.review`. An
+  authorized Agent can approve its own Candidate;
+  [separate submission and review](https://powercontext.oceanbase.io/en/docs/workflows/review-candidates/#separate-agent-submission-from-review)
+  with distinct identities and permissions when a person must decide.
 - **One Server, several views of the same contract.** HTTP is the complete remote application contract. The Python Client
   gives typed access, MCP is a curated Agent-facing projection, and Core protocols let an application assemble its own
   Source, Artifact, and Trigger implementations.

README_CN.md

@@ -174,7 +174,7 @@ Experience 记录一个场景、一次动作、观察到的结果，以及可复
 - **一切都带版本、可追溯。** 每个 Artifact 都以 `家族/ARTIFACT_ID@REVISION` 寻址。通过替换产生的后续 Revision 不会改变 Artifact ID，读取一个精确的引用会返回那一份历史快照，即使家族主版本已经前进。
 - **生成、评审、执行是三个分开的步骤。** 模型可以提出内容，评审通过某个 Revision，导出生成宿主内副本。这三步都不会授予 Agent 执行指令的权限。各个入口目前各自暴露了什么，见[接口说明](https://powercontext.oceanbase.io/zh/docs/develop/interfaces/)。
 - **召回是有边界的，不是整包倾倒。** `PreparedContext` 会按请求选择活跃的 Memory 和已通过的 Experience，并可选加入 Profile 快照和 Topic Memory，再套用一个共享的字节预算，返回 `ready` 内容或 `empty`。召回的内容是历史，不是指令权威：接收方仍然要遵循当前指令，并检查工作区的实时状态。
-- **复用之前先评审。** Experience 和 Skill 都要经过一次评审决策，无论通过还是驳回都是终态。模型负责提议，而不是悄悄把自己生成的内容提上去。
+- **复用之前先评审。** Experience 和 Skill 都要经过一次评审决策，无论通过还是驳回都是终态；批准会写入不可变 Revision。启用权限控制后，批准需要 `scope.review`。有审核权限的 Agent 仍可批准自己的 Candidate；需要由人决定时，应使用不同身份和权限[分离 Agent 提交与审核](https://powercontext.oceanbase.io/zh/docs/workflows/review-candidates/#分离-agent-提交与审核)。
 - **一个 Server，同一份契约的多个视图。** HTTP 是完整的远端应用契约。Python Client 提供带类型的访问，MCP 是面向 Agent 的精选投影，Core 协议则允许应用自行组装 Source、Artifact 和 Trigger 实现。
 
 ### 横向对比

README_JP.md

@@ -168,7 +168,7 @@ Experience は、状況・行動・観察された結果・再利用可能な教
 - **すべてがリビジョン管理され、追跡可能です。** 各 Artifact は `ファミリ/ARTIFACT_ID@REVISION` で識別されます。承認された置換が後のリビジョンを作っても ARTIFACT_ID は変わらず、正確な参照を読めば、ファミリのヘッドが進んだ後でもその時点のスナップショットが返ります。
 - **生成・レビュー・実行は別々のステップです。** モデルが内容を提案し、レビューがリビジョンを承認し、エクスポートがホスト内のコピーを作ります。いずれのステップも、Agent に命令実行の権限を与えるものではありません。各入口が現在何を公開しているかは[インターフェース](https://powercontext.oceanbase.io/en/docs/develop/interfaces/)を参照してください。
 - **想起はまとめてではなく、境界つきで行われます。** `PreparedContext` は設定されたセクションからアクティブな Memory と承認済み Experience を選択し、必要に応じて Profile スナップショットと Topic Memory を加え、共有のバイト予算を適用して `ready` または `empty` を返します。想起された内容は履歴であり、命令の権威ではありません。受け手の Agent は現在の指示に従い、実際のワークスペースの状態を確認します。
-- **再利用の前にレビューを通します。** Experience と Skill はレビューの決定を経ます。承認・却下のいずれも終端です。モデルは提案までを担い、自分の出力を暗黙のうちに昇格させることはありません。
+- **再利用の前にレビューを通します。** Experience と Skill はレビューの決定を経て、承認・却下のいずれも終端です。承認は不変リビジョンを書き込みます。アクセス制御が有効な場合、承認には `scope.review` が必要です。レビュー権限を持つ Agent は自分の Candidate も承認できます。人が判断する運用では、異なる ID と権限で[Agent の提出とレビューを分離](https://powercontext.oceanbase.io/en/docs/workflows/review-candidates/#separate-agent-submission-from-review)してください。
 - **1 つの Server、同じ契約の複数の見え方。** HTTP が完全なリモートアプリケーション契約です。Python クライアントは型付きアクセスを提供し、MCP は Agent 向けに取捨選択された投影であり、Core プロトコルを使えばアプリケーション側で Source・Artifact・Trigger の実装を組み込めます。
 
 ### 他手段との比較

docs/en/docs/develop/interfaces.md

@@ -179,6 +179,11 @@ The unified HTTP review routes are `/v1/candidates/list`, `get`, `history`, `rev
 `candidate_kind=artifact|tag` distinguishes proposals. Old Artifact Candidate routes are removed; callers must upgrade together.
 Artifact approval returns a real revision; Tag approval returns committed tags and ETag without creating a content revision.
 
+Review decisions remain available through MCP. With access control enforced, Server authorization requires
+`scope.review`; it does not prohibit an authorized proposer from approving its own Candidate. MCP tool annotations let
+hosts apply confirmation policies but do not require human confirmation. See
+[Review authority](../workflows/review-candidates.md#review-authority) for access modes and reviewer separation.
+
 The `candidate` command group exposes the human Review Inbox. See [Review Candidates](../workflows/review-candidates.md)
 for the ordered workflow to list, inspect, revise, approve, or reject Candidates.
 
@@ -210,8 +215,8 @@ sets `target`. Managed Skill generation also declares its provenance shape:
 
 These generation operations require `POWERCONTEXT_SERVER_INFERENCE_GENERATION_MODEL`. The lower-level `propose_*`
 operations remain available for a human or integration that already has complete typed content and exact evidence.
-Neither path approves its own Candidate. After Review approval, deterministic `searchable_text` is stored on the
-existing generic Artifact head and enters the backend's rebuildable FTS index, making the Experience eligible for
+Both paths return pending content; approval is a separate operation. After Review approval, deterministic
+`searchable_text` is stored on the existing generic Artifact head and enters the backend's rebuildable FTS index, making the Experience eligible for
 `PreparedContext` recall in the same scope. Pending and rejected Candidates, all managed Skills, and historical
 Experience revisions remain excluded.
 

docs/en/docs/operate/deploy-server.md

@@ -181,6 +181,10 @@ AccessControlService must disable the Dashboard; an incompatible enabled configu
 Disabling it does not affect team API or MCP access. For personal setup, see
 [Install and run](../get-started/install-and-run.md).
 
+A shared static token does not enforce human review or prevent an Agent from approving its own Candidate. For separate
+submission and approval, use distinct authenticated Principals and grant review permission only to the reviewer.
+See [Separate Agent submission from review](../workflows/review-candidates.md#separate-agent-submission-from-review).
+
 ## Check the deployment
 
 Use liveness to determine whether the process can answer HTTP requests:

docs/en/docs/workflows/architecture.md

@@ -69,9 +69,11 @@ See [deployment and operations](../operate/index.md) for deployment settings, se
 | Review / projection | Reviews Candidates or exports an exact approved Skill Revision to a host | Rewriting historical Revisions, installing, or executing a Skill automatically |
 | Database and persistence layer | Stores Scopes, Sources, Artifact Revisions, and processing state | The deployment layer's backup and recovery policy |
 
-Model generation, human review, and execution authority are separate boundaries. Proposals requiring review commit after
-approval; direct Create/Replace commits a validated Revision under the caller's governance policy. Export creates a
-host-local copy without granting execution authority. `PreparedContext` is temporary for one Agent turn, not a new Artifact.
+Model generation, Review approval, and execution authority are separate boundaries. Proposals requiring review commit after
+approval; [review authority](review-candidates.md#review-authority) determines who can approve, without requiring a human
+or a different proposer identity. Direct Create/Replace commits a validated Revision under the caller's governance
+policy. Export creates a host-local copy without granting execution authority. `PreparedContext` is temporary for one
+Agent turn, not a new Artifact.
 
 ## Content types currently supported
 

docs/en/docs/workflows/experience-and-skill-lifecycle.md

@@ -5,9 +5,10 @@ description: Learn how evidence becomes reviewed Experience and managed Skill Ar
 
 # Experience and Skill lifecycle
 
-Experience and managed Skill content passes through the same review boundary. Evidence supports a proposal, a human
-reviews one exact Candidate version, and approval creates an immutable Artifact Revision. Generation never approves
-its own result.
+Experience and managed Skill content passes through the same review boundary. Evidence supports a proposal, a reviewer
+inspects one exact Candidate version, and approval creates an immutable Artifact Revision. Generation returns pending
+content; approval requires a separate operation. The reviewer may be an authorized Agent, including the proposer.
+For human review, [separate submission and review permissions](review-candidates.md#separate-agent-submission-from-review).
 
 ## Evidence comes first
 

docs/en/docs/workflows/review-candidates.md

@@ -33,6 +33,67 @@ powercontext ready
 Set `POWERCONTEXT_SCOPE_ID` to the existing Scope ID that contains the Candidate. This guide starts after an
 Experience or Skill operation has created a pending Candidate.
 
+## Review authority
+
+Review is a state transition: pending content becomes an immutable Artifact Revision only after an explicit approval.
+It does not by itself prove that a person reviewed the content or that the reviewer differs from the proposer.
+
+| Server access mode | Who can approve |
+| --- | --- |
+| `disabled` (default) | Any caller that can reach the review operation; no reviewer identity is enforced |
+| `enforced` | An authenticated Principal with `scope.review`, subject to the Candidate's evidence and target permissions |
+
+HTTP, the Python Client, CLI, and MCP use the same Server authorization. A Principal with submission and review
+permissions can approve its own Candidate. The built-in static bearer token represents one shared administrator
+identity; sharing that token does not separate an Agent from a reviewer.
+
+MCP exposes `approve_candidate`, `reject_candidate`, and `revise_candidate`. Their tool annotations describe side
+effects so a host can apply its confirmation policy. Annotations do not force a prompt or prove human confirmation.
+Approval also does not install, publish, or authorize execution of a Skill.
+
+## Separate Agent submission from review
+
+For a workflow where an Agent submits new Experience or Skill Candidates and a person decides whether to approve:
+
+1. Enable `POWERCONTEXT_SERVER_ACCESS_MODE=enforced` and configure an Authentication Provider that establishes distinct
+   identities. See [Scopes and access](scopes-and-access.md#enable-access-control). A shared static token is insufficient.
+2. Have an administrator grant the Agent `scope.contributor` and the reviewer `scope.reviewer` on the exact Scope.
+   Do not give the Agent review or role-management authority, including through groups or additional credentials.
+3. Keep the reviewer's credentials outside the Agent's tools and process environment. Use an authenticated Client or
+   integration for review. The Dashboard supports personal and demonstration deployments, not team RBAC.
+4. Submit a Candidate as the Agent, then read it as each identity. The Agent must receive a denial when attempting
+   approval through HTTP or MCP; the reviewer can approve the exact pending version.
+5. If changes are needed, reject with a reason and submit a corrected new Candidate. Rejection is terminal. Revising
+   an existing Candidate requires both `scope.review` and the original proposer identity, so neither of these separate
+   roles can use `revise` in this setup. Do not grant review authority to the Agent just to edit a proposal.
+
+With the built-in writable Access Provider, an administrator can send these requests to
+`POST /v1/access/bindings/create`. Replace the IDs with identities established by the Authentication Provider and the
+existing Scope ID; request bodies assign roles and do not authenticate the named subjects.
+
+```json
+{
+  "subject": {"type": "service", "id": "coding-agent"},
+  "resource": {"type": "scope", "scope_id": "scope-project"},
+  "role": "scope.contributor",
+  "idempotency_key": "project-agent-contributor"
+}
+```
+
+```json
+{
+  "subject": {"type": "user", "id": "reviewer"},
+  "resource": {"type": "scope", "scope_id": "scope-project"},
+  "role": "scope.reviewer",
+  "idempotency_key": "project-human-reviewer"
+}
+```
+
+These assignments cover new Artifact identities. A proposal that revises an existing Artifact also requires the
+applicable target permissions; the two Scope roles alone do not authorize every replacement. This workflow separates
+authority through role assignments, without a Server rule prohibiting all self-approval. If one identity later receives
+both permissions, it can submit and approve its own Candidate.
+
 ## Start a Dream from existing evidence
 
 Dreaming turns selected Atomic Memory or Experience revisions into one proposal for review. It runs in the background;

docs/en/docs/workflows/scopes-and-access.md

@@ -42,6 +42,12 @@ Inspect `GET /v1/access/me` for the active identity and provider capabilities. R
 Scope, and Artifact actions. Scope creation requires `server.admin`; Prompt changes require current `scope.admin`.
 The ability to read review candidates does not grant permission to approve them.
 
+To let an Agent submit new Experience or Skill Candidates while a separate reviewer decides, assign
+`scope.contributor` to the Agent and `scope.reviewer` to the reviewer using distinct authenticated identities.
+Keep reviewer credentials out of the Agent's environment. A Principal holding both permissions can approve its own
+Candidate. Follow [Separate Agent submission from review](review-candidates.md#separate-agent-submission-from-review)
+for role-assignment examples, rejection and resubmission, and existing-Artifact permission limits.
+
 Scheduled processing needs an authorized background Principal. Tag queries require `scope.read`, while editing a
 target's tags follows that target's write permission. Use [Tags](manage-artifact-tags.md) and
 [Scope profiles](use-profiles.md) for the corresponding workflows.

docs/en/rfcs/0050_artifact_candidate_review_inbox.md

@@ -232,8 +232,12 @@ pending Candidate; the latter reads an approved Experience Revision only by exac
 The generated Python Client exposes the same operations, the CLI provides
 `candidate list/show/approve/reject/revise`, and MCP projects all five Review operations as tools. Transport does not
 change Candidate validation, `expected_version` checks, or the atomic approval transaction. PowerContext does not treat
-MCP visibility as an authorization boundary; deployments that require reviewer separation must control access to the
-MCP endpoint.
+MCP visibility as an authorization boundary. With RFC 1396 access control enforced, review decisions require
+`scope.review` through every transport. With access control disabled, any caller that reaches the operation can make
+a decision. An authorized proposer may approve its own Candidate. Deployments requiring separate submission and review
+must use distinct authenticated Principals, withhold review authority from the submitting Agent, and keep reviewer
+credentials outside its environment. MCP annotations describe side effects for host confirmation policies; they do
+not enforce human confirmation.
 
 This RFC does not modify the existing Memory contract:
 

docs/en/rfcs/0051_experience_skill_artifact_families.md

@@ -32,8 +32,11 @@ does not create a managed Artifact. Only an explicit import or fork proposes a n
 
 Experience and managed Skill generation and evolution are advanced capabilities that require a configured generation
 model. Without one, Runtime generates no Candidate and provides no rule-based fallback. Artifact persistence, Review,
-exact reads, and local external Skill registration continue to work independently. A model cannot approve its own
-Candidate, allocate final Artifact identity, or acquire execution authority.
+exact reads, and local external Skill registration continue to work independently. Generation creates pending content
+without final Artifact identity or execution authority. Approval is a separate Review operation. With access control
+enforced, it requires `scope.review`; an Agent holding that permission may approve its own Candidate. To reserve
+approval for a separate reviewer, assign submission and review permissions to distinct authenticated identities. See
+[Review Candidates](../docs/workflows/review-candidates.md#separate-agent-submission-from-review).
 
 # Motivation
 
@@ -469,8 +472,9 @@ Without a configured generation model:
 - Runtime never wraps raw summaries or deterministic rule output in Experience or managed Skill content.
 
 Rules still enforce input bounds, scope, exact references, typed shape, and lineage, but those checks do not replace
-semantic generation. Even when available, an LLM cannot approve Candidates, choose execution authority, invent
-evidence, install Skills, or commit final Revisions.
+semantic generation. A generation model supplies proposal content, not approval or final Revision commits, and must
+not invent evidence. Review commits the final Revision through a separate operation; an authorized Agent can call
+that operation. Generation and approval do not grant installation or execution authority.
 
 ## Identity, Revision, persistence, and projections
 

docs/en/rfcs/1304_experience_skill_review_page.md

@@ -36,7 +36,9 @@ writable.
 
 Experience and managed Skill are intentionally gated by Review. A generated proposal is untrusted, does not receive
 final Artifact identity, and cannot enter retrieval or PreparedContext until a reviewer approves it. This boundary is
-already implemented across HTTP, the Python Client, CLI, and MCP.
+already implemented across HTTP, the Python Client, CLI, and MCP. It is a lifecycle and retrieval boundary, not proof
+of human or independent review. RFC 1396 governs authorization when enforced; an Agent with review authority can
+approve its own Candidate. The page does not add a prohibition on self-approval or a trusted human-confirmation step.
 
 The Server Dashboard currently shows how many Candidates are pending, but it does not let a user inspect or act on
 them. Completing the review requires command-line or MCP calls with exact IDs, versions, proposal shapes, and evidence