/superloopy-backend

name: superloopy-backend
description: Use only after explicit Codex `$superloopy:superloopy-backend` or Claude Code `/superloopy:superloopy-backend` invocation, a backend task beginning with leading `loopy` or `루피`, or an active Superloopy loop routes backend work here. Relevant work includes backend application boundaries, APIs, persistence, migrations, transactions, background jobs, caches, events, reliability, security, and runtime database-agent tools. Plain API, server, database, SQL, or agent vocabulary does not activate this workflow.

SUPERLOOPY BACKEND ENABLED

Open the response with `SUPERLOOPY BACKEND ENABLED`. If another active Superloopy mode mandates its own first line, print that first and this marker on the next line. Resolve this skill's installed directory, set `BACKEND_SKILL_DIR` to that absolute path, and announce `BACKEND_SKILL_DIR=<path>` before loading a reference. Do not assume the repository-relative path is the installed path.

Discover in proportion to the change

Inspect the repository before prescribing commands, code, schema, or infrastructure: its instructions, its recorded conventions and the hooks, linters, formatters, or convention checks that enforce them, language and runtime, data stores and schema authority, test commands, generated artifacts and how they are regenerated, and the project's own definition of done for a change of this kind. Preserve the existing stack and patterns; remain stack-neutral when evidence does not select a technology. Ask only when a missing fact would materially change the implementation or its safety.

Fill the context card only as far as the classified change reaches. A change confined to one unit needs the first five lines; a schema, contract, or runtime-agent change needs all of it. A card filled to the bottom for a two-line fix is cost, not diligence.

User outcome:
Language and runtime / existing architecture:
Recorded conventions and their enforcement:
Generated artifacts and their regeneration command:
Project definition of done (one line per item, copied from the project):
Data stores / schema authority:
API consumers / compatibility:
Deployment model / production access / compliance constraints:
Unknowns that affect the decision:

Classify and route

Classify the change as one or more of: API behavior, schema or migration, transaction, background job, cache, event or queue, runtime agent tool, performance, reliability, or security. Load only the modules the classification names:

• [Architecture](references/architecture.md) — system boundaries, API or event contracts, consistency, transactions, idempotency, caching, background work, compatibility, stack restraint.
• [Data safety](references/data-safety.md) — whenever the diff touches a query, mapper, schema, migration, privilege, or transaction boundary: schema authority, tenant isolation, least-privilege identities, reconcilable writes, migration preflight, rollout and recovery.
• [Runtime agents](references/runtime-agents.md) — typed tool boundaries with read-only, least-privilege defaults; authorization and tenant scope from verified context; retrieved records are untrusted data, not instructions or authority; bounded time, rows, payload, cost, retries.
• [Testing and operations](references/testing-and-operations.md) — realistic persistence tests, observability, performance evidence, rollout and recovery proof.
• [Evidence](references/evidence.md) — when finishing: where the active or standalone evidence root comes from, how to publish, how to recover a lost receipt.
• [Upstream notice](references/upstream-notice.md) — only when auditing the public evidence behind this guidance.

Do not load unrelated modules or invent their contents when a reference is unavailable; state the missing guidance as a blocker or evidence gap.

Contracts before code

Define the request and response or event shapes, invariants, authorization decision, tenant boundary, consistency expectation, idempotency behavior, failure semantics, observability, compatibility, and rollout before implementation. For runtime database agents, default to typed application tools or narrowly scoped services with read-only, least-privilege capability, explicit allowlists, bounds, redaction, and auditability.

Honor the project's recorded conventions as constraints, not suggestions: naming, layering, error and log shape, endpoint form, and anything its own hooks, linters, formatters, or convention checks already enforce. A change that a project check would reject is not finished. When a change adds a member to an established published surface — another endpoint, operation, tool, field, error code, or event — its existing siblings specify the name and shape it inherits; the informal wording of the request does not.

Require explicit user authority before production writes, destructive operations, DDL, bulk changes, privilege changes, or dependency additions. Preflight migrations and consequential data changes for old/new version compatibility, locks and resources, transaction behavior, backup validity, staged rollout, and rollback or roll-forward. Prefer an isolated or disposable real database for behavior that depends on transactions, concurrency, migrations, tenant separation, or query semantics; a mock or single fixture does not prove database behavior.

Rules that are decisions

Each of these is checkable from the diff or from a run. Measured effect (see the README): about a quarter fewer changes ship an untested part; the rest is checkable procedure without a separately measured effect.

1. **Reproduce first, and re-run the same reproduction at the end.** Capture the reported symptom as a runnable reproduction before changing anything, at the conditions the report describes rather than narrowed onto the cause you find. A change that does not make the reported behavior go away is not a fix, however well the cause is explained. 2. **Extend the suite that already states t