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.
31 lines
1.2 KiB
Markdown
31 lines
1.2 KiB
Markdown
# Architecture Memory
|
|
|
|
Technical context that spans projects: shared-infrastructure quirks, integration details
|
|
between Gitea, Plane, and ACT Runner discovered in practice, and patterns worth reusing across
|
|
projects rather than rediscovering each time. Primarily maintained by the Architect role, but
|
|
open to any engineer who learns something worth keeping. See [../MEMORY.md](../MEMORY.md).
|
|
|
|
## Log
|
|
|
|
*No entries yet.*
|
|
|
|
Known gaps to fill once true, not written speculatively:
|
|
|
|
- Plane is not yet deployed (`../PLANE.md`) — once it is, record actual workspace conventions
|
|
discovered during setup here if they differ from what `PLANE.md` assumed.
|
|
- `../GITEA.md` and `../ACT_RUNNER.md` currently use placeholders for instance URLs and runner
|
|
labels — once replaced with real values, note here anything about the actual instances (quirks,
|
|
constraints, capacity) that future engineers should know but that doesn't belong in the policy
|
|
docs themselves.
|
|
|
|
Format for new entries:
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
|
|
<the technical fact or pattern>
|
|
|
|
**Why:** <how it was discovered / why it matters>
|
|
**How to apply:** <what future work should do differently because of this>
|
|
```
|