Files

T

arcodangeandClaude Fable 5 44ae6ff323 docs(prd): client dossiers — the junction of the three agent families

Operator insight 2026-07-11: the second brain's client dossiers
(01-Projects/Clients/<client>/) are where the back-office fleet meets
the sales chain and the future delivery agents working on client
projects. Knowledge-layer bullet: agent-owned deposit files (never
edits of human notes), each family feeds and reads the dossier
(billing state + contract facts in; dunning tone, contract scope,
new-business sightings out — the KM 4% settlement clause makes
delivery observations a billing input); vault routing doctrine
(local-first) for confidential client content. Backlog updated with
the 2026-07-11 CRM audit facts (propal/contrat/projet modules empty,
KM retainer terms only in WIP JSON — deferred schedule = T06's source
of truth) and the third family (delivery agents; Granola→vault ingest
as an sb.py job; REX → Mode B evidence → CMS).

Co-Authored-By: Claude Fable 5 <[email protected]>

2026-07-11 20:32:35 +02:00

ai-back-office

docs(prd): client dossiers — the junction of the three agent families

2026-07-11 20:32:35 +02:00

safe-prod-like-environment

docs(prd): AI back-office — agent fleet for daily admin & accounting

2026-07-11 14:25:04 +02:00

README.md

docs(prd): AI back-office — agent fleet for daily admin & accounting

2026-07-11 14:25:04 +02:00

README.md

vibe > PRD

Product Requirement Documents

Status: 🟢 Active Last Updated: 2026-07-11 Related: vibe/ADR · vibe/Investigations

vibe/PRD/ holds the Product Requirement Documents that drive larger pieces of work in the lab. A PRD captures what we want and why it matters; the matching ADRs capture how we decided to build it, and investigations capture what we learned along the way.

Convention

One subfolder per PRD, kebab-case (e.g. safe-prod-like-environment/).
Each subfolder MUST contain:
- README.md — the PRD hub: problem, goals/non-goals, requirements, success criteria, and a QA strategy.
- STATUS.md — the implementation tracker. Update it whenever something ships (a PR merges, a brick lands, a milestone closes). It is the living view of "where are we" against the PRD.
A big PRD uses tree-docs: the README.md stays a hub and detail lives in leaf pages (each with its own breadcrumb and bidirectional cross-links). A tree-sized PRD MUST detail an explicit QA strategy — how the delivered work will be verified, and what "done and safe" means.
PRs cross-link to the PRD, and the PRD's STATUS.md cross-links back to the PRs/ADRs/investigations that realised each part. Links are bidirectional.
No-tombstone rule applies: the PRD reads as currently true. Progress lives in STATUS.md (which is a tracker and may legitimately list shipped items), not as "previously / now" edits scattered through the hub.

Index

PRD	Hub	Status
Safe, production-like environment	safe-prod-like-environment/README.md	🟡 In design
AI back-office (admin & accounting agent fleet)	ai-back-office/README.md	🟡 In design

Rules to contribute

Create a kebab-case subfolder named for the PRD.
Add README.md (the hub) and STATUS.md (the tracker). Both carry a breadcrumb first line and the leaf header blockquote (Status / Last Updated / Related).
In the hub, state the problem, goals and non-goals, requirements, success criteria, and the QA strategy. If the PRD is large, split detail into leaf pages and keep the README as a navigable hub.
Keep STATUS.md current: every time a piece ships, record it there and link the PR/ADR that delivered it.
Add a row to the Index table above.
Ensure every PR that implements part of the PRD links to the PRD, and that STATUS.md links back. Bidirectional links are mandatory.