domus-api
Project Summary
REST API that exposes the entire domus-captures documentation system as 43 programmable endpoints. 2,935 AsciiDoc files across 21 content categories, 1,107 partials, 495 examples, 21 standards, 53 projects, and 127 antora.yml attributes — all queryable as JSON. No database — the filesystem IS the database. FastAPI auto-generates OpenAPI schema, making the entire documentation system self-describing and machine-readable.
Every content category has a dedicated endpoint. Every skill (/incident, /project, /rca, /change-request) is a POST endpoint. Every document — pages, partials, examples — is queryable. The documentation system is an API.
Status
| Phase | Description | Status | Notes |
|---|---|---|---|
Phase 1: Read + Search |
39 GET endpoints — every content category: pages, standards, case studies, skills, worklogs, patterns, codex, sessions, graph, education, portfolio, reference, templates, api-hub, objectives, discoveries, runbooks, meta, drafts, trackers, partials, examples |
✅ Done |
21/21 page categories + 1,107 partials + 495 examples. Full-text search, backlink analysis, Aristotelian taxonomy. |
Phase 2: Write Operations |
5 write endpoints — incidents (STD-011), changes (STD-005), RCAs (STD-010), projects (STD-001), PATCH project status |
✅ Done |
Scaffolder + PATCH. Cache invalidation on all writes. |
Infrastructure Hardening |
CLAUDE.md, pytest suite (48 tests), DI refactor (Depends pattern), cache invalidation, STD-NNN filter, API CLI Mastery curriculum |
✅ Done |
Test suite: 48/48 in 0.3s. Module-level cache injection replaced with FastAPI Depends. |
Architecture Documentation |
Full architecture doc — endpoint table, stack rationale, Phase 3-5 design |
✅ Done |
Includes Ollama RAG, Multi-Spoke, and Automation architecture. |
Demo + Validation |
|
✅ Done |
Presentation-ready. 43/43 validated. |
Phase 3: Ollama Integration |
Natural language queries against documentation via local LLM |
❌ Not started |
RTX 5090 + qwen3:30b. RAG over AsciiDoc files. |
Phase 4: Multi-Spoke |
Add all 15 spoke repos to config — unified search across entire ecosystem |
❌ Not started |
Config change only — architecture already supports it. |
Phase 5: Event Automation |
Webhooks — incident resolution auto-triggers RCA, filesystem watcher refreshes cache |
❌ Not started |
inotifywait or watchfiles for filesystem events. |
The Problem
A senior infrastructure engineer produces documentation every day. Worklogs, incident reports, change requests, root cause analyses, project plans, CLI patterns, security findings — thousands of documents across years of practice. The documentation lives in AsciiDoc files, rendered through Antora, deployed to a static site.
The site is readable. The content is structured. But the knowledge is trapped.
You cannot ask the system "what did I write about Mandiant?" without opening a browser and clicking through pages. You cannot create an incident report without switching to a terminal, remembering the right skill command, and hoping the template hasn’t changed. You cannot query your standards programmatically. You cannot let another tool — another machine, another agent — interact with your knowledge.
The documentation exists. The documentation is excellent. But it has no voice. It cannot speak to anything except a human with a browser.
The Design Response
domus-api exposes the documentation system as a REST API. Every document becomes a queryable resource. Every standard becomes a machine-readable contract. Every operational workflow — incident creation, change request scaffolding, root cause analysis — becomes a POST endpoint that produces files identical to what a human would create manually.
The filesystem is the database. There is no Postgres, no SQLite, no ORM. AsciiDoc files are the records. The directory structure is the schema. The Antora component is the data model. When you curl localhost:8080/search?q=mandiant, the API searches the same files you would search with grep. When you POST an incident, the API writes the same file your /incident skill would create.
Nothing is abstracted away. Nothing is duplicated. The API is a window into the filesystem, not a copy of it.
Requirements
| # | Requirement | Status |
|---|---|---|
R1 |
Every content category in domus-captures must have a dedicated GET endpoint |
✅ 18/20 categories routed |
R2 |
Every standards-governed document type must have a POST endpoint |
✅ 4/4 (STD-001, 005, 010, 011) |
R3 |
No database — filesystem is single source of truth |
✅ pathlib + in-memory cache |
R4 |
OpenAPI schema auto-generated from code |
✅ FastAPI + Pydantic |
R5 |
Writes must comply with the same standards a human would follow |
✅ Scaffolder embeds templates |
R6 |
POST writes must be immediately visible to GET reads |
✅ Cache invalidation on all writes |
R7 |
Test coverage for all endpoints |
✅ 48 pytest tests, 45 validate.sh checks |
| Field | Value |
|---|---|
PRJ ID |
PRJ-2026-04-domus-api |
Author |
Evan Rosado |
Created |
2026-04-06 |
Updated |
2026-04-07 |
Status |
Active — 44 endpoints (40 GET + 4 POST), 48 tests, DI refactor complete |
Category |
Software / API Development |
Priority |
P1 |
Stack |
FastAPI, Pydantic v2, uvicorn, PyYAML |
Repository |
~/atelier/_projects/personal/domus-api/ |
Endpoint |
localhost:8080 (Tailscale accessible) |
OpenAPI Docs |
Related
-
domus-captures — the documentation system this API exposes
-
API CLI Mastery — jq/curl/httpx curriculum using domus-api