# @garuda/engine — Stage-1 walking skeleton

**The first code of the foundation build.** It proves the load-bearing thesis:

> **Config (Blueprint + Workflow) *produces* runtime.** The engine interprets the published
> config and runs one HU end-to-end — with **no per-customer code.**

## Run it
```bash
node src/run.js      # or: npm run demo
```
It loads the published config from `architecture/structural-model/retailer-a/` and runs the same
engine over three scenarios; every threshold, label, device and quantity comes from that config.

## Stage-1 end game (the acceptance it checks)
- **Happy (50 valid):** RECEIVED → … → ACCEPTED → COMPLETED · counters 50/50/50/50 · stock **+50 once** at ACC-01 · EPCIS events · GRN txn.
- **Short (49), tolerance 0:** → **ON_HOLD** · **no stock.**
- **Replay the happy HU:** stock **still 50** (idempotent).
- **The proof:** the runner greps `engine.js` — **no per-customer literals** (tenant / warehouse / HU / quantity are all config).

## What it is (and isn't)
- **Is:** a runnable interpreter — graph walker + guard evaluators + onEntry actions + a deterministic device stand-in + an in-memory event log. Reuses the Blueprint's states/rules/slots as *data*.
- **Isn't (Stage-2+):** the real event log (**lift from tag-mgmt**, ADR-0008), persistence, the device simulation service (ADR-0006), real EncoderRegistry wiring, full process-generic dispatch (ADR-0009), and integration via the IH (ADR-0007). Guard evaluation and per-state ops are keyed by Blueprint ids here — **customer-generic now, process-generic later.**

## Traceability
Change-spec: CHG-001/002 (config), 003/004 (interpreter+engine), 006 (rules), 013 (Commission), 015 (device sim), 007-thin (events). ADR-0009/0010/0005/0008.