Web Console: Versioned policy editing, validation, simulation, approval, and rollback (Phase 3) #647

Open
opened 2026-07-10 14:41:39 -05:00 by jcwalker3 · 0 comments
Owner

Problem statement

After policy visibility (#646), controllers need versioned policy editing with validation, simulation, approval, and rollback — without live-editing production profiles unsafely or bypassing code review norms.

User and operational impact

Policy changes are error-prone; no simulation before apply; hard rollback.

Scope

  • Versioned policy store for console-managed overlays (not raw secret-bearing profile files).
  • Validate schema; simulate impact (which gates change); require approval role; rollback to prior version.
  • Prefer PR-based apply for code-owned policies; allow overlay for operational toggles if explicitly designed.
  • Full audit trail.

Explicit non-goals

  • Do not allow arbitrary shell or unrestricted profile secret edits from browser.
  • Do not disable hard safety rails (self-merge ban, branches-only) via overlay.

Required implementation investigation

#646, #633, #434, profile model, docs/gitea-execution-profiles.md, #631.

Proposed architecture or implementation direction

Policy bundle versions in CP-DB or git; simulate using dry-run evaluators; dual-control approve for high-risk changes.

Security and workflow-safety requirements

RBAC; dual-control for high risk; audit; fail closed; never store secrets in policy JSON.

Acceptance criteria

  1. Create version → validate → simulate → approve → apply → rollback path.
  2. High-risk policies blocked from single-actor apply if dual-control configured.
  3. Tests cover invalid policy reject and rollback.
  4. Docs define which policies are overlay vs code-owned.

Required tests

Validation/simulation/rollback unit tests; authz tests.

Observability and audit requirements

Every version transition audited.

Dependencies and linkage

Canonical issue state

STATE: ready-for-author
WHO_IS_NEXT: author
NEXT_ACTION: Implement versioned policy change workflow after visibility
NEXT_PROMPT: Author policy versioning; PR; stop

Required final evidence

PR with versioning, tests, docs.

Required final response and handoff expectations

Brief PR → reviewer/controller.

## Problem statement After policy visibility (#646), controllers need **versioned policy editing** with validation, simulation, approval, and rollback — without live-editing production profiles unsafely or bypassing code review norms. ## User and operational impact Policy changes are error-prone; no simulation before apply; hard rollback. ## Scope * Versioned policy store for console-managed overlays (not raw secret-bearing profile files). * Validate schema; simulate impact (which gates change); require approval role; rollback to prior version. * Prefer PR-based apply for code-owned policies; allow overlay for operational toggles if explicitly designed. * Full audit trail. ## Explicit non-goals * Do not allow arbitrary shell or unrestricted profile secret edits from browser. * Do not disable hard safety rails (self-merge ban, branches-only) via overlay. ## Required implementation investigation #646, #633, #434, profile model, docs/gitea-execution-profiles.md, #631. ## Proposed architecture or implementation direction Policy bundle versions in CP-DB or git; simulate using dry-run evaluators; dual-control approve for high-risk changes. ## Security and workflow-safety requirements RBAC; dual-control for high risk; audit; fail closed; never store secrets in policy JSON. ## Acceptance criteria 1. Create version → validate → simulate → approve → apply → rollback path. 2. High-risk policies blocked from single-actor apply if dual-control configured. 3. Tests cover invalid policy reject and rollback. 4. Docs define which policies are overlay vs code-owned. ## Required tests Validation/simulation/rollback unit tests; authz tests. ## Observability and audit requirements Every version transition audited. ## Dependencies and linkage * Parent: #631 · Depends: #646, #633 · Related: #434 ## Canonical issue state ```text STATE: ready-for-author WHO_IS_NEXT: author NEXT_ACTION: Implement versioned policy change workflow after visibility NEXT_PROMPT: Author policy versioning; PR; stop ``` ## Required final evidence PR with versioning, tests, docs. ## Required final response and handoff expectations Brief PR → reviewer/controller.
jcwalker3 added the type:featurestatus:readyworkflow-hardeningdashboardsafety labels 2026-07-10 14:41:39 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#647