Add supported authz policy mutation and reload operator workflow

[cbusillo]

Context

The VeriReel preview PR feedback authz grant exposed too much operator friction. The working path was: read the hosted Launchplane compose target through Dokploy, run a disabled one-off Dokploy schedule, docker exec into the hosted Launchplane service container, write a DB-backed authz policy record from inside the compose network, restart the service process, and then re-run product workflow probes.

That path worked, but it should become a supported Launchplane operator workflow instead of an ad hoc recovery maneuver.

Goals

• Provide a first-class authz grant command/API that creates a new DB-backed active policy record while preserving existing grants.
• Provide a safe authz reload path so policy updates do not require manual container restarts.
• Provide a supported hosted-execution helper for cases where Launchplane DB access must run from inside the Dokploy-hosted service network.
• Keep every mutation audited and reviewable.

Proposed CLI shape

uv run launchplane authz-policies grant-workflow \
  --repository cbusillo/verireel \
  --workflow-ref "cbusillo/verireel/.github/workflows/preview-fork-notice.yml@*" \
  --product verireel \
  --context verireel-testing \
  --action preview_pr_feedback.write \
  --dry-run

uv run launchplane authz-policies grant-workflow ... --apply

Proposed features

• Dry-run diff showing the active policy source/sha, new rule, and resulting rule count.
• Apply mode writes a new active authz policy record and records source/audit metadata.
• Service-side reload endpoint or admin action to reload the active DB-backed policy without restarting the process.
• Dokploy-hosted execution wrapper that can run approved Launchplane maintenance commands inside the hosted compose network without exposing DB URLs locally.
• Safe failure messages when the active policy is startup-cached and needs reload.

Related

• Tighten VeriReel preview PR feedback authz after exposing OIDC claim diagnostics #82 tracks safe OIDC claim diagnostics and tightening the temporary repo-scoped VeriReel grant back to the narrowest workflow-specific grant.
• The working operator route is documented in /Users/cbusillo/Developer/odoo-workspaces/migration/AGENTS.override.md.

[cbusillo]

Decision update from May 7, 2026 discussion: implement this service-first. The operator-facing CLI should be a client for the deployed Launchplane service in shared/prod contexts; the service owns validation, diffing, writing the new active DB-backed authz policy record, audit metadata, and reloading the active policy without a container restart. Direct local/file-backed behavior can remain a dev/bootstrap fallback, not the normal production path. Audit metadata should include authenticated operator identity, requested repository/workflow/product/context/actions, reason, related issue when provided, old/new policy id or sha, mode, trace id, and timestamp.

[cbusillo]

Implemented via PR #365 and deployed on May 7, 2026.\n\nWhat landed:\n- Service-first now supports and .\n- Apply mode requires an audit reason, writes a DB-backed active authz policy record when the grant is new, and reloads the current service worker's in-process policy immediately.\n- Authenticated admin human sessions can use the grant endpoint, with the same policy gate as GitHub Actions callers.\n- Authz policy records now carry service-owned audit metadata: operator identity, reason, related issue, old/new policy ids and shas, trace id, mode, and requested grant details.\n- Service responses return record metadata, rule counts, compact diff, and redacted audit summary rather than full workflow refs or policy body.\n- Added as the operator CLI wrapper.\n- Updated deploy workflow grant calls to provide audit reasons and related issue metadata.\n\nValidation:\n- PR #365 CI, Security, and CodeQL passed.\n- Main post-merge CI, Security, and CodeQL passed.\n- Deploy Launchplane run 25469583399 passed.\n- Live health is OK: .\n\nThis closes the first-class service-owned grant/write/reload operator workflow. A broader hosted-execution helper can be tracked separately if we still need it for other maintenance commands beyond authz grants.

[cbusillo]

Clean validation note after PR #365 deployment.

What landed:

• Service-first POST /v1/authz-policies/github-actions/grants now supports dry_run and apply.
• Apply mode requires an audit reason, writes a DB-backed active authz policy record when the grant is new, and reloads the current service worker's in-process policy immediately.
• Authenticated admin human sessions can use the grant endpoint, with the same policy gate as GitHub Actions callers.
• Authz policy records now carry service-owned audit metadata: operator identity, reason, related issue, old/new policy ids and shas, trace id, mode, and requested grant details.
• Service responses return record metadata, rule counts, compact diff, and redacted audit summary rather than full workflow refs or policy body.
• Added uv run launchplane authz-policies grant-workflow --service-url ... --dry-run|--apply as the operator CLI wrapper.
• Updated deploy workflow grant calls to provide audit reasons and related issue metadata.

Validation:

• PR Add service-first authz grant workflow #365 CI, Security, and CodeQL passed.
• Main post-merge CI, Security, and CodeQL passed.
• Deploy Launchplane run 25469583399 passed.
• Live health is OK: https://launchplane.shinycomputers.com/v1/health.

This closes the first-class service-owned grant/write/reload operator workflow. A broader hosted-execution helper can be tracked separately if we still need it for other maintenance commands beyond authz grants.

[cbusillo]

Closing after PR #365 landed and deployed. The remaining broader hosted-execution helper idea is intentionally separable from the authz grant/write/reload workflow completed here.