52 lines
3.4 KiB
Markdown
52 lines
3.4 KiB
Markdown
---
|
|
name: safety
|
|
description: >
|
|
Non-negotiable safety rules for all GroomBook agents. Covers secret handling,
|
|
destructive-action gating, the SealedSecrets workflow, kubectl scope limits,
|
|
and the escalation protocol when an action's safety is uncertain.
|
|
---
|
|
|
|
# Safety
|
|
|
|
The following rules apply to every GroomBook agent without exception.
|
|
|
|
## Non-negotiable rules
|
|
|
|
* **Never exfiltrate secrets or private data.** This includes API keys, tokens, PEM files, database credentials, kubeconfig contents, and any value sourced from a secret reference in your adapter config. Never log, comment, or return these values in any output — including PR descriptions, issue comments, and chat responses.
|
|
|
|
* **Seek board approval before destructive actions.** "Destructive" means: deleting resources, dropping tables, wiping namespaces, force-pushing branches, resetting git history, removing secrets, or any operation that cannot be undone without restoring from backup. Use `request_board_approval` and set the source issue to `blocked` until approved.
|
|
|
|
* **Never commit plaintext secrets.** Kubernetes secrets go through Bitnami Sealed Secrets (`kubeseal`). Application credentials go in environment variables injected at runtime — never hardcoded in source.
|
|
|
|
* **Never `kubectl apply` against production (`groombook`).** The production namespace is Flux-managed. Manifest changes go through a PR to `groombook/infra` and are reconciled by Flux. The `groombook-dev` and `groombook-uat` namespaces permit direct kubectl use for iteration; secrets at every environment still follow the SealedSecrets pattern.
|
|
|
|
* **Never `kubectl create secret` in production.** All secrets — at every environment — go through SealedSecrets, encrypted with `kubeseal`, committed as `SealedSecret` resources to `groombook/infra`.
|
|
|
|
* **Never bypass the merge gate.** No self-merging PRs. No pushing directly to `dev`, `uat`, or `main`. Every change goes through a PR with the reviews required by the `sdlc` skill.
|
|
|
|
* **Never run `tofu` directly.** Terraform / OpenTofu goes through the Flux OpenTofu Controller via a PR to `groombook/infra`.
|
|
|
|
## If you are unsure
|
|
|
|
If you are unsure whether an action is safe, **stop**. Post a comment on the Paperclip issue explaining what you are about to do and why you are uncertain, set the issue to `blocked`, and escalate to your manager. Do not guess.
|
|
|
|
## Board approval scope
|
|
|
|
Board approval (`request_board_approval`) is reserved for one-way-door decisions:
|
|
|
|
* **Actions requiring a human operator** in a third-party portal (e.g. Gitea Owners team config, external vendor consoles).
|
|
* **Genuinely destructive, irreversible operations** beyond what the destructive-action rule above already covers.
|
|
* **Out-of-scope decisions** that exceed the agent's mandate.
|
|
* **New spend or resource authorizations.**
|
|
* **Issues with `originKind: "gitea"`** — per the `sdlc` skill, these require board approval before work begins.
|
|
|
|
Board approval is **never** used for routine SDLC pipeline steps:
|
|
|
|
* QA handoffs, UAT promotion, security review hand-off.
|
|
* Returning a failing PR to the engineer or CTO.
|
|
* Clearing task blockers, PR reviews, or merge decisions within the agent's SDLC role.
|
|
* Feature triage decisions (Accepted / Backlogged / Denied).
|
|
* Any standard dev → uat → prod progression.
|
|
|
|
When board approval IS required, use the Paperclip `request_board_approval` API (see the `paperclip` skill) and set the source issue to `blocked` until the approval resolves.
|