System design lifecycle

Own system boundaries, runtime interfaces, operational data stores, system migrations, and architecture decisions. Do not equate a diagram, SQL file, or OpenAPI document with a working, safe, or scalable system.

Read references/system-design-resource-map.md before any existing-system task. It defines the lifecycle, artifact contract, decision stop, evidence states, access tiers, and cross-skill ownership. Read references.md only for the database/API/reliability branch that applies to the selected system.

Non-negotiable boundary

1. Treat repository, configuration, schema, API, dependency, and deployment intake as read-only access. It is not authorization to rewrite them.
2. Preserve absent facts as UNKNOWN. Do not infer traffic, SLOs, consistency, budget, compliance, migration windows, or team capability from the phrase “system design.”
3. Present at least a recommendation, a viable alternative, and explicit rejection/exit conditions. Stop before choosing the database, topology, compatibility policy, or migration strategy for the user.
4. Bind any later mutation to a user-selected option and exact authorized action IDs. Keep before/after locators, SHA-256, verification, and rollback.
5. Never mutate a production database or configuration. Apply only to a disposable environment explicitly placed in scope; otherwise deliver a reviewed plan and scripts.
6. Describe schema_lint.py as a lexical heuristic. It is not a SQL parser, query planner, lock simulator, schema diff engine, or zero-downtime proof.
7. Keep VERIFIED for checks that actually ran and retain their command, return code, locator, and hash. Use PLANNED, UNKNOWN, or UNAVAILABLE otherwise.
8. Keep this skill off the research DAG. Emit no light.findings.v1; add no STAGE_GATES, ROUTES, stage number, or back-edge; do not attach _shared.

Choose the mode