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

bash demo.sh walks through all 43 endpoints. bash validate.sh tests all endpoints + cleanup. bash demo-cleanup.sh removes artifacts.

✅ 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

localhost:8080/docs