Christopher Clendening
96b7ff9766
- Create SECURITY.md to outline security policies and practices. - Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective. - Introduce decision log structure in decisions/README.md for tracking architecture decisions. - Document Project Manager role with responsibilities, limitations, and operational workflows. - Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints. - Set up memory logs for architecture and company-wide lessons learned. - Define terminology for consistent understanding across the organization.
35 lines
1.1 KiB
Markdown
35 lines
1.1 KiB
Markdown
# ADR-NNNN: <title>
|
|
|
|
**Status:** Proposed | Accepted | Superseded by ADR-NNNN | Rejected
|
|
**Date:** YYYY-MM-DD
|
|
**Author:** <employee role/identity>
|
|
**Approved by:** <Architect, + Founder if it clears the FOUNDER.md approval-gate table>
|
|
|
|
## Context
|
|
|
|
What situation makes this decision necessary? What constraints (technical, organizational,
|
|
timeline) are in play? A future reader should understand the problem without needing to have
|
|
been present for the discussion.
|
|
|
|
## Decision
|
|
|
|
What was decided, stated plainly and specifically enough to act on.
|
|
|
|
## Alternatives considered
|
|
|
|
What else was on the table, and why it wasn't chosen. This is the section that keeps the same
|
|
question from being re-litigated later without new information.
|
|
|
|
- **Alternative A** — why not
|
|
- **Alternative B** — why not
|
|
|
|
## Consequences
|
|
|
|
What becomes easier, harder, or different as a result of this decision. Include the honest
|
|
downsides, not just the benefits — an ADR that only lists upside isn't trustworthy.
|
|
|
|
## References
|
|
|
|
Links to related ADRs, the Plane epic/story this came from, and any relevant project's
|
|
`PROJECT.md`.
|