- 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.
1.2 KiB
1.2 KiB
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.
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 whatPLANE.mdassumed. ../GITEA.mdand../ACT_RUNNER.mdcurrently 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>