01
The operational problem
One-off objects can be promised twice when temporary interest exists only in private messages and is not reflected in the availability state seen by other users.
INVENTORY COORDINATION
A transaction-backed hold workflow lets eligible users reserve scarce catalog items for a limited time, with conflict checks, project context, release, and scheduled expiry.
Evidence statusImplemented system
02
The system response
We implemented transactional callable functions and scheduled expiry around hold metadata, eligibility limits, project mirrors, conflict rejection, release, and restoration.
03
Operational impact
A bounded hold becomes visible in both catalog availability and the user’s project context, with explicit paths for rejection, manual release, and automatic expiry.
INVENTORY COORDINATION
Implemented scope
26Temporary Holds
- 01
Firestore transaction and active-hold conflict check
- 02
Project ownership validation
- 03
Account-type validation
- 04
Ten-total active-hold limit
- 05
Three-per-product-type limit
- 06
One-hour expiry metadata
- 07
Public on-hold availability state
- 08
Project hold mirror records
- 09
Manual release callable
- 10
Scheduled expiry sweep
04
Technical foundation
TypeScriptFirebase AuthFirebase Cloud FunctionsFirestore transactionsCloud SchedulerNext.js cache revalidation
Responsive product and project UI backed by transactional Functions and scheduled expiry logic.
05
Implementation notes
Claims on this page describe implemented scope at a high level. Private interfaces and live operational data are not published.
Operational impact