CLAUDE.md git:20260913.cf80e2eA

Immutable. This exact content is served forever at /api/v1/blob/a4c6944cd9f0b968.

# User-level instructions

These instructions apply at all times, in every conversation, regardless of which skill (if any) is invoked.

## Hard limits

Do not perform any of the actions below unless the user has explicitly instructed you to in the current conversation. If a task seems to require one of them, surface it as a question first — explain the consequence in one line — and wait for explicit approval.

- **Git state mutation**: `add`, `commit`, `push`, `stash`, `reset`, `revert`, `checkout` over dirty work, branch/tag creation or deletion, force pushes. Read-only inspection (`status`, `diff`, `log`, `show`, `blame`, `ls-files`) is fine.
- **Applying database migrations** to any database. Generating migration files (Django `makemigrations`, Alembic `revision --autogenerate`, etc.) is fine; running them (`migrate`, `upgrade`) is not.
- **Dependency changes**: installing, upgrading, or removing packages via `npm`/`yarn`/`pnpm`/`pip`/`poetry`/`cargo`/`go mod` and similar.
- **Environment files and secrets**: editing or printing `.env*`, credential files, kubeconfig contents, or anything containing tokens or keys.
- **Production**: running scripts against production, calling destructive endpoints, or touching production data. Even read-only commands warrant confirmation when the active credentials or context target production.
- **Weakening the safety net**: disabling, skipping, deleting, or weakening tests to make a change pass.
- **Infrastructure mutation**: `terraform apply`, `pulumi up`, `kubectl apply`/`delete`/`patch`/`scale`, `helm install`/`upgrade`/`uninstall`, mutating `aws`/`gcloud`/`az` commands, DNS or IAM changes. Read-only inspection (`terraform plan`, `kubectl get`/`describe`/`logs`, cloud `describe`/`list`/`get`) is fine.
- **Deployments and pipelines**: pushing to deploy branches, manually invoking CD, restarting services, draining nodes, rolling deployments.
- **System state mutation**: `apt`/`dnf`/`pacman` install/remove/upgrade, `systemctl start`/`stop`/`enable`/`disable`/`mask`, `mount`/`umount`, `mkfs`, `parted`/`fdisk`/`lvm` operations, kernel module load/unload, `sysctl -w`, user/group changes (`useradd`, `passwd`, `chown -R`), edits under `/etc` or `/boot`, GRUB changes.
- **Running as root or with `sudo`** unless the user has explicitly said to. Read-only inspection without sudo is fine and preferred.
- **Auth-relevant configuration**: firewall rules (`iptables`/`nft`/`ufw`), SSH config, PAM, sudoers. Misconfiguring these can lock the user out of their own machine — always confirm and explain the recovery path before suggesting changes.

File deletion and CI configuration edits are allowed when relevant — they're version-controlled and recoverable.

## Authoring conventions

- **Break multi-line comments, docstrings, and string literals at sentence or comma-free clause boundaries, never mid-sentence.** When prose in code spans more than one line, end each line at a natural stop — the end of a sentence, or a clause boundary that carries no comma — so no line severs a phrase mid-thought. A line ending on a comma is still mid-thought; rewrite rather than wrap. This holds in every language and for every kind of embedded prose: code comments, docstrings, and multi-line message, label, or help strings alike.
- **Name things with words, and let a name be as long as it needs to be.** Length is not a cost worth optimizing, and both failure modes come from pretending it is: inventing contractions to save typing (`kw`, `assoc`, `u`), and settling for a weaker name because the right one felt long. The only question is whether the name is what the thing is actually called in that language or domain — established names are right however short they are (`kwargs`, `ctx`, `id`, `i`). A name is too long only when its extra words repeat what the type, scope, or surrounding code already establishes; that is redundancy, not length. Names are read far more often than they are written, so shorthand trades a one-time saving for a permanent tax on every reader, human or model. Apply this to names you introduce, and match the surrounding code — do not rename existing shorthand as a drive-by.
- **Leave a blank line after every flow break.** After a `return`, `continue`, `break`, `raise` or `throw`, or an `exit`, and after the closing brace of the block it ends in brace languages, the next line is blank before any further statement in the enclosing scope. The blank line marks where one path ends and the surviving path resumes, so a guard clause reads as a guard and not as the first step of what follows it. When the flow break is the last statement in its scope nothing follows it, so nothing is added before the closing brace or dedent. This holds in every language and every codebase, including ones that do not do it today.
- **No double negation in identifier names.** A name states what a thing is, not what it is not: `isEnabled`, `hasAccess`, `visibleItems`, never `isNotDisabled`, `notHidden`, or `skipNoCache`. Prefer the positive form for booleans and flags you introduce, so call sites read `if enabled` rather than `if not disabled`, which is the same double negation moved one line down. A single negative that is the domain's own word (`disabled`, `hidden`, `missing`) is fine; the problem is stacking a second one on it. When the positive form is tricky or impossible, because a library, API, schema, or existing field already fixes the negative name and the alternative is a wrapper or a rename, raise it as a question with the options and let the user decide rather than picking silently. Do not rename existing identifiers as a drive-by.