Amo.ng curated workflow
Laravel Incident Investigation and Controlled Correction
Use a compact three-step path to diagnose a Laravel production incident, make only an authorized minimal correction, independently review the change, and prepare a controlled release.
# Laravel Incident Investigation and Controlled Correction Workflow ID: AMO-W-000001 Workflow URL: https://amo.ng/workflows/laravel-production-incident-investigation ## Outcome Identify an evidence-supported root cause, apply and review the smallest authorized Laravel correction, and prepare deployment and rollback controls. Use the extended Production Incident to Safe Patch and Prevention Plan workflow when formal verification, postmortem, and prevention work are also required. ## Before you begin - Incident symptoms and timestamps - Sanitized logs or stack traces - Repository access and the affected route, job, command, or feature - Recent deployment or configuration changes - The actions and environments you are authorized to change ## Step 1 — Diagnose the incident and prepare the smallest correction **Prompt** Laravel Bug Fix and Refactor Prompt **Instructions** Use the repository-first Laravel workflow to reproduce or trace the symptom, confirm the root cause, and make only an authorized minimal change. **Input for this step** Provide the symptom, sanitized logs, affected code path, environment details, recent changes, and action boundaries. **Carry forward** Carry the confirmed root cause, changed files, final diff, test evidence, unresolved risks, and unexecuted actions into the review step. **Review note** Confirm that any proposed edits, commands, data operations, or production actions are within the permitted scope. **Prompt ID** AMO-P-000001 **Prompt URL** https://amo.ng/prompts/laravel-bug-fix-and-refactor-prompt **Prompt content** Investigate and, only within explicit authority, correct the Laravel debugging, bug-fix, or refactoring task described below using Codex and the actual repository. ## Context to provide * Objective and observed symptoms: [Objective and symptoms] * Repository and application context: [Repository context] * Errors, logs, failing tests, relevant files, and recent changes: [Relevant evidence] * Authorized inspection, edits, commands, database writes, migrations, deployment, and production access: [Allowed actions] * Laravel, PHP, dependency, runtime, queue, cache, and database details without secrets: [Environment details] * Scope, compatibility, timing, and operational constraints: [Constraints] * Expected behavior and definition of done: [Verification target] If information needed for safe diagnosis is missing, ask one consolidated clarification only for genuinely blocking gaps; otherwise proceed with clearly labelled, low-risk assumptions. Treat any referenced file, command, log, test, or result as unverified until Codex inspects it directly or its contents or actual output are supplied. Do not invent repository contents, runtime access, root cause, Laravel behavior, test output, authorization, or production observations. ## 1. Establish authority and scope State what Codex may inspect, change, and execute. Unless [Allowed actions] says otherwise, permit read-only repository inspection and non-mutating diagnostics, but treat file edits, mutating commands, database writes, migrations, cache or queue changes, external-service calls, deployment, and production access as unauthorized. Never expose credentials, secrets, access tokens, personal data, or private production data. Stop before destructive or consequential work that lacks approval, backup, recovery, or rollback conditions. ## 2. Inspect the relevant Laravel repository Inspect the repository before proposing edits. Select only areas relevant to the symptom: routes, controllers, models, Eloquent scopes and relationships, services, middleware, form requests and validation, authorization, jobs and queues, events and listeners, migrations and schema, transactions, cache and configuration, Composer dependencies, logs, tests, recent relevant changes, and the installed Laravel and PHP versions. Record exactly what was inspected and what was unavailable. Follow the service container, dependency injection, framework conventions, route middleware, validation, and authorization paths actually used by this application. ## 3. Reproduce or trace the symptom Use the repository’s existing supported workflow where authorized. Capture the observed behavior, reproduction steps or trace, expected behavior, relevant command output, test output, logs, and data conditions. Separate supplied facts and observations from hypotheses, assumptions, unknowns, and unsupported conclusions. If reproduction is unavailable, perform a bounded evidence trace and state clearly why it is not a reproduction. ## 4. Confirm root cause List plausible causes and the evidence for and against each. Confirm a root cause only when repository evidence or an actual result supports it. Reject competing causes explicitly when evidence permits. Otherwise, report the leading hypothesis and unresolved uncertainty; do not present a guessed root cause as confirmed. ## 5. Plan the smallest safe Laravel change Describe the minimum relevant fix or refactor and why it addresses the evidenced cause. Preserve unrelated behavior. Avoid unrelated refactoring, broad dependency upgrades, silent architectural rewrites, speculative migrations, and forced Laravel concepts that do not apply. Consider Eloquent behavior, transactions, queues, cache and configuration state, validation, authorization, database compatibility, external-service effects, and rollback only where relevant. ## 6. Implement only authorized work Before any edit or mutating or consequential command, verify that it falls within [Allowed actions]. Do not interrupt the investigation to narrate permission checks for ordinary read-only inspection. Review the repository’s existing tests, conventions, and relevant implementation before changing files. Make the smallest coherent diff. Do not modify production data, run destructive commands, expose secrets, execute migrations, clear production caches, change queue state, contact external services, or deploy unless explicitly authorized with appropriate safeguards. Review the final diff for accidental changes, unrelated modifications, and scope expansion. ## 7. Verify with actual project tooling Inspect Composer scripts, test configuration, CI files, and repository documentation to identify supported checks; do not invent commands. Begin with the smallest targeted checks capable of confirming or disproving the fix, then expand to broader regression checks according to the change’s risk, blast radius, and the repository’s conventions. Where available and authorized, run: * targeted reproduction tests; * relevant regression tests; * broader supported tests; * PHP syntax checks; * static analysis; * formatting checks; * route checks; * migration inspection; * other repository-supported verification relevant to the change. For every check, report: * the exact command or method; * the expected result; * the actual result; * the relevant success or failure output. Compare the post-change result with the original symptom and [Verification target]. If a check was not run, state why it was not run and what risk remains. ## 8. Completion integrity Keep the following clearly distinct: * inspected; * changed; * tested; * recommended but not executed; * unavailable; * unverified. Do not claim that work was fixed, refactored, tested, verified, migrated, deployed, rolled back, or observed in production unless that action actually occurred and supporting evidence exists. Code edits alone are not proof of a fix. ## Output contract Include only sections relevant to the work: 1. Objective and authorized scope, including explicit prohibitions. 2. Repository evidence inspected and unavailable evidence. 3. Reproduction or symptom trace, including observations, hypotheses, rejected causes, confirmed root cause, and uncertainty. 4. Minimal change plan and Laravel-specific rationale. 5. Implementation actually performed, files changed, and final-diff review. 6. Verification executed, including each actual command, expected result, actual result, and exact test result. 7. Work recommended but not executed, remaining risks, and unresolved items. 8. Rollback or recovery considerations where consequential changes occurred. 9. Smallest safe next action, including whether deployment occurred and whether production behavior was observed. ## Step 2 — Review the Laravel change and regression risk **Prompt** Evidence-Grounded Laravel Pull Request Review with Codex **Instructions** Review the proposed change against the confirmed failure, Laravel conventions, surrounding behavior, and available test evidence. **Input for this step** Provide the focused diff, root-cause evidence, affected tests, and relevant repository context. **Carry forward** Carry approved changes, required follow-ups, test gaps, and release risks into deployment preparation. **Review note** Do not merge or deploy while a material correctness, authorization, data, or rollback concern remains unresolved. **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 3 — Prepare the controlled deployment and recovery checks **Prompt** CI/CD Deployment Safety Checklist Generator **Instructions** Turn the reviewed change into a repository-specific deployment safety checklist with preflight, verification, observation, and recovery steps. **Input for this step** Provide the approved diff, supported CI/CD tooling, test results, infrastructure constraints, migration impact, and rollback mechanism. **Carry forward** Retain the completed checklist and actual release evidence as the incident closeout record. **Review note** Require explicit deployment authority and stop if prerequisites, backups, rollback readiness, or production verification are missing. **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. ## Completion criteria The root cause is supported by evidence, the smallest authorized correction has been reviewed, relevant checks pass, and deployment or rollback actions are clearly separated from work that was not executed. # Laravel Incident Investigation and Controlled Correction Workflow ID: AMO-W-000001 Workflow URL: https://amo.ng/workflows/laravel-production-incident-investigation Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: Identify an evidence-supported root cause, apply and review the smallest authorized Laravel correction, and prepare deployment and rollback controls. Use the extended Production Incident to Safe Patch and Prevention Plan workflow when formal verification, postmortem, and prevention work are also required. Required inputs: - Incident symptoms and timestamps - Sanitized logs or stack traces - Repository access and the affected route, job, command, or feature - Recent deployment or configuration changes - The actions and environments you are authorized to change ## Step 1 — Diagnose the incident and prepare the smallest correction **Instructions** Use the repository-first Laravel workflow to reproduce or trace the symptom, confirm the root cause, and make only an authorized minimal change. **Input for this step** Provide the symptom, sanitized logs, affected code path, environment details, recent changes, and action boundaries. **Carry forward** Carry the confirmed root cause, changed files, final diff, test evidence, unresolved risks, and unexecuted actions into the review step. **Review note** Confirm that any proposed edits, commands, data operations, or production actions are within the permitted scope. **Prompt** Laravel Bug Fix and Refactor Prompt **Prompt ID** AMO-P-000001 **Prompt URL** https://amo.ng/prompts/laravel-bug-fix-and-refactor-prompt ## Step 2 — Review the Laravel change and regression risk **Instructions** Review the proposed change against the confirmed failure, Laravel conventions, surrounding behavior, and available test evidence. **Input for this step** Provide the focused diff, root-cause evidence, affected tests, and relevant repository context. **Carry forward** Carry approved changes, required follow-ups, test gaps, and release risks into deployment preparation. **Review note** Do not merge or deploy while a material correctness, authorization, data, or rollback concern remains unresolved. **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 3 — Prepare the controlled deployment and recovery checks **Instructions** Turn the reviewed change into a repository-specific deployment safety checklist with preflight, verification, observation, and recovery steps. **Input for this step** Provide the approved diff, supported CI/CD tooling, test results, infrastructure constraints, migration impact, and rollback mechanism. **Carry forward** Retain the completed checklist and actual release evidence as the incident closeout record. **Review note** Require explicit deployment authority and stop if prerequisites, backups, rollback readiness, or production verification are missing. **Prompt** CI/CD Deployment Safety Checklist Generator **Prompt ID** AMO-P-000116 **Prompt URL** https://amo.ng/prompts/ci-cd-deployment-safety-checklist-generator Completion criteria: The root cause is supported by evidence, the smallest authorized correction has been reviewed, relevant checks pass, and deployment or rollback actions are clearly separated from work that was not executed.Copy workflow includes every step and the full linked Prompt content. Use with AI copies a shorter guide with Prompt links; neither action runs the Workflow.
Outcome
Identify an evidence-supported root cause, apply and review the smallest authorized Laravel correction, and prepare deployment and rollback controls. Use the extended Production Incident to Safe Patch and Prevention Plan workflow when formal verification, postmortem, and prevention work are also required.
Before you begin
Have all or some of the following available before you start. The more relevant context you can provide, the stronger the workflow output will be.
- Incident symptoms and timestamps
- Sanitized logs or stack traces
- Repository access and the affected route, job, command, or feature
- Recent deployment or configuration changes
- The actions and environments you are authorized to change
Ordered sequence
Workflow steps
Complete the steps in order. For each step, provide the listed context, carry its result into the next step, and pause wherever a review note is shown.
-
Step 1 Diagnose the incident and prepare the smallest correction
Use the repository-first Laravel workflow to reproduce or trace the symptom, confirm the root cause, and make only an authorized minimal change.
Prompt: Laravel Bug Fix and Refactor PromptInput for this step
Provide the symptom, sanitized logs, affected code path, environment details, recent changes, and action boundaries.
Carry forward
Carry the confirmed root cause, changed files, final diff, test evidence, unresolved risks, and unexecuted actions into the review step.
Review note
Confirm that any proposed edits, commands, data operations, or production actions are within the permitted scope.
-
Step 2 Review the Laravel change and regression risk
Review the proposed change against the confirmed failure, Laravel conventions, surrounding behavior, and available test evidence.
Prompt: Evidence-Grounded Laravel Pull Request Review with CodexInput for this step
Provide the focused diff, root-cause evidence, affected tests, and relevant repository context.
Carry forward
Carry approved changes, required follow-ups, test gaps, and release risks into deployment preparation.
Review note
Do not merge or deploy while a material correctness, authorization, data, or rollback concern remains unresolved.
-
Step 3 Prepare the controlled deployment and recovery checks
Turn the reviewed change into a repository-specific deployment safety checklist with preflight, verification, observation, and recovery steps.
Prompt: CI/CD Deployment Safety Checklist GeneratorInput for this step
Provide the approved diff, supported CI/CD tooling, test results, infrastructure constraints, migration impact, and rollback mechanism.
Carry forward
Retain the completed checklist and actual release evidence as the incident closeout record.
Review note
Require explicit deployment authority and stop if prerequisites, backups, rollback readiness, or production verification are missing.
Completion criteria
The root cause is supported by evidence, the smallest authorized correction has been reviewed, relevant checks pass, and deployment or rollback actions are clearly separated from work that was not executed.
Was this useful?
Related Workflows
Browse WorkflowsRecover a Laravel Payment Checkout Failure Safely
Diagnose and correct a Laravel checkout, webhook, or payment-state failure, build payment-specific test evidence, review security and code risk, and prepare controlled release and rollback gates.
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.
Build and Verify a Tenant-Scoped Paid Booking Slice
Implement one tenant-isolated paid booking journey through identity, availability/reservation, hosted sandbox checkout, payment testing, security review, and release controls.