Apply an approved reconciliation plan only if stock is unchanged
An operator reviews a drift report, but a fresh vendor event arrives before Apply. Bind corrections to the reviewed before-state so approval cannot overwrite a newer update.
- Focused work estimate
- 3h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Optimistic concurrency · Authorization · Transactional updates · Audit logs
Estimated field mix
- Integrations40%
- Database engineering40%
- Security20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional retailer receives stock from two vendor warehouses. The vendor API paginates snapshots and emits change events, but retries and deleted products have caused unexplained stock drift. Work against a local vendor simulator.
Setup prerequisites
- Create a local vendor API simulator with cursor pages and stock events.
- Use synthetic tenants, SKUs, and warehouse records; no vendor account is required.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- SYNC-101 · Validate vendor stock records at the adapter boundary
- SYNC-102 · Map vendor items without assuming SKUs are globally unique
- SYNC-103 · Resume a paginated snapshot from the last committed page
- SYNC-104 · Ignore stale stock events while retaining their delivery record
- SYNC-106 · Distinguish a discontinued item from an item missing on one page
- SYNC-107 · Produce a stock drift report before applying corrections
Acceptance criteria
- A plan records each item before revision, proposed quantity, source snapshot, and a canonical plan digest.
- Application verifies permission, plan digest, and every current before revision in one transaction.
- Any stale item blocks the plan with a conflict; approved applications record an append-only actor audit.
Implementation constraints
- Choose all-or-nothing application for this bounded exercise.
- Recovery creates a new reviewed plan; it does not rewrite the old approval.
Verification to include
- Apply an unchanged plan and verify exact proposed quantities and one audit record.
- Advance one item revision before apply and confirm no item in the plan changes.
Deliverables
- Reviewable correction plan and stale-approval tests
Rollout and recovery
Allow only explicitly authorized operators to apply plans; keep a read-only report mode available if conflicts spike.
Value of the work
For the engineer: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure.
For the team: Inspect whether integration changes protect inventory correctness and give operators a clear 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.