Why: The user approved the U5 action scope (A client-local fully open; B command-binding machinery with an empty first whitelist; C plugin-own writes via KV/task ledger; D business writes and DangerHigh-direct closed; confirm UX reuses the inline card). This lands the action half of the loop: migration v24 idempotent ledger keyed (owner, surface, action, requestId) with params-hash; SubmitAction as the single choke point (plugin activation, current-revision, action whitelist); dispatch through the command bus so DangerHigh lands on the existing inline confirm card - the endpoint does not even bind a confirmed field; generative-ui.submit is button-only (not exposed to the model) and stores form data in the plugin KV ledger; the catalog rejects unknown action ids at present time; frontend drafts travel only inside the action payload with an in-flight double-click guard.
Evidence: Task card carries precheck/task-sync/make test/make build receipts (make evidence, SELF); CI ci/test on PR HEAD is the authoritative gate. Component suites green incl. PG dialect; UI 107/107 (draft+action case); frontend 95/95 (request-shape). Red matrix covers all six approved acceptance lines: submit/validate/retry with ledger read-back, stale-revision/cross-owner/unknown-action/different-params rejections, DangerHigh await-confirm with no execution and no Confirmed passthrough, drafts-only-in-payload, post-disable 403, idempotent replay without redispatch.
Impact: backend/ui/frontend/documents gitlinks; B-class whitelist intentionally empty per approved scope; U6 (workspace) and deployment stay separately reviewed.
Why: The user approved the U5 action scope (A client-local fully open; B command-binding machinery with an empty first whitelist; C plugin-own writes via KV/task ledger; D business writes and DangerHigh-direct closed; confirm UX reuses the inline card). This lands the action half of the loop: migration v24 idempotent ledger keyed (owner, surface, action, requestId) with params-hash; SubmitAction as the single choke point (plugin activation, current-revision, action whitelist); dispatch through the command bus so DangerHigh lands on the existing inline confirm card - the endpoint does not even bind a confirmed field; generative-ui.submit is button-only (not exposed to the model) and stores form data in the plugin KV ledger; the catalog rejects unknown action ids at present time; frontend drafts travel only inside the action payload with an in-flight double-click guard.
Evidence: Task card carries precheck/task-sync/make test/make build receipts (make evidence, SELF); CI ci/test on PR HEAD is the authoritative gate. Component suites green incl. PG dialect; UI 107/107 (draft+action case); frontend 95/95 (request-shape). Red matrix covers all six approved acceptance lines: submit/validate/retry with ledger read-back, stale-revision/cross-owner/unknown-action/different-params rejections, DangerHigh await-confirm with no execution and no Confirmed passthrough, drafts-only-in-payload, post-disable 403, idempotent replay without redispatch.
Impact: backend/ui/frontend/documents gitlinks; B-class whitelist intentionally empty per approved scope; U6 (workspace) and deployment stay separately reviewed.
Refs: modules/documents/docs/proposals/2026-10-11-generative-ui-u5-action-scope.md (r2 approved); task card feature/generative-ui-u5
Why: establish the authorized task workspace and its initial baseline.
Evidence: preserved precheck receipt in .task/feature-generative-ui-u5.md; R0=f9c6ccc263c00d95919c021cb2fe31cf2f0936d8.
Impact: task metadata only; the feature workspace starts at f9c6ccc263.
Refs: .task/feature-generative-ui-u5.md
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=53a3effef777c83bd6baa63f8181f34480533559.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
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 user approved the U5 action scope (A client-local fully open; B command-binding machinery with an empty first whitelist; C plugin-own writes via KV/task ledger; D business writes and DangerHigh-direct closed; confirm UX reuses the inline card). This lands the action half of the loop: migration v24 idempotent ledger keyed (owner, surface, action, requestId) with params-hash; SubmitAction as the single choke point (plugin activation, current-revision, action whitelist); dispatch through the command bus so DangerHigh lands on the existing inline confirm card - the endpoint does not even bind a confirmed field; generative-ui.submit is button-only (not exposed to the model) and stores form data in the plugin KV ledger; the catalog rejects unknown action ids at present time; frontend drafts travel only inside the action payload with an in-flight double-click guard.
Evidence: Task card carries precheck/task-sync/make test/make build receipts (make evidence, SELF); CI ci/test on PR HEAD is the authoritative gate. Component suites green incl. PG dialect; UI 107/107 (draft+action case); frontend 95/95 (request-shape). Red matrix covers all six approved acceptance lines: submit/validate/retry with ledger read-back, stale-revision/cross-owner/unknown-action/different-params rejections, DangerHigh await-confirm with no execution and no Confirmed passthrough, drafts-only-in-payload, post-disable 403, idempotent replay without redispatch.
Impact: backend/ui/frontend/documents gitlinks; B-class whitelist intentionally empty per approved scope; U6 (workspace) and deployment stay separately reviewed.
Refs: modules/documents/docs/proposals/2026-10-11-generative-ui-u5-action-scope.md (r2 approved); task card feature/generative-ui-u5