Project context

A fictional equipment retailer lets customers choose a refund or replacement after inspection. Its payment and stock providers can time out after accepting an operation, so retrying the whole return is unsafe. Create a local TypeScript application, PostgreSQL state/outbox tables, and synthetic provider doubles with controllable outcomes; no starter code or fixtures are supplied. Use invented orders and integer minor-unit amounts only, with no real payments or external provider calls.

Setup prerequisites

• SQL transactions
• Idempotent commands
• Async failure handling
• State modeling

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

• PRECOVER-101 · Reject return decisions that skip inspection or reverse a completed refund
• PRECOVER-102 · Bind a repeated refund request to its original merchant and intent
• PRECOVER-103 · Commit approved return work and its dispatch record together
• PRECOVER-104 · Persist replacement progress across stock reservation and shipment creation
• PRECOVER-105 · Open the refund circuit without declaring timed-out refunds failed
• PRECOVER-106 · Keep stalled stock calls from consuming every refund execution slot
• PRECOVER-107 · Stop compensation retries when a replacement has already shipped
• PRECOVER-108 · Preview the exact return command before an operator requests replay
• PRECOVER-109 · Rehearse returns recovery at every commit and provider acknowledgment boundary

Acceptance criteria

• Define bounded admission and fair scheduling between new and recovery work, with retry jitter generated from a reproducible test seed.
• Coordinate half-open probes, provider pool limits, and the shared database budget so reopening cannot enqueue or execute the entire backlog at once.
• Report backlog age, queue occupancy, rejection/defer counts, and completion time for the declared local load; justify selected limits and remaining shared bottlenecks.

Implementation constraints

• No universal throughput target is assumed; state machine resources, workload, and acceptable service objectives before comparing capacity settings.

Verification to include

• Recover a seeded 2,000-return backlog while submitting new work and verify bounded concurrency, queue sizes, and progress for both classes.
• Make the provider fail again during recovery and cancel waiting work; assert permits are released, retries remain durable, and no tight retry loop forms.

Deliverables

• Recovery scheduling policy, reproducible saturation run, and capacity tradeoff report

Rollout and recovery

Enable recovery scheduling with conservative limits and a pause control; reduce admission before shrinking active pools and preserve pending command identities.

Value of the work

For the engineer: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts.

For the team: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.