task-list.rs

Clean-architecture full-stack starter in Rust + React, built to light up the whole Azure stack end-to-end. Developed by the 4-pack agentic loop.

Features

• Mobile-first, offline-first installable PWA (offline/PWA layer lands in a later slice).
• Clean architecture: a Cargo workspace with a strict domain ← application ← infrastructure/api dependency flow and ports/adapters (dependency inversion) at every external seam.
• Agentic development in action.
• Stack: Rust (axum) · React 19 + TypeScript + Vite · GitHub Actions CI/CD · Containers · Azure Container Apps · Cosmos DB · Azure Blob Storage · Auth0 (Google) · App Insights.

How this was built — the agentic loop

Built by a small self-improving, hub-and-spoke, human-in-the-loop agentic loop — a crew of AI agents that doesn't just build the product, it sharpens itself each cycle. JARVIS orchestrates and every agent hands back to it; per task the flow is Dave implements → Bhaskar verifies → Anders design-reviews → Mr. Das decides. Work happens on vibe/<feature> branches — main is never touched directly — and JARVIS owns git and the PR.

• Mr. Das (human) — the visionary owner in the Iron Man mold: sets the direction, makes the final call, runs end-to-end testing, merges to main, and ships.
• JARVIS — the unflappable, dryly polite orchestrator (an AI butler of that same lineage); sequences hand-offs and owns git, the task file, and the PR.
• Anders — the exacting architect who reasons from first principles and won't let a layering violation slide; design and review only (no code, builds, or commits).
• Dave — the steady, pragmatic coder who just gets the task done (no commits/pushes).
• Bhaskar — the rigorous verifier who trusts nothing until the build, tests, and contracts prove it (no code, no commits).

The engine of that self-improvement is the periodic retrospective: every few features it distills what worked (and what didn't) back into the guardrails and agent playbooks, so each cycle sharpens the next — JARVIS reminds the human when one is due.

Repository layout

domain/          Entities, value-object newtypes, enums, domain errors (zero inbound deps)
application/     Use-cases, port traits, DTOs, application errors (depends only on domain)
infrastructure/  Port adapters (in-memory now; Azure later) + config loader
api/             axum host: routers, OpenAPI, RFC7807, SPA serving, composition root
web/             React 19 + TS + Vite SPA
scripts/         Local-dev PowerShell helpers
docs/            design.md (project map + rules + full design), features/
Dockerfile       Multi-stage build → single image serving the API + SPA on one port

See docs/design.md for the full design + hard rules.

Prerequisites

• Rust ≥ 1.88 (stable), Node.js 22+, Docker (for the container build).
• Optional local tooling: cargo install cargo-watch (used by scripts/dev.ps1).

Quick start

Clone, then run the whole local loop (API watcher + Vite) with ./scripts/dev.ps1 and open the Vite dev URL it prints — the health indicator turns green off a live GET /api/health. API docs at /swagger, spec at /api/openapi.json.

Full launch/restart/liveness details: run-app skill and scripts/dev.ps1.

Build & test

Commands live in the skills — single source of truth, not restated here:

• build-test skill — fast gate: fmt · clippy (-D warnings) · unit tests · web lint/typecheck/test/build.
• build-test-full skill — full gate: adds the release build and the OpenAPI client drift check.

The committed OpenAPI spec + typed client (web/src/ApiClient.generated.ts) are regenerated and drift-checked per the build-test-full skill; see also docs/design.md.

Container

The multi-stage Dockerfile builds a single image serving the API + SPA on port 8080 (docker build -t tasklist . && docker run --rm -p 8080:8080 tasklist).

Conventions

Hard rules — dependency flow, zero-warnings, never editing generated files, and secret handling — live in docs/design.md.