Contents

Built With Spec4

Built With Spec4 is a live gallery of small apps, every one planned with Spec4 and built by a coding agent working from Spec4's phase files. Each app demonstrates one tier of the ladder Agentifier recommends from, so you can see what a tier looks like as software. It was planned in nine rounds, with hand edits between them, and its full .spec4/ history — v0 through v8, every artifact and every phase file — is in its repository.

The apps

App Tier Round
Embeddings embeddings v1
Single Call single_call v2
RAG rag v0
Tool Use tool_agent v0
Chained Calls chained_calls v3
Planning Agent planning_agent v4
ReAct Loop planning_agent v7
Orchestrated Subagents orchestrated_subagents v5
Multi-Agent Collaboration multi_agent_collaboration v6

Two apps share the planning_agent tier on purpose: Planning Agent fixes its plan up front, and ReAct Loop discovers it one observation at a time. The tier ladder is on the Agentifier page.

Every app runs on free OpenRouter models through LiteLLM, with per-session run caps so a public demo can't spend the quota. The caps are stated on each app's page.

The nine rounds

One line per round, from each vision.json's revision_history:

Round What it planned Agents run
v0 The framework — landing page, shared model and embedding services, the Exa search integration — and the first two apps, RAG and Tool Use. Hosted on Render's free tier. 7
v1 Embeddings, as a visual explorer on the framework's existing embedding model. 7
v2 Single Call, in simple and schema-constrained modes. 6
v3 Chained Calls: a writer and a critic, capped at two calls. 6
v4 Planning Agent: plan, approve, then execute, under a per-run call cap. 6
v5 Orchestrated Subagents: a coordinator briefs two of four specialists, runs them concurrently, merges. 6
v6 Multi-Agent Collaboration: a buyer negotiates against two sellers holding private constraints, over A2A-shaped messages. 6
v7 ReAct Loop, in deliberate contrast with v4. 6
v8 Hosting moved from Render to a self-hosted VPS, behaviour-preserving; PostgreSQL with pgvector stays on Neon. 5

IMPLEMENTED is present in all nine. Seven of the eight brownfield rounds open with an integration thread; v3 went straight to backend work. v8 skipped Designer and Agentifier, since nothing it planned had a screen or a model call; Deployer ran only when the deployment changed — v0, v1, and v8. Run the agents a round needs.

Phases in v0v4 run 7 to 14 instructions; the agentic-pattern rounds v5v8 run 14 to 26.

The recommendation and the decision

Agentifier writes its recommendation and the developer's decision to the same file. From .spec4/v0/ai_catalog.json:

{
  "name": "rag_example_app",
  "tier_recommendation": "single_call",
  "tier_decision": "rag",
  "tier_decision_rationale": "The whole point of this example is to illustrate the use of RAG, so the retrieval pipeline is intentional despite the small dataset size."
}

The tool argued against the agent; the developer decided; the file records both. Every other product feature across v1v7 shows recommendation and decision agreeing; the infrastructure entries — embedding_pipeline, vector_index, agent_loop_runtime, and the rest — carry no recommendation, because they're injected from the tier's pattern file rather than chosen.

Hand edits, reconciled

Between v0 and v1 the developer changed the code without Spec4, and the next round's CodeScanner read it. Three things entered the codebase that no v0 artifact mentions:

Term In a v0 artifact? In v1's code_review.json? Later in a spec?
Groq no yes — change_risks, from the README v6 on in phases; stack.json in v8
model_registry no yes — change_risks, from the README phases in v2v4 and v6v8; stack.json from v7
oxlint no yes — coding_style.linter, from package.json v4 and v6 phases; stack.json in v8

The v1 review's one recorded change risk is the free-tier model chains in model_registry.py rotting as providers retire slugs — a risk in code the plan never asked for, caught on the next scan. Rounds

Deployment

The VPS runs the plan Deployer wrote in v8. It opens with instructions for the coding agent named for the round, then the whole system, one target at a time. The web client's block, from .spec4/v8/deployment-plan.md:

### `web_client`

- **Type:** on-premise (self-hosted VPS)
- **Provider:** netcup — VPS 500 G12 (2 vCore, 4 GB DDR5 ECC, 128 GB NVMe, always-on)
- **Service:** Caddy 2 serving static files from `/srv/bws4/frontend/dist`
- **Region:** netcup European datacenter (Nuremberg / Vienna / Amsterdam). Choose the one nearest your primary audience — this bears directly on `nfr_pages_appear_within_about_a_second`.
- **Transport:** HTTPS only. Automatic Let's Encrypt issuance and renewal by Caddy, automatic HTTP→HTTPS redirect.
- **CORS:** not applicable — serves the browser origin itself rather than consuming one.

Build: `npm ci && npm run build` executed **on the VPS** by `deploy/deploy.sh`, producing a hashed bundle with route-based lazy-loaded chunks per example app. Served with SPA history fallback.

The plan's Configuration Files section carries the Caddyfile, the systemd unit, deploy/deploy.sh, and a CLAUDE.md for the coding agent, complete. Its Roadmap records what was considered and not provisioned — CI, fail2ban, snapshots — so a later round can pick them up.

The nine rounds predate Spec4's usage recording, so there is no cost line for them; Spec4's own rounds carry one on the front page.