Files

T

arcodangeandClaude Fable 5 8e4186dbeb docs(prd): agent catalog — task→(prompt+model+orchestrator) matrix + agent-facing file syntax

New agent-catalog.md leaf answering three operator directions:
(1) the document surface agents read is now specified — AGENTS.md
orientation maps, SKILL.md with trigger-carrying descriptions
(Use-when/SKIP-for), atom.yaml registry contracts, thin prompt.md
files (no business rules in prompts — rules live in profile files
and validators), schema'd fiscal.yaml/calendar.yaml with
effective_from dates, [AGENT]/[HUMAN] runbooks, env-var-indirected
.mcp.json; same-change freshness rule extended to the fleet.
(2) hermes's telegram-gateway confirmed as THE human channel when
available (cluster-served cards, email fallback; D1 operator-endorsed).
(3) the categorization to prove: seven agent classes (incl. the
LLM-free deterministic controller) and a T01-T17 assignment matrix
with per-row proof gates and statuses (proven / to-prove / not-built),
re-scored monthly from run journals (fallback rate >20% = wrong cell).
New D8 (fleet code home, leaning erp fleet/).

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

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

ai-back-office

docs(prd): agent catalog — task→(prompt+model+orchestrator) matrix + agent-facing file syntax

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