Why: The r2 U5 clause requires a human review of the action scope before implementation. The proposal (Documents #70) grounds the decision in the current command inventory and existing safety machinery: A-class client-local actions fully open; B-class command binding machinery built with an EMPTY first whitelist (no safe read-only builtin commands exist today); C-class plugin-own low-risk writes (form -> plugin KV/task ledger, no business mutations); D-class business writes and DangerHigh stays closed. Approval attachment reuses the existing DangerHigh inline-confirm card (user card click is the only approval source), audit envelope, and (owner, surfaceId, revision, actionId, requestId, params-hash) idempotency.
Evidence: Task card carries precheck/task-sync/make test receipts (make evidence, SELF); CI ci/test on PR HEAD is the authoritative gate. Source facts verified against backend main 2026-10-11.
Impact: documents gitlink + task card only; U5 implementation starts only after the user rules on the three questions in the proposal.
Why: The r2 U5 clause requires a human review of the action scope before implementation. The proposal (Documents #70) grounds the decision in the current command inventory and existing safety machinery: A-class client-local actions fully open; B-class command binding machinery built with an EMPTY first whitelist (no safe read-only builtin commands exist today); C-class plugin-own low-risk writes (form -> plugin KV/task ledger, no business mutations); D-class business writes and DangerHigh stays closed. Approval attachment reuses the existing DangerHigh inline-confirm card (user card click is the only approval source), audit envelope, and (owner, surfaceId, revision, actionId, requestId, params-hash) idempotency.
Evidence: Task card carries precheck/task-sync/make test receipts (make evidence, SELF); CI ci/test on PR HEAD is the authoritative gate. Source facts verified against backend main 2026-10-11.
Impact: documents gitlink + task card only; U5 implementation starts only after the user rules on the three questions in the proposal.
Refs: modules/documents/docs/proposals/2026-10-11-generative-ui-u5-action-scope.md; Documents PR #70; task card feature/generative-ui-u5-scope
Why: establish the authorized task workspace and its initial baseline.
Evidence: preserved precheck receipt in .task/feature-generative-ui-u5-scope.md; R0=259270b4e339132219490b95b42d12386f9abe1e.
Impact: task metadata only; the feature workspace starts at 259270b4e3.
Refs: .task/feature-generative-ui-u5-scope.md
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why: The r2 U5 clause requires a human review of the action scope before implementation. The proposal (Documents #70) grounds the decision in the current command inventory and existing safety machinery: A-class client-local actions fully open; B-class command binding machinery built with an EMPTY first whitelist (no safe read-only builtin commands exist today); C-class plugin-own low-risk writes (form -> plugin KV/task ledger, no business mutations); D-class business writes and DangerHigh stays closed. Approval attachment reuses the existing DangerHigh inline-confirm card (user card click is the only approval source), audit envelope, and (owner, surfaceId, revision, actionId, requestId, params-hash) idempotency.
Evidence: Task card carries precheck/task-sync/make test receipts (make evidence, SELF); CI ci/test on PR HEAD is the authoritative gate. Source facts verified against backend main 2026-10-11.
Impact: documents gitlink + task card only; U5 implementation starts only after the user rules on the three questions in the proposal.
Refs: modules/documents/docs/proposals/2026-10-11-generative-ui-u5-action-scope.md; Documents PR #70; task card feature/generative-ui-u5-scope