Amo.ng curated workflow
Laravel Production Incident Investigation
Move from a Laravel production symptom to an evidence-supported correction and a controlled deployment plan.
# Laravel Production Incident Investigation Workflow ID: AMO-W-000001 ## Outcome Identify the likely root cause of a Laravel production incident, apply the smallest justified correction when authorized, and verify the result using repository and runtime evidence. ## 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. **Human checkpoint** Confirm that any proposed edits, commands, data operations, or production actions are within the permitted scope. **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** Safe and Thorough Pull Request Review for Laravel Projects 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. **Human checkpoint** Do not merge or deploy while a material correctness, authorization, data, or rollback concern remains unresolved. **Prompt content** You are an expert Laravel software engineer and code reviewer specializing in safe, precise pull request reviews for SaaS applications. Context: - Goal or task: [Goal or task] - Project context: [Project context] - Relevant files: [Relevant files] - Error message or logs: [Error message or logs] - Current behavior: [Current behavior] - Expected behavior: [Expected behavior] - Constraints: [Constraints] - Environment details without secrets: [Environment details without secrets] - Verification commands: [Verification commands] - Definition of done: [Definition of done] Instructions: 1. Carefully inspect all changed files and related code areas to understand the intended behavior and scope of the pull request. 2. Identify any bugs, security vulnerabilities, regressions, missing or incomplete tests, and gaps in verification coverage. 3. Avoid suggesting broad rewrites or changes unrelated to the pull request scope. 4. Do not expose or request any secrets or sensitive information. 5. Distinguish clearly between blocking issues that must be fixed before merging and non-blocking suggestions. 6. Summarize your findings in a clear, concise review comment, including: - A list of blocking issues with detailed explanations. - Suggestions for improvements or best practices. - Verification checklist items to confirm before merging. 7. End with a clear next steps section advising what actions the developer should take. Output format: Provide your review in markdown format with the following sections: # Pull Request Review Summary ## Blocking Issues - List blocking issues that must be fixed before merging, with clear explanations. ## Suggestions - List non-blocking improvements, best practices, or cleanup recommendations. ## Verification Checklist - List concrete checks, tests, commands, and manual review steps to complete before merging. ## Next Steps - List the recommended actions the developer should take next. Ensure your review is actionable, precise, and respects the constraints above. ## 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. **Human checkpoint** Require explicit deployment authority and stop if prerequisites, backups, rollback readiness, or production verification are missing. **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 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 the likely root cause of a Laravel production incident, apply the smallest justified correction when authorized, and verify the result using repository and runtime evidence. 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. **Human checkpoint** Confirm that any proposed edits, commands, data operations, or production actions are within the permitted scope. **Prompt** Laravel Bug Fix and Refactor Prompt **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. **Human checkpoint** Do not merge or deploy while a material correctness, authorization, data, or rollback concern remains unresolved. **Prompt** Safe and Thorough Pull Request Review for Laravel Projects with Codex **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. **Human checkpoint** Require explicit deployment authority and stop if prerequisites, backups, rollback readiness, or production verification are missing. **Prompt** CI/CD Deployment Safety Checklist Generator **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.Outcome
Identify the likely root cause of a Laravel production incident, apply the smallest justified correction when authorized, and verify the result using repository and runtime evidence.
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
Ordered sequence
Workflow steps
-
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 PromptInvestigate 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.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.
Human checkpoint
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: Safe and Thorough Pull Request Review for Laravel Projects with CodexYou are an expert Laravel software engineer and code reviewer specializing in safe, precise pull request reviews for SaaS applications. Context: - Goal or task: [Goal or task] - Project context: [Project context] - Relevant files: [Relevant files] - Error message or logs: [Error message or logs] - Current behavior: [Current behavior] - Expected behavior: [Expected behavior] - Constraints: [Constraints] - Environment details without secrets: [Environment details without secrets] - Verification commands: [Verification commands] - Definition of done: [Definition of done] Instructions: 1. Carefully inspect all changed files and related code areas to understand the intended behavior and scope of the pull request. 2. Identify any bugs, security vulnerabilities, regressions, missing or incomplete tests, and gaps in verification coverage. 3. Avoid suggesting broad rewrites or changes unrelated to the pull request scope. 4. Do not expose or request any secrets or sensitive information. 5. Distinguish clearly between blocking issues that must be fixed before merging and non-blocking suggestions. 6. Summarize your findings in a clear, concise review comment, including: - A list of blocking issues with detailed explanations. - Suggestions for improvements or best practices. - Verification checklist items to confirm before merging. 7. End with a clear next steps section advising what actions the developer should take. Output format: Provide your review in markdown format with the following sections: # Pull Request Review Summary ## Blocking Issues - List blocking issues that must be fixed before merging, with clear explanations. ## Suggestions - List non-blocking improvements, best practices, or cleanup recommendations. ## Verification Checklist - List concrete checks, tests, commands, and manual review steps to complete before merging. ## Next Steps - List the recommended actions the developer should take next. Ensure your review is actionable, precise, and respects the constraints above.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.
Human checkpoint
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 GeneratorReview 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.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.
Human checkpoint
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.
Related Workflows
Browse WorkflowsProduction 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.
Was this useful?