The Atlas

doc.haus documentation, bound to its code

Journeys

Zero to a running demo

From a fresh clone to asking a fictional engagement letter about its liability cap — the fastest way to feel what doc.haus is.

5 stops →

How a question becomes a cited answer

Follow one question — "What is the cap on the firm's liability?" — from the qa agent through local embeddings to a verified [Document § 9] citation in the browser.

5 stops →

The redline pipeline

From "change clause 9" to native Word tracked changes — proposal, review, and the accept that bakes the edit into the canonical .docx.

7 stops →

Fork discipline: staying mergeable with OpenCode

doc.haus pulls upstream innovation with git merge upstream/dev. This path shows the rules that keep that merge clean and the seams where the legal product actually lives.

5 stops →

Getting Started

The front door: the product README and the fictional demo matter. Together they take you from a clone to a seeded "Aldgate Mills — Engagement (Demo)" workspace with five suggested exercises — cited Q&A, tabular review, multi-agent review, drafting and case-law research — without touching a real document.

Demo matter First run, demos to others, or safe testing of new agents and tools.
README First contact with the project, or when you need the product's own framing of its privacy posture.

Architecture & Design

How the system actually runs: the three-process topology (engine :4096, ingest :4500, web :5173), the OpenCode session-runtime terminology the fork inherits, provider resolution and data-egress guarantees, and a code-verified analysis that measures the prose docs against the tree and flags where they have drifted.

Architecture Joining the project and you want the intended design in one read — pair it with ARCHITECTURE-ANALYSIS.md for the measured reality.
doc.haus — Architecture & Technology Analysis (code-verified) When you need authoritative numbers or suspect the prose docs have drifted — this doc is the drift detector in long form.
OpenCode Session Runtime When working on or reasoning about the V2 session core and you need the vocabulary the specs use.
Providers and confidentiality First-launch configuration, swapping providers, or assessing data egress for a deployment.
Threat model: prompt injection via untrusted documents

Legal Domain Layer

The fork's own brain: ten agents, one command and three skills under dochaus/, all plain markdown with YAML frontmatter. This is where routing precedence, citation discipline ([Document § section] with verbatim excerpts), tracked-changes-first editing and the reviewer → challenger → summarizer pipeline are defined — no TypeScript required to change agent behaviour.

Technical Specs

Design documents, mostly inherited from upstream OpenCode's V2 effort: session runner and durable-event architecture, config schema review, provider/model catalogs and policy, storage migration off the legacy db.ts wrapper, plus the fork's own Docxodus spike that validated the redline engine. Statuses range from completed migrations to open work-in-progress checklists.

Catalog / Config / Plugin Lifecycle Options Implementing plugin lifecycle, config hot-reload, or catalog rematerialisation.
Docxodus spike scratch Re-running the spike evidence; otherwise skip.
Effect Drizzle SQLite Package Working on the storage layer or the Effect migration.
Policy Authoring provider allow/deny rules or implementing their evaluation.
project Designing or consuming the multi-project server routes.
Provider and Model Catalog Adding a provider plugin or debugging catalog/model resolution.
Remove `packages/opencode/src/storage/db.ts` Auditing the storage migration or hunting a regression that smells transactional.
Session API Working on the session runner, the prompt inbox, or consuming the events API.
Spike #1 — Docxodus under Bun + offset alignment Touching the redline/tracked-changes/word-integration tools or wondering why edits are text-anchored.
TODO Picking up V2 work or checking whether a gap is known and owned.
V2 Config Review Touching config parsing or migrating user configs to V2.
V2 Core Instructions Writing or reviewing a new core service or plugin hook.
V2 Schema Changelog Replaying durable events, writing a migration, or upgrading across V2 iterations.

Fork & Governance

The rules of the fork: AGENTS.md's mergeability-first principles (CLAUDE.md is a one-line pointer to it), the contributor guide split between doc.haus and upstream expectations, the self-hosted security posture, and the deprecated FUTURE.md that now redirects to GitHub issues.

CLAUDE Only to confirm where the actual guidance lives; read AGENTS.md instead.
Contributing to doc.haus Before opening a PR or issue — against the fork or upstream.
doc.haus Before writing any code in this repo — it decides where your change is allowed to live.
doc.haus — Future Seams (DEPRECATED) Only for history; current work is tracked on GitHub issues.
Security — doc.haus Evaluating doc.haus for firm deployment, exposing it beyond localhost, or reporting a vulnerability.

Package Docs

READMEs and design notes shipped inside the upstream OpenCode packages (packages/*). Indexed for search so upstream concepts are findable, but not curated — they document code the fork deliberately never edits.

Upstream Dev Config

OpenCode's own development config inherited under .opencode/ — dev agents, commands and prompt fragments. Search-only: useful for understanding how upstream works on itself, out of scope for the fork's documentation.

Doc Builds

The Atlas's own paper trail: which commit each curation pass was authored against and what changed in the authored layer between builds.

Atlas doc-build log Checking how stale the authored curation is before trusting a summary, or before running an --update pass.