[Step 10] Request/approval workflow + audit

[haydercyber]

Goal — REFACTOR_PLAN.md Step 10

Implement the access-request → approval → execution workflow. This is the heart of the Control Plane and the BRD's primary user-facing flow.

Scope

Domain

• pkg/workflow/ state machine: Submitted → Pending → Approved | Rejected → Executed | Failed
• One-stage approval for MVP (multi-stage parked for Phase 7+)
• Mandatory justification on every request (BRD §12.2)
• Separation of duties: requester ≠ approver enforced at submit time (BRD §15)

API

• POST /api/v1/requests — developer submits update request
• GET /api/v1/requests / GET /api/v1/requests/{id} — list/inspect
• POST /api/v1/requests/{id}/approve / POST /.../reject — with comment
• On approval: create a sync_job consumed by the agent loop (Step 8)
• Webhook / notification hook for "new request" + "approved/rejected" (Slack/email/webhook plugin)

Audit

• Every state transition emits an immutable audit event (audit_events append-only)
• correlation_id propagated from request → approval → job → run → audit
• Audit log API: GET /api/v1/audit-events with filtering (resource, actor, action, since)

Secret-value entry

• New value is provided at approval time, written directly to the provider via the agent (BRD §12.2 step 5)
• Never stored in Postgres, Redis, request body retained in DB, or audit metadata (FR-04)

Acceptance criteria

• A developer can submit a request, an approver can approve it, and the resulting sync_job is consumed by the agent and ends in succeeded
• DB scan after E2E: zero rows in any table contain the secret value
• Audit events show the full chain with a single correlation_id
• Rejecting requires a comment

References

• BRD §12.2, §13 FR-01, FR-02, FR-10, §15, §17
• REFACTOR_PLAN §6 row 10

Dependencies

• Step 5 (storage), Step 7 (agents), Step 8 (job loop)