Conventions, not configuration

You point sitrep at the folders where your projects live. That is the whole setup. There is no import step, no vault, and nothing is copied or moved - it reads your files where they are.

Real workspaces are mostly noise, and not just node_modules and build output: the bulk is machine-shaped markdown that real work accumulates - issue-tracker exports, archived records, vendored docs, files that are markdown only in extension. An exclusion engine separates project documents from all of that - in the corpus sitrep is developed against, roughly 54,900 markdown files narrow to about 730 real docs. What counts as a doc is visible and adjustable, not a black box.

Watching uses kernel file events, never a directory walk, so startup is instant and steady-state work is proportional to what changed - not to how big your corpus is. Editors that save atomically (write a temp file, rename it over the target) are handled; the document updates even though the file system never reported its name.

Agent-written project docs converge on a handful of shapes. sitrep parses those shapes - and only those - into structured state:

The reading surface is deliberately shaped like an email client, not a file tree: newest activity first, pending items surfaced, filters as removable chips. Across every project at once you see what moved, what is stalled, what is waiting on a decision, and what the docs claim beside when they last changed.

Opening a document gives full reading fidelity - GitHub-flavored markdown, syntax-highlighted code with copy buttons, Mermaid diagrams rendered offline and theme-aware, KaTeX, callouts, fast on multi-thousand-line files. Rendering is a floor sitrep meets, not the product it sells.

And nothing takes the page away from you: when a watched file changes, the open document refreshes in place, scroll re-anchored; reload restores your position; Esc peels one layer at a time.

The nastiest failure mode of agent-written docs is drift: the agent patches code without updating the plan, and a confident document describes a reality that no longer exists. A stale plan looks exactly like a current one - until something compares the claim against what actually moved. That comparison is what sitrep does.

A document claims work is happening when it carries an active dated status (in progress, planned, blocked) or a phase list that has started but not finished. For every claiming doc, sitrep asks four questions, strongest first, and the first "yes" wins:

The badge always shows the number that tripped it - "left behind 40d" means your project moved 40 days past this document. And the signal is computed fresh at the moment you ask, never stored, so the staleness flag is the one thing in the system that cannot itself go stale.

The thresholds were measured, not guessed: every flag was read against the real development corpus before the feature shipped, and the intuitive two-week drift threshold would have flagged half of everything - so it is thirty days, a line at which the reviewed false-positive rate on the live corpus was zero. When sitrep is not sure, it stays quiet: a missed stale doc is invisible, but a false "this doc lies" would poison the one promise the feature makes. And because projects have rhythms, the thresholds are settings, not constants: global, per-workspace and per-project granularity, the most specific value winning, your deviations stored as data while the measured defaults stay in code. A fast-moving project can call three days stale while a quarterly one is fine at ninety - and since staleness is computed at read time, a changed threshold is true on the next view, no reindex.

sitrep is a reader with exactly one, narrow writing surface: three convention-shaped operations - set a status, set a due date, mark a ruling superseded - each writing a single line in the document's own convention, behind a server-side preview and a content-hash guard that refuses to touch a file that changed since you looked at it.

No other code path writes to your documents. Sorting, filtering, hidden columns and saved views are local view state with export - they never touch the file. This is a product-level covenant, not an implementation detail.

Every extraction rule ships only after being measured against the real development corpus - if a heuristic would misread the corpus, it does not ship. Every UI behaviour is verified by driving the real app in headless Chrome: contrast in both themes, scroll restoration, live refresh, the lot. A claim that cannot be measured is not made.