Files

T

Christopher Clendening 96b7ff9766 feat: Add foundational documentation for security, workflow, and project management

- 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.

2026-07-30 13:34:07 -04:00

868 B

Raw Blame History

Retrospective — Sprint ,

Date: YYYY-MM-DD Facilitated by: Project Manager

What went well

Concrete, not generic — specific enough that repeating it is actually actionable.

What didn't go well

Same standard. Name the actual friction, not a softened version of it.

Root causes

For anything in "what didn't go well" — why did it actually happen, not just what happened. This is the section that turns a retrospective from a vent into something useful.

Changes for next sprint

Concrete, ownable changes — not "be more careful."

Change — owner

Memory update

This is the section that matters most: what from this retro gets written into memory/lessons-learned.md? A retrospective that produces no memory update didn't do its job (WORKFLOW.md). List the exact entry (or entries) added, so it's traceable.

868 B Raw Blame History