# Build a Conflict-Safe Booking Feature from Approved Requirements

Amo ID: AMO-P-000347
Version: 1.0.0
Public URL: https://amo.ng/prompts/build-conflict-safe-booking-feature-approved-requirements

Summary: Implement one approved booking journey with explicit states, capacity invariants, transactional conflict prevention, timezone handling, sandboxed integrations, recovery, and concurrency evidence.

Use this for: Use this for implementing availability, reservation, confirmation, cancellation, and rescheduling as one bounded booking feature with executed conflict and recovery tests.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: feature build

## Best Use Cases

1. Implementing appointment or resource booking where the final slot must be protected under concurrent requests.
2. Adding expiring holds, capacity rules, cancellation, and rescheduling to an existing application.
3. Building a timezone-aware reservation journey with disabled calendar and notification integrations.
4. Replacing sequential booking tests with transaction, idempotency, conflict, and uncertain-completion evidence.

## Prompt Body

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.

## Variables to Replace

1. approved_booking_requirements
2. repository_and_resource_model
3. availability_timezone_and_capacity_rules
4. integration_and_notification_contracts
5. acceptance_criteria_and_authorized_scope

## How to Use

Run this Prompt in Codex with the authorized application repository, approved booking states and rules, resource and capacity model, timezone policy, sandbox or mock integration contracts, synthetic fixtures, acceptance criteria, and exact file and command permissions. Do not provide secrets, live booking data, or production provider access. Ask Codex to implement only the bounded journey and run a concurrency-capable final-slot test plus idempotency, timezone, failure, and recovery cases. The product owner and release owner must review state rules, migration risk, provider boundaries, conflict evidence, and rollback before release.

## Example Use Case

A shared-equipment application needs one approved reservation journey with 15-minute holds, capacity of two, confirmation, cancellation, and rescheduling. Codex implements the supplied states and transaction boundary, validates timezone-aware windows, directs calendar and notification effects to fakes, and uses two concurrent synthetic users to contest the final unit. The handoff includes final database state, idempotency, expiry, provider-timeout, reconciliation, and rollback evidence without creating live bookings.

## Tags

1. codex
2. Codex & Coding
3. feature-build
4. state-transition
5. concurrency
6. concurrency-control
7. database-locks
8. idempotency
9. capacity-planning
10. integration-tests
11. transaction-integrity

## Dates

Published: 2026-09-09
Updated: 2026-09-09