Files
bot-bottle/docs/prds
didericis-claude 8e43c26ab4 fix(backend): extract poll_ca_cert helper and fix PRD port docs
Extract the shared CA cert polling loop into `backend/util.poll_ca_cert`
(firecracker and macos backends were duplicating deadline/sleep/raise logic).
Each caller now wraps a fetch lambda and converts TimeoutError to its own
error type. Also corrects the PRD port publication line from {port}:{port}
to {host_port}:8099.
2026-07-21 04:54:40 +00:00
..
2026-05-07 22:45:36 -04:00

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 use a prd-new-<kebab-title>.md placeholder name while the PR is open. On merge to main a CI workflow assigns the next sequential number (0024-…, 0025-…), renames the file, and updates the title header. 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 main and 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>    ← placeholder; CI fills in the number on 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.