Amo.ng curated workflow
Build and Verify a Tenant-Scoped Paid Booking Slice
Implement one tenant-isolated paid booking journey through identity, availability/reservation, hosted sandbox checkout, payment testing, security review, and release controls.
# Build and Verify a Tenant-Scoped Paid Booking Slice Workflow ID: AMO-W-000037 Workflow URL: https://amo.ng/workflows/build-verify-tenant-scoped-paid-booking-slice ## Outcome Tenant-boundary map, booking/order state transitions, repository/schema manifests, cross-tenant and concurrency tests, hosted-checkout/webhook reconciliation, payment/security findings, disabled fulfilment evidence, rollback and release-owner package. ## Before you begin - Approved tenant-scoped journey - Identity/authorization model - Booking states/capacity/timezone rules - Price/order/fulfilment contract - Repository/schema authority - Hosted-payment sandbox - Synthetic tenants/users/resources/products - CI/CD and rollback context ## Step 1 — Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification **Prompt** Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification **Instructions** Implement only the approved tenant/account boundary needed by one paid booking journey. **Input for this step** Approved slice, repository/stack, tenancy/identity rules, sanitized fixtures, authorized scope. **Carry forward** Tenant-boundary map, authorization/persistence implementation, cross-tenant tests, reversible control. **Review note** Stop if tenancy rules, roles, tenant resolution, schema authority, or synthetic isolation tests are unavailable. **Prompt ID** AMO-P-000346 **Prompt URL** https://amo.ng/prompts/build-multi-tenant-saas-vertical-slice-approved-specification **Prompt content** Implement one complete, approved tenant-isolated user journey through the existing application stack. Build only the vertical slice defined in the supplied specification. Do not expand the work into an entire SaaS product, a generic tenancy framework, or an architecture document. ## Required inputs Approved vertical-slice specification: {{approved_vertical_slice_specification}} Repository and stack context: {{repository_and_stack_context}} Tenancy, identity, and authorization model: {{tenancy_identity_and_authorization_model}} Data interfaces and test fixtures: {{data_interfaces_and_test_fixtures}} Acceptance criteria and authorized scope: {{acceptance_criteria_and_authorized_scope}} ## Evidence and assumption rules 1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite file paths, symbols, schema objects, routes, policy rules, commands, and test output where available. 2. Do not invent tenant-resolution rules, roles, permissions, ownership rules, database fields, lifecycle states, APIs, job behavior, cache behavior, storage conventions, search capabilities, test results, credentials, or approvals. 3. Treat the supplied tenancy and authorization model as the authority contract. If it conflicts with repository behavior or omits a rule that affects isolation, stop the affected implementation path and request a decision from the product owner and security reviewer. 4. UI visibility is not authorization evidence. Require server-side enforcement at every applicable entry point and data boundary. 5. Use synthetic tenants, identities, records, files, and search documents. Do not request secrets, production tenant access, or real customer data. 6. Preserve unrelated repository changes and existing tenant behavior. Do not reformat, replace, or repair work outside the approved slice. 7. Separate changes actually applied and tests actually run from proposed changes, expected behavior, and unverified assumptions. ## Authorization boundaries - Implementation requires an authorized repository, a bounded journey specification, an explicit tenancy and identity model, safe fixtures, and permission to change the identified files. - Inspect only the supplied workspace, configuration, schemas, interfaces, fixtures, and command output. Do not imply access to identity providers, production tenants, external storage, search services, queues, or deployment systems unless the session provides direct evidence. - Change only the approved files, schemas, configuration, and test surfaces. Use local fakes, isolated services, or approved non-production endpoints for jobs, notifications, storage, search, and other integrations. - Do not broaden roles or permissions, replace the identity provider, access production tenant data, activate live billing, deploy, merge, push, publish, communicate externally, or run destructive migrations. - Obtain separate approval before any schema migration with data-loss or lock risk, dependency installation, identity-model change, new cross-system permission, destructive action, or production-adjacent operation. - Stop with a blocked handoff when the approved specification, tenant boundary, safe environment, essential fixture, or authority is absent. ## Implementation method ### 1. Establish the vertical-slice contract Restate the single triggering actor, tenant context, entry route or interface, authorized action, domain transition, persisted or returned result, and observable completion condition. List explicit non-goals. Identify every actor and role in the journey, how the active tenant is resolved, which tenant owns each record, and what happens when the tenant is missing, disabled, deleted, mismatched, or changed. Do not add states or permissions that the specification does not authorize. ### 2. Inspect the repository and current tenant boundary Before editing, inspect the working-tree state, framework and runtime, route and middleware registration, authentication integration, tenant resolver, policies or permission checks, request validation, domain services, models, schema and migrations, query scopes, API resources, jobs, events, notifications, caches, file or object storage, search or indexes, exports, tests, feature flags, and observability. Trace the current journey end to end. Record each source as inspected, unavailable, or not relevant. Identify repository conventions and pre-existing isolation risks without broadening the repair scope. ### 3. Set a concise implementation checkpoint Map every acceptance criterion to affected files, symbols, data objects, authorization rules, test cases, commands, external-effect fakes, and rollback actions. State the smallest coherent change set and the approved schema effect, if any. If implementation would require inventing the tenancy model, replacing foundational identity behavior, changing unrelated modules, accessing production, or using unavailable systems, stop. Provide a precise blocked handoff instead of a fictional implementation. ### 4. Implement trusted tenant resolution Resolve the active tenant from the approved trusted identity, membership, route-binding, or server-side context. Do not trust a client-supplied tenant identifier by itself. Validate membership status, tenant status, and permitted role before entering domain logic. Ensure modified URLs, query parameters, request bodies, headers, object identifiers, and API payloads cannot select another tenant or elevate a role. Return the approved denied or not-found behavior without leaking whether another tenant’s object exists. ### 5. Implement validation, authorization, and domain behavior Apply server-side request validation and explicit authorization before reads, writes, exports, jobs, notifications, or other effects. Keep policy, service, and persistence rules aligned with the approved ownership and role model. Implement the specified domain transition and its loading, empty, denied, validation, conflict, error, and recovery states. Keep the change bounded to the approved journey. Do not add generic administration, billing, onboarding, or unrelated tenant features. ### 6. Implement tenant-scoped persistence Use the approved tenant key, ownership relationship, unique constraints, indexes, and transaction boundaries. Make query scoping explicit at trust-sensitive points. Validate that create, find, update, delete, aggregate, and export operations cannot cross the tenant boundary. For approved schema changes, inspect existing data and migration conventions first. Use reversible migrations and explain lock, backfill, nullability, uniqueness, and rollback behavior. Do not run destructive or production migrations without separate approval. Prevent global uniqueness assumptions from incorrectly blocking legitimate values across tenants or allowing duplicates where uniqueness is tenant-scoped. Do not treat a default model scope as the only protection for sensitive direct-object access. ### 7. Carry isolation across asynchronous and derived systems Where the slice uses background jobs, events, notifications, cache entries, files, object storage, search indexes, or exports: - include the approved tenant identity in the durable payload or storage namespace; - re-resolve and validate tenant and actor authority at execution time where required; - namespace cache keys and invalidation by tenant; - isolate storage paths, retrieval policies, and generated URLs; - apply tenant filters to search indexing and retrieval; - ensure exports contain only the current authorized tenant’s rows; - send notifications only to test sinks during verification; - prevent stale jobs or cached data from surviving a disabled or deleted tenant contrary to the specification. Do not claim these surfaces are isolated if they were unavailable or untested. ### 8. Implement interfaces and recovery states Implement the approved web, API, or command interface using repository conventions. Preserve accessibility, keyboard behavior, responsive states, API contracts, pagination, error shapes, and rate controls where applicable. Provide explicit behavior for loading, no eligible records, validation denial, authorization denial, missing tenant, disabled tenant, stale state, duplicate submission, partial failure, retriable failure, and rollback or feature disablement. ### 9. Add audit and observability evidence Record the minimum safe tenant, actor, action, object, correlation, result, and failure metadata required by the supplied contract. Do not log secrets, sensitive payloads, or unnecessary personal data. Make authorization denial, cross-tenant attempts, job failures, export generation, and feature disablement observable where required. Audit evidence records what the application attempted or decided. It does not itself prove isolation or authorize access. ### 10. Run the tenant-isolation test suite Use at least two synthetic tenants and multiple roles, including an allowed and a denied role. Test the complete journey and all applicable supporting surfaces: - authorized access inside the active tenant; - unauthorized and inactive roles; - another tenant’s valid object identifier; - direct-object access and modified URLs, query parameters, request payloads, and headers; - tenant-scoped create, read, update, aggregation, and delete behavior where included; - duplicate submissions and validation failures; - jobs executed with the expected tenant and attempts to substitute another tenant; - cache-key isolation, stale cache, and invalidation; - file paths, object retrieval, signed URLs, and storage namespace isolation; - search indexing and result filtering; - export row isolation and direct export retrieval; - partial failure and retry behavior; - missing, disabled, or deleted tenant behavior where specified; - feature flag off and rollback behavior. Record the exact fixture identities, commands, exit states, and relevant assertions without exposing secrets. Sequential happy-path tests are insufficient. A passing UI test does not prove server-side authorization, and one data-layer test does not prove jobs, caches, files, search, or exports. ### 11. Reconcile acceptance and prepare rollback Map every acceptance criterion to code and execution evidence. Mark it demonstrated, partially demonstrated, failed, blocked, or not run. Preserve failures and pre-existing issues rather than weakening assertions. Define feature-flag behavior or the smallest reversible control, schema rollback constraints, job and cache cleanup, search or file recovery, and restoration steps. Release remains a decision for the security reviewer and release owner. ## Stop conditions Stop with a precise blocked handoff when: - tenant resolution, ownership, role, or disabled-state rules are missing or conflicting; - the authorized repository or safe test environment is unavailable; - implementation would require production tenant access, live billing, an identity-provider replacement, or broader permission changes; - the slice cannot be tested with two synthetic tenants and multiple roles; - a required job, cache, storage, search, or export boundary cannot be inspected or safely faked; - a destructive migration or irreversible operation lacks separate approval and recovery evidence; - cross-tenant or direct-object tests fail and cannot be corrected within scope; - rollback cannot preserve tenant data integrity. ## Output contract Return these sections: 1. **Vertical-slice implementation status**: `Implemented and tested in the authorized environment`, `Partially implemented`, or `Blocked`. Separate inspected, applied, executed, demonstrated, and unverified work. 2. **Evidence and assumptions register**: source, classification, location, relevance, conflict or limitation, and required owner. 3. **Tenant-boundary map**: entry point, trusted tenant source, actor and role, object ownership, authorization control, persistence scope, derived-system scope, denied behavior, and evidence. 4. **Specification-to-code traceability**: requirement or acceptance criterion, file and symbol, implementation, test, result, and unresolved gap. 5. **Repository change manifest**: file, schema, configuration, job, cache, storage, search, or test item changed; purpose; state; and rollback action. 6. **Schema and persistence record**: tenant keys, ownership links, constraints, indexes, query boundaries, transaction behavior, migration status, and rollback limits. 7. **Authorization matrix**: tenant state, actor role, action, resource ownership, expected result, enforcement location, test result, and evidence. 8. **Cross-tenant isolation test ledger**: test tenant and actor, target tenant and object, interface, attempted manipulation, expected denial, observed result, status, and evidence. 9. **Failure and recovery matrix**: failure, affected state, containment, retry rule, recovery, cleanup, owner, and test evidence. 10. **Feature-flag or rollback plan**: disablement, schema considerations, job and cache cleanup, storage/search recovery, data reconciliation, and verification. 11. **Security and release-owner handoff**: remaining risks, untested surfaces, schema approval, access review, release prerequisites, and accountable owners. 12. **Completion statement**: reconcile every acceptance criterion and end with the smallest safe next action. Completion requires actual authorized code or configuration changes for the bounded journey, server-side tenant enforcement, matching immutable versioned evidence where applicable, executed cross-tenant tests using at least two synthetic tenants and multiple roles, coverage of every included derived-system boundary, and a viable rollback or feature-disablement path. Do not claim the whole SaaS product was built or that tenant isolation, security, or production readiness is established beyond the recorded evidence. ## Step 2 — Build a Conflict-Safe Booking Feature from Approved Requirements **Prompt** Build a Conflict-Safe Booking Feature from Approved Requirements **Instructions** Add availability, reservation, confirmation, cancellation/rescheduling, and concurrency-safe capacity inside that boundary. **Input for this step** Step 1 tenant contract, approved booking states/capacity/timezone rules, repository and sandbox integrations. **Carry forward** Booking state table, code/schema manifest, concurrency/idempotency evidence, recovery and reconciliation procedures. **Review note** Stop for invented state rules, missing timezone/capacity policy, live bookings, unsafe migration, or untestable concurrency. **Prompt ID** AMO-P-000347 **Prompt URL** https://amo.ng/prompts/build-conflict-safe-booking-feature-approved-requirements **Prompt content** Implement one bounded booking journey from the approved requirements. Cover availability, reservation or hold, confirmation, cancellation, rescheduling, and conflict prevention only where those behaviors are supplied. Build working repository changes and collect concurrency evidence; do not design an entire booking business or invent its rules. ## Required inputs Approved booking requirements: {{approved_booking_requirements}} Repository and resource model: {{repository_and_resource_model}} Availability, timezone, and capacity rules: {{availability_timezone_and_capacity_rules}} Integration and notification contracts: {{integration_and_notification_contracts}} Acceptance criteria and authorized scope: {{acceptance_criteria_and_authorized_scope}} ## Evidence and assumption rules 1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite files, symbols, schema objects, state rules, provider contracts, test fixtures, commands, and observed results. 2. Do not invent booking states, resource or capacity rules, hold duration, availability windows, blackout periods, cancellation terms, rescheduling rules, timezone policy, prices, providers, notification behavior, data fields, test results, or approvals. 3. Use the states defined by the supplied requirements. States such as `Available`, `Held`, `Pending`, `Confirmed`, `Cancelled`, `Expired`, `Rescheduled`, and `Failed` are examples only. Do not add or rename them when the approved model differs. 4. Distinguish a proposed transaction or lock from one implemented and exercised. Sequential tests do not demonstrate protection against concurrent booking attempts. 5. Treat local time as ambiguous unless the supplied timezone policy, locale, and daylight-saving behavior resolve it. Preserve the original input and derived instant where the contract requires auditability. 6. Use synthetic users, resources, bookings, provider responses, and notification sinks. Do not request secrets, production customer data, or live calendar access. 7. Preserve unrelated repository and configuration changes. Keep applied changes, proposed work, and unexecuted tests separate. ## Authorization boundaries - Implementation requires an authorized repository, approved booking and resource rules, a safe test database, and enough authority to modify the bounded journey. - Inspect only the supplied workspace, schemas, interfaces, fixtures, provider contracts, and command output. Do not imply access to a production calendar, booking system, payment service, or notification provider. - Change only approved files, schema objects, and disabled non-production integration configuration. Use fakes, mocks, test clocks, synthetic data, and test sinks. - Do not create live bookings, charge customers, send customer-visible notifications, replace an external calendar provider, enable production triggers, deploy, merge, push, publish, or run destructive migrations. - Obtain separate approval before a migration with lock or data-loss risk, production integration, irreversible state change, or action beyond the specified file and environment boundary. - If the approved rules, safe environment, concurrency-capable test setup, or integration contract is absent, stop with a blocked handoff. ## Implementation method ### 1. Establish the booking contract Restate the in-scope actor, resource, capacity unit, availability source, booking window, timezone, hold behavior, confirmation rule, cancellation and rescheduling boundary, integration effects, and observable completion condition. Create the approved state and transition table before editing. For every transition, identify the initiating actor or event, preconditions, capacity effect, idempotency identity, transaction boundary, side effects, denied transitions, expiry behavior, and recovery route. Preserve unspecified or conflicting rules as blockers. ### 2. Inspect the repository and baseline behavior Inspect the working-tree state, framework and runtime, routes, controllers or handlers, authorization, validation, resource and booking models, schema and constraints, availability queries, transactions, locks, queues, provider adapters, notifications, clock handling, tests, feature flags, logs, and current failure behavior. Identify how times are stored and converted, how capacity is represented, and whether an authoritative booking record or provider state exists. Record observed, unavailable, and uninspected surfaces. ### 3. Set a concise implementation checkpoint Map requirements to files, symbols, state transitions, schema changes, invariants, provider boundaries, test cases, permitted commands, external-effect fakes, and rollback actions. Define the smallest coherent journey that can be completed without broadening scope. If there is no editable repository, approved state model, safe test database, or way to run a meaningful concurrency test, stop. Do not return a generic implementation plan and call the feature built. ### 4. Implement the state and persistence model Implement only the approved states and transitions. Enforce transition preconditions in server-side domain logic and persistence, not only in UI controls. Prevent a cancelled, expired, failed, or superseded record from taking an unauthorized path back to an active state. Use approved keys, constraints, indexes, version fields, transactions, and lock or atomic-update behavior. Make the core capacity invariant explicit. Where applicable, confirmed bookings plus unexpired capacity-consuming holds must never exceed the resource capacity for the relevant interval. For capacity greater than one, reserve and release the correct unit count atomically. Ensure expiry, cancellation, failed confirmation, and rescheduling release or transfer capacity according to the contract. Do not rely on a check-then-write sequence without concurrency control. ### 5. Implement availability and time handling Calculate availability from the approved resource schedule, booking window, blackout periods, capacity, holds, confirmed bookings, and exceptions. Define inclusive and exclusive interval boundaries and prevent overlap errors. Use the approved IANA timezone or equivalent authoritative rule. Convert and store instants consistently. Test daylight-saving gaps, repeated local times, date boundaries, and user or resource timezone differences where applicable. When local input maps to no instant or more than one instant, apply the supplied disambiguation rule or reject it clearly. ### 6. Implement create, hold, and confirm behavior Validate resource identity, user authority, requested interval, quantity, availability, and booking window server-side. Use an approved idempotency identity for repeated submissions. Create the hold or booking and claim capacity within the required transaction or atomic boundary. Confirmation must validate the current state, unexpired hold, capacity ownership, and relevant provider evidence. Duplicate requests must return the existing safe result or a defined conflict without consuming capacity twice. ### 7. Implement cancellation, expiry, and rescheduling Apply the approved actor, deadline, reason, and state restrictions. Release capacity exactly once. For rescheduling, use the specified atomic or compensating sequence so the original booking and replacement cannot leave the user with neither slot or both slots unless that is explicitly permitted and recoverable. Make expiry deterministic using an injectable or test-controlled clock. Do not let delayed jobs expire a booking that has already confirmed, and make repeated expiry handling idempotent. ### 8. Bound integrations and notifications Integrate only through the approved provider or calendar interface in sandbox, mock, or disabled mode. Define the authoritative local and provider state, correlation identifiers, timeout behavior, retry eligibility, and reconciliation route. Send all notifications to an approved test sink or fake. Notification failure must not silently corrupt booking state. Keep production activation and customer-visible messages disabled. ### 9. Implement failure and uncertain-completion recovery Handle invalid resources, unavailable slots, expired holds, duplicate submissions, transaction conflicts, provider timeouts, partial provider success, failed persistence after provider response, notification failure, retry exhaustion, and uncertain completion. Record enough safe evidence to reconcile local state, capacity, and provider state. Define when to retry, compensate, release, hold for review, or stop. Do not retry an ambiguous external action until its prior result has been checked. ### 10. Run domain and concurrency tests Use synthetic users and resources. Execute applicable tests for: - an authorized valid booking journey; - two users attempting the final available slot concurrently; - repeated submission with the same idempotency identity; - expired holds and an expiry-confirm race; - capacity greater than one and capacity exhaustion; - invalid, inactive, or unauthorized resource; - booking outside allowed windows and during blackouts; - interval boundaries and overlapping requests; - timezone conversion, daylight-saving gaps, and repeated local times; - cancellation and released capacity; - rescheduling into an occupied interval and rollback of a failed move; - provider timeout, failure, or ambiguous completion; - partial success between local and provider state; - notification failure; - retry after uncertain completion; - feature disabled and rollback behavior. Use a concurrency-capable test method appropriate to the actual database and framework. Record barriers, workers, transactions, exit states, final rows, capacity totals, provider calls, and notification assertions. Do not call a result conflict-safe based only on sequential requests or an in-memory database that cannot exercise the relevant locking behavior. ### 11. Reconcile, recover, and prepare release handoff Reconcile every test booking across state, capacity, idempotency record, provider fixture, and notification sink. Map acceptance criteria to code and actual execution evidence. Document feature-flag or route disablement, migration rollback constraints, safe release of orphaned holds, repair of inconsistent capacity, provider reconciliation, and restoration of the previous configuration. Release remains a decision for the product owner and release owner. ## Stop conditions Stop with a precise blocked handoff when: - booking states, capacity, availability, hold, timezone, cancellation, or rescheduling rules are missing or conflicting; - no authorized repository, safe database, or concurrency-capable test method is available; - implementation requires live bookings, customer messages, charges, production providers, or production activation; - a destructive schema change lacks separate approval and rollback evidence; - provider behavior or the authoritative state cannot be determined safely; - concurrent final-slot tests, idempotency tests, or uncertain-completion recovery fail outside a bounded correction; - time inputs remain ambiguous under the supplied policy; - rollback cannot restore valid booking and capacity state. ## Output contract Return these sections: 1. **Booking implementation status**: `Implemented and tested in the authorized environment`, `Partially implemented`, or `Blocked`. Separate inspected, applied, executed, demonstrated, and unverified work. 2. **Evidence and assumptions register**: source, classification, location, conflict or limitation, implementation effect, and required owner. 3. **Booking-state and transition table**: state, allowed transition, actor or event, preconditions, capacity effect, transaction boundary, side effect, failure route, and evidence. 4. **Requirement-to-code traceability**: requirement, file and symbol, implementation, test, result, and unresolved gap. 5. **Repository and schema change manifest**: file, schema or configuration item, change, reason, risk, applied state, and rollback. 6. **Availability and capacity invariant register**: invariant, enforcement point, transaction or lock, boundary cases, test evidence, and remaining risk. 7. **Concurrency and idempotency test ledger**: scenario, workers or requests, synchronization method, expected result, observed rows and capacity, idempotency result, status, and evidence. 8. **Timezone test matrix**: input zone and local time, expected instant or rejection, daylight-saving condition, observed result, and evidence. 9. **Integration and side-effect record**: provider or notification operation, sandbox or test target, authoritative state, observed effect, prohibited live effect, and reconciliation status. 10. **Recovery and reconciliation procedure**: failure or ambiguity, evidence to inspect, safe retry or compensation, capacity repair, provider reconciliation, owner, and stop rule. 11. **Rollback and release-owner handoff**: feature disablement, schema constraints, orphaned holds, monitoring, release checks, approval, and rollback verification. 12. **Completion statement**: map every acceptance criterion to implementation and execution evidence, then identify the smallest safe next action. Completion requires actual authorized code and configuration changes for the bounded journey, an explicit enforced state model, transactional capacity controls, an executed concurrent final-slot test, idempotency and timezone evidence, tested failure and reconciliation behavior, disabled production integrations, and a viable rollback. Do not claim the wider booking platform was built or that conflict safety, production readiness, or external-provider behavior is established beyond the evidence. ## Step 3 — Build a Hosted-Checkout E-commerce Vertical Slice **Prompt** Build a Hosted-Checkout E-commerce Vertical Slice **Instructions** Add hosted sandbox checkout and verified webhook/order transitions to the booking. **Input for this step** Approved price/order contract, step 2 booking states, hosted-payment sandbox contract, test products. **Carry forward** Catalog/order traceability, checkout/webhook evidence, event-order/idempotency matrix, provider reconciliation, disabled fulfilment. **Review note** Stop for live keys/charges, raw card handling, invented tax/refund rules, production webhooks, or unverifiable provider state. **Prompt ID** AMO-P-000348 **Prompt URL** https://amo.ng/prompts/build-hosted-checkout-ecommerce-vertical-slice **Prompt content** Implement one bounded catalog-to-order journey using the approved hosted-checkout provider in its sandbox. Build the catalog presentation, cart integrity, local order, hosted session, return handling, verified webhook transitions, and reconciliation required by the supplied contract. Keep payment-card collection on the provider’s hosted interface and keep production payment, fulfilment, and customer messaging disabled. Treat this as a medium-risk implementation because it changes order state and integrates with a payment service. Do not expand it into a complete online store, marketplace, subscription platform, inventory system, refund service, dispute process, or administration suite. ## Required inputs Approved catalog, cart, and order contract: {{approved_catalog_cart_and_order_contract}} Repository and stack context: {{repository_and_stack_context}} Hosted-payment sandbox and webhook contract: {{hosted_payment_sandbox_and_webhook_contract}} Test products and fulfilment boundaries: {{test_products_and_fulfilment_boundaries}} Acceptance criteria and authorized scope: {{acceptance_criteria_and_authorized_scope}} ## Evidence and assumption rules 1. Classify material statements as supplied fact, repository observation, provider-contract evidence, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite files, symbols, schema objects, product fixtures, sandbox object or event identifiers, commands, and test output. 2. Do not invent products, prices, quantities, availability, currencies, taxes, discounts, delivery charges, refund rules, legal terms, order states, provider capabilities, webhook behavior, fulfilment behavior, test results, credentials, or approvals. 3. Treat browser cart values and return-page parameters as untrusted. Resolve products and calculate approved prices, discounts, taxes, delivery, currency, and payable totals server-side. 4. The browser success return is navigation evidence, not authoritative payment confirmation. Mark an order paid only from the approved authenticated provider evidence, normally a verified webhook or separately approved server-side verification. 5. Never request, receive, log, store, or reproduce raw card details. Refer to provider credentials and webhook secrets by configuration name only; never include their values. 6. Use synthetic customers, approved test products, sandbox provider objects, fake messages, and disabled fulfilment. Do not use live API keys, production webhooks, or real customer data. 7. Preserve unrelated repository and configuration work. Distinguish changes applied and tests executed from proposals and unverified expectations. ## Authorization boundaries - Implementation requires an authorized repository, approved catalog and order rules, hosted-provider sandbox access already configured securely or a mockable contract, test products, and permission to change the bounded slice. - Inspect only the supplied workspace, schemas, interfaces, sandbox evidence, configuration references, fixtures, and command output. Do not imply access to production payment, fulfilment, tax, inventory, email, or deployment systems. - Change only approved files, schema objects, sandbox configuration references, and test fixtures. Keep production credentials absent, provider live mode disabled, fulfilment disabled, and customer messages routed to fakes or test sinks. - Do not charge a customer, use live keys, replay production webhooks, activate fulfilment, send production order messages, deploy, merge, push, publish, or run destructive migrations. - Obtain separate approval before schema changes with lock or data-loss risk, external calls outside the provider sandbox, dependency installation, financially consequential action, or production activation. - Stop with a blocked handoff if the catalog or order contract, authoritative payment evidence, webhook-signature requirements, safe sandbox, fixtures, or execution authority is unavailable. ## Implementation method ### 1. Establish the bounded commerce contract Restate the approved user journey from catalog view through cart, local order creation, hosted-checkout session, success or cancellation return, webhook processing, final local state, and disabled fulfilment handoff. List included products, quantity and availability rules, currency, pricing authority, taxes, discounts, delivery behavior, order states, payment states, provider events, test fulfilment boundary, and acceptance criteria. Preserve unresolved commercial, tax, delivery, legal, or refund rules as blockers. ### 2. Inspect the repository and payment boundary Inspect the working-tree state, framework and runtime, product and price source, routes, cart state, validation, authorization, order schema, transactions, provider adapter or SDK, checkout-session code, success and cancellation routes, webhook route and middleware, raw-request handling, signature verification, idempotency storage, queues, fulfilment boundary, notifications, tests, feature flags, and logs. Confirm the provider sandbox environment and credential-reference names without revealing values. Identify the authoritative payment-confirmation mechanism and current state-transition rules. Record unavailable or unverified surfaces. ### 3. Set a concise implementation checkpoint Map each requirement to files, symbols, schema or configuration changes, state transitions, provider operations, tests, fakes, and rollback actions. Identify the precise external calls allowed in the sandbox and the evidence they should produce. If an approved product/price contract, editable repository, safe provider sandbox or mock, signed-webhook contract, or testable order model is unavailable, stop. Do not substitute a design document and claim implementation. ### 4. Implement catalog and cart integrity Render only approved active test products and fields. Use stable server-side product and price identifiers. Validate quantity, availability, currency, discount eligibility, tax and delivery inputs against the supplied contract. Treat cart state as a request to purchase, not a financial authority. Re-read current approved product and price data on the server before local order or checkout-session creation. Reject missing or inactive products, invalid quantities, stale or tampered prices, currency mismatches, and unsupported discounts visibly. Do not silently substitute a different product, price, currency, tax, or delivery rule. Record a conflict when approved sources disagree. ### 5. Implement local order creation Implement the approved order and payment states with explicit allowed transitions. Create a local order from the server-verified cart inside the appropriate transaction. Record immutable line-item descriptions, unit amounts, quantities, currency, approved adjustments, total, and provider correlation fields required by the contract. Use an idempotency identity for repeated checkout submissions so one user action cannot create uncontrolled duplicate orders or sessions. Do not mark the order paid or start fulfilment during session creation. ### 6. Implement hosted-checkout session creation Create the provider sandbox session server-side using approved price references or server-calculated amounts, metadata, success URL, cancellation URL, and provider idempotency support where specified. Ensure card collection, authentication, and payment-method handling remain on the hosted provider interface. Handle provider validation errors, timeouts, rate limits, unavailable service, and ambiguous completion. Persist enough non-sensitive correlation evidence to look up the sandbox result before retrying. Never expose secrets or sensitive provider responses to the browser. ### 7. Implement success and cancellation returns Treat the success return as a pending-status display until authoritative provider evidence has updated the order. Do not trust query parameters or the browser session to confirm payment. Provide clear pending, paid, failed, cancelled, expired, and unavailable states according to the approved model. A cancellation return must not overwrite an authoritative successful payment event. Repeated return-page access must be safe and side-effect free. ### 8. Implement webhook verification and event processing Preserve the raw request body where the provider’s signature protocol requires it. Verify the signature, timestamp tolerance, environment, relevant account, event type, object identity, order correlation, currency, and amount before changing state. Reject invalid signatures and mismatched objects without applying business effects. Store a stable provider event identity and payload fingerprint or equivalent approved evidence so duplicate delivery is idempotent and conflicting reuse is visible. Process supported events through explicit order-state transition rules. Handle duplicate, delayed, and out-of-order events without regressing a terminal state or duplicating effects. A verified event may authenticate its contents; it does not authorize behavior outside the approved transition table. ### 9. Keep fulfilment and messages disabled Represent the approved fulfilment handoff behind a disabled feature flag, fake queue, test adapter, or explicit non-production terminal state. Route order messages only to fakes or approved test sinks. Record that a fulfilment action would be eligible only after authoritative payment evidence and required owner controls. Do not ship, grant entitlements, create live inventory movements, or contact customers. ### 10. Implement recovery and reconciliation Handle failed or abandoned checkout, failed session creation, webhook processing failure, ambiguous provider response, database failure, queue failure, delayed events, and local/provider disagreement. Provide an idempotent recovery path that checks provider sandbox state before retrying uncertain session or event work. Reconcile local order ID and state, provider object and event state, amount, currency, event history, and fulfilment-disabled state. Do not force a match by overwriting unexplained differences. ### 11. Run the commerce test suite Use approved test products, synthetic customers, provider sandbox fixtures, and fake fulfilment and notifications. Execute applicable tests for: - valid cart and hosted-session creation; - tampered price or quantity; - missing or inactive product; - currency mismatch and invalid discount; - duplicate checkout submission; - failed, timed-out, and ambiguously completed session creation; - abandoned or cancelled checkout; - successful and failed sandbox payment; - invalid webhook signature and malformed raw body; - duplicate, out-of-order, and delayed webhook events; - amount, currency, environment, account, or order mismatch; - retry after uncertain completion; - return-page access before webhook completion and repeated return access; - local/provider reconciliation difference; - fulfilment and production messaging remaining disabled; - feature flag off and rollback behavior. Record exact commands, provider sandbox or fixture identifiers, expected transitions, observed local rows, provider evidence, queued or blocked effects, exit states, and failures. Do not claim production behavior from sandbox results, or PCI, legal, security, or operational compliance from these tests. ### 12. Reconcile acceptance and prepare rollback Map every acceptance criterion to applied code and execution evidence. Preserve failed or unrun tests. Provide rollback for application files and configuration, schema constraints, pending sandbox orders, event records, queues, feature flags, and the disabled fulfilment boundary. Release remains subject to security review and release-owner approval. Live credentials, production webhooks, fulfilment activation, refunds, subscriptions, disputes, and operational commerce controls remain outside this Prompt. ## Stop conditions Stop with a precise blocked handoff when: - approved products, prices, currency, taxes, discounts, delivery, order states, or payment authority are missing or conflicting; - an authorized repository, safe database, hosted-provider sandbox or mock, or signed-webhook contract is unavailable; - raw card details, live keys, real customers, production webhooks, charges, fulfilment, or customer messaging would be required; - the browser return would be the only proposed payment authority; - signature, amount, currency, environment, account, or order correlation cannot be verified; - duplicate and out-of-order events cannot be processed idempotently; - local and provider sandbox state cannot be reconciled after an uncertain result; - a destructive schema change lacks approval and rollback evidence; - critical payment-state or fulfilment-disablement tests fail outside a bounded correction. ## Output contract Return these sections: 1. **Commerce-slice implementation status**: `Implemented and tested in the authorized sandbox`, `Partially implemented`, or `Blocked`. Separate inspected, applied, executed, demonstrated, and unverified work. 2. **Evidence and assumptions register**: source, classification, location, conflict or limitation, implementation effect, and required owner. 3. **Catalog-to-order traceability**: requirement, product or price authority, interface, file and symbol, implementation, test evidence, and gap. 4. **Repository and configuration change manifest**: file, schema, configuration or adapter item, change, financial or side-effect risk, applied state, and rollback. 5. **Order-state transition table**: current state, event or actor, authenticity and preconditions, next state, prohibited regression, side effect, and evidence. 6. **Price and cart-integrity test record**: product and cart case, server-side authority, manipulation, expected rejection or amount, observed result, and evidence. 7. **Hosted-checkout and webhook evidence**: sandbox object or event, signature and correlation checks, amount and currency, local transition, execution result, and evidence. 8. **Idempotency and event-ordering matrix**: request or event identity, duplicate or ordering scenario, transaction rule, expected result, observed state and effects, and status. 9. **Sandbox order/payment reconciliation**: local order, provider object, amount, currency, local state, provider state, event history, difference, disposition, and owner. 10. **External-side-effect record**: provider call, fulfilment, message, queue, test target, observed effect, prohibited production effect, and disabled-state evidence. 11. **Rollback and release-owner handoff**: feature disablement, schema and pending-order considerations, webhook containment, reconciliation, security review, release prerequisites, and rollback verification. 12. **Completion statement**: reconcile every acceptance criterion and end with the smallest safe next action. Completion requires actual authorized code and configuration changes for the bounded catalog-to-order path, server-side price integrity, a hosted sandbox checkout, verified-webhook state changes, duplicate and out-of-order event evidence, local/provider reconciliation, proof that fulfilment and customer messaging remain disabled, and a viable rollback. Do not claim that a complete store was built or that payments, security, PCI, legal compliance, production readiness, or deployment are established beyond the evidence. ## Step 4 — Laravel Payment Flow Smoke Test and Edge Case Planner **Prompt** Laravel Payment Flow Smoke Test and Edge Case Planner **Instructions** Challenge checkout, webhooks, idempotency, retries, order/entitlement states, and edge-case coverage. **Input for this step** Actual step 3 code/configuration, sandbox artifacts, provider contract, tests and authorization boundary. **Carry forward** Payment-flow test matrix, expected results, missing evidence, replay controls and owner review needs. **Review note** Stop before live replay or provider action; mark unrun cases explicitly. **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 5 — Evidence-Based Code Security Review Prompt **Prompt** Evidence-Based Code Security Review Prompt **Instructions** Review server authorization, tenant isolation, input/webhook security, secret handling, and release blockers. **Input for this step** Repository diff, trust boundaries, payment/booking data flow, security rules, authorized commands. **Carry forward** Evidence-linked findings, severity, required fixes, validation procedures, residual-risk decision. **Review note** Block release if material authorization, isolation, signature, injection, secret, or data exposure evidence is unresolved. **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 6 — CI/CD Deployment Safety Checklist Generator **Prompt** CI/CD Deployment Safety Checklist Generator **Instructions** Gate deployment, rollback, migrations, observability, and owner approval for the bounded slice. **Input for this step** Steps 1-5 implementation and review evidence, CI/CD, feature flags, migration/rollback and monitoring context. **Carry forward** Final conditional release package, blockers, staged rollout, rollback triggers, monitoring and accountable handoff. **Review note** No deployment authorization without approved payment mode, rollback, monitoring, migration and release-owner evidence. **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 same bounded journey passes authorized role/cross-tenant, capacity/concurrency, timezone, price, checkout, signature, duplicate/out-of-order event and recovery checks; material security findings are resolved or block release; no live charge or fulfilment occurs; release remains human-controlled. Scope remains one tenant-scoped booking-to-hosted-checkout journey. Full SaaS-platform construction, subscriptions, marketplace functionality, production billing, live customer or tenant data, live fulfilment, refunds, administrative-platform expansion and production deployment remain out of scope. # Build and Verify a Tenant-Scoped Paid Booking Slice Workflow ID: AMO-W-000037 Workflow URL: https://amo.ng/workflows/build-verify-tenant-scoped-paid-booking-slice Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: Tenant-boundary map, booking/order state transitions, repository/schema manifests, cross-tenant and concurrency tests, hosted-checkout/webhook reconciliation, payment/security findings, disabled fulfilment evidence, rollback and release-owner package. Required inputs: - Approved tenant-scoped journey - Identity/authorization model - Booking states/capacity/timezone rules - Price/order/fulfilment contract - Repository/schema authority - Hosted-payment sandbox - Synthetic tenants/users/resources/products - CI/CD and rollback context ## Step 1 — Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification **Instructions** Implement only the approved tenant/account boundary needed by one paid booking journey. **Input for this step** Approved slice, repository/stack, tenancy/identity rules, sanitized fixtures, authorized scope. **Carry forward** Tenant-boundary map, authorization/persistence implementation, cross-tenant tests, reversible control. **Review note** Stop if tenancy rules, roles, tenant resolution, schema authority, or synthetic isolation tests are unavailable. **Prompt** Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification **Prompt ID** AMO-P-000346 **Prompt URL** https://amo.ng/prompts/build-multi-tenant-saas-vertical-slice-approved-specification ## Step 2 — Build a Conflict-Safe Booking Feature from Approved Requirements **Instructions** Add availability, reservation, confirmation, cancellation/rescheduling, and concurrency-safe capacity inside that boundary. **Input for this step** Step 1 tenant contract, approved booking states/capacity/timezone rules, repository and sandbox integrations. **Carry forward** Booking state table, code/schema manifest, concurrency/idempotency evidence, recovery and reconciliation procedures. **Review note** Stop for invented state rules, missing timezone/capacity policy, live bookings, unsafe migration, or untestable concurrency. **Prompt** Build a Conflict-Safe Booking Feature from Approved Requirements **Prompt ID** AMO-P-000347 **Prompt URL** https://amo.ng/prompts/build-conflict-safe-booking-feature-approved-requirements ## Step 3 — Build a Hosted-Checkout E-commerce Vertical Slice **Instructions** Add hosted sandbox checkout and verified webhook/order transitions to the booking. **Input for this step** Approved price/order contract, step 2 booking states, hosted-payment sandbox contract, test products. **Carry forward** Catalog/order traceability, checkout/webhook evidence, event-order/idempotency matrix, provider reconciliation, disabled fulfilment. **Review note** Stop for live keys/charges, raw card handling, invented tax/refund rules, production webhooks, or unverifiable provider state. **Prompt** Build a Hosted-Checkout E-commerce Vertical Slice **Prompt ID** AMO-P-000348 **Prompt URL** https://amo.ng/prompts/build-hosted-checkout-ecommerce-vertical-slice ## Step 4 — Laravel Payment Flow Smoke Test and Edge Case Planner **Instructions** Challenge checkout, webhooks, idempotency, retries, order/entitlement states, and edge-case coverage. **Input for this step** Actual step 3 code/configuration, sandbox artifacts, provider contract, tests and authorization boundary. **Carry forward** Payment-flow test matrix, expected results, missing evidence, replay controls and owner review needs. **Review note** Stop before live replay or provider action; mark unrun cases explicitly. **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 5 — Evidence-Based Code Security Review Prompt **Instructions** Review server authorization, tenant isolation, input/webhook security, secret handling, and release blockers. **Input for this step** Repository diff, trust boundaries, payment/booking data flow, security rules, authorized commands. **Carry forward** Evidence-linked findings, severity, required fixes, validation procedures, residual-risk decision. **Review note** Block release if material authorization, isolation, signature, injection, secret, or data exposure evidence is unresolved. **Prompt** Evidence-Based Code Security Review Prompt **Prompt ID** AMO-P-000006 **Prompt URL** https://amo.ng/prompts/security-review-prompt ## Step 6 — CI/CD Deployment Safety Checklist Generator **Instructions** Gate deployment, rollback, migrations, observability, and owner approval for the bounded slice. **Input for this step** Steps 1-5 implementation and review evidence, CI/CD, feature flags, migration/rollback and monitoring context. **Carry forward** Final conditional release package, blockers, staged rollout, rollback triggers, monitoring and accountable handoff. **Review note** No deployment authorization without approved payment mode, rollback, monitoring, migration and release-owner evidence. **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 same bounded journey passes authorized role/cross-tenant, capacity/concurrency, timezone, price, checkout, signature, duplicate/out-of-order event and recovery checks; material security findings are resolved or block release; no live charge or fulfilment occurs; release remains human-controlled. Scope remains one tenant-scoped booking-to-hosted-checkout journey. Full SaaS-platform construction, subscriptions, marketplace functionality, production billing, live customer or tenant data, live fulfilment, refunds, administrative-platform expansion and production deployment remain out of scope.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
Tenant-boundary map, booking/order state transitions, repository/schema manifests, cross-tenant and concurrency tests, hosted-checkout/webhook reconciliation, payment/security findings, disabled fulfilment evidence, rollback and release-owner package.
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.
- Approved tenant-scoped journey
- Identity/authorization model
- Booking states/capacity/timezone rules
- Price/order/fulfilment contract
- Repository/schema authority
- Hosted-payment sandbox
- Synthetic tenants/users/resources/products
- CI/CD and rollback context
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 Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification
Implement only the approved tenant/account boundary needed by one paid booking journey.
Prompt: Build a Multi-Tenant SaaS Vertical Slice from an Approved SpecificationInput for this step
Approved slice, repository/stack, tenancy/identity rules, sanitized fixtures, authorized scope.
Carry forward
Tenant-boundary map, authorization/persistence implementation, cross-tenant tests, reversible control.
Review note
Stop if tenancy rules, roles, tenant resolution, schema authority, or synthetic isolation tests are unavailable.
-
Step 2 Build a Conflict-Safe Booking Feature from Approved Requirements
Add availability, reservation, confirmation, cancellation/rescheduling, and concurrency-safe capacity inside that boundary.
Prompt: Build a Conflict-Safe Booking Feature from Approved RequirementsInput for this step
Step 1 tenant contract, approved booking states/capacity/timezone rules, repository and sandbox integrations.
Carry forward
Booking state table, code/schema manifest, concurrency/idempotency evidence, recovery and reconciliation procedures.
Review note
Stop for invented state rules, missing timezone/capacity policy, live bookings, unsafe migration, or untestable concurrency.
-
Step 3 Build a Hosted-Checkout E-commerce Vertical Slice
Add hosted sandbox checkout and verified webhook/order transitions to the booking.
Prompt: Build a Hosted-Checkout E-commerce Vertical SliceInput for this step
Approved price/order contract, step 2 booking states, hosted-payment sandbox contract, test products.
Carry forward
Catalog/order traceability, checkout/webhook evidence, event-order/idempotency matrix, provider reconciliation, disabled fulfilment.
Review note
Stop for live keys/charges, raw card handling, invented tax/refund rules, production webhooks, or unverifiable provider state.
-
Step 4 Laravel Payment Flow Smoke Test and Edge Case Planner
Challenge checkout, webhooks, idempotency, retries, order/entitlement states, and edge-case coverage.
Prompt: Laravel Payment Flow Smoke Test and Edge Case PlannerInput for this step
Actual step 3 code/configuration, sandbox artifacts, provider contract, tests and authorization boundary.
Carry forward
Payment-flow test matrix, expected results, missing evidence, replay controls and owner review needs.
Review note
Stop before live replay or provider action; mark unrun cases explicitly.
-
Step 5 Evidence-Based Code Security Review Prompt
Review server authorization, tenant isolation, input/webhook security, secret handling, and release blockers.
Prompt: Evidence-Based Code Security Review PromptInput for this step
Repository diff, trust boundaries, payment/booking data flow, security rules, authorized commands.
Carry forward
Evidence-linked findings, severity, required fixes, validation procedures, residual-risk decision.
Review note
Block release if material authorization, isolation, signature, injection, secret, or data exposure evidence is unresolved.
-
Step 6 CI/CD Deployment Safety Checklist Generator
Gate deployment, rollback, migrations, observability, and owner approval for the bounded slice.
Prompt: CI/CD Deployment Safety Checklist GeneratorInput for this step
Steps 1-5 implementation and review evidence, CI/CD, feature flags, migration/rollback and monitoring context.
Carry forward
Final conditional release package, blockers, staged rollout, rollback triggers, monitoring and accountable handoff.
Review note
No deployment authorization without approved payment mode, rollback, monitoring, migration and release-owner evidence.
Completion criteria
The same bounded journey passes authorized role/cross-tenant, capacity/concurrency, timezone, price, checkout, signature, duplicate/out-of-order event and recovery checks; material security findings are resolved or block release; no live charge or fulfilment occurs; release remains human-controlled. Scope remains one tenant-scoped booking-to-hosted-checkout journey. Full SaaS-platform construction, subscriptions, marketplace functionality, production billing, live customer or tenant data, live fulfilment, refunds, administrative-platform expansion and production deployment remain out of scope.
Was this useful?
Related Workflows
Browse WorkflowsRecover a Laravel Payment Checkout Failure Safely
Diagnose and correct a Laravel checkout, webhook, or payment-state failure, build payment-specific test evidence, review security and code risk, and prepare controlled release and rollback gates.
Build and Verify an Offline Searchable Directory PWA
Implement an approved searchable directory, add bounded offline PWA behavior, protect its API contract, repair confirmed accessibility regressions, and prepare production verification and rollback controls.
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.