didericis-claude
88b82a169e
Expand the PRD from a schema sketch to the full contract the issue mandates (issue is spec-only: 'defines the contract; implementation may be split into follow-up PRs'): - Envelope: add observed vs event timestamps, bottle/activation ids, manifest_digest + policy_version, actor/action/resource/outcome, correlation_id/causation_id, sensitivity class, typed payload, segment id. - Add a per-field trust-provenance table (trusted vs claimed for every common field); per-type trusted/claimed in the registry. - Canonicalization: normative, reproducible hash-chain test vectors; idempotency (id key, UPSERT), ordering guarantees, and behavior across rotation/restart/import/truncation (truncated-tail vs gap). - Storage: indexable fields + local audit query/verify/rebuild/import CLI. - Registry: cover all mandated groups incl hostctl.*, egress request/decision/cutoff/anomaly, commit.signed (#480), auth/authz, and audit.* self-events; schema-evolution + backward-compatible reader rules. - Export: #324 delivery contract (payload, (epoch,seq) cursor, dedup, backpressure, retention ordering); #480 mapping preserving its byte-to-activation-key guarantee. - No raw prompt/response/body capture by default. - Add an acceptance-criteria coverage table mapping each #487 checkbox to a section. Refs #487 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Product requirement docs
One PRD per feature: what to build, why, and how it's scoped. The PRD
is the durable spec — it should stand on its own without a Gitea issue
thread (see ../README.md for when a PRD is the right
document vs. a research note or a decision record).
Naming and numbering
New PRDs may use a prd-new-<kebab-title>.md placeholder name while the
design is being drafted. Before merge, assign the next sequential number
after the highest-numbered PRD on main, rename the file to
NNNN-<kebab-title>.md, and update the title header. CI blocks merging
while any prd-new-*.md placeholder remains. If concurrent PRs select the
same number, the later PR must take the next available number before it
merges. Numbers are never reused; gaps are fine.
Once numbered, the filename stays fixed for the life of the doc.
Status
The Status: line near the top tracks the PRD's lifecycle:
- Draft — proposed, not yet shipped.
- Active — the design has shipped to
mainand is in effect. - Superseded by PRD NNNN — replaced by a later PRD; kept for history.
- Retargeted by PRD NNNN — folded into a later PRD's scope.
Format
# PRD prd-new: <short title> ← replace with the final number before merge
- **Status:** Draft
- **Author:** <who>
- **Created:** YYYY-MM-DD
- **Issue:** #<n> # optional — convenience pointer only
## Summary
One paragraph: what this builds and the pain it solves.
## Problem
The current state and why it's inadequate.
## Goals / Success Criteria
Bullets a reviewer can check the finished work against.
## Non-goals
What this explicitly does not do — and won't, to head off scope creep.
## Scope
In scope / out of scope, when the boundary needs spelling out.
## Design
How it works: schema, data flow, diagrams, algorithms as needed.
## Implementation chunks
Ordered, mergeable steps (optional; for multi-PR features).
## Open questions
Unresolved decisions — resolve or fold into Design before shipping.
Sections are a guide, not a straitjacket: drop the ones a given PRD doesn't need (a small change rarely needs Scope or Implementation chunks) and add others where they help (e.g. Testing strategy, Alternatives considered, References). Keep the rationale self-contained — inline the reasoning rather than linking out to an issue thread, so the PRD survives a move off Gitea.