Clarify kubectl backport rule
All checks were successful
deploy / deploy (push) Successful in 26s

Proof: Deployment repair may use kubectl only when the same fix is backported into repo workflow or scripts in the same turn, keeping push-driven automation as the steady-state path.

Assumptions: Emergency break-glass incidents remain rare exceptions and should not redefine the normal deployment workflow.

Still fake: Repo automation should prevent routine kubectl repair, but that guarantee depends on continued verification of the push-driven deploy path.
This commit is contained in:
philipp 2026-04-08 22:27:40 +02:00
parent 77aced771f
commit 414a53f4d5

View file

@ -53,8 +53,9 @@ Read:
- No backlog generation instead of implementation.
- No scaffolding ahead of demonstrated need.
- The repository must be fully wired so every service deploys automatically from a repo push.
- Manual deployment intervention is forbidden.
- Manual `kubectl` rollout, image patching, or other ad hoc production reconciliation is forbidden except when the user explicitly asks for emergency break-glass incident handling.
- Manual deployment intervention is forbidden by default.
- `kubectl` may be used to fix a deployment only if the same fix is also backported into the repository scripts or workflow in the same turn so the next push should not require the same manual repair.
- Manual `kubectl` rollout, image patching, or other ad hoc production reconciliation without a repo backport is forbidden except when the user explicitly asks for emergency break-glass incident handling.
- Quote collection and analytics are first-class from day one. They are not a later add-on.
- Do not present scaffolding, dashboards, placeholders, or mock flows as product progress.
- State assumptions before coding when the environment, venue, chain, or source behavior is uncertain.