Assess feasibility of non-read-only K8s functionality

[bhf]

Area: Architectural

Description

The project is currently designed with a strict "Read-Only" constraint for safety. We need to assess the feasibility, security implications, and necessary architecture changes to support non-read-only functionality (mutations) such as creating, updating, or deleting Kubernetes resources.

This assessment should cover:

1. Impact on key architectural patterns (lazy loading, API routes).
2. Security model (handling user permissions, prevention of accidental deletions).
3. Candidate operations for the first iteration (e.g., Scaling a deployment vs. raw YAML editing).

Acceptance Criteria

• Document the security risks involved in enabling write access.
• Propose a technical design for handling mutations safely (e.g., dry-run validation).
• Identify which initial set of resources/actions should be supported (e.g., restart pod, scale deployment).
• Define how to gate these features behind configuration or flags.