Production readiness self-check

Act as the senior engineer signing a production-readiness decision. Audit the current repository and its checked-in operational configuration. This is a read-only assessment: do not edit files, install packages, change infrastructure, call production services, run migrations, or expose customer data.

Optional context from me may follow this prompt: intended release, environment, critical workflows, regulated data, expected load, and known concerns. If context is missing, state your assumptions and continue. Do not turn missing context into a pass.

Operating method
1. Establish the system boundary. Identify the languages, frameworks, deployable services, data stores, queues, storage, third-party integrations, CI/CD path, environments, and likely production entry points. Cite the files that support the map.
2. Identify the three to five workflows whose failure would cause the most harm: unauthorized access, cross-tenant disclosure, money or entitlement errors, irreversible data loss, prolonged outage, or a misleading regulated decision.
3. Discover the project's existing non-destructive verification commands from manifests and CI files. You may run read-only discovery and existing lint, type-check, build, and test commands when they do not contact production or mutate persistent data. Record every command, exit code, and material limitation. Do not invent successful test results.
4. Assess every domain below using cited evidence. Trace behavior across the whole request or event path rather than checking for the presence of a library.

Assessment domains and weights
- Authentication and session security — 12%: server-side identity validation, session/token lifecycle, revocation, recovery, MFA or step-up where appropriate, privileged-account handling.
- Authorization and tenant isolation — 15%: object-level and function-level checks, tenant derivation, database/storage policies, service-role bypasses, administrative paths, negative isolation tests.
- Secrets and key management — 10%: committed or bundled secrets, environment boundaries, least privilege, rotation path, logging/redaction, CI prevention.
- Input and failure handling — 10%: validation at trust boundaries, injection/XSS/SSRF/file risks, safe errors, timeouts, retries, partial-failure behavior.
- Transactional integrity — 13%: authoritative state, idempotency, concurrency, webhook integrity, reconciliation, recovery from interrupted operations.
- Performance and scalability — 8%: unbounded work, query/index risks, pagination, caching correctness, queue pressure, timeouts, rate limits, capacity evidence.
- Automated testing and CI — 10%: critical-path coverage, negative tests, deterministic setup, migration checks, required status gates, artifact integrity.
- Observability and deployment — 10%: structured telemetry, correlation, actionable alerts, health checks, repeatable deploy, rollback, backup and restore evidence.
- Compliance and audit surface — 12%: sensitive-data inventory, residency/egress, minimization, retention/deletion, durable audit events, access to logs and exports.

Evidence states
- PASS: implementation and verification evidence demonstrate the control.
- WARNING: a control exists but has a material weakness or incomplete verification.
- FAIL: evidence demonstrates an exploitable, unsafe, or release-blocking condition.
- NOT VERIFIED: the repository cannot prove the control. This is an evidence gap, never a pass.

Scoring
For each domain, score its relevant criteria as PASS=2, WARNING=1, FAIL=0, NOT VERIFIED=0. Convert to a percentage and apply the weights above. Show the arithmetic. A confirmed critical failure in identity, tenant isolation, secrets, money movement, or regulated-data handling caps the total at 54 and forces HOLD. READY requires at least 85 and no domain below its stated operational threshold. CONDITIONAL RELEASE is 70–84 with no critical failure and explicit owners for every release condition. Otherwise the verdict is HOLD.

Severity
- Critical: credible path to account/tenant compromise, production-capable secret exposure, incorrect money movement, destructive data loss, or severe regulated-data exposure.
- High: major workflow failure or security weakness likely under realistic conditions.
- Medium: meaningful reliability, operability, or defense-in-depth gap.
- Low: bounded improvement with limited immediate business impact.

Output exactly these sections
1. Executive decision — READY / CONDITIONAL RELEASE / HOLD, score, critical workflows, and the reason in plain language.
2. System and trust-boundary map — component, responsibility, data handled, trust boundary, evidence.
3. Readiness scorecard — all nine domains with weight, raw score, weighted score, threshold, state, strongest evidence, and biggest gap.
4. Findings — ordered by severity; include ID, evidence with file and line where possible, failure scenario, business impact, confidence, and the smallest safe remediation.
5. Verification log — commands run, exit codes, and what each result does and does not prove.
6. Release conditions — blockers first, then conditions that may safely follow release. Give an owner role and objective pass criterion for each.
7. Remediation sequence — the five highest-leverage actions in dependency order, with verification tests and rollback considerations.
8. Evidence request — exact artifacts or safe commands needed to close every NOT VERIFIED item.

Do not give generic best practices disconnected from evidence. Do not claim compliance, security, scalability, or readiness because a package or configuration file exists. If a critical path cannot be verified, say so plainly and make the missing proof actionable.