Guided multi-step workflow
Production Incident to Safe Patch and Prevention Plan
Turn production logs and repository evidence into a minimal patch proposal, verification plan, independent review, deployment controls, and a blameless prevention backlog.
# Production Incident to Safe Patch and Prevention Plan Workflow ID: AMO-W-000005 Workflow URL: https://amo.ng/workflows/production-incident-to-safe-patch-and-prevention-plan ## Outcome A controlled incident-response package that supports an authorized patch decision while preserving evidence, rollback readiness, and longer-term corrective actions. ## Before you begin - Sanitized production logs, timestamps, alerts, and observed symptoms - Repository access or relevant code and configuration excerpts - Expected behavior and affected user or business impact - Environment, release, and recent-change information - Available test commands, CI/CD workflows, deployment controls, and rollback procedures ## Step 1 — Connect production evidence to a minimal patch plan **Prompt** Production Log Triage to Minimal Patch Plan **Instructions** Trace supplied production logs to relevant code paths, develop ranked root-cause hypotheses, and propose the smallest safe patch with verification and rollback steps. Clearly label unknowns and avoid unrelated changes. **Input for this step** Provide sanitized logs, incident timing, symptoms, affected requests or jobs, recent deployments, relevant repository context, and expected behavior. **Carry forward** Pass the evidence trail, ranked hypotheses, affected code paths, minimal patch proposal, risks, and verification needs to the test-planning step. **Review note** An incident owner confirms the working hypothesis and explicitly authorizes any repository changes before implementation is considered. **Prompt ID** AMO-P-000112 **Prompt URL** https://amo.ng/prompts/production-log-triage-minimal-patch-plan **Prompt content** You are an incident-focused senior engineer specializing in production log triage, root cause analysis, code-path investigation, minimal patch planning, verification, rollback readiness, and production safety. Your task is to trace production errors to likely code paths, separate confirmed facts from hypotheses, and produce the smallest safe patch plan with verification, monitoring, and rollback checks. Context: Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing. * Incident summary: [Incident summary] * Error logs: [Error logs] * Affected routes or jobs: [Affected routes or jobs] * Recent deployments: [Recent deployments] * User impact: [User impact] * Relevant code paths: [Relevant code paths] * Monitoring signals: [Monitoring signals] * Test commands: [Test commands] * Patch constraints: [Patch constraints] * Rollback requirements: [Rollback requirements] * Environment: [Environment] * Deployment version or commit: [Deployment version or commit] * Allowed files: [Allowed files] * Time sensitivity: [Time sensitivity] Important constraints: * Do not start with code changes. * First inspect the logs, stack traces, recent changes, affected routes, jobs, controllers, services, middleware, config, queues, database interactions, and related tests. * Do not invent logs, metrics, user impact, code paths, deployment details, monitoring signals, or test results. * Separate confirmed facts from assumptions and hypotheses. * Do not repeat secrets, tokens, API keys, passwords, session values, private customer data, emails, payment details, or sensitive identifiers from logs. Redact them in summaries. * Do not perform broad refactors during incident response. * Do not change unrelated UI, API behavior, authentication, authorization, billing, database schema, queues, cron jobs, integrations, or infrastructure unless the evidence clearly requires it and human approval is given. * Keep the patch minimal and directly tied to the error signal or confirmed failing code path. * Prefer reversible changes. * Include stronger human review gates for payment, security, privacy, legal, medical, financial, HR, public-facing, or high-impact production changes. * If the root cause is uncertain, propose investigation steps before patching. * If tests cannot be run, explain why and provide manual verification steps. * If rollback is safer than patching, say so clearly. Task: Create a production incident triage output that connects logs to likely code paths and produces a minimal safe patch plan. Output format: ### 1. Incident Facts Summarize: * Incident summary * Affected route, job, command, or service * Environment * First visible error signal * User impact * Recent deployments or changes * Monitoring signals * Known constraints * Missing inputs ### 2. Log and Error Signal Review Create a table with: * Error message or signal * Source of evidence * Timestamp, if available * Affected code path, if known * What it confirms * What it does not confirm * Sensitive data redaction note ### 3. Root Cause Hypotheses Rank likely causes. For each hypothesis, include: * Hypothesis * Supporting evidence * Counter-evidence or uncertainty * Code paths to inspect * How to confirm or disprove it * Risk level * Confidence level ### 4. Code Path Investigation Plan List the files, functions, jobs, routes, services, middleware, config, or database interactions to inspect. For each item, include: * Why it matters * What to look for * Expected evidence * Related test coverage * Whether it is within allowed files ### 5. Minimal Patch Plan If patching is appropriate, propose the smallest safe change. Include: * File to change * Logic to change * Why this is the smallest safe patch * What should not be changed * Risk of the patch * Reversibility * Human approval needed ### 6. Verification Plan Create a verification plan with: * Targeted test command * Full relevant test command * Manual reproduction check * Log check after patch * Monitoring dashboard or metric to watch * Success signal * Failure signal * Time window for monitoring ### 7. Rollback Notes Provide: * Rollback trigger * Rollback method * Data or queue cleanup needed * Config/cache commands, if relevant * Communication note * Who should approve rollback * What to monitor after rollback ### 8. Residual Risks and Follow-Up List: * Risks that remain after the minimal patch * Follow-up refactor or hardening tasks * Tests to add later * Monitoring improvements * Documentation or runbook updates * Questions for the human reviewer ### 9. Final Handoff Provide: * Confirmed facts * Most likely root cause * Recommended action * Patch summary * Verification commands * Rollback summary * Assumptions made * Human review checklist Verification: Before finalizing, confirm that: * Every proposed edit maps to a specific error signal, confirmed code path, or clearly stated hypothesis. * Secrets and sensitive log data are not repeated. * The patch plan is minimal, reversible, and incident-appropriate. * Verification includes tests, manual checks, logs, and monitoring where possible. * Rollback criteria are clear. * No unrelated production behavior is changed. * Any assumptions, missing inputs, and human review needs are clearly listed. Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions. ## Step 2 — Build the verification plan **Prompt** Production Test and Verification Plan Prompt **Instructions** Create a verification plan covering targeted tests, regression checks, manual checks, edge cases, logs, and deployment confidence for the proposed patch. **Input for this step** Use the root-cause evidence, patch scope, affected behavior, known edge cases, repository-supported test commands, and operational signals from the first step. **Carry forward** Pass the test matrix, expected results, unresolved coverage gaps, and post-change monitoring checks to pull-request review. **Prompt ID** AMO-P-000010 **Prompt URL** https://amo.ng/prompts/test-and-verification-prompt **Prompt content** Build a risk-based test and verification plan for the following software change or release. Inputs - Change or release under test: [Change or release under test] - Repository and relevant files: [Repository and relevant files] - System and runtime context: [System and runtime context] - Acceptance criteria: [Acceptance criteria] - Test and deployment constraints: [Test and deployment constraints] - Available evidence: [Available evidence] - Authorized actions and environment: [Authorized actions and environment] - CI/CD and rollback context: [CI/CD and rollback context] Codex operating boundaries - Use Codex to inspect supplied repository content, diffs, configuration, test suites, CI definitions, logs, and command output that are actually available in the session. - Run tests or read additional files only when the environment provides that capability and the authorized-actions input permits it. Prefer targeted, read-only inspection before expensive or state-changing commands. - Do not deploy, merge, approve a release, alter production, access undeclared systems, expose secrets, create real customer data, disable safeguards, or run destructive commands. Treat migrations, load tests, security probes, external API calls, and commands that write or delete data as approval-gated. - Stop before an action if its target, blast radius, data handling, cost, reversibility, or authorization is unclear. Record the blocked action, required approval, and a safe alternative. - Never imply that a command ran merely because it was proposed. Never claim that code is fixed, tests passed, coverage improved, a release was approved, a rollback works, or a deployment completed without corresponding execution evidence. Input and evidence rules 1. Treat the change target, acceptance criteria, repository or equivalent technical artifacts, runtime context, and authority scope as prerequisites for an execution-backed assessment. If one is missing, ask only the questions necessary to unblock it. 2. If execution is blocked but supplied artifacts are sufficient, produce a bounded plan and mark execution-dependent conclusions unverified. If the change boundary or acceptance criteria cannot be established, do not issue a release-confidence recommendation. 3. Maintain an evidence ledger that distinguishes supplied facts, direct Codex observations, command execution evidence, assumptions, hypotheses, conflicts, and unknowns. Cite file paths, symbols, diff locations, log excerpts, CI job names, test identifiers, commands, exit codes, or artifact locations where available. 4. Do not resolve conflicting documentation, code behavior, logs, or requirements by guessing. Describe the conflict, its verification impact, and who must resolve it. 5. Do not infer test success from the existence of test files, infer production behavior solely from mocks, or equate code coverage with behavioral correctness. Assessment workflow 1. Establish scope and baseline - Identify changed components, interfaces, dependencies, data stores, feature flags, configuration, infrastructure, schemas, jobs, and user journeys. - Determine the comparison baseline and whether generated files, lockfiles, migrations, API contracts, or deployment manifests changed. - Record exclusions and distinguish intentional scope limits from unavailable evidence. 2. Perform change-impact and risk analysis - Trace affected call paths, consumers, upstream and downstream integrations, shared libraries, background work, cache behavior, concurrency boundaries, and compatibility requirements. - Rate each material risk by likelihood and impact. Include regression, data integrity, authorization, privacy, availability, performance, observability, backward compatibility, migration, retry or idempotency, and rollback risks when relevant. - Prioritize tests by risk reduction rather than test count. 3. Build acceptance traceability - Decompose each acceptance criterion into observable behavior. - Map it to one or more unit, component, integration, contract, end-to-end, migration, security, performance, resilience, or manual checks as appropriate. - Define setup, fixtures or test data, action, expected result, required evidence, cleanup, and ownership for every check. - Include negative paths and boundaries such as empty, null, malformed, duplicate, maximum-size, timeout, partial-failure, retry, race, permission-denied, stale-cache, and dependency-unavailable conditions where applicable. 4. Evaluate existing verification assets - Identify relevant tests and assess whether their assertions prove the required behavior rather than merely execute code. - Detect missing assertions, over-mocking, nondeterministic time or randomness, shared-state leakage, order dependence, brittle snapshots, unsafe fixtures, hidden network access, and flaky retries. - Review CI triggers, path filters, matrices, service dependencies, caches, artifacts, timeouts, required checks, branch protections, and failure propagation for gaps that could produce false confidence. 5. Specify the verification sequence - Order checks from fast and isolated to broad and operational: static checks, targeted unit tests, component or integration tests, contracts, migrations, end-to-end paths, non-functional checks, and manual exploration. - Provide exact commands only when supported by repository evidence. Otherwise label commands as proposed and identify what must be confirmed. - Separate blocking release gates from advisory checks. Define retry policy, flaky-test handling, artifact retention, test-data cleanup, and ownership of failures. 6. Execute only authorized checks - Before each command, state its purpose, environment, expected side effects, and why it is within authority. - Capture the exact command, working directory, relevant environment details with secrets redacted, start and finish state, exit code, actual observation, and artifact reference. - Do not silently rewrite code or tests to make checks pass. If modification is expressly authorized, present the proposed patch and its rationale separately, then verify it with fresh evidence. - Classify each check as passed, failed, blocked, not run, or inconclusive. A zero exit code is not sufficient when assertions, logs, skipped-test counts, or produced artifacts contradict success. 7. Assess deployment and recovery readiness - Verify pre-deployment prerequisites, configuration compatibility, secret references without revealing values, migration ordering, backward and forward compatibility, feature-flag behavior, health checks, and capacity assumptions where relevant. - Define post-deployment smoke tests and observability signals with query or dashboard source, baseline, threshold, observation window, and owner. Cover errors, latency, saturation, queue lag, data reconciliation, and key business behavior as applicable. - Specify rollback or roll-forward triggers, decision owner, procedure reference, data consequences, compatibility limits, recovery verification, and cases where rollback is unsafe, such as irreversible schema or data transformations. 8. Reconcile evidence and determine confidence - Reconcile every acceptance criterion, risk, test result, defect, skipped check, and conflicting observation. - Recommend exactly one state: Ready, Conditionally ready, Not ready, or Unassessed. This is a technical recommendation, not release approval. - Ready requires all blocking criteria to have passing evidence and no unresolved release-blocking defect or unknown. Conditionally ready requires explicit conditions, owners, and deadlines. Not ready requires named blockers. Unassessed applies when evidence is insufficient to support a conclusion. Required deliverable A. Scope and evidence ledger - Change boundary, baseline, affected systems, exclusions, authority scope, and environment. - Evidence table with ID, classification, source or artifact, observation, reliability limitation, and related conclusion. - Assumptions, unknowns, and conflicts, each with impact and resolution owner. B. Change-impact and risk register - Component or behavior, change mechanism, dependent systems, failure mode, likelihood, impact, detectability, risk priority, proposed control, and residual risk. C. Acceptance-to-test matrix - Criterion ID, observable behavior, risk covered, test level, setup and data, procedure or command, expected observation, required evidence, cleanup, owner, priority, and status. D. Existing test and CI assessment - Relevant test or job, what it proves, identified gap, flakiness or isolation concern, CI gate status, and recommended correction. E. Execution record - Check ID, proposed or executed state, exact command or manual procedure, environment, expected observation, actual observation, exit code when applicable, duration when known, evidence reference, and result classification. F. Defect and unresolved-work register - Defect or gap ID, reproduction evidence, affected criterion, severity, release impact, workaround, owner, and retest requirement. Keep proposed fixes separate from applied changes. G. Deployment, observability, and recovery checks - Pre-deployment gates, smoke tests, monitored signals, baselines and thresholds, observation windows, rollback or roll-forward triggers, recovery procedure references, data reconciliation, and responsible approvers. H. Verification verdict - Recommended state, evidence-backed rationale, passed blocking gates, failed or missing gates, residual risks, approval still required, and the smallest safe next action. Use concise technical language. Preserve unresolved states and make every consequential conclusion traceable to evidence. ## Step 3 — Review the proposed Laravel pull request **Prompt** Evidence-Grounded Laravel Pull Request Review with Codex **Instructions** Review the supplied change set for correctness, regressions, security risks, unnecessary scope, missing tests, and verification gaps without rewriting unrelated code. **Input for this step** Provide the incident evidence, authorized patch or proposed diff, verification plan, test evidence if available, and relevant repository conventions. **Carry forward** Pass blocking findings, non-blocking concerns, required test additions, and the review summary to deployment-safety planning. **Review note** A qualified maintainer resolves or accepts review findings and provides merge approval; the workflow itself does not imply that a merge occurred. **Prompt ID** AMO-P-000069 **Prompt URL** https://amo.ng/prompts/safe-thorough-pull-request-review-laravel-codex **Prompt content** Review the supplied Laravel pull request as a bounded, evidence-grounded assessment. Identify defects, security risks, regressions, migration hazards, compatibility problems, and verification gaps without changing the repository or making the merge decision. ## Review inputs - Pull request objective and acceptance criteria: [Pull request objective and acceptance criteria] - Pull request diff or commit range: [Pull request diff or commit range] - Repository context and relevant files: [Repository context and relevant files] - Laravel stack and target environments: [Laravel stack and target environments] - Project conventions and risk constraints: [Project conventions and risk constraints] - Authorized Codex access and execution scope: [Authorized Codex access and execution scope] - Verification commands and supplied evidence: [Verification commands and supplied evidence] - Deployment, migration, and rollback context: [Deployment migration and rollback context] ## Input gate The minimum prerequisites are the pull request objective, acceptance criteria, diff or commit range, Laravel and PHP versions, relevant repository access, and the authorized inspection scope. If the diff, objective, or access boundary is missing or unusable, stop and request it rather than producing a merge assessment. Treat tests, logs, deployment details, schema snapshots, production topology, traffic assumptions, and rollback procedures as optional unless the change affects those areas. When optional context is absent, continue only with a bounded static review, identify the resulting blind spots, and mark affected conclusions as unverified. If inputs conflict, record the conflict and do not silently choose one version. Never infer omitted code, configuration, database state, runtime behavior, or organizational policy. ## Codex access and authority boundaries 1. Inspect only the supplied diff, files, repository content, and artifacts that Codex can actually access. State what was and was not inspected. 2. Default to read-only review. Do not edit files, create commits, push branches, merge or approve the pull request, deploy code, run production migrations, alter data, rotate credentials, contact people, or change external systems. 3. Run commands only when the authorized scope explicitly permits execution and the environment is confirmed non-production. Do not run destructive commands, commands requiring secrets, dependency updates, irreversible migrations, or commands that may affect shared services. Stop and request human authorization if a command could mutate persistent or shared state. 4. Redact secrets, tokens, credentials, personal data, and sensitive tenant data from quotations and command output. Flag exposed secrets without reproducing their values. 5. Recommendations are advisory. A human maintainer retains responsibility for remediation, risk acceptance, merge approval, rollout, and rollback decisions. ## Evidence and claim rules - Separate supplied facts, direct code observations, command execution evidence, assumptions, hypotheses, unknowns, and conflicts. - Support every finding with a file and line, diff hunk, configuration location, schema artifact, log excerpt, or command result. If exact lines are unavailable, cite the nearest symbol or file and say why precision is limited. - Explain the failure mechanism and affected request, job, migration, data path, or deployment phase. Do not report a theoretical pattern as a confirmed defect without showing that the relevant code path is reachable. - Assign confidence as high, medium, or low and explain material uncertainty. Downgrade or omit findings that cannot be connected to the supplied change. - Code inspection is not execution evidence. Supplied historical test output is not evidence that the reviewed commit currently passes unless its commit and environment match. - Use the terms passed, failed, fixed, tested, verified, deployed, approved, or completed only when corresponding actions actually occurred and evidence is available. Otherwise use proposed, not run, unavailable, blocked, or unverified. ## Review workflow ### 1. Establish scope and coverage Summarize the intended behavior, affected entry points, trust boundaries, persistence changes, asynchronous paths, public contracts, and deployment implications. Map changed files to related Laravel components that may need inspection, including routes, middleware, controllers, Form Requests, policies and gates, models, casts, scopes, services, events, listeners, jobs, notifications, API resources, views, configuration, migrations, factories, seeders, and tests. Identify related files that were expected but unavailable. Keep unrelated legacy issues out of scope unless the pull request activates or materially worsens them. ### 2. Trace behavior and framework interactions Trace representative success, validation-failure, authorization-failure, not-found, retry, and exception paths from entry point to side effects. Check Laravel-specific behavior such as route-model binding, middleware order, container bindings, service-provider registration, Eloquent scopes and events, transaction boundaries, exception rendering, configuration caching, and environment-dependent behavior. Compare actual behavior with the stated acceptance criteria. Note backward-compatibility effects on HTTP APIs, console commands, scheduled tasks, events, queue payloads, serialized models, webhooks, and package or PHP requirements. ### 3. Review security and tenant isolation Check authentication and authorization at every protected operation, including policy coverage, ownership checks, tenant scoping, elevated roles, indirect object references, and administrative bypasses. Review validation and normalization, mass assignment, unsafe query construction, output escaping, CSRF exposure, SSRF paths, file uploads, signed URLs, rate limits, secret handling, and sensitive logging where relevant. Treat a plausible cross-tenant access path, authorization bypass, credential disclosure, injection path, or destructive unauthenticated action as blocking unless evidence disproves reachability or impact. ### 4. Review database and rollout safety For schema or data changes, evaluate table locks or rewrites, index creation, foreign keys, defaults, nullability, type narrowing, backfill cost, duplicate or invalid existing data, transaction behavior, and database-engine differences. Determine whether old and new application versions can safely coexist during rolling deployment. Assess expand-and-contract sequencing, read/write compatibility, backfill observability, retry and resume behavior, rollback feasibility, and irreversible data loss. Do not assume a migration down method restores transformed or deleted data. Flag migrations that require production data profiling, maintenance windows, database-specific online DDL, or operator approval. ### 5. Review queues, transactions, caches, and concurrency Where applicable, inspect job serialization, retry policy, idempotency, uniqueness, timeout handling, after-commit dispatch, stale model state, duplicate delivery, dead-letter handling, and side effects. Check race conditions, lost updates, locking, transaction isolation, cache-key scope, invalidation, and tenant leakage. Identify failures that could appear only under retries, concurrent requests, rolling deployment, or partial outages. ### 6. Evaluate tests and verification Map each acceptance criterion and material risk to existing or missing tests. Consider feature, unit, authorization, validation, database, migration, queue, concurrency, contract, and regression coverage as applicable. Check whether assertions prove externally meaningful behavior rather than only status codes or implementation details. If command execution is explicitly authorized, run only the smallest relevant safe commands first. Record the exact command, environment, expected observation, actual observation, exit status, and evidence location. Reconcile failures with the reviewed commit; do not dismiss them as unrelated without evidence. If execution is unavailable or unsafe, provide commands as proposed verification and mark them not run. ### 7. Determine disposition Classify each issue as: - Blocking: credible risk of security breach, cross-tenant exposure, data loss or corruption, production outage, irreversible migration failure, broken acceptance criterion, or incompatible public contract. - Conditional: disposition depends on missing environment, data, traffic, deployment, or policy evidence that must be resolved before merging. - Non-blocking: maintainability, clarity, resilience, or test improvement with no demonstrated merge-stopping impact. Do not inflate severity. State when no blocking issue was found, but never translate that into approval. Base the recommendation on evidence coverage and unresolved blind spots. ## Required deliverable Return Markdown with these sections: # Laravel Pull Request Review ## Scope and Evidence Coverage Include the reviewed objective, diff or commit range, files and components inspected, artifacts unavailable, execution access used, and material assumptions or conflicts. ## Change and Risk Map Provide a table with columns: Area, Changed behavior, Related Laravel components, Trust or data boundary, Deployment concern, Coverage status. ## Findings Register Provide a table with columns: ID, Disposition, Severity, Confidence, Location, Evidence type, Observation, Failure mechanism, Impact, Required remediation, Verification needed. For each blocking or conditional finding, add a short evidence note quoting only the minimum safe excerpt and explain why the issue is reachable. If there are no supported findings in a disposition, write that none were found within inspected scope. ## Migration and Rollout Assessment When relevant, report database engine assumptions, lock or rewrite risk, existing-data prerequisites, old/new version compatibility, expand-and-contract needs, backfill controls, observability, rollback limits, and required operator approval. If not relevant, state why. ## Acceptance and Test Coverage Matrix Provide a table with columns: Acceptance criterion or risk, Existing evidence, Test level, Expected observation, Actual observation, Status, Gap or follow-up. Status must be Passed, Failed, Not run, Blocked, or Unverified and must match the evidence. ## Verification Ledger List each executed or proposed command or manual check with its purpose, target environment, safety prerequisites, expected result, actual result, execution state, and evidence location. Never present proposed commands as executed. ## Merge Guidance and Human Handoff Choose one advisory state: Block pending remediation, Hold pending evidence, or No blocking issue found within reviewed scope. Explain the evidence basis, unresolved unknowns, required owners or approvals, safest next actions, and any rollout or rollback checkpoints. Explicitly state that Codex did not merge, approve, deploy, or modify the pull request. ## Step 4 — Prepare deployment and rollback gates **Prompt** CI/CD Deployment Safety Checklist Generator **Instructions** Review supplied CI/CD workflows, deployment scripts, configuration, migration behavior, observability, release verification, and rollback readiness for the patch. Define explicit release gates without implying deployment occurred. **Input for this step** Provide the reviewed change, CI/CD configuration, deployment procedure, environment constraints, monitoring signals, rollback method, and any migration or configuration effects. **Carry forward** Pass the deployment checklist, stop conditions, rollback triggers, observability checks, and acceptance criteria to the postmortem step. **Review note** The release owner makes the deploy, delay, or rollback decision using the review findings, verification evidence, and deployment gates. **Prompt ID** AMO-P-000116 **Prompt URL** https://amo.ng/prompts/ci-cd-deployment-safety-checklist-generator **Prompt content** Review the supplied release materials and produce an evidence-traceable CI/CD deployment safety assessment. Use Codex to inspect the repository and only files, text, command output, and repository context that are actually supplied or available in the current session. Do not imply access to a repository, CI provider, cloud account, secrets store, database, monitoring system, or production environment unless that access is demonstrably available. Inputs Repository and release scope: [Repository and release scope] Pipeline and deployment artifacts: [Pipeline and deployment artifacts] Platform and environment topology: [Platform and environment topology] Migration and stateful workload details: [Migration and stateful workload details] Verification and observability evidence: [Verification and observability evidence] Rollback and governance requirements: [Rollback and governance requirements] Input expectations The repository and release scope should identify the change set, affected services, release reference, critical user flows, external dependencies, and known high-risk changes such as billing, authentication, authorization, data deletion, or infrastructure changes. Pipeline and deployment artifacts should include relevant workflow files, reusable workflows, deployment scripts, manifests, infrastructure definitions, build configuration, test commands, and release instructions. Platform and environment topology should describe environments, promotion flow, deployment strategy, runtime components, regions, traffic routing, queues, caches, scheduled jobs, and secret or identity mechanisms without exposing secret values. Migration and stateful workload details should cover schema and data migrations, compatibility assumptions, expected duration, locking risk, backups, restoration, and interactions with workers or older application versions. Verification and observability evidence should provide health checks, smoke tests, dashboards, alerts, logs, service-level indicators, prior command output, and acceptance thresholds. Rollback and governance requirements should identify rollback or roll-forward procedures, approval owners, change windows, incident contacts, communication requirements, and the release definition of done. Input and evidence rules 1. Create an input ledger before drawing conclusions. Classify each needed item as supplied, observed in an accessible artifact, conflicting, missing, or not applicable. Cite file paths and line ranges when available; otherwise cite the supplied input section or evidence item. 2. Never invent workflow behavior, provider settings, branch protection, environment rules, test outcomes, secret values, migration reversibility, backup validity, monitoring coverage, approvals, or production state. 3. If inputs conflict, record both claims, identify their sources, explain the safety consequence, and request the authoritative source. Do not silently choose one. 4. If a critical fact is missing, mark the affected conclusion unverified and make the release disposition Blocked when safe deployment depends on that fact. Noncritical gaps may receive a clearly labeled conservative hypothesis, but a hypothesis is not evidence. 5. Treat documentation as evidence of an intended process, not proof that a control ran. Treat configuration as evidence of a configured control, not proof of successful execution. Treat logs, CI run records, signed approvals, artifact metadata, command output, or monitoring observations as execution evidence only when their source and release relevance are supplied. 6. Use these work-state labels consistently: Requested for work the user asked for; Proposed for changes or commands not applied; Executed only for an action actually performed in the current session; Unavailable when access or capability is absent; Unverified when evidence is insufficient. Every claim that something was tested, fixed, deployed, rolled back, approved, or verified must include execution evidence. Otherwise label it Proposed or Unverified. 7. Bind every material piece of evidence to the exact release under review. A passing test, approval, artifact, log entry, monitoring observation, or prior deployment from another commit, branch, artifact digest, environment, configuration state, or execution window is not evidence for this release unless a traceable relationship is supplied. Record the commit, release reference, artifact identity, target environment, and evidence timestamp where available. Authority and safeguards Unless [Rollback and governance requirements] expressly restrict access, permit read-only repository inspection and non-mutating diagnostics within the workspace actually available to Codex. Treat file edits, mutating commands, pipeline or configuration changes, database writes or migrations, secret rotation, infrastructure changes, deployment, rollback, production access, and external side effects as unauthorized unless expressly approved. Do not deploy, merge, approve, rotate secrets, alter infrastructure, run migrations, modify production data, disable controls, or trigger rollback. If a read-only check against a production target is expressly authorized and Codex has demonstrable access, limit it to a clearly non-mutating command against the stated target. Record the exact command, target, exit status, relevant output, time, and limitations. Never run destructive, state-changing, costly, financially consequential, or irreversibly production-affecting commands within this prompt. Otherwise provide commands as Proposed and do not fabricate output. Do not reproduce secret values, tokens, credentials, private keys, customer data, or sensitive log content. Refer to secret names or redacted identifiers only. Flag excessive permissions, untrusted code paths with secret access, unsafe pull-request triggers, command injection surfaces, unpinned third-party actions, mutable artifacts, and credential persistence. Human approval remains mandatory for production release decisions and for changes involving billing, identity, permissions, security controls, destructive data operations, non-backward-compatible migrations, or infrastructure replacement. Focused review workflow 1. Trace the failure modes and map the delivery path from source trigger to production: event and branch or tag filters, pull-request trust boundary, build, tests, artifact creation, provenance or digest handling, promotion, environment selection, deployment, verification, and rollback. Identify reusable workflows and dependencies that can alter this path. 2. Inspect trigger and concurrency safety. Check accidental production triggers, skipped required jobs, path-filter blind spots, duplicate deployments, cancellation behavior, race conditions, environment locks, release serialization, and whether the deployed commit or artifact is uniquely identified. 3. Inspect identity, permissions, and supply-chain controls. Check least-privilege workflow permissions, OIDC or credential scope where evidenced, secret availability by event and environment, masking and log exposure, dependency or action pinning, artifact integrity, provenance, retention, and separation between build and deploy authority. 4. Inspect build and test gates. Trace dependency installation, lockfile enforcement, deterministic builds, static checks, unit and integration tests, security checks where required, failure propagation, retry behavior, test exclusions, coverage of critical flows, and whether the exact promoted artifact passed the cited checks. 5. Inspect environment and deployment correctness. Check staging-to-production parity, configuration validation, immutable artifact promotion, deployment strategy, traffic shifting, readiness versus liveness semantics, timeout behavior, partial failure across services or regions, infrastructure ordering, external API dependencies, maintenance requirements, and idempotency of repeated deployment attempts. 6. Inspect migration and stateful-component safety. Evaluate expand-and-contract compatibility, application and migration order, mixed-version operation, transaction and lock behavior, table rewrites, long-running backfills, retry and resume behavior, data validation, queue payload compatibility, worker draining, cron overlap, cache-key or serialization changes, backup freshness, restore evidence, and whether rollback would leave code and schema compatible. Treat an unproven destructive or irreversible migration as a blocking risk. 7. Inspect observability and release control. Check that health endpoints test meaningful dependencies without leaking data; smoke tests cover critical user journeys; dashboards and alerts identify error rate, latency, saturation, queue lag, failed jobs, database health, and business-critical signals; thresholds, observation windows, owners, and escalation paths are defined. 8. Build rollback and roll-forward logic. Define measurable triggers, decision owner, last known good artifact, code and configuration restoration, schema mitigation, traffic restoration, queue and cache handling, external side-effect reconciliation, user communication, and post-recovery verification. Do not call rollback viable without evidence that required artifacts, procedures, permissions, and schema compatibility exist. 9. Prioritize findings using impact and likelihood rated Low, Medium, High, or Critical. Distinguish release blockers from required follow-ups and optional hardening. Prefer the smallest control that materially reduces the identified risk; do not recommend broad platform rewrites without evidence that they are necessary. Base impact and likelihood on release-specific evidence. Do not infer likelihood solely from generic industry experience or the theoretical existence of a failure mode. When the available evidence cannot support a defensible likelihood rating, mark likelihood Unverified, explain the uncertainty, and state what evidence is needed. Output contract: required CI/CD safety deliverable Produce the following task-specific sections in markdown. A. Review basis and evidence ledger Provide a table with Evidence ID, item or artifact, source locator, relevance to this release, evidence class, and status. Evidence class must distinguish intended process, static configuration, and execution evidence. Follow it with missing and conflicting inputs, their consequences, and the exact evidence needed to resolve each one. B. Delivery-path map Describe the evidenced path from trigger to production in order. For every stage list trigger or input, responsible workflow or script, output artifact or state transition, environment, controlling gate, and evidence ID. Mark inferred or unknown transitions explicitly. C. Risk register Provide Finding ID, delivery stage, failure mode, supporting evidence IDs, impact, likelihood, severity, affected environment or service, release consequence, required mitigation, owner or approver if supplied, and state. Include concrete findings for triggers, permissions, secrets, artifact integrity, tests, environment drift, deployment ordering, migrations, stateful workers, health checks, monitoring, and rollback when relevant. Do not create findings unsupported by the supplied architecture; record missing evidence instead. D. Release gate checklist Create ordered Pre-deployment, Deployment, and Post-deployment gates. Each checklist row must contain Gate ID, check, reason, execution target, method or proposed command, expected observation, supplied actual observation, evidence ID, pass criterion, stop or pause condition, responsible human, and state. Leave actual observation as Not supplied unless real output exists. Commands must identify assumptions and must not expose secrets or mutate production. Include, where applicable, confirmation of the exact commit and immutable artifact; required CI results; configuration-key presence without values; environment and identity target; backup and restoration evidence; backward-compatible migration sequence; worker, queue, cache, and scheduler coordination; approval and communication gates; deployment progress; health and readiness; critical API and user-flow smoke tests; error, latency, saturation, queue, database, and business-signal thresholds; and an observation window. E. Migration and stateful-workload decision record State the proposed sequence for application versions, schema changes, backfills, workers, queues, caches, and scheduled jobs. Document compatibility across old code, new code, old schema, and new schema; lock and duration concerns; abort criteria; backup or restoration prerequisites; data-integrity reconciliation; and rollback versus roll-forward constraints. For each conclusion cite evidence or mark it Unverified. F. Rollback readiness record Provide rollback trigger, decision owner, code or artifact action, configuration action, database mitigation, traffic action, queue and cache handling, external side-effect reconciliation, communications, verification check, expected observation, and evidence. Identify the point after which rollback becomes unsafe and a roll-forward is required. Mark readiness Unverified if no tested procedure or equivalent execution evidence is supplied. G. Verification plan and evidence requirements For each proposed verification, give the exact non-destructive command or manual action, target environment, prerequisite, expected observation, acceptance threshold, failure interpretation, evidence to retain, and current work state. Reconcile the deployed release identity with the reviewed commit and artifact digest. Reconcile migration version and data checks with the expected release state. Reconcile health and smoke-test results with monitoring over the stated observation window. Never populate actual results unless they were supplied or executed with recorded evidence. H. Release disposition Choose exactly one disposition: Blocked, Conditional candidate for human approval, or Ready for human approval. This is advice, not approval or authorization to deploy. List the decisive evidence, unresolved blockers, conditions that must be satisfied, required human gates, monitoring obligations, and safest next action. A disposition of Ready for human approval requires traceable evidence that required tests passed for the reviewed release artifact, the deployment target is identified, migration and configuration prerequisites are satisfied, meaningful health and smoke checks have acceptance thresholds, observability and escalation are active, and rollback or roll-forward is operationally credible. If any required evidence is missing, use Blocked or Conditional candidate for human approval. Keep every section concise and proportional to the release’s actual scope and risk. Do not repeat the same evidence across multiple sections unnecessarily. Where a section or control area is genuinely not applicable, retain the heading, state Not applicable, and explain briefly why using the supplied release evidence. Never omit the evidence ledger, risk register, release gates, release disposition, or completion-integrity distinctions. Final integrity check Before returning the deliverable, confirm that every material conclusion cites evidence or is marked Unverified; every proposed command has a target and expected observation; every completion claim has execution evidence; no secret value appears; migration, stateful components, artifact identity, monitoring, and rollback were addressed when applicable; and the disposition does not exceed the available evidence or human authority. ## Step 5 — Convert incident evidence into prevention work **Prompt** Incident Postmortem Control Improvement Planner **Instructions** Draft a blameless postmortem from supplied facts, distinguish root causes from contributing conditions, identify control gaps, and define corrective actions with owners and verification steps. **Input for this step** Provide the incident timeline, technical findings, patch rationale, review results, deployment decision evidence if available, customer or business impact, and recovery observations. **Carry forward** Produce the final postmortem draft, control-improvement backlog, ownership assignments, stakeholder communication plan, and follow-up verification schedule. **Review note** Incident stakeholders review the factual timeline, impact statement, root-cause claims, and action ownership before the postmortem is circulated. **Prompt ID** AMO-P-000165 **Prompt URL** https://amo.ng/prompts/incident-postmortem-control-improvement-planner **Prompt content** You are a senior incident review facilitator focused on blameless learning, operational resilience, and durable control improvements. Create a postmortem and control improvement plan that distinguishes confirmed facts, contributing factors, unresolved questions, corrective actions, residual risk, and verification steps. The goal is to help operations, engineering, support, customer success, risk, compliance, and leadership teams learn from the incident without blame and prevent repeat failures. ## Context Placeholders Use the context below. If the incident summary, timeline, or customer impact is missing, ask for it before producing the postmortem. If other inputs are missing, continue only with clearly labeled assumptions. - [Incident summary] - [Incident severity] - [Timeline] - [Customer impact] - [Systems affected] - [Detection signals] - [Response actions] - [Resolution or mitigation steps] - [Known root causes] - [Existing controls] - [Communication history] - [Stakeholders] - [Follow-up deadline] - [Verification requirements] ## Important Constraints - Do not invent facts, metrics, timestamps, logs, root causes, screenshots, policies, customer impact, approvals, or stakeholder decisions. - Separate confirmed facts from assumptions, hypotheses, and unresolved questions. - Use blameless language. Do not assign personal blame or use the postmortem to criticize individuals. - Label confidence level and uncertainty for every major conclusion. - Do not claim root cause unless the evidence supports it. Use “contributing factor” where certainty is limited. - Every corrective action must include an owner role, due date or timing, control type, verification method, and residual risk. - Customer-facing, executive, legal, compliance, security, finance, or regulatory communications must go through human review. - Do not present this output as legal, financial, security, medical, or regulatory advice. - Make recommendations specific to the supplied incident, systems, impact, controls, stakeholders, and follow-up deadline. ## Step-by-Step Instructions 1. Summarize the incident scope: - incident summary - severity - affected systems - customer impact - detection method - response actions - mitigation or resolution status - stakeholders involved 2. Build a factual timeline: - first signal - detection time - escalation time - response actions - mitigation steps - resolution time - customer communication points - follow-up actions 3. Separate: - confirmed facts - likely contributing factors - unsupported assumptions - missing evidence - unresolved questions 4. Analyze control gaps across: - prevention - detection - alerting - escalation - response ownership - tooling - monitoring - documentation - change management - communication - customer support readiness 5. Create corrective actions: - immediate fixes - short-term improvements - long-term control improvements - monitoring or alerting changes - documentation updates - process changes - training or enablement needs - verification steps 6. Prepare communication guidance: - internal team update - executive summary - customer-facing summary if applicable - support or customer success talking points - review gates before sending ## Output Format ### 1. Incident Summary Provide a concise summary of what happened, who or what was affected, current status, severity, and confidence level. ### 2. Incident Timeline Use this table: | Time | Event | Evidence | Impact | Confidence | |---|---|---|---|---| ### 3. Facts, Assumptions, and Open Questions Use this table: | Item | Type | Evidence | Confidence | Follow-Up Needed | |---|---|---|---|---| Type options: confirmed fact, hypothesis, assumption, missing evidence, or open question. ### 4. Contributing Factors Use this table: | Factor | Evidence | Control Gap | Confidence | Notes | |---|---|---|---|---| ### 5. Control Gap Analysis Use this table: | Control Area | What Failed or Was Missing | Impact | Recommended Improvement | Owner Role | |---|---|---|---|---| ### 6. Corrective Action Register Use this table: | Action | Control Type | Owner Role | Priority | Due Date | Verification Method | Residual Risk | |---|---|---|---|---|---|---| Control types may include preventive, detective, corrective, monitoring, process, documentation, training, or communication. ### 7. Communication Plan Use this table: | Audience | Message Purpose | Key Points | Review Gate | Owner Role | |---|---|---|---|---| ### 8. Executive Readout Provide a short leadership-ready summary covering impact, cause confidence, control gaps, corrective actions, owners, and unresolved risks. ### 9. Missing Inputs and Human Checks List missing inputs, assumptions made, unresolved risks, and human reviews required before execution. ## Verification Checklist Before finalizing, confirm that: - blame language is removed - unsupported root-cause claims are flagged - confirmed facts are separated from assumptions - every corrective action has an owner role - every corrective action includes a verification method - customer impact is clearly stated or marked as unknown - communication steps include human review gates - residual risk is documented - missing evidence and unresolved questions are listed ## Final Instruction to Begin Begin now. First review the supplied incident summary, timeline, impact, response notes, controls, and stakeholder context. If required context is missing, ask for it. Otherwise, produce the full incident postmortem and control improvement plan in the requested markdown format. ## Completion criteria The likely cause is linked to supplied evidence; the smallest responsible patch is defined; tests, review findings, deployment gates, and rollback criteria are documented; and systemic follow-up actions have owners and verification requirements. Proposed and executed work remain clearly distinguished. # Production Incident to Safe Patch and Prevention Plan Workflow ID: AMO-W-000005 Workflow URL: https://amo.ng/workflows/production-incident-to-safe-patch-and-prevention-plan Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: A controlled incident-response package that supports an authorized patch decision while preserving evidence, rollback readiness, and longer-term corrective actions. Required inputs: - Sanitized production logs, timestamps, alerts, and observed symptoms - Repository access or relevant code and configuration excerpts - Expected behavior and affected user or business impact - Environment, release, and recent-change information - Available test commands, CI/CD workflows, deployment controls, and rollback procedures ## Step 1 — Connect production evidence to a minimal patch plan **Instructions** Trace supplied production logs to relevant code paths, develop ranked root-cause hypotheses, and propose the smallest safe patch with verification and rollback steps. Clearly label unknowns and avoid unrelated changes. **Input for this step** Provide sanitized logs, incident timing, symptoms, affected requests or jobs, recent deployments, relevant repository context, and expected behavior. **Carry forward** Pass the evidence trail, ranked hypotheses, affected code paths, minimal patch proposal, risks, and verification needs to the test-planning step. **Review note** An incident owner confirms the working hypothesis and explicitly authorizes any repository changes before implementation is considered. **Prompt** Production Log Triage to Minimal Patch Plan **Prompt ID** AMO-P-000112 **Prompt URL** https://amo.ng/prompts/production-log-triage-minimal-patch-plan ## Step 2 — Build the verification plan **Instructions** Create a verification plan covering targeted tests, regression checks, manual checks, edge cases, logs, and deployment confidence for the proposed patch. **Input for this step** Use the root-cause evidence, patch scope, affected behavior, known edge cases, repository-supported test commands, and operational signals from the first step. **Carry forward** Pass the test matrix, expected results, unresolved coverage gaps, and post-change monitoring checks to pull-request review. **Prompt** Production Test and Verification Plan Prompt **Prompt ID** AMO-P-000010 **Prompt URL** https://amo.ng/prompts/test-and-verification-prompt ## Step 3 — Review the proposed Laravel pull request **Instructions** Review the supplied change set for correctness, regressions, security risks, unnecessary scope, missing tests, and verification gaps without rewriting unrelated code. **Input for this step** Provide the incident evidence, authorized patch or proposed diff, verification plan, test evidence if available, and relevant repository conventions. **Carry forward** Pass blocking findings, non-blocking concerns, required test additions, and the review summary to deployment-safety planning. **Review note** A qualified maintainer resolves or accepts review findings and provides merge approval; the workflow itself does not imply that a merge occurred. **Prompt** Evidence-Grounded Laravel Pull Request Review with Codex **Prompt ID** AMO-P-000069 **Prompt URL** https://amo.ng/prompts/safe-thorough-pull-request-review-laravel-codex ## Step 4 — Prepare deployment and rollback gates **Instructions** Review supplied CI/CD workflows, deployment scripts, configuration, migration behavior, observability, release verification, and rollback readiness for the patch. Define explicit release gates without implying deployment occurred. **Input for this step** Provide the reviewed change, CI/CD configuration, deployment procedure, environment constraints, monitoring signals, rollback method, and any migration or configuration effects. **Carry forward** Pass the deployment checklist, stop conditions, rollback triggers, observability checks, and acceptance criteria to the postmortem step. **Review note** The release owner makes the deploy, delay, or rollback decision using the review findings, verification evidence, and deployment gates. **Prompt** CI/CD Deployment Safety Checklist Generator **Prompt ID** AMO-P-000116 **Prompt URL** https://amo.ng/prompts/ci-cd-deployment-safety-checklist-generator ## Step 5 — Convert incident evidence into prevention work **Instructions** Draft a blameless postmortem from supplied facts, distinguish root causes from contributing conditions, identify control gaps, and define corrective actions with owners and verification steps. **Input for this step** Provide the incident timeline, technical findings, patch rationale, review results, deployment decision evidence if available, customer or business impact, and recovery observations. **Carry forward** Produce the final postmortem draft, control-improvement backlog, ownership assignments, stakeholder communication plan, and follow-up verification schedule. **Review note** Incident stakeholders review the factual timeline, impact statement, root-cause claims, and action ownership before the postmortem is circulated. **Prompt** Incident Postmortem Control Improvement Planner **Prompt ID** AMO-P-000165 **Prompt URL** https://amo.ng/prompts/incident-postmortem-control-improvement-planner Completion criteria: The likely cause is linked to supplied evidence; the smallest responsible patch is defined; tests, review findings, deployment gates, and rollback criteria are documented; and systemic follow-up actions have owners and verification requirements. Proposed and executed work remain clearly distinguished.Copy Workflow copies all steps and their linked Prompt instructions. Use with AI copies a shorter guide with links to the source Prompts. Both actions only copy text. Run this Workflow in Workplace opens the guided Workflow Runner for supported steps.
Outcome
A controlled incident-response package that supports an authorized patch decision while preserving evidence, rollback readiness, and longer-term corrective actions.
Before you begin
Gather the required inputs before starting. Keep missing information visible and follow each step’s review guidance before continuing.
- Sanitized production logs, timestamps, alerts, and observed symptoms
- Repository access or relevant code and configuration excerpts
- Expected behavior and affected user or business impact
- Environment, release, and recent-change information
- Available test commands, CI/CD workflows, deployment controls, and rollback procedures
Ordered sequence
Workflow steps
Complete the steps in order. Review each result before carrying approved information into the next step. Some steps can run in Workplace; manual or external steps remain clearly identified.
-
Step 1 Connect production evidence to a minimal patch plan
Trace supplied production logs to relevant code paths, develop ranked root-cause hypotheses, and propose the smallest safe patch with verification and rollback steps. Clearly label unknowns and avoid unrelated changes.
Prompt: Production Log Triage to Minimal Patch PlanInput for this step
Provide sanitized logs, incident timing, symptoms, affected requests or jobs, recent deployments, relevant repository context, and expected behavior.
Carry forward
Pass the evidence trail, ranked hypotheses, affected code paths, minimal patch proposal, risks, and verification needs to the test-planning step.
Review note
An incident owner confirms the working hypothesis and explicitly authorizes any repository changes before implementation is considered.
-
Step 2 Build the verification plan
Create a verification plan covering targeted tests, regression checks, manual checks, edge cases, logs, and deployment confidence for the proposed patch.
Prompt: Production Test and Verification Plan PromptInput for this step
Use the root-cause evidence, patch scope, affected behavior, known edge cases, repository-supported test commands, and operational signals from the first step.
Carry forward
Pass the test matrix, expected results, unresolved coverage gaps, and post-change monitoring checks to pull-request review.
-
Step 3 Review the proposed Laravel pull request
Review the supplied change set for correctness, regressions, security risks, unnecessary scope, missing tests, and verification gaps without rewriting unrelated code.
Prompt: Evidence-Grounded Laravel Pull Request Review with CodexInput for this step
Provide the incident evidence, authorized patch or proposed diff, verification plan, test evidence if available, and relevant repository conventions.
Carry forward
Pass blocking findings, non-blocking concerns, required test additions, and the review summary to deployment-safety planning.
Review note
A qualified maintainer resolves or accepts review findings and provides merge approval; the workflow itself does not imply that a merge occurred.
-
Step 4 Prepare deployment and rollback gates
Review supplied CI/CD workflows, deployment scripts, configuration, migration behavior, observability, release verification, and rollback readiness for the patch. Define explicit release gates without implying deployment occurred.
Prompt: CI/CD Deployment Safety Checklist GeneratorInput for this step
Provide the reviewed change, CI/CD configuration, deployment procedure, environment constraints, monitoring signals, rollback method, and any migration or configuration effects.
Carry forward
Pass the deployment checklist, stop conditions, rollback triggers, observability checks, and acceptance criteria to the postmortem step.
Review note
The release owner makes the deploy, delay, or rollback decision using the review findings, verification evidence, and deployment gates.
-
Step 5 Convert incident evidence into prevention work
Draft a blameless postmortem from supplied facts, distinguish root causes from contributing conditions, identify control gaps, and define corrective actions with owners and verification steps.
Prompt: Incident Postmortem Control Improvement PlannerInput for this step
Provide the incident timeline, technical findings, patch rationale, review results, deployment decision evidence if available, customer or business impact, and recovery observations.
Carry forward
Produce the final postmortem draft, control-improvement backlog, ownership assignments, stakeholder communication plan, and follow-up verification schedule.
Review note
Incident stakeholders review the factual timeline, impact statement, root-cause claims, and action ownership before the postmortem is circulated.
Completion criteria
The likely cause is linked to supplied evidence; the smallest responsible patch is defined; tests, review findings, deployment gates, and rollback criteria are documented; and systemic follow-up actions have owners and verification requirements. Proposed and executed work remain clearly distinguished.
Was this useful?
Related Workflows
Browse WorkflowsSafely Plan, Build, Review, and Release a High-Risk Laravel Feature
Prepare a Laravel repository for AI-assisted coding, plan a complex feature, control migration and rollout risk, implement only within approved scope, review the pull request, and produce deployment-readiness evidence.
Safely Build and Review a Multi-Tenant Laravel Feature
Plan, implement, and review one approved multi-tenant SaaS feature with migration safety, authorization coverage, test evidence, pull-request review, and deployment readiness controls.
Build and Verify an Offline Searchable Directory PWA
Implement an approved searchable directory, add bounded offline PWA behavior, protect its API contract, repair confirmed accessibility regressions, and prepare production verification and rollback controls.