A full-stack optimistic release engine designed to stay honest when the network is not.
This is the recommended submission for Anzibloom’s Full-stack Engineer — Optimistic interface coding assessment. It concentrates the reviewer signal into one system: interface behavior, optimistic state, API design, concurrency control, failure recovery, and technical judgment are all observable in the same action.
This is not a dashboard mockup. The command deck is attached to a real Express API and a deterministic network edge. The hero’s Run the failure path button executes the same reducer, scheduler, retry policy, and server contract covered by the tests.
- Open the live system and press Run the failure path in the hero.
- Watch projected state advance before the request settles.
- Enter the command deck and observe
503 → retry_wait → same-key retry → server v5. - Switch to Contention and issue three writes: independent resources run concurrently while stale versions become explicit
412rollbacks. - Go Offline, mutate Atlas, reload, and watch the IndexedDB outbox recover the original intent.
- Export the mutation transcript, then challenge the implementation in
DECISIONS.md.
| Reviewer question | Executable answer |
|---|---|
| Does the UI really update optimistically? | Confirmed state and projected state are separate; a pure reducer derives every optimistic frame. |
| Can retries duplicate an effect? | Stable UUID + payload fingerprint + in-flight coalescing + settled-result replay. |
| Can stale clients overwrite newer truth? | Every write carries If-Match; mismatches return typed 412 problems with the latest resource. |
| Does intent survive interruption? | Unsettled commands are transactionally persisted in IndexedDB and restored with the same key. |
| Can one resource block all work? | The scheduler serializes within a resource and runs independent resources concurrently. |
| Can tabs rewind each other? | BroadcastChannel propagates acknowledgements; the reducer accepts only strictly newer versions. |
| Can reset lose a race? | Client epochs and server generations fence responses from the obsolete scenario. |
| Will public reviewers corrupt each other’s demo? | A bounded LRU/TTL registry isolates the canonical store, chaos profile, and idempotency ledger per browser scenario. |
| Are the failure claims reproducible? | Seeded chaos is keyed by semantic scenario coordinates and attempt number; UI and test runs agree. |
flowchart LR
A[Operator intent] --> B[Pure optimistic reducer]
B --> C[Projected interface]
B --> D[IndexedDB outbox]
D --> E[Per-resource scheduler]
E -- X-Scenario-Id --> F[Isolated scenario registry]
F -- Idempotency-Key + If-Match --> G[Command API]
G --> H[Deterministic chaos edge]
H -- 503 --> I[Bounded same-key retry]
H -- 412 --> J[Adopt truth + explicit rollback]
H -- 200 --> K[Canonical acknowledgement]
I --> E
J --> B
K --> B
K --> L[Monotonic cross-tab broadcast]
The central rule is deliberately boring and difficult to break:
projected UI = latest confirmed state + active local intent
Canonical data is never mutated to fake responsiveness. Rollback changes the command’s status; the next render falls naturally out of the projection.
| Condition | Visible behavior | Recovery contract |
|---|---|---|
| Slow acknowledgement | Intent remains projected and transport stays observable | Wait without freezing the interface |
Retryable 503 |
Projection survives; attempt count advances | Bounded exponential backoff with the original key |
Version conflict 412 |
Latest server truth replaces the stale base | Settle ambiguous intent as rolled back |
| Offline + reload | Intent remains in the local mutation ledger | Restore as queued and resend when connected |
| Concurrent duplicate | Both callers receive one canonical result | Coalesce in flight or replay the stored result |
| Reset during flight | Old response is rejected at the scenario boundary | Client epoch + server generation fence |
Live product: rollforward-engine.onrender.com
Requires Node.js 24+.
npm install
npm run dev- Product:
http://localhost:5173 - API:
http://localhost:8787 - Readiness:
http://localhost:8787/healthz
npm run check
npx playwright install chromium
npm run test:e2eThe same suite can challenge the deployed system directly:
PLAYWRIGHT_BASE_URL=https://rollforward-engine.onrender.com npm run test:e2eThe current evidence is 38 deterministic unit/integration tests + 7 real-browser journeys. The browser suite exercises the guided failure path, optimistic convergence, IndexedDB reload recovery, explicit conflicts, cross-tab propagation, responsive overflow, reduced motion, and axe-core accessibility at desktop and mobile widths.
GitHub Actions repeats the locked install, source verification, production builds, Chromium installation, and browser suite on every push. A separate pinned Google OSV workflow scans the lockfile on every main push and every week, fails on known vulnerabilities, and retains its SARIF evidence with the workflow run.
The repository ships one deployable artifact: Express serves the compiled React client and the command API from the same origin. That keeps the content-security policy strict and the browser/API contract simple.
The public Docker deployment is live at rollforward-engine.onrender.com. Its landing page, health check, isolated API, security headers, and all seven browser journeys were verified after deployment.
- Multi-stage, non-root
Dockerfile - Declarative Singapore-region
render.yaml - HTTP readiness check at
/healthz SIGTERM/SIGINTrequest draining for zero-downtime replacement- Bounded public-demo state: 256 browser scenarios, 30-minute idle TTL, 512 replay records per scenario
- No external fonts, stock media, analytics, cookies, or secrets
The scenario registry is intentionally process-local. A real multi-node product would move canonical state and idempotency records into a transactional shared store; this demo does not disguise that boundary.
| Concern | Start here |
|---|---|
| Product and scope | PRODUCT.md |
| Decisions and alternatives | DECISIONS.md |
| Correctness invariants | docs/ARCHITECTURE.md |
| 90-second review path | docs/REVIEWER_GUIDE.md |
| Threat model and non-goals | docs/THREAT_MODEL.md |
| Optimistic decision core | src/domain/engine.ts |
| API/idempotency boundary | server/app.ts |
| Public scenario isolation | server/session-registry.ts |
| Adversarial browser evidence | e2e/rollforward.spec.ts |
The private timed starter package was not accessed or redistributed. This independent proof-of-skill was built from Anzibloom’s public role description so the technical approach can be reviewed before any official timed attempt.
OpenAI Codex materially assisted with research, implementation, testing, visual review, and documentation. The candidate remains responsible for understanding and defending every submitted decision; the disclosure is repeated in DECISIONS.md.