Amo.ng curated workflow
Recover 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.
# Recover a Laravel Payment Checkout Failure Safely Workflow ID: AMO-W-000020 Workflow URL: https://amo.ng/workflows/laravel-payment-checkout-bug-fix-and-release-readiness-workflow ## Outcome An evidence-backed payment recovery package containing repository boundaries, root cause, the smallest authorized correction, payment-flow test coverage, security and PR findings, and release, rollback, and monitoring conditions. ## Before you begin - Laravel repository context and current repository instructions, if they exist - Checkout, webhook, payment-state, settlement, or entitlement failure evidence - Logs, traces, gateway events, reproduction steps, affected versions, and recent changes - Relevant routes, handlers, jobs, listeners, queues, migrations, configuration, and provider contracts - Existing tests and CI, provider sandbox limits, deployment and rollback process, monitoring, and authorization boundaries ## Step 1 — Confirm repository safety instructions **Prompt** Codex AGENTS.md Safety and Verification Instructions Generator **Instructions** Use this step when current repository instructions do not already define editable paths, protected areas, verification commands, migration and deployment restrictions, and approval gates. Otherwise validate the existing instructions and mark generation Not applicable. **Input for this step** Provide existing AGENTS.md or repository guidance, conventions, allowed and protected paths, test, lint and build commands, deployment restrictions, migration rules, and approval requirements. **Carry forward** Carry the confirmed repository boundaries, commands, protected behavior, and approval gates into payment-failure diagnosis. **Review note** A repository maintainer approves editing boundaries and verification commands before any code change is authorized. **Prompt ID** AMO-P-000080 **Prompt URL** https://amo.ng/prompts/codex-agents-md-project-instructions-generator **Prompt content** Create a copy-ready AGENTS.md that governs how Codex may inspect, modify, verify, and report work in this repository. Project inputs - Project name: [Project name] - Project purpose: [Project purpose] - Repository map: [Repository map] - Tech stack and package managers: [Tech stack and package managers] - Editable paths: [Editable paths] - Protected paths: [Protected paths] - Coding conventions: [Coding conventions] - Verification commands: [Verification commands] - CI, build, deployment, and cache commands: [CI build deployment and cache commands] - Environment and secret-handling rules: [Environment and secret-handling rules] - Known fragile areas: [Known fragile areas] - High-risk operations and approval rules: [High-risk operations and approval rules] - Definition of done: [Definition of done] - Workflow preferences: [Workflow preferences] Input and evidence rules 1. Treat the project name, purpose, repository map, editing boundaries, approval rules, and definition of done as required. A verification command may be unknown, but that unknown must be preserved explicitly. 2. Useful supporting evidence includes an accessible repository tree, an existing AGENTS.md, README files, package manifests and lockfiles, formatter or linter configuration, test configuration, framework configuration, CI workflow files, deployment documentation, and contributor guidance. 3. If Codex has repository access, it may perform read-only inspection of relevant files to ground the draft. It must not edit files, run commands, install dependencies, modify configuration, create commits, open pull requests, deploy, migrate data, clear production caches, rotate credentials, or publish anything while generating this document unless the user separately authorizes that action. 4. Distinguish each instruction or command source as owner-supplied, repository-observed, inferred, or unknown. Repository-observed means the exact value appears in inspected project evidence. Inferred content must be labeled for owner review and must not be presented as established fact. 5. Never expose or reproduce secrets, tokens, private keys, credentials, customer data, or sensitive environment values. Refer only to environment variable names or redacted examples when necessary. 6. Do not invent commands, path permissions, deployment procedures, rollback steps, or approval authority. When a required fact is missing or conflicting, ask a focused clarification question if it blocks a safe boundary. Otherwise, produce a bounded draft with a clearly marked owner decision item. 7. If an existing AGENTS.md is present, do not silently replace its instructions. Compare it with the supplied requirements, identify conflicts and scope differences, and produce a proposed consolidated draft plus a short change summary. 8. Account for AGENTS.md scope: repository-root instructions establish the default, while a more specific AGENTS.md in a descendant directory may refine instructions for that subtree. Do not claim that repository instructions override system, platform, user, security, or organizational policy. Drafting workflow 1. Inspect the supplied evidence and identify the repository architecture, package managers, generated artifacts, test layers, CI entry points, deployment-sensitive files, migration paths, caches, and security boundaries that are actually evidenced. 2. Reconcile editable and protected paths. A protected path takes precedence when lists overlap. Mark ambiguous, missing, generated, vendored, lockfile, schema, infrastructure, credential, and production configuration boundaries for owner review. 3. Convert coding conventions into actionable rules tied to the actual stack, such as formatting, static analysis, dependency policy, framework conventions, database migration practices, backward compatibility, generated-file handling, and test placement. Include only applicable rules. 4. Build a workflow that requires Codex to inspect before editing, state its intended files and approach, keep changes within scope, preserve unrelated work, make the smallest coherent change, and stop when repository state or instructions conflict. 5. Build a command matrix from owner-supplied or repository-observed commands. Separate fast targeted checks from broader tests, linting, static analysis, builds, integration tests, and release checks. Never imply that a command was executed merely because it appears in AGENTS.md. 6. Define approval gates for consequential operations. Deployment, production access, destructive database operations, irreversible migrations, dependency upgrades with broad impact, secret handling, force pushes, history rewrites, cache clearing in shared environments, external communications, and deletion of user or production data must require explicit human authorization when applicable. 7. Define stop conditions and recovery controls. Codex must stop on suspected secret exposure, unexpected destructive output, permission uncertainty, failing preconditions, unrelated repository changes, ambiguous environment targets, unavailable rollback paths, or a verification failure that makes further action unsafe. 8. Define truthful reporting states so future Codex sessions keep proposed, changed, executed, passed, failed, blocked, skipped, unavailable, and unverified work distinct. Required AGENTS.md structure Return the complete file in one Markdown code block using these sections: # Project Instructions State the project purpose, relevant architecture, primary stack, and the evidence basis for the instructions. ## Instruction Scope and Precedence Explain repository-root and descendant-directory scope, conflict handling, and the precedence of system, platform, organizational, security, and explicit user instructions. ## Repository Map Describe important source, test, configuration, generated, vendor, migration, infrastructure, and documentation locations that are supported by evidence. Mark unknown locations rather than guessing. ## Change Authority Matrix Provide a table with columns for path or resource, allowed action, prohibited action, approval required, evidence source, and notes. Cover editable paths, protected paths, generated files, dependencies, database schemas or migrations, CI configuration, deployment configuration, secrets, and production data when applicable. ## Coding and Change Rules Specify stack-relevant conventions, dependency and lockfile policy, generated-file policy, migration compatibility requirements, security expectations, scope control, and treatment of unrelated changes. ## Required Work Sequence Define the inspect, clarify, plan, edit, verify, review, and report sequence. Require Codex to name intended files before editing and to pause when the requested work exceeds authority. ## Verification Matrix Provide a table with columns for change type, exact command, source, execution authority, expected successful observation, failure handling, and unavailable-command fallback. Include targeted tests, broader tests, linting, formatting, static analysis, builds, and relevant CI or release checks only when applicable. Unknown commands must remain explicit owner action items. ## High-Risk and Production Operations List applicable approval gates, environment confirmation requirements, backup or rollback prerequisites, dry-run expectations, monitoring or post-change checks, and stop conditions. State that documentation of a command is not authorization to execute it. ## Security and Data Handling Cover secret redaction, least privilege, sensitive logs, personal or production data, dependency provenance, and incident escalation appropriate to the supplied project. ## Definition of Done Translate the supplied definition into observable acceptance criteria. Require scope reconciliation, applicable verification evidence, documentation updates where needed, no unauthorized protected-path changes, and disclosure of unresolved failures or skipped checks. ## Completion Report Contract Require future Codex sessions to report changed files, concise change summary, commands actually executed, actual outcomes, checks not run and why, assumptions, residual risks, approval-dependent actions, and recommended human follow-up. Prohibit claims such as fixed, tested, verified, approved, deployed, rolled back, or completed unless the corresponding action occurred and evidence is available. After the code block, provide these companion sections: ## Evidence and Decision Register Use a table with columns for item, classification, source, confidence, conflict or gap, and owner action. Classifications must distinguish supplied fact, repository observation, inference, unknown, and conflict. ## Owner Review Checklist Include concrete checks for path scope, command accuracy, nested AGENTS.md behavior, secret safety, approval ownership, destructive operations, rollback readiness, verification expectations, and definition-of-done acceptance. ## Proposed Change Summary If an existing AGENTS.md was inspected, summarize retained, changed, added, and unresolved instructions. Otherwise state that this is a new proposed file. Final validation - Confirm every project-specific statement is traceable to supplied or inspected evidence, or is labeled as an inference or unknown. - Confirm protected paths override editable paths where they overlap. - Confirm every command is exact and sourced, or explicitly unknown. - Confirm command documentation and command execution authority are separate. - Confirm consequential actions require the stated human approval and applicable recovery controls. - Confirm no secret values or sensitive data are included. - Confirm acceptance criteria are observable and unresolved states remain visible. - Confirm no execution, test, approval, deployment, rollback, or completion claim is made without actual evidence. - Confirm the AGENTS.md is internally consistent and copy-ready, while remaining a proposal until the project owner reviews and installs it. ## Step 2 — Diagnose the checkout or webhook failure **Prompt** Codex Prompt for Safely Diagnosing and Fixing Laravel Payment Checkout Bugs **Instructions** Reproduce or bound the Laravel payment failure using evidence for signatures, idempotency, retries, ordering, payment-state integrity, queues, and gateway compatibility. If edits are authorized, constrain the correction to the smallest responsible change. **Input for this step** Provide repository guidance, failure description, logs, traces, gateway payloads, affected code, environment constraints, and explicit authorization for read-only diagnosis or code changes. **Carry forward** Carry root-cause evidence, competing hypotheses, the proposed or authorized correction, touched files, unresolved risks, and verification needs into payment test planning. **Review note** The engineering owner approves the correction scope before implementation or any expansion beyond the minimal fix. **Prompt ID** AMO-P-000068 **Prompt URL** https://amo.ng/prompts/codex-fix-laravel-payment-checkout-bugs-safely **Prompt content** Laravel payment incident inputs - Project and incident context: [Project and incident context] - Relevant code and sanitized non-secret configuration: [Relevant code and sanitized non-secret configuration] - Sanitized logs and event evidence: [Sanitized logs and event evidence] - Observed and expected behavior: [Observed and expected behavior] - Gateway contract and event model: [Gateway contract and event model] - Constraints and authority: [Constraints and authority] - Verification environment and commands: [Verification environment and commands] - Acceptance criteria: [Acceptance criteria] Codex operating rules Use only the repository files, snippets, logs, documentation, commands, and workspace capabilities actually available in this session. Do not imply that Codex accessed a repository, payment-provider dashboard, external API, database, queue, log service, network, or test runner unless that access occurred and the resulting evidence can be cited. Inspect the repository and relevant files before proposing or making changes. Unless [Constraints and authority] explicitly restricts it, permit read-only repository inspection and non-mutating diagnostics. Treat file edits, mutating commands, dependency changes, database writes or migrations, cache or queue changes, external-service calls, deployment, production access, and financially consequential actions as unauthorized unless expressly approved. When editing is not authorized, provide a proposed diff only from repository content or code snippets Codex actually inspected. When repository access is unavailable but relevant snippets were supplied, label any patch illustrative and unverified against the complete codebase. When the available source is insufficient, provide a bounded change plan rather than inventing an exact patch. Do not deploy, rotate credentials, alter production configuration or data, replay live webhooks, retry or capture payments, issue refunds, contact a provider, or trigger any financially consequential operation within this prompt. Record such work as a separate human-controlled handoff. Treat secrets, complete payment tokens, authorization headers, signing secrets, personal data, and full customer records as prohibited input and output. If encountered, do not reproduce them; identify the location generically and request redacted evidence. Do not add sensitive payload logging as a diagnostic shortcut. Input sufficiency and conflicts 1. Inventory the supplied inputs and identify the Laravel version, PHP version, payment gateway or gateways, checkout path, webhook route, relevant event types, persistence model, queue behavior, and incident scope only when supported by evidence. 2. If a blocking item is absent, ambiguous, or contradictory, ask one consolidated set of focused questions before diagnosing or editing. Blocking items include the failing flow, relevant route and handler code, a sanitized error or event trace, expected gateway behavior, and change authority. 3. Record non-blocking gaps as unknowns and continue only when a bounded analysis is possible. Do not fill gaps with typical Laravel or gateway behavior. 4. When code, logs, tests, and stated behavior conflict, show the conflict and give precedence only after explaining why one source is more direct or current. Do not silently reconcile incompatible evidence. Evidence discipline Maintain these distinctions throughout the work: - Supplied fact: a statement or artifact provided by the user. - Observation: something directly found in an available file, log, diff, or command result. - Hypothesis: a testable explanation that has not yet been established. - Assumption: a temporary premise needed to proceed and clearly marked as such. - Unknown: information not available or not determinable. - Unsupported claim: a conclusion lacking sufficient evidence; do not use it as the basis for a fix. Cite observations with available file paths and symbols, sanitized log timestamps or correlation identifiers, gateway documentation supplied in the session, or exact commands and relevant output. Never claim that a defect is reproduced, fixed, tested, compatible, or verified solely because a patch appears plausible. Payment-specific diagnosis Trace the failing path from checkout creation through provider interaction, redirect or callback handling, webhook receipt, payment-state persistence, queued work, and user-visible state. Limit the trace to components supported by the supplied artifacts. Evaluate applicable failure modes without assuming any is present: - Route registration, HTTP method, middleware, CSRF exclusions, authentication, rate limiting, and request-body mutation. - Webhook signature verification against the raw payload, required headers, timestamp tolerance, secret selection, and replay protection according to the supplied gateway contract. - The distinction between browser redirect success and authoritative server-side payment confirmation. - Event identity, checkout or payment identity, idempotency keys, duplicate deliveries, retry behavior, unique constraints, and whether repeated processing can duplicate transitions or side effects. - Transaction boundaries, locking, queue dispatch timing, partial writes, worker retries, timeouts, and acknowledgement behavior. - Out-of-order, delayed, stale, or conflicting events and whether state transitions can regress a terminal payment state. - Amount, currency, account, customer, order, metadata, and environment correlation before changing local payment state. - Sandbox versus live configuration, endpoint mismatch, gateway-version differences, and multi-gateway routing without exposing credentials. - Exception handling and HTTP responses that could cause lost events, retry storms, premature acknowledgement, or sensitive logging. - Checkout races, abandoned sessions, asynchronous confirmation, inventory or entitlement side effects, and recovery or reconciliation paths. For each credible hypothesis, state the supporting evidence, contradicting evidence, a qualitative confidence statement justified by that evidence, and the smallest discriminating check. Select a root cause only when evidence supports the causal chain. Otherwise report ranked hypotheses and the missing evidence needed to decide. Minimal safe change If code changes are authorized and the cause is sufficiently supported: 1. Define the payment invariant the change must restore, such as one durable business transition per gateway event or no transition before authenticated event validation. 2. Implement the smallest localized change consistent with the supplied Laravel and gateway versions. Preserve unrelated checkout paths and gateway adapters. 3. Avoid broad rewrites, speculative dependency upgrades, credential changes, destructive migrations, and production-only workarounds. 4. For schema or constraint changes, provide migration, rollback, collision-handling, and existing-data considerations. Do not execute destructive or production migrations. 5. Add or update focused tests where the available project structure permits. Do not weaken assertions or delete failing tests merely to obtain a passing result. 6. Show the exact diff or proposed patch. Label it executed only if files were actually modified; otherwise label it proposed. Payment verification matrix Derive checks from the supplied gateway contract and acceptance criteria. Include the applicable cases below, and mark inapplicable or unavailable cases with reasons: - Checkout creation and expected local initial state. - Valid authenticated webhook and intended state transition. - Invalid signature, malformed payload, missing header, or expired timestamp rejection. - Duplicate delivery of the same event without duplicate state changes or side effects. - Transient handler or queue failure followed by a safe retry. - Delayed or out-of-order event without improper state regression. - Amount, currency, order, account, and environment mismatch handling. - Database transaction or uniqueness behavior under repeated processing. - Existing gateway and non-payment regression tests relevant to modified code. - Syntax, static analysis, formatting, and targeted Laravel test commands supplied or discoverable in the available project. For every check, report the command or inspection method, expected observation, actual observation, and evidence. A command not run is unavailable or not executed, never passed. A test failure must remain visible. If execution is unavailable, provide exact proposed commands and expected acceptance signals without fabricating output. Compatibility with an existing gateway may be called verified only when relevant evidence was reviewed and applicable tests passed; otherwise call it assessed or unverified. Output contract: Laravel payment-fix deliverable Return the following task-specific sections: Keep every section concise and proportional to the work actually performed. Where a section is not applicable or an action was not executed, state that explicitly rather than filling it with generic content. Never omit the authority, evidence, verification, or completion-declaration sections. 1. Incident scope and authority - Failing checkout or webhook path - In-scope gateway, events, files, and environment - Permitted actions, prohibited actions, and required human approvals 2. Evidence ledger - Each supplied fact or observation - Source location or sanitized identifier - Conflicts, assumptions, and unknowns 3. Failure-path reconstruction - Ordered request, event, queue, and persistence sequence - First evidenced divergence from expected behavior 4. Root-cause verdict - Supported root cause and confidence, or ranked hypotheses if unresolved - Supporting and contradicting evidence - Affected payment invariant and failure modes 5. Change record - Files actually modified and concise diff summary - Proposed but unapplied changes in a separate list - Schema, rollback, idempotency, retry, state-transition, and gateway-compatibility effects 6. Verification matrix - Check, expected observation, actual observation, evidence, and status - Use only passed, failed, unavailable, not executed, or not applicable as statuses 7. Residual risk and recovery handoff - Remaining unknowns and unverified gateway paths - Safe rollback or disablement approach - Any reconciliation, replay, production validation, or provider action requiring human approval 8. Completion declaration - Requested work - Proposed work - Executed work with evidence - Unavailable work and reason - Unverified work - Acceptance criteria met and not met Do not state that the Laravel payment issue is fixed or complete unless the authorized change was applied, the relevant verification ran successfully, and every required acceptance criterion has supporting evidence. ## Step 3 — Design payment-flow regression evidence **Prompt** Laravel Payment Flow Smoke Test and Edge Case Planner **Instructions** Define checkout, signed webhook, idempotency, retry, ordering, refund, entitlement, subscription, and manual-review tests without implying execution unless results are supplied. **Input for this step** Provide the diagnosis, proposed or actual changes, gateway behavior, payment states, webhook samples, existing tests, sandbox boundaries, and acceptance needs. **Carry forward** Carry the test matrix, edge cases, replay controls, environment boundaries, expected results, and evidence gaps into security review. **Prompt ID** AMO-P-000182 **Prompt URL** https://amo.ng/prompts/laravel-payment-flow-smoke-test-edge-case-planner **Prompt content** Use Codex to inspect the supplied Laravel repository and prepare a payment-flow smoke-test and edge-case plan. This is a planning and verification task by default. It is not permission to edit files, execute migrations, contact a payment provider, create charges, issue refunds, replay live webhooks, mutate production data, or claim that testing succeeded. ## Inputs - Payment provider, environment, and lifecycle: [Payment provider and flow] - Checkout, callback, and webhook endpoints: [Checkout and webhook routes] - Payment, order, invoice, subscription, and entitlement records: [Payment, order, or subscription models] - Required business-state behavior: [Success, failure, refund, and manual review rules] - Delivery, concurrency, and replay concerns: [Idempotency, retry, and duplicate event concerns] - Existing local tests, fakes, mocks, and provider-sandbox facilities: [Existing tests and sandbox or fake setup] - Permitted inspection, edits, commands, environments, and data operations: [Execution boundaries and verification commands] ## Scope, authority, and evidence rules Unless [Execution boundaries and verification commands] explicitly restricts it, permit: - read-only repository inspection; - review of supplied documentation and sanitized logs; - non-mutating local diagnostics. Treat the following as unauthorized unless expressly approved: - file edits; - mutating commands; - dependency changes; - database writes or migrations; - cache or queue mutations; - provider API calls; - provider-sandbox actions; - production access; - webhook replay; - real charges, captures, cancellations, disputes, or refunds; - customer notifications or entitlement changes. Do not interrupt ordinary read-only inspection by repeatedly narrating permission checks. Verify authority before any edit, mutating command, external call, database action, or financially consequential activity. Use only repository files, snippets, documentation, logs, command results, and workspace capabilities actually available in the current session. Do not imply access to a provider dashboard, network, database, queue, logs platform, sandbox, test runner, or production system unless that access exists and the resulting evidence can be identified. Never request or reproduce: - live credentials; - signing secrets; - access tokens; - authorization headers; - raw cardholder data; - complete payment tokens; - real customer payment methods; - full customer payment records; - unnecessary personal information. Use synthetic customers, provider test identifiers, redacted configuration descriptions, safe fixtures, Laravel fakes, mocks, and approved provider test facilities. If a blocking input is missing, ask one consolidated set of focused questions. Blocking inputs include: - the provider and environment; - the authoritative payment-confirmation mechanism; - relevant checkout and webhook code; - the supported lifecycle states; - material business rules; - the test boundary; - execution authority. A partial plan may still be produced for supported areas, but affected conclusions must be marked blocked or unverified. When user descriptions, code, tests, migrations, configuration, logs, and provider documentation conflict: 1. Preserve the conflicting statements. 2. Identify their sources. 3. Explain the financial, state, entitlement, or authorization consequence. 4. Identify the evidence or owner needed to reconcile them. 5. Do not silently select one version. Use these work states consistently: - **Observed** — directly found in an accessible repository file, configuration, migration, test, log, or command result. - **Supplied** — provided by the user but not independently reproduced by Codex. - **Proposed** — recommended but not executed. - **Executed** — actually performed in the current session with recorded evidence. - **Unavailable** — the required source, capability, or environment could not be accessed. - **Unverified** — plausible but not established by sufficient evidence. - **Conflicting** — available sources disagree. - **Not applicable** — excluded for a payment-flow-specific reason. Never claim that a defect was reproduced or fixed, that a test passed, that a payment was verified, that a refund occurred, or that provider or production behavior is safe without direct evidence for that exact statement. ## Review workflow ### 1. Establish the authoritative payment lifecycle Map the observed flow from the first checkout request through payment confirmation and downstream effects. Identify, where applicable: - checkout route and controller; - request validation and authorization; - server-side product, price, amount, currency, quantity, tax, and discount calculation; - provider adapter or SDK call; - checkout session, payment intent, charge, subscription, invoice, customer, refund, and event identifiers; - internal order, payment, subscription, invoice, and entitlement references; - browser success and cancellation returns; - synchronous provider responses; - webhook receipt and verification; - queued processing; - local state changes; - fulfillment; - entitlement changes; - customer notifications; - reconciliation and manual-review paths. Determine the authoritative source of payment confirmation. Do not treat a browser redirect, success page, client-supplied value, or local pending record as proof of payment unless the supplied application and provider contract explicitly establish that behavior. Record only lifecycle states supported by the repository or supplied rules, such as: - pending; - processing; - paid; - failed; - canceled; - expired; - refunded; - partially refunded; - disputed; - manual review. Identify which transitions are legal and which states are terminal. Flag any path that allows a stale or lower-authority event to regress a terminal successful state. ### 2. Review checkout trust and duplicate prevention Inspect applicable controls for: - authentication and authorization; - request validation; - server-side price and product lookup; - client-value distrust; - provider request construction; - idempotency-key creation and reuse; - internal order or payment reference uniqueness; - repeated form submission; - browser refresh and retry; - abandoned checkout; - simultaneous requests; - repeated provider-object creation. Determine whether duplicate requests can create duplicate: - provider payment objects; - internal orders; - invoices; - fulfillment; - customer notifications; - entitlements; - ledger entries. An application-level “record exists” check is not sufficient evidence of concurrency safety unless it is supported by an atomic operation, unique constraint, lock, compare-and-set transition, or equivalent durable control. ### 3. Review webhook authenticity, correlation, and replay safety Inspect: - raw request-body preservation; - signature or SDK verification; - signing-secret selection; - required headers; - timestamp tolerance; - replay handling; - malformed and oversized payload handling; - unsupported event behavior; - test versus live environment separation. Confirm that an accepted event is correlated to the expected: - provider account and environment; - event ID; - payment, checkout, charge, invoice, subscription, or refund object; - internal order or payment reference; - customer; - amount; - currency; - product or plan; - expected prior state. Identify the durable deduplication mechanism, such as: - a unique provider-event constraint; - a processed-events table; - an atomic insert; - row locking; - a compare-and-set update; - a transactional state transition. Trace duplicate, delayed, replayed, stale, and out-of-order events. Confirm that repeated or reordered processing cannot duplicate or incorrectly reverse: - payment state; - fulfillment; - invoices; - notifications; - entitlement grants or revocations; - subscription transitions; - refunds. Assess acknowledgement behavior. Determine when the handler returns success, how transient failures differ from permanent failures, and how provider retries interact with local transactions and queues. ### 4. Review transaction, queue, and side-effect boundaries Identify: - database transactions; - row locks; - unique constraints; - optimistic state checks; - after-commit dispatch; - queued listeners and jobs; - retry counts and backoff; - timeouts; - failed-job handling; - partial-failure windows. For every externally visible side effect, determine: - what triggers it; - whether it occurs before or after durable state change; - whether retry can repeat it; - what idempotency guard exists; - how failure is reconciled. Inspect failure windows between: - provider confirmation and local persistence; - local persistence and entitlement grant; - state change and job dispatch; - transaction commit and notification; - webhook receipt and durable event recording. ### 5. Review refunds, subscriptions, entitlements, and manual review Where applicable, inspect: #### Refunds - authorization; - requested, pending, succeeded, failed, partial, and reversed states; - maximum refundable amount; - currency; - duplicate refund prevention; - provider and local reconciliation; - order and entitlement consequences; - audit evidence; - customer communication. #### Subscriptions - plan eligibility; - upgrade and downgrade rules; - billing-cycle anchors; - proration assumptions; - invoice state; - trial effects; - failed payment; - scheduled changes; - webhook ordering; - recovery behavior. #### Entitlements Confirm that access grant, change, suspension, and revocation: - derive from documented payment or subscription states; - are idempotent; - cannot occur twice from a duplicate event; - cannot be lost after a partial failure; - reconcile with refunds and subscription changes. #### Manual review Inspect: - entry criteria; - authorized roles or policies; - approval and rejection transitions; - reason capture; - audit records; - stale reviews; - duplicate actions; - segregation of duties where required; - customer communication. ### 6. Define financial and entitlement invariants Create evidence-linked invariants for the observed flow. Applicable examples include: - one logical checkout produces no more than one intended provider payment object; - only authenticated, correlated provider evidence can authorize a successful local payment transition; - accepted amount, currency, customer, account, product, plan, and internal reference match expectations; - one provider event produces no more than one durable business transition; - a duplicate or retried event cannot repeat fulfillment, invoice creation, notification, refund, or entitlement mutation; - stale or out-of-order events cannot regress a valid terminal state; - failed or canceled payment cannot grant paid access; - refund amount cannot exceed the supported refundable balance; - manual decisions require the documented authority; - retries and partial failures remain reconcilable. Do not assume every example applies. Add only invariants supported by the flow or necessary to prevent a credible failure. ## Test architecture Separate the test plan into three evidence levels. ### A. Minimal smoke suite Design a small, fast, deterministic suite that answers whether the application’s most critical payment paths still work. Include only the highest-value applicable cases, normally: - checkout creation with correct local initial state; - valid authoritative confirmation and intended state transition; - invalid or unauthenticated webhook rejection; - duplicate event without duplicate business effects; - failed or canceled payment without paid entitlement; - one critical refund, subscription, or manual-review path where relevant. The smoke suite should be suitable for frequent local or CI execution and should not require live credentials or real financial actions. ### B. Edge-case and regression suite Design broader coverage for applicable risks such as: - stale signature; - malformed payload; - unsupported event; - duplicate internal reference; - amount or currency mismatch; - wrong account or customer; - delayed and out-of-order events; - simultaneous processing; - transaction rollback; - queue retry after partial failure; - notification retry; - abandoned checkout; - unauthorized manual action; - refund failure; - partial refund; - upgrade, downgrade, proration, invoice, and entitlement transitions. Do not force irrelevant cases into the suite merely to increase coverage. ### C. Provider-sandbox checks Use provider-sandbox checks only where local fakes and integration tests cannot establish the required behavior. A sandbox call is still an external, state-changing action and requires explicit authorization. For every sandbox check define: - purpose; - test account and environment; - synthetic input; - prohibited data and actions; - exact steps; - expected provider evidence; - expected Laravel evidence; - cleanup; - approval owner; - limitation. A local fake does not prove provider behavior. A provider-sandbox result does not prove production behavior. ## Test-design rules Prefer Laravel feature or integration tests for: - routes; - middleware; - authorization; - database state; - transactions; - queues; - events; - notifications; - webhooks; - end-to-end local state transitions. Use unit tests for isolated mappings, validators, or state-transition logic. Use Laravel fakes only where they preserve the behavior being tested. State when a fake bypasses: - real signature verification; - SDK serialization; - network transport; - database transactions; - queue serialization; - provider retries. Use synthetic fixtures and test-mode provider identifiers. Do not weaken assertions, suppress failures, delete tests, or replace meaningful integration coverage with mocks merely to obtain a passing suite. ## Risk labels Use these qualitative labels: - **Critical** — credible risk of unauthorized or duplicate money movement, unrecoverable financial-state corruption, widespread incorrect entitlement, exposed payment secrets, or a state from which safe reconciliation is not possible. - **High** — material risk involving authentication, idempotency, ordering, amount or currency integrity, refunds, subscriptions, entitlements, authorization, or repeated customer-facing side effects. - **Medium** — a meaningful but bounded weakness requiring additional tests, controls, monitoring, or human review. - **Low** — evidence supports limited impact and adequate controls within the stated test scope. - **Unknown** — evidence is insufficient to classify the risk defensibly. Do not classify a risk Low merely because an existing test passes or a familiar provider SDK is used. ## Verification rules Derive commands from the accessible repository’s: - Composer scripts; - test configuration; - CI workflow; - project documentation; - existing test layout. Do not invent runnable commands. Begin with the smallest targeted checks, then expand according to the affected flow and blast radius. For every command or procedure report: - purpose; - work state; - authorization basis; - target environment; - data boundary; - exact command or method; - expected observation; - actual exit status and relevant output only when executed; - failure meaning; - what the result cannot prove. Do not run destructive migrations, resets, real provider calls, production webhooks, queue purges, live refunds, or real charges. ## Required deliverable Keep the deliverable concise and proportional to the observed payment flow and evidence. Use `Not applicable` with an evidence-based reason instead of filling unsupported sections with generic content. ### A. Scope, evidence, and conflict register Provide: - files and sources inspected; - unavailable evidence; - missing inputs; - conflicts; - assumptions; - execution permissions; - blocked decisions. ### B. Payment lifecycle and authority map Provide a table containing: - lifecycle stage; - initiating route or event; - Laravel handler; - provider object or event; - internal record and state; - transaction or queue boundary; - business side effect; - authoritative confirmation source; - evidence; - uncertainty. ### C. Financial and entitlement invariant register Provide: - invariant ID; - protected asset or outcome; - current enforcement evidence; - credible failure mode; - risk; - required assertion; - remaining gap. ### D. Webhook trust, ordering, and idempotency review Provide: - scenario; - authenticity requirement; - correlation checks; - deduplication control; - ordering rule; - transaction boundary; - expected acknowledgement or retry behavior; - protected side effects; - evidence; - gap. ### E. Minimal smoke suite For each test provide: - priority; - suggested test name; - Laravel test level; - setup and fixtures; - stimulus; - expected payment and business state; - database assertions; - queue, event, or notification assertions; - negative assertions; - risk covered; - acceptance criterion. ### F. Edge-case and regression backlog Group applicable tests under: - checkout; - webhook authenticity; - replay and ordering; - retries and concurrency; - refunds; - subscriptions and entitlements; - manual review; - notifications and reconciliation. Distinguish essential release coverage from lower-priority hardening. ### G. Verification and provider-sandbox runbook Separate: - authorized local commands; - proposed but unexecuted commands; - provider-sandbox checks; - human review; - production checks that remain out of scope. Record actual results only where execution evidence exists. ### H. Risk-ranked implementation sequence Order: 1. characterization or missing baseline tests; 2. high-risk smoke coverage; 3. schema or uniqueness requirements; 4. idempotency and state-transition controls; 5. side-effect isolation; 6. edge-case regression tests; 7. provider-sandbox checks; 8. broader regression execution. Identify every step requiring: - file-edit approval; - migration review; - provider access; - financial approval; - security review; - production change control. ### I. Evidence and readiness record List every statement that could imply: - tests passed; - a defect was fixed; - provider behavior was verified; - financial action occurred; - production is safe. For each statement report: - status; - supporting evidence; - limitation. End with exactly one readiness status: - **Blocked** — a critical lifecycle, evidence, authorization, or test-boundary gap prevents a reliable plan. - **Ready for test-plan review** — the proposed coverage is coherent and ready for human review, but implementation or execution is not yet authorized. - **Ready for authorized local test implementation or execution** — repository evidence and boundaries are sufficient for the specified local work to be considered by an authorized human. - **Ready to request authorized provider-sandbox verification** — local evidence is complete for the stated scope and the remaining provider-specific checks are clearly defined. None of these statuses means that tests passed, provider behavior was verified, production is safe, or financial action is authorized. ## Final acceptance gate Before returning the plan, confirm that: 1. Every material payment state and business side effect is linked to repository or supplied-rule evidence. 2. The authoritative payment-confirmation source is identified. 3. Checkout does not trust client-supplied financial values without server-side validation. 4. Webhook authenticity, correlation, duplicate delivery, replay, delay, ordering, retries, and concurrency are covered where applicable. 5. Partial failures cannot silently duplicate or lose critical financial or entitlement effects. 6. The smoke suite remains minimal, fast, and focused on critical invariants. 7. Broader edge cases are separated into a prioritized regression backlog. 8. Local fake, provider-sandbox, and production evidence are not conflated. 9. Commands are repository-supported and have explicit safety boundaries. 10. No live credentials, real customer payment methods, or raw restricted data are required. 11. Conflicts, unavailable evidence, and human approval requirements are explicit. 12. No testing, fix, provider, production, refund, charge, deployment, or safety claim exceeds the evidence actually obtained. ## Step 4 — Review payment-code security risk **Prompt** Evidence-Based Code Security Review Prompt **Instructions** Review affected code and proposed or actual changes for authentication, authorization, injection, unsafe input, signature validation, secret exposure, data integrity, and release-blocking security risk. **Input for this step** Provide the diff or correction plan, routes and handlers, webhook verification, authorization, validation, secret and configuration handling, and test plan. **Carry forward** Carry evidence-linked security findings, severity, locations, required corrections, and residual risk into pull-request review. **Review note** The security reviewer and engineering owner disposition material security findings before merge readiness is assessed. **Prompt ID** AMO-P-000006 **Prompt URL** https://amo.ng/prompts/security-review-prompt **Prompt content** Conduct a code-level security review in Codex using the following inputs. Review objective: [Review objective] Repository materials: [Repository materials] System context: [System context] Security requirements: [Security requirements] Execution permissions: [Execution permissions] Validation commands: [Validation commands] Definition of done: [Definition of done] Input and access rules - Treat the review objective and inspectable repository materials as minimum prerequisites. The materials should include the relevant source files or repository, dependency manifests and lockfiles, configuration examples, database or API boundaries, and tests when available. - System architecture, trust boundaries, data classifications, deployment configuration, known threats, prior findings, and applicable security requirements are useful context. Mark them unknown when they are not supplied. - If no relevant code or configuration is accessible, stop the code-level assessment. Return a blocking-input list and review plan rather than security conclusions. - Ask a clarification question only when an ambiguity prevents safe scoping, severity assignment, or interpretation of an access-control rule. Otherwise, proceed with a bounded review and record the limitation. - If supplied materials conflict, identify the conflict, cite both sources, and do not silently choose one. Codex operating boundaries - Use Codex to inspect only the files and repository context actually available in the session. Do not imply access to services, branches, secrets, logs, infrastructure, tickets, or production environments that Codex cannot access. - Read and analyze within the granted scope. Run only the validation commands explicitly authorized by the execution permissions and only in an approved non-production environment. - Do not deploy, merge, commit, push, rotate or reveal secrets, alter accounts or permissions, modify production data, contact third parties, or approve a release. - Do not perform destructive tests, denial-of-service tests, credential attacks, persistence, data exfiltration, or exploitation beyond the minimum safe proof needed to establish a finding. Stop if a command could expose sensitive data, affect production, cross an authorization boundary, or cause irreversible changes. - Redact credentials, tokens, personal data, private keys, and sensitive business data from the report. Refer to secret locations without reproducing secret values. - Code changes are proposals unless the execution permissions explicitly authorize edits. Before any authorized edit, describe the files affected, security intent, compatibility risk, validation plan, and rollback method. Keep human approval as the gate for consequential changes and release decisions. Evidence model Maintain these distinctions throughout the review: - Supplied fact: context stated by the user but not independently demonstrated in the available materials. - Observation: behavior or code directly visible in an accessible file, with file path and line or symbol reference. - Execution evidence: a command actually run in this session, including command, environment, exit status, and relevant redacted output. - Assumption: a bounded interpretation required to continue. - Hypothesis: a plausible security issue that still requires evidence. - Unknown: information unavailable from the supplied scope. - Conflict: incompatible evidence or requirements that require reconciliation. Never present a hypothesis, scanner alert, pattern match, or dependency advisory as a confirmed exploitable vulnerability without tracing the relevant data flow, control flow, configuration, affected version, or reachable call path. State when line numbers are approximate or generated files reduce traceability. Review procedure 1. Establish scope and attack surface - Inventory the inspected files, languages, frameworks, dependency manifests, externally reachable endpoints, background jobs, administrative functions, file-processing paths, data stores, and third-party integrations visible in scope. - Map trust boundaries and principal types such as anonymous users, authenticated users, tenants, administrators, services, and webhook senders. - Record excluded components and explain how each exclusion limits assurance. 2. Trace identity and session controls - Inspect login, registration, password reset, account recovery, multifactor flows, API-key handling, token creation and validation, session rotation, logout invalidation, cookie attributes, token expiry, and replay resistance where present. - Check for authentication bypasses, user enumeration, insecure default credentials, weak token validation, confused identity sources, and inconsistent enforcement between web, API, job, and internal routes. 3. Test authorization logic by resource and action - Trace how each sensitive endpoint or operation establishes the acting principal, requested resource, tenant ownership, role, and permitted action. - Look for missing object-level and function-level authorization, insecure direct object references, tenant-boundary failures, privilege escalation, mass assignment, hidden-field trust, administrative route exposure, and checks performed only in the client. - Distinguish authentication from authorization; the presence of a logged-in user is not evidence that access is permitted. 4. Follow untrusted input to security-sensitive sinks - Identify request fields, headers, cookies, uploaded files, webhook payloads, queue messages, imported records, and third-party responses that cross trust boundaries. - Trace validation, normalization, canonicalization, encoding, and type enforcement to SQL, NoSQL, shell, template, HTML, URL fetch, deserialization, logging, filesystem, redirect, and dynamic evaluation sinks. - Evaluate injection, cross-site scripting, server-side request forgery, path traversal, open redirect, request smuggling assumptions, unsafe deserialization, command execution, and log-forging risks as applicable to the actual stack. - Prefer parameterization and context-specific output encoding. Do not treat blocklists or client-side validation as sufficient controls. 5. Review secrets, cryptography, and sensitive data handling - Check source, configuration, fixtures, logs, error paths, build files, and client bundles for embedded credentials or unintended sensitive-data disclosure without reproducing any discovered value. - Inspect key and token storage, randomness, password hashing, encryption modes, signature verification, certificate validation, key separation, rotation support, and fail-open behavior where relevant. - Verify that sensitive fields are minimized and protected in logs, caches, analytics, backups, URLs, error messages, and API responses. 6. Review database, file, and network boundaries - Inspect query construction, row or tenant scoping, transaction boundaries, race conditions, unsafe raw queries, and excessive database privileges visible in configuration. - For uploads and downloads, check filename canonicalization, extension and content validation, size limits, storage location, execution permissions, archive extraction, access checks, content disposition, malware-scanning hooks, and cleanup behavior. - For outbound requests and webhooks, inspect destination allowlisting, redirect handling, DNS and private-network protections, timeouts, response limits, signature validation, replay controls, and error handling. 7. Review security configuration and dependency exposure - Examine debug modes, verbose errors, CORS, CSRF protections, security headers, cookie settings, rate limits, proxy trust, environment separation, default routes, feature flags, and fail-open defaults. - Compare dependency versions against supplied lockfiles and available advisory evidence. Account for reachability, affected version ranges, mitigations, and uncertainty; do not infer compromise from version presence alone. 8. Analyze abuse cases and operational failure modes - Consider brute force, replay, duplicate requests, concurrency, stale authorization, cache confusion, race conditions, partial failures, retries, queue redelivery, oversized inputs, malformed encodings, and cross-tenant access. - Identify controls that exist but can be bypassed through alternate endpoints, asynchronous workers, internal APIs, legacy paths, or inconsistent middleware ordering. 9. Triage and recommend remediation - Assign each confirmed finding a unique identifier and severity of Critical, High, Medium, Low, or Informational. - Explain severity using exploit preconditions, required privileges, reachability, affected assets, confidentiality/integrity/availability impact, tenant or user scope, detectability, and compensating controls. If these factors are unknown, lower confidence rather than inventing them. - Separate confirmed findings from hypotheses and hardening opportunities. Avoid duplicate findings that share one root cause. - Propose the smallest robust fix at the correct enforcement layer. Include compatibility, migration, performance, usability, observability, and rollback considerations. 10. Verify safely - For each finding, define a reproducible validation procedure with prerequisites, a benign test input or unit/integration test design, expected secure behavior, expected vulnerable behavior when safe to describe, and required evidence. - Run a procedure only when access and execution permissions allow it. Record the exact command, environment, exit status, and redacted result. Otherwise mark it Not run and state why. - Include positive tests, negative tests, authorization tests across relevant roles or tenants, regression tests for the root cause, and checks that the remediation does not create a fail-open path. - Reconcile static observations with execution results. Preserve discrepancies as unresolved instead of choosing the preferred result. 11. Determine handoff state - Identify release blockers, accepted residual risks requiring owner approval, unresolved hypotheses, missing evidence, and dependencies on infrastructure or operational controls outside the repository. - Recommend one of: Hold for remediation, Conditional review required, or No release-blocking issue identified in reviewed scope. The last state is not a declaration that the system is secure. - A human security or engineering owner must approve remediation, risk acceptance, and release decisions. Required deliverable A. Scope and assurance statement - Review objective and definition of done - Materials inspected, including commit or revision when available - Components, environments, and threat actors considered - Exclusions, unknowns, conflicts, assumptions, and their effect on assurance - Commands authorized, commands executed, and tools or data unavailable B. Attack-surface and control map Provide a table with: component or entry point; principal; trust boundary; sensitive asset or operation; authentication control; authorization control; untrusted inputs; sensitive sinks; relevant security requirement; evidence reference. C. Confirmed finding register For every confirmed finding provide: - Finding ID and concise title - Severity and confidence - Affected component, file path, line or symbol, endpoint or operation - Security property violated and plausible abuse scenario - Preconditions, required privileges, reachability, and affected scope - Evidence trace from source to control or sink - Existing and missing controls - Impact and severity rationale - Minimal safe reproduction or test design - Remediation at the root enforcement point - Trade-offs, compatibility concerns, migration needs, and rollback approach - Verification procedure, expected result, actual result if executed, and evidence reference - Status: Confirmed-unfixed, Proposed remediation, Edited-not-tested, Tested-not-remediated, Verified-remediated, Blocked, or Risk-accepted with named human approval evidence D. Hypotheses and hardening register List unconfirmed concerns and defense-in-depth improvements separately. For each include the triggering observation, missing evidence, potential impact, and the next evidence needed. Do not assign confirmed-vulnerability language to this section. E. Validation matrix Provide a table with: finding ID; test type; authorized environment; command or procedure; expected secure observation; actual observation; evidence; result of Pass, Fail, Not run, or Inconclusive; follow-up owner. A Pass requires an executed test whose actual observation matches the expected secure behavior. Code inspection alone may support a finding but must not be described as an executed test. If edits were made but tests were unavailable or failed to run, report Edited-not-tested rather than fixed or verified. F. Release and remediation handoff - Prioritized remediation order based on exploitability and impact - Release blockers and rationale - Required human approvals and risk owners - Residual risks, monitoring or detection recommendations, and rollback triggers - Final recommendation using one permitted handoff state - Smallest safe next action Completion language - Use fixed, remediated, tested, verified, approved, deployed, or completed only when the corresponding action occurred and supporting evidence is cited. - Never claim that an unexecuted command passed, a proposed patch was applied, an unavailable environment was inspected, or a release was approved. - If no confirmed findings are identified, say only that no confirmed findings were identified within the reviewed scope and evidence; do not claim the application is secure. ## Step 5 — Review the Laravel change set **Prompt** Evidence-Grounded Laravel Pull Request Review with Codex **Instructions** Conduct a read-only Laravel change review across behavior, authorization, data changes, queues, caches, compatibility, deployment safety, and test evidence. Mark migration review Not applicable when no schema or data migration exists. **Input for this step** Provide the real diff or change set, diagnosis, payment test plan and results if run, security findings, CI evidence, migration status, and release constraints. **Carry forward** Carry merge blockers, test gaps, behavior, migration and deployment risk, evidence limits, and merge recommendation into release planning. **Review note** The engineering reviewer decides merge readiness; the database owner reviews migration risk only when an applicable migration exists. **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 6 — Gate deployment, rollback, and monitoring **Prompt** CI/CD Deployment Safety Checklist Generator **Instructions** Review CI/CD, deployment scripts, applicable migrations, configuration, observability, rollback readiness, and release verification for the payment correction. **Input for this step** Provide the review output, CI and deployment configuration, rollback options, monitoring, migration status, cache and configuration considerations, and required smoke checks. **Carry forward** Produce the final pre-deploy gates, authorized execution plan, rollback conditions, post-deploy checks, monitoring window, and unresolved decisions. **Review note** The release owner approves merge and deployment; payment, database, security, and operations owners approve actions within their scope, including any live provider verification. **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 workflow is complete when: - Repository boundaries are confirmed or created before authorized changes. - Root cause and the smallest correction are tied to supplied code and runtime evidence. - Payment-specific tests cover signatures, idempotency, retries, ordering, states, and relevant edge cases without false execution claims. - Security and pull-request findings have explicit dispositions. - The release owner has observable pre-deploy, rollback, smoke-test, and monitoring gates; any live replay, migration, configuration, provider, or deployment action remains separately authorized. # Recover a Laravel Payment Checkout Failure Safely Workflow ID: AMO-W-000020 Workflow URL: https://amo.ng/workflows/laravel-payment-checkout-bug-fix-and-release-readiness-workflow Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: An evidence-backed payment recovery package containing repository boundaries, root cause, the smallest authorized correction, payment-flow test coverage, security and PR findings, and release, rollback, and monitoring conditions. Required inputs: - Laravel repository context and current repository instructions, if they exist - Checkout, webhook, payment-state, settlement, or entitlement failure evidence - Logs, traces, gateway events, reproduction steps, affected versions, and recent changes - Relevant routes, handlers, jobs, listeners, queues, migrations, configuration, and provider contracts - Existing tests and CI, provider sandbox limits, deployment and rollback process, monitoring, and authorization boundaries ## Step 1 — Confirm repository safety instructions **Instructions** Use this step when current repository instructions do not already define editable paths, protected areas, verification commands, migration and deployment restrictions, and approval gates. Otherwise validate the existing instructions and mark generation Not applicable. **Input for this step** Provide existing AGENTS.md or repository guidance, conventions, allowed and protected paths, test, lint and build commands, deployment restrictions, migration rules, and approval requirements. **Carry forward** Carry the confirmed repository boundaries, commands, protected behavior, and approval gates into payment-failure diagnosis. **Review note** A repository maintainer approves editing boundaries and verification commands before any code change is authorized. **Prompt** Codex AGENTS.md Safety and Verification Instructions Generator **Prompt ID** AMO-P-000080 **Prompt URL** https://amo.ng/prompts/codex-agents-md-project-instructions-generator ## Step 2 — Diagnose the checkout or webhook failure **Instructions** Reproduce or bound the Laravel payment failure using evidence for signatures, idempotency, retries, ordering, payment-state integrity, queues, and gateway compatibility. If edits are authorized, constrain the correction to the smallest responsible change. **Input for this step** Provide repository guidance, failure description, logs, traces, gateway payloads, affected code, environment constraints, and explicit authorization for read-only diagnosis or code changes. **Carry forward** Carry root-cause evidence, competing hypotheses, the proposed or authorized correction, touched files, unresolved risks, and verification needs into payment test planning. **Review note** The engineering owner approves the correction scope before implementation or any expansion beyond the minimal fix. **Prompt** Codex Prompt for Safely Diagnosing and Fixing Laravel Payment Checkout Bugs **Prompt ID** AMO-P-000068 **Prompt URL** https://amo.ng/prompts/codex-fix-laravel-payment-checkout-bugs-safely ## Step 3 — Design payment-flow regression evidence **Instructions** Define checkout, signed webhook, idempotency, retry, ordering, refund, entitlement, subscription, and manual-review tests without implying execution unless results are supplied. **Input for this step** Provide the diagnosis, proposed or actual changes, gateway behavior, payment states, webhook samples, existing tests, sandbox boundaries, and acceptance needs. **Carry forward** Carry the test matrix, edge cases, replay controls, environment boundaries, expected results, and evidence gaps into security review. **Prompt** Laravel Payment Flow Smoke Test and Edge Case Planner **Prompt ID** AMO-P-000182 **Prompt URL** https://amo.ng/prompts/laravel-payment-flow-smoke-test-edge-case-planner ## Step 4 — Review payment-code security risk **Instructions** Review affected code and proposed or actual changes for authentication, authorization, injection, unsafe input, signature validation, secret exposure, data integrity, and release-blocking security risk. **Input for this step** Provide the diff or correction plan, routes and handlers, webhook verification, authorization, validation, secret and configuration handling, and test plan. **Carry forward** Carry evidence-linked security findings, severity, locations, required corrections, and residual risk into pull-request review. **Review note** The security reviewer and engineering owner disposition material security findings before merge readiness is assessed. **Prompt** Evidence-Based Code Security Review Prompt **Prompt ID** AMO-P-000006 **Prompt URL** https://amo.ng/prompts/security-review-prompt ## Step 5 — Review the Laravel change set **Instructions** Conduct a read-only Laravel change review across behavior, authorization, data changes, queues, caches, compatibility, deployment safety, and test evidence. Mark migration review Not applicable when no schema or data migration exists. **Input for this step** Provide the real diff or change set, diagnosis, payment test plan and results if run, security findings, CI evidence, migration status, and release constraints. **Carry forward** Carry merge blockers, test gaps, behavior, migration and deployment risk, evidence limits, and merge recommendation into release planning. **Review note** The engineering reviewer decides merge readiness; the database owner reviews migration risk only when an applicable migration exists. **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 6 — Gate deployment, rollback, and monitoring **Instructions** Review CI/CD, deployment scripts, applicable migrations, configuration, observability, rollback readiness, and release verification for the payment correction. **Input for this step** Provide the review output, CI and deployment configuration, rollback options, monitoring, migration status, cache and configuration considerations, and required smoke checks. **Carry forward** Produce the final pre-deploy gates, authorized execution plan, rollback conditions, post-deploy checks, monitoring window, and unresolved decisions. **Review note** The release owner approves merge and deployment; payment, database, security, and operations owners approve actions within their scope, including any live provider verification. **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 workflow is complete when: - Repository boundaries are confirmed or created before authorized changes. - Root cause and the smallest correction are tied to supplied code and runtime evidence. - Payment-specific tests cover signatures, idempotency, retries, ordering, states, and relevant edge cases without false execution claims. - Security and pull-request findings have explicit dispositions. - The release owner has observable pre-deploy, rollback, smoke-test, and monitoring gates; any live replay, migration, configuration, provider, or deployment action remains separately authorized.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
An evidence-backed payment recovery package containing repository boundaries, root cause, the smallest authorized correction, payment-flow test coverage, security and PR findings, and release, rollback, and monitoring conditions.
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.
- Laravel repository context and current repository instructions, if they exist
- Checkout, webhook, payment-state, settlement, or entitlement failure evidence
- Logs, traces, gateway events, reproduction steps, affected versions, and recent changes
- Relevant routes, handlers, jobs, listeners, queues, migrations, configuration, and provider contracts
- Existing tests and CI, provider sandbox limits, deployment and rollback process, monitoring, and authorization boundaries
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 Confirm repository safety instructions
Use this step when current repository instructions do not already define editable paths, protected areas, verification commands, migration and deployment restrictions, and approval gates. Otherwise validate the existing instructions and mark generation Not applicable.
Prompt: Codex AGENTS.md Safety and Verification Instructions GeneratorCreate a copy-ready AGENTS.md that governs how Codex may inspect, modify, verify, and report work in this repository. Project inputs - Project name: [Project name] - Project purpose: [Project purpose] - Repository map: [Repository map] - Tech stack and package managers: [Tech stack and package managers] - Editable paths: [Editable paths] - Protected paths: [Protected paths] - Coding conventions: [Coding conventions] - Verification commands: [Verification commands] - CI, build, deployment, and cache commands: [CI build deployment and cache commands] - Environment and secret-handling rules: [Environment and secret-handling rules] - Known fragile areas: [Known fragile areas] - High-risk operations and approval rules: [High-risk operations and approval rules] - Definition of done: [Definition of done] - Workflow preferences: [Workflow preferences] Input and evidence rules 1. Treat the project name, purpose, repository map, editing boundaries, approval rules, and definition of done as required. A verification command may be unknown, but that unknown must be preserved explicitly. 2. Useful supporting evidence includes an accessible repository tree, an existing AGENTS.md, README files, package manifests and lockfiles, formatter or linter configuration, test configuration, framework configuration, CI workflow files, deployment documentation, and contributor guidance. 3. If Codex has repository access, it may perform read-only inspection of relevant files to ground the draft. It must not edit files, run commands, install dependencies, modify configuration, create commits, open pull requests, deploy, migrate data, clear production caches, rotate credentials, or publish anything while generating this document unless the user separately authorizes that action. 4. Distinguish each instruction or command source as owner-supplied, repository-observed, inferred, or unknown. Repository-observed means the exact value appears in inspected project evidence. Inferred content must be labeled for owner review and must not be presented as established fact. 5. Never expose or reproduce secrets, tokens, private keys, credentials, customer data, or sensitive environment values. Refer only to environment variable names or redacted examples when necessary. 6. Do not invent commands, path permissions, deployment procedures, rollback steps, or approval authority. When a required fact is missing or conflicting, ask a focused clarification question if it blocks a safe boundary. Otherwise, produce a bounded draft with a clearly marked owner decision item. 7. If an existing AGENTS.md is present, do not silently replace its instructions. Compare it with the supplied requirements, identify conflicts and scope differences, and produce a proposed consolidated draft plus a short change summary. 8. Account for AGENTS.md scope: repository-root instructions establish the default, while a more specific AGENTS.md in a descendant directory may refine instructions for that subtree. Do not claim that repository instructions override system, platform, user, security, or organizational policy. Drafting workflow 1. Inspect the supplied evidence and identify the repository architecture, package managers, generated artifacts, test layers, CI entry points, deployment-sensitive files, migration paths, caches, and security boundaries that are actually evidenced. 2. Reconcile editable and protected paths. A protected path takes precedence when lists overlap. Mark ambiguous, missing, generated, vendored, lockfile, schema, infrastructure, credential, and production configuration boundaries for owner review. 3. Convert coding conventions into actionable rules tied to the actual stack, such as formatting, static analysis, dependency policy, framework conventions, database migration practices, backward compatibility, generated-file handling, and test placement. Include only applicable rules. 4. Build a workflow that requires Codex to inspect before editing, state its intended files and approach, keep changes within scope, preserve unrelated work, make the smallest coherent change, and stop when repository state or instructions conflict. 5. Build a command matrix from owner-supplied or repository-observed commands. Separate fast targeted checks from broader tests, linting, static analysis, builds, integration tests, and release checks. Never imply that a command was executed merely because it appears in AGENTS.md. 6. Define approval gates for consequential operations. Deployment, production access, destructive database operations, irreversible migrations, dependency upgrades with broad impact, secret handling, force pushes, history rewrites, cache clearing in shared environments, external communications, and deletion of user or production data must require explicit human authorization when applicable. 7. Define stop conditions and recovery controls. Codex must stop on suspected secret exposure, unexpected destructive output, permission uncertainty, failing preconditions, unrelated repository changes, ambiguous environment targets, unavailable rollback paths, or a verification failure that makes further action unsafe. 8. Define truthful reporting states so future Codex sessions keep proposed, changed, executed, passed, failed, blocked, skipped, unavailable, and unverified work distinct. Required AGENTS.md structure Return the complete file in one Markdown code block using these sections: # Project Instructions State the project purpose, relevant architecture, primary stack, and the evidence basis for the instructions. ## Instruction Scope and Precedence Explain repository-root and descendant-directory scope, conflict handling, and the precedence of system, platform, organizational, security, and explicit user instructions. ## Repository Map Describe important source, test, configuration, generated, vendor, migration, infrastructure, and documentation locations that are supported by evidence. Mark unknown locations rather than guessing. ## Change Authority Matrix Provide a table with columns for path or resource, allowed action, prohibited action, approval required, evidence source, and notes. Cover editable paths, protected paths, generated files, dependencies, database schemas or migrations, CI configuration, deployment configuration, secrets, and production data when applicable. ## Coding and Change Rules Specify stack-relevant conventions, dependency and lockfile policy, generated-file policy, migration compatibility requirements, security expectations, scope control, and treatment of unrelated changes. ## Required Work Sequence Define the inspect, clarify, plan, edit, verify, review, and report sequence. Require Codex to name intended files before editing and to pause when the requested work exceeds authority. ## Verification Matrix Provide a table with columns for change type, exact command, source, execution authority, expected successful observation, failure handling, and unavailable-command fallback. Include targeted tests, broader tests, linting, formatting, static analysis, builds, and relevant CI or release checks only when applicable. Unknown commands must remain explicit owner action items. ## High-Risk and Production Operations List applicable approval gates, environment confirmation requirements, backup or rollback prerequisites, dry-run expectations, monitoring or post-change checks, and stop conditions. State that documentation of a command is not authorization to execute it. ## Security and Data Handling Cover secret redaction, least privilege, sensitive logs, personal or production data, dependency provenance, and incident escalation appropriate to the supplied project. ## Definition of Done Translate the supplied definition into observable acceptance criteria. Require scope reconciliation, applicable verification evidence, documentation updates where needed, no unauthorized protected-path changes, and disclosure of unresolved failures or skipped checks. ## Completion Report Contract Require future Codex sessions to report changed files, concise change summary, commands actually executed, actual outcomes, checks not run and why, assumptions, residual risks, approval-dependent actions, and recommended human follow-up. Prohibit claims such as fixed, tested, verified, approved, deployed, rolled back, or completed unless the corresponding action occurred and evidence is available. After the code block, provide these companion sections: ## Evidence and Decision Register Use a table with columns for item, classification, source, confidence, conflict or gap, and owner action. Classifications must distinguish supplied fact, repository observation, inference, unknown, and conflict. ## Owner Review Checklist Include concrete checks for path scope, command accuracy, nested AGENTS.md behavior, secret safety, approval ownership, destructive operations, rollback readiness, verification expectations, and definition-of-done acceptance. ## Proposed Change Summary If an existing AGENTS.md was inspected, summarize retained, changed, added, and unresolved instructions. Otherwise state that this is a new proposed file. Final validation - Confirm every project-specific statement is traceable to supplied or inspected evidence, or is labeled as an inference or unknown. - Confirm protected paths override editable paths where they overlap. - Confirm every command is exact and sourced, or explicitly unknown. - Confirm command documentation and command execution authority are separate. - Confirm consequential actions require the stated human approval and applicable recovery controls. - Confirm no secret values or sensitive data are included. - Confirm acceptance criteria are observable and unresolved states remain visible. - Confirm no execution, test, approval, deployment, rollback, or completion claim is made without actual evidence. - Confirm the AGENTS.md is internally consistent and copy-ready, while remaining a proposal until the project owner reviews and installs it.Input for this step
Provide existing AGENTS.md or repository guidance, conventions, allowed and protected paths, test, lint and build commands, deployment restrictions, migration rules, and approval requirements.
Carry forward
Carry the confirmed repository boundaries, commands, protected behavior, and approval gates into payment-failure diagnosis.
Review note
A repository maintainer approves editing boundaries and verification commands before any code change is authorized.
-
Step 2 Diagnose the checkout or webhook failure
Reproduce or bound the Laravel payment failure using evidence for signatures, idempotency, retries, ordering, payment-state integrity, queues, and gateway compatibility. If edits are authorized, constrain the correction to the smallest responsible change.
Prompt: Codex Prompt for Safely Diagnosing and Fixing Laravel Payment Checkout BugsLaravel payment incident inputs - Project and incident context: [Project and incident context] - Relevant code and sanitized non-secret configuration: [Relevant code and sanitized non-secret configuration] - Sanitized logs and event evidence: [Sanitized logs and event evidence] - Observed and expected behavior: [Observed and expected behavior] - Gateway contract and event model: [Gateway contract and event model] - Constraints and authority: [Constraints and authority] - Verification environment and commands: [Verification environment and commands] - Acceptance criteria: [Acceptance criteria] Codex operating rules Use only the repository files, snippets, logs, documentation, commands, and workspace capabilities actually available in this session. Do not imply that Codex accessed a repository, payment-provider dashboard, external API, database, queue, log service, network, or test runner unless that access occurred and the resulting evidence can be cited. Inspect the repository and relevant files before proposing or making changes. Unless [Constraints and authority] explicitly restricts it, permit read-only repository inspection and non-mutating diagnostics. Treat file edits, mutating commands, dependency changes, database writes or migrations, cache or queue changes, external-service calls, deployment, production access, and financially consequential actions as unauthorized unless expressly approved. When editing is not authorized, provide a proposed diff only from repository content or code snippets Codex actually inspected. When repository access is unavailable but relevant snippets were supplied, label any patch illustrative and unverified against the complete codebase. When the available source is insufficient, provide a bounded change plan rather than inventing an exact patch. Do not deploy, rotate credentials, alter production configuration or data, replay live webhooks, retry or capture payments, issue refunds, contact a provider, or trigger any financially consequential operation within this prompt. Record such work as a separate human-controlled handoff. Treat secrets, complete payment tokens, authorization headers, signing secrets, personal data, and full customer records as prohibited input and output. If encountered, do not reproduce them; identify the location generically and request redacted evidence. Do not add sensitive payload logging as a diagnostic shortcut. Input sufficiency and conflicts 1. Inventory the supplied inputs and identify the Laravel version, PHP version, payment gateway or gateways, checkout path, webhook route, relevant event types, persistence model, queue behavior, and incident scope only when supported by evidence. 2. If a blocking item is absent, ambiguous, or contradictory, ask one consolidated set of focused questions before diagnosing or editing. Blocking items include the failing flow, relevant route and handler code, a sanitized error or event trace, expected gateway behavior, and change authority. 3. Record non-blocking gaps as unknowns and continue only when a bounded analysis is possible. Do not fill gaps with typical Laravel or gateway behavior. 4. When code, logs, tests, and stated behavior conflict, show the conflict and give precedence only after explaining why one source is more direct or current. Do not silently reconcile incompatible evidence. Evidence discipline Maintain these distinctions throughout the work: - Supplied fact: a statement or artifact provided by the user. - Observation: something directly found in an available file, log, diff, or command result. - Hypothesis: a testable explanation that has not yet been established. - Assumption: a temporary premise needed to proceed and clearly marked as such. - Unknown: information not available or not determinable. - Unsupported claim: a conclusion lacking sufficient evidence; do not use it as the basis for a fix. Cite observations with available file paths and symbols, sanitized log timestamps or correlation identifiers, gateway documentation supplied in the session, or exact commands and relevant output. Never claim that a defect is reproduced, fixed, tested, compatible, or verified solely because a patch appears plausible. Payment-specific diagnosis Trace the failing path from checkout creation through provider interaction, redirect or callback handling, webhook receipt, payment-state persistence, queued work, and user-visible state. Limit the trace to components supported by the supplied artifacts. Evaluate applicable failure modes without assuming any is present: - Route registration, HTTP method, middleware, CSRF exclusions, authentication, rate limiting, and request-body mutation. - Webhook signature verification against the raw payload, required headers, timestamp tolerance, secret selection, and replay protection according to the supplied gateway contract. - The distinction between browser redirect success and authoritative server-side payment confirmation. - Event identity, checkout or payment identity, idempotency keys, duplicate deliveries, retry behavior, unique constraints, and whether repeated processing can duplicate transitions or side effects. - Transaction boundaries, locking, queue dispatch timing, partial writes, worker retries, timeouts, and acknowledgement behavior. - Out-of-order, delayed, stale, or conflicting events and whether state transitions can regress a terminal payment state. - Amount, currency, account, customer, order, metadata, and environment correlation before changing local payment state. - Sandbox versus live configuration, endpoint mismatch, gateway-version differences, and multi-gateway routing without exposing credentials. - Exception handling and HTTP responses that could cause lost events, retry storms, premature acknowledgement, or sensitive logging. - Checkout races, abandoned sessions, asynchronous confirmation, inventory or entitlement side effects, and recovery or reconciliation paths. For each credible hypothesis, state the supporting evidence, contradicting evidence, a qualitative confidence statement justified by that evidence, and the smallest discriminating check. Select a root cause only when evidence supports the causal chain. Otherwise report ranked hypotheses and the missing evidence needed to decide. Minimal safe change If code changes are authorized and the cause is sufficiently supported: 1. Define the payment invariant the change must restore, such as one durable business transition per gateway event or no transition before authenticated event validation. 2. Implement the smallest localized change consistent with the supplied Laravel and gateway versions. Preserve unrelated checkout paths and gateway adapters. 3. Avoid broad rewrites, speculative dependency upgrades, credential changes, destructive migrations, and production-only workarounds. 4. For schema or constraint changes, provide migration, rollback, collision-handling, and existing-data considerations. Do not execute destructive or production migrations. 5. Add or update focused tests where the available project structure permits. Do not weaken assertions or delete failing tests merely to obtain a passing result. 6. Show the exact diff or proposed patch. Label it executed only if files were actually modified; otherwise label it proposed. Payment verification matrix Derive checks from the supplied gateway contract and acceptance criteria. Include the applicable cases below, and mark inapplicable or unavailable cases with reasons: - Checkout creation and expected local initial state. - Valid authenticated webhook and intended state transition. - Invalid signature, malformed payload, missing header, or expired timestamp rejection. - Duplicate delivery of the same event without duplicate state changes or side effects. - Transient handler or queue failure followed by a safe retry. - Delayed or out-of-order event without improper state regression. - Amount, currency, order, account, and environment mismatch handling. - Database transaction or uniqueness behavior under repeated processing. - Existing gateway and non-payment regression tests relevant to modified code. - Syntax, static analysis, formatting, and targeted Laravel test commands supplied or discoverable in the available project. For every check, report the command or inspection method, expected observation, actual observation, and evidence. A command not run is unavailable or not executed, never passed. A test failure must remain visible. If execution is unavailable, provide exact proposed commands and expected acceptance signals without fabricating output. Compatibility with an existing gateway may be called verified only when relevant evidence was reviewed and applicable tests passed; otherwise call it assessed or unverified. Output contract: Laravel payment-fix deliverable Return the following task-specific sections: Keep every section concise and proportional to the work actually performed. Where a section is not applicable or an action was not executed, state that explicitly rather than filling it with generic content. Never omit the authority, evidence, verification, or completion-declaration sections. 1. Incident scope and authority - Failing checkout or webhook path - In-scope gateway, events, files, and environment - Permitted actions, prohibited actions, and required human approvals 2. Evidence ledger - Each supplied fact or observation - Source location or sanitized identifier - Conflicts, assumptions, and unknowns 3. Failure-path reconstruction - Ordered request, event, queue, and persistence sequence - First evidenced divergence from expected behavior 4. Root-cause verdict - Supported root cause and confidence, or ranked hypotheses if unresolved - Supporting and contradicting evidence - Affected payment invariant and failure modes 5. Change record - Files actually modified and concise diff summary - Proposed but unapplied changes in a separate list - Schema, rollback, idempotency, retry, state-transition, and gateway-compatibility effects 6. Verification matrix - Check, expected observation, actual observation, evidence, and status - Use only passed, failed, unavailable, not executed, or not applicable as statuses 7. Residual risk and recovery handoff - Remaining unknowns and unverified gateway paths - Safe rollback or disablement approach - Any reconciliation, replay, production validation, or provider action requiring human approval 8. Completion declaration - Requested work - Proposed work - Executed work with evidence - Unavailable work and reason - Unverified work - Acceptance criteria met and not met Do not state that the Laravel payment issue is fixed or complete unless the authorized change was applied, the relevant verification ran successfully, and every required acceptance criterion has supporting evidence.Input for this step
Provide repository guidance, failure description, logs, traces, gateway payloads, affected code, environment constraints, and explicit authorization for read-only diagnosis or code changes.
Carry forward
Carry root-cause evidence, competing hypotheses, the proposed or authorized correction, touched files, unresolved risks, and verification needs into payment test planning.
Review note
The engineering owner approves the correction scope before implementation or any expansion beyond the minimal fix.
-
Step 3 Design payment-flow regression evidence
Define checkout, signed webhook, idempotency, retry, ordering, refund, entitlement, subscription, and manual-review tests without implying execution unless results are supplied.
Prompt: Laravel Payment Flow Smoke Test and Edge Case PlannerUse Codex to inspect the supplied Laravel repository and prepare a payment-flow smoke-test and edge-case plan. This is a planning and verification task by default. It is not permission to edit files, execute migrations, contact a payment provider, create charges, issue refunds, replay live webhooks, mutate production data, or claim that testing succeeded. ## Inputs - Payment provider, environment, and lifecycle: [Payment provider and flow] - Checkout, callback, and webhook endpoints: [Checkout and webhook routes] - Payment, order, invoice, subscription, and entitlement records: [Payment, order, or subscription models] - Required business-state behavior: [Success, failure, refund, and manual review rules] - Delivery, concurrency, and replay concerns: [Idempotency, retry, and duplicate event concerns] - Existing local tests, fakes, mocks, and provider-sandbox facilities: [Existing tests and sandbox or fake setup] - Permitted inspection, edits, commands, environments, and data operations: [Execution boundaries and verification commands] ## Scope, authority, and evidence rules Unless [Execution boundaries and verification commands] explicitly restricts it, permit: - read-only repository inspection; - review of supplied documentation and sanitized logs; - non-mutating local diagnostics. Treat the following as unauthorized unless expressly approved: - file edits; - mutating commands; - dependency changes; - database writes or migrations; - cache or queue mutations; - provider API calls; - provider-sandbox actions; - production access; - webhook replay; - real charges, captures, cancellations, disputes, or refunds; - customer notifications or entitlement changes. Do not interrupt ordinary read-only inspection by repeatedly narrating permission checks. Verify authority before any edit, mutating command, external call, database action, or financially consequential activity. Use only repository files, snippets, documentation, logs, command results, and workspace capabilities actually available in the current session. Do not imply access to a provider dashboard, network, database, queue, logs platform, sandbox, test runner, or production system unless that access exists and the resulting evidence can be identified. Never request or reproduce: - live credentials; - signing secrets; - access tokens; - authorization headers; - raw cardholder data; - complete payment tokens; - real customer payment methods; - full customer payment records; - unnecessary personal information. Use synthetic customers, provider test identifiers, redacted configuration descriptions, safe fixtures, Laravel fakes, mocks, and approved provider test facilities. If a blocking input is missing, ask one consolidated set of focused questions. Blocking inputs include: - the provider and environment; - the authoritative payment-confirmation mechanism; - relevant checkout and webhook code; - the supported lifecycle states; - material business rules; - the test boundary; - execution authority. A partial plan may still be produced for supported areas, but affected conclusions must be marked blocked or unverified. When user descriptions, code, tests, migrations, configuration, logs, and provider documentation conflict: 1. Preserve the conflicting statements. 2. Identify their sources. 3. Explain the financial, state, entitlement, or authorization consequence. 4. Identify the evidence or owner needed to reconcile them. 5. Do not silently select one version. Use these work states consistently: - **Observed** — directly found in an accessible repository file, configuration, migration, test, log, or command result. - **Supplied** — provided by the user but not independently reproduced by Codex. - **Proposed** — recommended but not executed. - **Executed** — actually performed in the current session with recorded evidence. - **Unavailable** — the required source, capability, or environment could not be accessed. - **Unverified** — plausible but not established by sufficient evidence. - **Conflicting** — available sources disagree. - **Not applicable** — excluded for a payment-flow-specific reason. Never claim that a defect was reproduced or fixed, that a test passed, that a payment was verified, that a refund occurred, or that provider or production behavior is safe without direct evidence for that exact statement. ## Review workflow ### 1. Establish the authoritative payment lifecycle Map the observed flow from the first checkout request through payment confirmation and downstream effects. Identify, where applicable: - checkout route and controller; - request validation and authorization; - server-side product, price, amount, currency, quantity, tax, and discount calculation; - provider adapter or SDK call; - checkout session, payment intent, charge, subscription, invoice, customer, refund, and event identifiers; - internal order, payment, subscription, invoice, and entitlement references; - browser success and cancellation returns; - synchronous provider responses; - webhook receipt and verification; - queued processing; - local state changes; - fulfillment; - entitlement changes; - customer notifications; - reconciliation and manual-review paths. Determine the authoritative source of payment confirmation. Do not treat a browser redirect, success page, client-supplied value, or local pending record as proof of payment unless the supplied application and provider contract explicitly establish that behavior. Record only lifecycle states supported by the repository or supplied rules, such as: - pending; - processing; - paid; - failed; - canceled; - expired; - refunded; - partially refunded; - disputed; - manual review. Identify which transitions are legal and which states are terminal. Flag any path that allows a stale or lower-authority event to regress a terminal successful state. ### 2. Review checkout trust and duplicate prevention Inspect applicable controls for: - authentication and authorization; - request validation; - server-side price and product lookup; - client-value distrust; - provider request construction; - idempotency-key creation and reuse; - internal order or payment reference uniqueness; - repeated form submission; - browser refresh and retry; - abandoned checkout; - simultaneous requests; - repeated provider-object creation. Determine whether duplicate requests can create duplicate: - provider payment objects; - internal orders; - invoices; - fulfillment; - customer notifications; - entitlements; - ledger entries. An application-level “record exists” check is not sufficient evidence of concurrency safety unless it is supported by an atomic operation, unique constraint, lock, compare-and-set transition, or equivalent durable control. ### 3. Review webhook authenticity, correlation, and replay safety Inspect: - raw request-body preservation; - signature or SDK verification; - signing-secret selection; - required headers; - timestamp tolerance; - replay handling; - malformed and oversized payload handling; - unsupported event behavior; - test versus live environment separation. Confirm that an accepted event is correlated to the expected: - provider account and environment; - event ID; - payment, checkout, charge, invoice, subscription, or refund object; - internal order or payment reference; - customer; - amount; - currency; - product or plan; - expected prior state. Identify the durable deduplication mechanism, such as: - a unique provider-event constraint; - a processed-events table; - an atomic insert; - row locking; - a compare-and-set update; - a transactional state transition. Trace duplicate, delayed, replayed, stale, and out-of-order events. Confirm that repeated or reordered processing cannot duplicate or incorrectly reverse: - payment state; - fulfillment; - invoices; - notifications; - entitlement grants or revocations; - subscription transitions; - refunds. Assess acknowledgement behavior. Determine when the handler returns success, how transient failures differ from permanent failures, and how provider retries interact with local transactions and queues. ### 4. Review transaction, queue, and side-effect boundaries Identify: - database transactions; - row locks; - unique constraints; - optimistic state checks; - after-commit dispatch; - queued listeners and jobs; - retry counts and backoff; - timeouts; - failed-job handling; - partial-failure windows. For every externally visible side effect, determine: - what triggers it; - whether it occurs before or after durable state change; - whether retry can repeat it; - what idempotency guard exists; - how failure is reconciled. Inspect failure windows between: - provider confirmation and local persistence; - local persistence and entitlement grant; - state change and job dispatch; - transaction commit and notification; - webhook receipt and durable event recording. ### 5. Review refunds, subscriptions, entitlements, and manual review Where applicable, inspect: #### Refunds - authorization; - requested, pending, succeeded, failed, partial, and reversed states; - maximum refundable amount; - currency; - duplicate refund prevention; - provider and local reconciliation; - order and entitlement consequences; - audit evidence; - customer communication. #### Subscriptions - plan eligibility; - upgrade and downgrade rules; - billing-cycle anchors; - proration assumptions; - invoice state; - trial effects; - failed payment; - scheduled changes; - webhook ordering; - recovery behavior. #### Entitlements Confirm that access grant, change, suspension, and revocation: - derive from documented payment or subscription states; - are idempotent; - cannot occur twice from a duplicate event; - cannot be lost after a partial failure; - reconcile with refunds and subscription changes. #### Manual review Inspect: - entry criteria; - authorized roles or policies; - approval and rejection transitions; - reason capture; - audit records; - stale reviews; - duplicate actions; - segregation of duties where required; - customer communication. ### 6. Define financial and entitlement invariants Create evidence-linked invariants for the observed flow. Applicable examples include: - one logical checkout produces no more than one intended provider payment object; - only authenticated, correlated provider evidence can authorize a successful local payment transition; - accepted amount, currency, customer, account, product, plan, and internal reference match expectations; - one provider event produces no more than one durable business transition; - a duplicate or retried event cannot repeat fulfillment, invoice creation, notification, refund, or entitlement mutation; - stale or out-of-order events cannot regress a valid terminal state; - failed or canceled payment cannot grant paid access; - refund amount cannot exceed the supported refundable balance; - manual decisions require the documented authority; - retries and partial failures remain reconcilable. Do not assume every example applies. Add only invariants supported by the flow or necessary to prevent a credible failure. ## Test architecture Separate the test plan into three evidence levels. ### A. Minimal smoke suite Design a small, fast, deterministic suite that answers whether the application’s most critical payment paths still work. Include only the highest-value applicable cases, normally: - checkout creation with correct local initial state; - valid authoritative confirmation and intended state transition; - invalid or unauthenticated webhook rejection; - duplicate event without duplicate business effects; - failed or canceled payment without paid entitlement; - one critical refund, subscription, or manual-review path where relevant. The smoke suite should be suitable for frequent local or CI execution and should not require live credentials or real financial actions. ### B. Edge-case and regression suite Design broader coverage for applicable risks such as: - stale signature; - malformed payload; - unsupported event; - duplicate internal reference; - amount or currency mismatch; - wrong account or customer; - delayed and out-of-order events; - simultaneous processing; - transaction rollback; - queue retry after partial failure; - notification retry; - abandoned checkout; - unauthorized manual action; - refund failure; - partial refund; - upgrade, downgrade, proration, invoice, and entitlement transitions. Do not force irrelevant cases into the suite merely to increase coverage. ### C. Provider-sandbox checks Use provider-sandbox checks only where local fakes and integration tests cannot establish the required behavior. A sandbox call is still an external, state-changing action and requires explicit authorization. For every sandbox check define: - purpose; - test account and environment; - synthetic input; - prohibited data and actions; - exact steps; - expected provider evidence; - expected Laravel evidence; - cleanup; - approval owner; - limitation. A local fake does not prove provider behavior. A provider-sandbox result does not prove production behavior. ## Test-design rules Prefer Laravel feature or integration tests for: - routes; - middleware; - authorization; - database state; - transactions; - queues; - events; - notifications; - webhooks; - end-to-end local state transitions. Use unit tests for isolated mappings, validators, or state-transition logic. Use Laravel fakes only where they preserve the behavior being tested. State when a fake bypasses: - real signature verification; - SDK serialization; - network transport; - database transactions; - queue serialization; - provider retries. Use synthetic fixtures and test-mode provider identifiers. Do not weaken assertions, suppress failures, delete tests, or replace meaningful integration coverage with mocks merely to obtain a passing suite. ## Risk labels Use these qualitative labels: - **Critical** — credible risk of unauthorized or duplicate money movement, unrecoverable financial-state corruption, widespread incorrect entitlement, exposed payment secrets, or a state from which safe reconciliation is not possible. - **High** — material risk involving authentication, idempotency, ordering, amount or currency integrity, refunds, subscriptions, entitlements, authorization, or repeated customer-facing side effects. - **Medium** — a meaningful but bounded weakness requiring additional tests, controls, monitoring, or human review. - **Low** — evidence supports limited impact and adequate controls within the stated test scope. - **Unknown** — evidence is insufficient to classify the risk defensibly. Do not classify a risk Low merely because an existing test passes or a familiar provider SDK is used. ## Verification rules Derive commands from the accessible repository’s: - Composer scripts; - test configuration; - CI workflow; - project documentation; - existing test layout. Do not invent runnable commands. Begin with the smallest targeted checks, then expand according to the affected flow and blast radius. For every command or procedure report: - purpose; - work state; - authorization basis; - target environment; - data boundary; - exact command or method; - expected observation; - actual exit status and relevant output only when executed; - failure meaning; - what the result cannot prove. Do not run destructive migrations, resets, real provider calls, production webhooks, queue purges, live refunds, or real charges. ## Required deliverable Keep the deliverable concise and proportional to the observed payment flow and evidence. Use `Not applicable` with an evidence-based reason instead of filling unsupported sections with generic content. ### A. Scope, evidence, and conflict register Provide: - files and sources inspected; - unavailable evidence; - missing inputs; - conflicts; - assumptions; - execution permissions; - blocked decisions. ### B. Payment lifecycle and authority map Provide a table containing: - lifecycle stage; - initiating route or event; - Laravel handler; - provider object or event; - internal record and state; - transaction or queue boundary; - business side effect; - authoritative confirmation source; - evidence; - uncertainty. ### C. Financial and entitlement invariant register Provide: - invariant ID; - protected asset or outcome; - current enforcement evidence; - credible failure mode; - risk; - required assertion; - remaining gap. ### D. Webhook trust, ordering, and idempotency review Provide: - scenario; - authenticity requirement; - correlation checks; - deduplication control; - ordering rule; - transaction boundary; - expected acknowledgement or retry behavior; - protected side effects; - evidence; - gap. ### E. Minimal smoke suite For each test provide: - priority; - suggested test name; - Laravel test level; - setup and fixtures; - stimulus; - expected payment and business state; - database assertions; - queue, event, or notification assertions; - negative assertions; - risk covered; - acceptance criterion. ### F. Edge-case and regression backlog Group applicable tests under: - checkout; - webhook authenticity; - replay and ordering; - retries and concurrency; - refunds; - subscriptions and entitlements; - manual review; - notifications and reconciliation. Distinguish essential release coverage from lower-priority hardening. ### G. Verification and provider-sandbox runbook Separate: - authorized local commands; - proposed but unexecuted commands; - provider-sandbox checks; - human review; - production checks that remain out of scope. Record actual results only where execution evidence exists. ### H. Risk-ranked implementation sequence Order: 1. characterization or missing baseline tests; 2. high-risk smoke coverage; 3. schema or uniqueness requirements; 4. idempotency and state-transition controls; 5. side-effect isolation; 6. edge-case regression tests; 7. provider-sandbox checks; 8. broader regression execution. Identify every step requiring: - file-edit approval; - migration review; - provider access; - financial approval; - security review; - production change control. ### I. Evidence and readiness record List every statement that could imply: - tests passed; - a defect was fixed; - provider behavior was verified; - financial action occurred; - production is safe. For each statement report: - status; - supporting evidence; - limitation. End with exactly one readiness status: - **Blocked** — a critical lifecycle, evidence, authorization, or test-boundary gap prevents a reliable plan. - **Ready for test-plan review** — the proposed coverage is coherent and ready for human review, but implementation or execution is not yet authorized. - **Ready for authorized local test implementation or execution** — repository evidence and boundaries are sufficient for the specified local work to be considered by an authorized human. - **Ready to request authorized provider-sandbox verification** — local evidence is complete for the stated scope and the remaining provider-specific checks are clearly defined. None of these statuses means that tests passed, provider behavior was verified, production is safe, or financial action is authorized. ## Final acceptance gate Before returning the plan, confirm that: 1. Every material payment state and business side effect is linked to repository or supplied-rule evidence. 2. The authoritative payment-confirmation source is identified. 3. Checkout does not trust client-supplied financial values without server-side validation. 4. Webhook authenticity, correlation, duplicate delivery, replay, delay, ordering, retries, and concurrency are covered where applicable. 5. Partial failures cannot silently duplicate or lose critical financial or entitlement effects. 6. The smoke suite remains minimal, fast, and focused on critical invariants. 7. Broader edge cases are separated into a prioritized regression backlog. 8. Local fake, provider-sandbox, and production evidence are not conflated. 9. Commands are repository-supported and have explicit safety boundaries. 10. No live credentials, real customer payment methods, or raw restricted data are required. 11. Conflicts, unavailable evidence, and human approval requirements are explicit. 12. No testing, fix, provider, production, refund, charge, deployment, or safety claim exceeds the evidence actually obtained.Input for this step
Provide the diagnosis, proposed or actual changes, gateway behavior, payment states, webhook samples, existing tests, sandbox boundaries, and acceptance needs.
Carry forward
Carry the test matrix, edge cases, replay controls, environment boundaries, expected results, and evidence gaps into security review.
-
Step 4 Review payment-code security risk
Review affected code and proposed or actual changes for authentication, authorization, injection, unsafe input, signature validation, secret exposure, data integrity, and release-blocking security risk.
Prompt: Evidence-Based Code Security Review PromptConduct a code-level security review in Codex using the following inputs. Review objective: [Review objective] Repository materials: [Repository materials] System context: [System context] Security requirements: [Security requirements] Execution permissions: [Execution permissions] Validation commands: [Validation commands] Definition of done: [Definition of done] Input and access rules - Treat the review objective and inspectable repository materials as minimum prerequisites. The materials should include the relevant source files or repository, dependency manifests and lockfiles, configuration examples, database or API boundaries, and tests when available. - System architecture, trust boundaries, data classifications, deployment configuration, known threats, prior findings, and applicable security requirements are useful context. Mark them unknown when they are not supplied. - If no relevant code or configuration is accessible, stop the code-level assessment. Return a blocking-input list and review plan rather than security conclusions. - Ask a clarification question only when an ambiguity prevents safe scoping, severity assignment, or interpretation of an access-control rule. Otherwise, proceed with a bounded review and record the limitation. - If supplied materials conflict, identify the conflict, cite both sources, and do not silently choose one. Codex operating boundaries - Use Codex to inspect only the files and repository context actually available in the session. Do not imply access to services, branches, secrets, logs, infrastructure, tickets, or production environments that Codex cannot access. - Read and analyze within the granted scope. Run only the validation commands explicitly authorized by the execution permissions and only in an approved non-production environment. - Do not deploy, merge, commit, push, rotate or reveal secrets, alter accounts or permissions, modify production data, contact third parties, or approve a release. - Do not perform destructive tests, denial-of-service tests, credential attacks, persistence, data exfiltration, or exploitation beyond the minimum safe proof needed to establish a finding. Stop if a command could expose sensitive data, affect production, cross an authorization boundary, or cause irreversible changes. - Redact credentials, tokens, personal data, private keys, and sensitive business data from the report. Refer to secret locations without reproducing secret values. - Code changes are proposals unless the execution permissions explicitly authorize edits. Before any authorized edit, describe the files affected, security intent, compatibility risk, validation plan, and rollback method. Keep human approval as the gate for consequential changes and release decisions. Evidence model Maintain these distinctions throughout the review: - Supplied fact: context stated by the user but not independently demonstrated in the available materials. - Observation: behavior or code directly visible in an accessible file, with file path and line or symbol reference. - Execution evidence: a command actually run in this session, including command, environment, exit status, and relevant redacted output. - Assumption: a bounded interpretation required to continue. - Hypothesis: a plausible security issue that still requires evidence. - Unknown: information unavailable from the supplied scope. - Conflict: incompatible evidence or requirements that require reconciliation. Never present a hypothesis, scanner alert, pattern match, or dependency advisory as a confirmed exploitable vulnerability without tracing the relevant data flow, control flow, configuration, affected version, or reachable call path. State when line numbers are approximate or generated files reduce traceability. Review procedure 1. Establish scope and attack surface - Inventory the inspected files, languages, frameworks, dependency manifests, externally reachable endpoints, background jobs, administrative functions, file-processing paths, data stores, and third-party integrations visible in scope. - Map trust boundaries and principal types such as anonymous users, authenticated users, tenants, administrators, services, and webhook senders. - Record excluded components and explain how each exclusion limits assurance. 2. Trace identity and session controls - Inspect login, registration, password reset, account recovery, multifactor flows, API-key handling, token creation and validation, session rotation, logout invalidation, cookie attributes, token expiry, and replay resistance where present. - Check for authentication bypasses, user enumeration, insecure default credentials, weak token validation, confused identity sources, and inconsistent enforcement between web, API, job, and internal routes. 3. Test authorization logic by resource and action - Trace how each sensitive endpoint or operation establishes the acting principal, requested resource, tenant ownership, role, and permitted action. - Look for missing object-level and function-level authorization, insecure direct object references, tenant-boundary failures, privilege escalation, mass assignment, hidden-field trust, administrative route exposure, and checks performed only in the client. - Distinguish authentication from authorization; the presence of a logged-in user is not evidence that access is permitted. 4. Follow untrusted input to security-sensitive sinks - Identify request fields, headers, cookies, uploaded files, webhook payloads, queue messages, imported records, and third-party responses that cross trust boundaries. - Trace validation, normalization, canonicalization, encoding, and type enforcement to SQL, NoSQL, shell, template, HTML, URL fetch, deserialization, logging, filesystem, redirect, and dynamic evaluation sinks. - Evaluate injection, cross-site scripting, server-side request forgery, path traversal, open redirect, request smuggling assumptions, unsafe deserialization, command execution, and log-forging risks as applicable to the actual stack. - Prefer parameterization and context-specific output encoding. Do not treat blocklists or client-side validation as sufficient controls. 5. Review secrets, cryptography, and sensitive data handling - Check source, configuration, fixtures, logs, error paths, build files, and client bundles for embedded credentials or unintended sensitive-data disclosure without reproducing any discovered value. - Inspect key and token storage, randomness, password hashing, encryption modes, signature verification, certificate validation, key separation, rotation support, and fail-open behavior where relevant. - Verify that sensitive fields are minimized and protected in logs, caches, analytics, backups, URLs, error messages, and API responses. 6. Review database, file, and network boundaries - Inspect query construction, row or tenant scoping, transaction boundaries, race conditions, unsafe raw queries, and excessive database privileges visible in configuration. - For uploads and downloads, check filename canonicalization, extension and content validation, size limits, storage location, execution permissions, archive extraction, access checks, content disposition, malware-scanning hooks, and cleanup behavior. - For outbound requests and webhooks, inspect destination allowlisting, redirect handling, DNS and private-network protections, timeouts, response limits, signature validation, replay controls, and error handling. 7. Review security configuration and dependency exposure - Examine debug modes, verbose errors, CORS, CSRF protections, security headers, cookie settings, rate limits, proxy trust, environment separation, default routes, feature flags, and fail-open defaults. - Compare dependency versions against supplied lockfiles and available advisory evidence. Account for reachability, affected version ranges, mitigations, and uncertainty; do not infer compromise from version presence alone. 8. Analyze abuse cases and operational failure modes - Consider brute force, replay, duplicate requests, concurrency, stale authorization, cache confusion, race conditions, partial failures, retries, queue redelivery, oversized inputs, malformed encodings, and cross-tenant access. - Identify controls that exist but can be bypassed through alternate endpoints, asynchronous workers, internal APIs, legacy paths, or inconsistent middleware ordering. 9. Triage and recommend remediation - Assign each confirmed finding a unique identifier and severity of Critical, High, Medium, Low, or Informational. - Explain severity using exploit preconditions, required privileges, reachability, affected assets, confidentiality/integrity/availability impact, tenant or user scope, detectability, and compensating controls. If these factors are unknown, lower confidence rather than inventing them. - Separate confirmed findings from hypotheses and hardening opportunities. Avoid duplicate findings that share one root cause. - Propose the smallest robust fix at the correct enforcement layer. Include compatibility, migration, performance, usability, observability, and rollback considerations. 10. Verify safely - For each finding, define a reproducible validation procedure with prerequisites, a benign test input or unit/integration test design, expected secure behavior, expected vulnerable behavior when safe to describe, and required evidence. - Run a procedure only when access and execution permissions allow it. Record the exact command, environment, exit status, and redacted result. Otherwise mark it Not run and state why. - Include positive tests, negative tests, authorization tests across relevant roles or tenants, regression tests for the root cause, and checks that the remediation does not create a fail-open path. - Reconcile static observations with execution results. Preserve discrepancies as unresolved instead of choosing the preferred result. 11. Determine handoff state - Identify release blockers, accepted residual risks requiring owner approval, unresolved hypotheses, missing evidence, and dependencies on infrastructure or operational controls outside the repository. - Recommend one of: Hold for remediation, Conditional review required, or No release-blocking issue identified in reviewed scope. The last state is not a declaration that the system is secure. - A human security or engineering owner must approve remediation, risk acceptance, and release decisions. Required deliverable A. Scope and assurance statement - Review objective and definition of done - Materials inspected, including commit or revision when available - Components, environments, and threat actors considered - Exclusions, unknowns, conflicts, assumptions, and their effect on assurance - Commands authorized, commands executed, and tools or data unavailable B. Attack-surface and control map Provide a table with: component or entry point; principal; trust boundary; sensitive asset or operation; authentication control; authorization control; untrusted inputs; sensitive sinks; relevant security requirement; evidence reference. C. Confirmed finding register For every confirmed finding provide: - Finding ID and concise title - Severity and confidence - Affected component, file path, line or symbol, endpoint or operation - Security property violated and plausible abuse scenario - Preconditions, required privileges, reachability, and affected scope - Evidence trace from source to control or sink - Existing and missing controls - Impact and severity rationale - Minimal safe reproduction or test design - Remediation at the root enforcement point - Trade-offs, compatibility concerns, migration needs, and rollback approach - Verification procedure, expected result, actual result if executed, and evidence reference - Status: Confirmed-unfixed, Proposed remediation, Edited-not-tested, Tested-not-remediated, Verified-remediated, Blocked, or Risk-accepted with named human approval evidence D. Hypotheses and hardening register List unconfirmed concerns and defense-in-depth improvements separately. For each include the triggering observation, missing evidence, potential impact, and the next evidence needed. Do not assign confirmed-vulnerability language to this section. E. Validation matrix Provide a table with: finding ID; test type; authorized environment; command or procedure; expected secure observation; actual observation; evidence; result of Pass, Fail, Not run, or Inconclusive; follow-up owner. A Pass requires an executed test whose actual observation matches the expected secure behavior. Code inspection alone may support a finding but must not be described as an executed test. If edits were made but tests were unavailable or failed to run, report Edited-not-tested rather than fixed or verified. F. Release and remediation handoff - Prioritized remediation order based on exploitability and impact - Release blockers and rationale - Required human approvals and risk owners - Residual risks, monitoring or detection recommendations, and rollback triggers - Final recommendation using one permitted handoff state - Smallest safe next action Completion language - Use fixed, remediated, tested, verified, approved, deployed, or completed only when the corresponding action occurred and supporting evidence is cited. - Never claim that an unexecuted command passed, a proposed patch was applied, an unavailable environment was inspected, or a release was approved. - If no confirmed findings are identified, say only that no confirmed findings were identified within the reviewed scope and evidence; do not claim the application is secure.Input for this step
Provide the diff or correction plan, routes and handlers, webhook verification, authorization, validation, secret and configuration handling, and test plan.
Carry forward
Carry evidence-linked security findings, severity, locations, required corrections, and residual risk into pull-request review.
Review note
The security reviewer and engineering owner disposition material security findings before merge readiness is assessed.
-
Step 5 Review the Laravel change set
Conduct a read-only Laravel change review across behavior, authorization, data changes, queues, caches, compatibility, deployment safety, and test evidence. Mark migration review Not applicable when no schema or data migration exists.
Prompt: Evidence-Grounded Laravel Pull Request Review with CodexReview 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.Input for this step
Provide the real diff or change set, diagnosis, payment test plan and results if run, security findings, CI evidence, migration status, and release constraints.
Carry forward
Carry merge blockers, test gaps, behavior, migration and deployment risk, evidence limits, and merge recommendation into release planning.
Review note
The engineering reviewer decides merge readiness; the database owner reviews migration risk only when an applicable migration exists.
-
Step 6 Gate deployment, rollback, and monitoring
Review CI/CD, deployment scripts, applicable migrations, configuration, observability, rollback readiness, and release verification for the payment correction.
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 review output, CI and deployment configuration, rollback options, monitoring, migration status, cache and configuration considerations, and required smoke checks.
Carry forward
Produce the final pre-deploy gates, authorized execution plan, rollback conditions, post-deploy checks, monitoring window, and unresolved decisions.
Review note
The release owner approves merge and deployment; payment, database, security, and operations owners approve actions within their scope, including any live provider verification.
Completion criteria
The workflow is complete when:
- Repository boundaries are confirmed or created before authorized changes.
- Root cause and the smallest correction are tied to supplied code and runtime evidence.
- Payment-specific tests cover signatures, idempotency, retries, ordering, states, and relevant edge cases without false execution claims.
- Security and pull-request findings have explicit dispositions.
- The release owner has observable pre-deploy, rollback, smoke-test, and monitoring gates; any live replay, migration, configuration, provider, or deployment action remains separately authorized.
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.
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.
Verify an AI-Generated Software Change for Release
Reconcile a coding agent’s instructions and completion claims against the actual change set, verify dependency and API assertions, close test-evidence gaps, and prepare controlled release gates.
Was this useful?