57 lines
1.4 KiB
Markdown
57 lines
1.4 KiB
Markdown
# `BEP-XXXX` - Title Case Summary
|
|
|
|
```text
|
|
Status: Draft | In Review | Accepted | Implemented | Rejected | Returned for Revision | Superseded | Archived
|
|
Proposal: BEP-XXXX
|
|
Authors: <name(s) or agent ids>
|
|
Coordinator: <name>
|
|
Reviewers: <people, bots, contributors>
|
|
Constitution Sections: <II, III, IV, etc.>
|
|
Implementation PRs: <link(s)> (optional while drafting)
|
|
Decision Date: <YYYY-MM-DD or Pending>
|
|
```
|
|
|
|
## Summary
|
|
|
|
One or two paragraphs that state the desired outcome and why it matters.
|
|
|
|
## Motivation
|
|
|
|
- What problem exists today?
|
|
- Why should Burrow solve it now?
|
|
- Which issues, incidents, or constraints support the change?
|
|
|
|
## Detailed Design
|
|
|
|
- Architecture and boundaries
|
|
- Data model and migration plan
|
|
- Protocol or API changes
|
|
- Observability, testing, and failure handling
|
|
|
|
## Security and Operational Considerations
|
|
|
|
- Access and secret handling
|
|
- Abuse, downgrade, or supply-chain risks
|
|
- Rollback and kill-switch plans
|
|
|
|
## Contributor Playbook
|
|
|
|
Give the concrete steps, commands, checks, and evidence a contributor should produce while implementing or rolling out the change.
|
|
|
|
## Alternatives Considered
|
|
|
|
List alternatives and why they were rejected.
|
|
|
|
## Impact on Other Work
|
|
|
|
- follow-up tasks
|
|
- dependencies
|
|
- compatibility constraints
|
|
|
|
## Decision
|
|
|
|
Record the final call, who made it, and any conditions.
|
|
|
|
## References
|
|
|
|
Link relevant issues, specs, transcripts, and external research.
|