mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-09-07 08:27:12 +00:00
86b1fbef7f
## Summary
Ask Fabro sessions are now run-bound instead of standalone. Sessions are
created under their owning run, then accessed by flat session ID routes,
with durable state projected from the run event stream rather than a
separate session store.
## Changes
- Move session creation/listing to `POST/GET /api/v1/runs/{id}/sessions`
while keeping flat session reads, turns, interrupts, and event streams
under `/api/v1/sessions/{id}/...`.
- Add typed `run.session.*` events, ULID-backed session/turn IDs,
read-only default permissions, and a rebuildable SlateDB `session_id ->
run_id` index.
- Remove the old file-backed session store and wire the server, runtime,
Rust client, generated API crates, and TypeScript client around run
event projections.
- Replace the old top-level CLI session command with `fabro run ask` for
chatting with a run.
- Regenerate the TypeScript API client; this also catches up existing
generated models for Pair/run event detail schemas already present in
the OpenAPI spec.
## Validation
- `cargo build -p fabro-api -p fabro-client -p fabro-server -p
fabro-cli`
- `cargo nextest run -p fabro-server --features test-support -E
'test(run_bound_session_is_created_as_run_event_and_resolves_by_flat_id)
| test(sessions_are_listed_only_under_their_owning_run)'`
- `cargo nextest run -p fabro-store
projection_rebuilds_runtime_context_from_run_events`
- `cargo +nightly-2026-04-14 clippy -p fabro-api -p fabro-client -p
fabro-store -p fabro-server -p fabro-cli --all-targets -- -D warnings`
- `cargo +nightly-2026-04-14 fmt --check --all`
- `cd lib/packages/fabro-api-client && bun run typecheck && cd
../../../apps/fabro-web && bun run typecheck`
- `git diff --check`
---
[](https://github.com/EveryInc/compound-engineering-plugin)
Generated with GPT-5 via [Codex](https://openai.com/codex)
57 lines
2.7 KiB
Text
57 lines
2.7 KiB
Text
---
|
|
title: "Demo Mode"
|
|
description: "Explore the Fabro API with realistic static data and no external dependencies"
|
|
---
|
|
|
|
Demo mode lets you explore every Fabro API endpoint without configuring authentication, running real workflows, or connecting external services. Every response returns realistic static data so you can build and test integrations against a predictable dataset.
|
|
|
|
## How It Works
|
|
|
|
Demo mode is activated **per-request** by sending a header:
|
|
|
|
```
|
|
X-Fabro-Demo: 1
|
|
```
|
|
|
|
When the server receives this header, it routes the request to a parallel set of demo handlers that return static JSON instead of hitting the real backend. Authentication is bypassed — no credentials are needed.
|
|
|
|
Requests **without** the header are routed to the real API as usual, so demo and production traffic coexist on the same server.
|
|
|
|
## Using Demo Mode
|
|
|
|
### With curl
|
|
|
|
```bash
|
|
curl http://localhost:3000/api/v1/runs -H "X-Fabro-Demo: 1"
|
|
```
|
|
|
|
### With the Web UI
|
|
|
|
Set the `FABRO_DEMO=1` environment variable when starting the web app. This configures the frontend to send the `X-Fabro-Demo: 1` header on every API request and disables authentication in the UI:
|
|
|
|
```bash
|
|
FABRO_DEMO=1 bun run dev
|
|
```
|
|
|
|
## What Demo Mode Covers
|
|
|
|
Demo mode implements every API endpoint. Read endpoints return static data representing a realistic workspace with completed runs, workflows, sessions, verifications, and more. Write endpoints (creating runs, answering questions, sending messages) accept the request and return a canned response without persisting any state.
|
|
|
|
| Endpoint group | Behavior |
|
|
|----------------|----------|
|
|
| Runs | Lists and detail views return static run data across multiple statuses |
|
|
| Workflows | Returns sample workflow definitions and associated runs |
|
|
| Sessions | Returns sample chat sessions with message history |
|
|
| Human-in-the-Loop | Questions return static data; answers are accepted but not stored |
|
|
| Run Outputs | Compare, usage, and verifications return realistic static results |
|
|
| Run Internals | Stages, turns, checkpoints, context, and configuration all return static data |
|
|
| Verifications | Categories and controls with pass/fail examples |
|
|
| Insights | Saved queries and history; execute returns a canned result |
|
|
| Projects | Sample projects and branches |
|
|
| Settings | Platform configuration |
|
|
|
|
## Limitations
|
|
|
|
- **No state changes.** Write operations return a success response but nothing is persisted. Creating a run returns a fixed ID; it won't appear in subsequent list calls.
|
|
- **No SSE streaming.** Event stream endpoints such as `/api/v1/runs/{id}/events` return immediately rather than streaming.
|
|
- **Static data only.** The same data is returned regardless of path parameters — requesting any run ID returns the same run detail.
|