TrashPal is a work-in-progress reference application for one commercial organics collection exception. Its local operator workspace exists because a provider can accept a dispatch while its acknowledgement is lost. A blind retry can duplicate work, while assuming failure can leave a missed collection unresolved. A dispatcher therefore reviews a proposed recovery, approves the exact payload, and reconciles an uncertain dispatch before any retry.
Status: Work in progress. The local demo exercises one synthetic recovery loop. It is not a deployable service, production-ready operational guidance, or evidence of live-provider performance.
Pal may inspect case-scoped evidence and prepare a cited recovery. Deterministic lifecycle code owns approval, dispatch, reconciliation, and the final receipt. The missed-collection workflow and every repository record are synthetic; they do not represent a real operation.
The local path makes each authority transition inspectable. Pal prepares; the dispatcher approves; the lifecycle reserves and sends; reconciliation decides what the evidence supports.
flowchart LR
A[Recorded synthetic case] --> B[Pal: bounded investigation]
B --> C{Cited recovery?}
C -->|Yes| D[Dispatcher approves exact binding]
C -->|No| E[Hold or escalate]
D --> F[Deterministic reservation and dispatch]
F --> G[Reconcile outcome and receipt]
Diagram: A recorded synthetic case enters a bounded investigation. A cited recovery may proceed to exact dispatcher approval, durable dispatch, outcome reconciliation, and a receipt; an unsupported recovery stops or escalates instead.
The default local demo uses a deterministic reasoner and does not contact a model provider. It is an architecture demonstration, not evidence of live-model quality or operational performance.
Use Node 22 or later and Corepack. Install the pinned dependencies once:
corepack enable
pnpm install --frozen-lockfileRun the complete local verification suite with:
pnpm checkRead the architecture contract, synthetic scenario corpus, and local verification receipt. The receipt documents what the local fixtures prove and, equally importantly, their limits.
Start Docker, then run these commands in three terminals from the repository root, in this order: services, API, then web.
pnpm demo:servicespnpm demo:apipnpm demo:webOpen http://127.0.0.1:3212. The browser flow is source records, prepare, approve and reserve, dispatch, reconcile, then receipt.
The web client calls the loopback API through same-origin /v1 requests. The API issues an HttpOnly local-demo cookie and resets its dedicated loopback demo schema on startup. PostgreSQL, VROOM, case records, and the lost-ack dispatch profile run locally. This demo does not contact a CRM, fleet provider, model provider, analytics service, or cloud account.