Files

Gabriel Radureau 3961914613 docs(adr): ADR-0002 — per-application environments via an env coordinate

Records the decision to extend the <app> join key with a second
coordinate <env>, governed by an elision rule (env=prod elides → every
existing app's derived names are byte-identical and its tofu plan is a
no-op; non-prod envs take the <app>-<env> suffix, with the Postgres
owner role staying snake-case <app>_<env>_role).

Motivated by the ERP's incoming write-capable AI-agent skill: it needs
an in-cluster sandbox instance (erp-sandbox) with a prod-like Dolibarr
API + isolated database to rehearse writes before a human promotes them
to prod. The ADR reconciles this against ADR-0001 honestly — ADR-0001
rejected an in-cluster sandbox for INFRA-change rehearsal (shared
fleet-wide control planes); ADR-0002 operates one layer up where the
agent's only reach is the app's HTTP API against an isolated DB, so the
fleet blast radius is not in scope. The two are complementary; ADR-0002
does not supersede ADR-0001.

Also:
- vibe/ADR/README.md: index row for 0002 + Last Updated 2026-06-25
- PRD safe-prod-like-environment README: bidirectional back-link to
  ADR-0002 on the Adjacent line + Last Updated 2026-06-25

Authored via the ADR Scribe persona, validated via the Continuity Warden
checklist (no-tombstone, breadcrumb, MADR-lite sections, dead-link scan,
bidirectional links).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-06-25 14:55:19 +02:00

safe-prod-like-environment

docs(adr): ADR-0002 — per-application environments via an env coordinate

2026-06-25 14:55:19 +02:00

README.md

docs(vibe): bootstrap vibe/ knowledge tree + ecosystem AGENTS.md

2026-06-23 11:52:37 +02:00

README.md

vibe > PRD

Product Requirement Documents

Status: 🟢 Active Last Updated: 2026-06-23 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

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.