[docs-scanner] Confusing explanation of approval-required outcome vs permit in MCP policy
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 1/5
- 見積もり時間
- 1時間未満
- 初心者へのやさしさ
- 88/100
- issue の種類
- ドキュメント
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
調査の方向性
content/manuals/ai/governance/reference/mcp-policy.mdを開き、「Approval annotation」セクションを読んでください。@requireApprovalはpermitに注釈を付け、リクエストを許可する前に確認を必要とすることを明確にしてください。そこで説明されているポリシーの動作と表現を一致させてください。承認が必要な結果は注釈付きのpermitであり、別個の競合する結果ではないと読者が理解できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
File: content/manuals/ai/governance/reference/mcp-policy.md
Issue
The "Approval annotation" section states:
An approval-required outcome takes precedence over a normal
permit.
This phrasing is confusing because an approval-required outcome IS a type of permit (specifically, a permit with the @requireApproval annotation). The statement makes it sound like there are two separate, competing outcomes when in fact the approval-required outcome is just a modified permit.
Why this matters
Readers trying to understand the evaluation model will be confused about whether approval-required is a distinct decision type or a variant of permit. The current phrasing suggests they're different things that can conflict, when actually an annotated permit simply requires an extra step before allowing the request.
Suggested fix
Rewrite to clarify the relationship. For example:
When a request matches a
permitannotated with@requireApprovaland noforbidoverrides it, the policy engine returns an approval-required outcome instead of immediately allowing the request. The annotation string is shown as the elicitation reason.
Or:
A
permitwith@requireApprovalrequires user confirmation before allowing the request. This approval-required behavior takes precedence over a plainpermitwithout the annotation.
Found by nightly documentation quality scanner
- 主要言語
- Markdown
- スター
- 4.7k
- フォーク
- 8.5k
- 平均マージ
- 2日 13時間
- マージ済み PR（30日）
- 139
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
docker/docs のほかの issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
status/triage
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
[docs-scanner] Unclear policy change timing in organization policies overview対応中かも @Mhdomer が今日担当しました。 オープン
難易度 1/5 1〜3時間 初心者へのやさしさ 89/100
メンテナーはふだん 1 日以内に返信
-
[docs-scanner] Unclear pronoun reference in cloud delivery note対応中かも @craig-osterhout が 1 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 94/100
メンテナーはふだん 1 日以内に返信
-
Debian installation pitfall対応中かも @Duo-ee が 6 日前に担当しました。 オープンstatus/triage
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
Blog update untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
sync-en
難易度 1/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
fix(docs): align git__gh troubleshooting with its actual failure paths対応中かも @akhil9tiet が今日担当しました。 オープンbug docs p2
難易度 1/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
cutover-blocker documentation v2-migration
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
disnog/netranger-db#11 · コメント 1 件 ·