Files

T

arcodangeandClaude Fable 5 5430e5f3ac docs(prd): dated roadmap leaf — Gantt, milestone spine, re-baselining rule

New roadmap.md: mermaid Gantt (validated) putting the six phases on
calendar time from baseline 2026-07-11 — P2 e-invoicing opens the plan
(ADR D4 target 08-14, two-week fallback before the hard 09-01), P1
flagship in parallel (golden set first, A2 earned ~10-09), ledger-
compliance verifications early September (FY-2026 FEC depends on the
accounting-module answer), P3 standing fleet through autumn (sentinel
24/7 ~11-13), P4 money-loop exit over December, P5 riding the fiscal
calendar (acompte 12-15, CA3 switch 01-01, Q1 filing April, CA12 early
May, AG 06-30), P6 e-reporting proven months before 2027-09-01.
Immovable-milestone table, dependency notes, re-baselining rule
(engineering bars slide, diamonds don't — slips shed scope instead).
Wired: hub pointer + leaves row, poc-plan/STATUS backlinks.

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

2026-07-11 15:02:02 +02:00

ai-back-office

docs(prd): dated roadmap leaf — Gantt, milestone spine, re-baselining rule

2026-07-11 15:02:02 +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.