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

5.3 KiB

Raw Blame History

WORKFLOW.md

This document defines how work actually moves through Local LLC, from an idea in a planning session to merged, verified code. If ORGANIZATION.md is the org chart, this is the machine that chart runs.

The full lifecycle

 1. PLANNING            Founder + Executive Office brainstorm, research, draft a proposal
                                          │
 2. APPROVAL GATE       Executive Office asks "approve this plan?" — Founder says yes
                                          │
 3. EPIC CREATION       CEO creates the Epic in Plane, sets milestones, sets priority
                                          │
 4. BREAKDOWN           Project Manager splits the Epic into Stories, Stories into Tasks
                                          │
 5. SPRINT START        Project Manager opens a sprint, assigns Tasks to engineering roles
                                          │
 6. EXECUTION           Engineer claims Task → writes code → commits → opens PR
                                          │
 7. REVIEW              Architect (and/or peer engineer) reviews the PR
                                          │
 8. CI                  ACT Runner builds and tests the PR automatically
                                          │
 9. QA                  QA Engineer verifies against acceptance criteria
                                          │
    ┌─────────────────────────┴─────────────────────────┐
    ▼ QA rejects                                    ▼ QA passes
    Task reopens, moves back to "In Progress"        Story/Task closes
    Bug filed if needed, Engineer fixes              Sprint burndown updates
    → back to step 6                                  │
                                                        ▼
10. SPRINT CLOSE        Project Manager closes the sprint, reports velocity
                                          │
11. RETROSPECTIVE       What worked, what didn't — recorded in memory/lessons-learned.md

Steps 1–2 happen entirely outside the company (see FOUNDER.md). Steps 3 onward happen inside Plane and Gitea, and are where AI employees actually operate.

Where the line sits: approval vs. autonomy

Once an Epic clears the approval gate, the company does not go back to the Founder for routine decisions inside it. Concretely:

Needs to go back through the gate: new scope not implied by the approved Epic, a direction change, anything in an employee's LIMITATIONS.md "escalate to Founder" list.
Company handles it: how an Epic splits into Stories/Tasks, which engineer gets what, sprint length and pacing, how a bug gets triaged, code review outcomes, QA verdicts.

If a Task's scope grows enough that it stops looking like what was approved, the Architect (for technical scope) or Project Manager (for schedule/priority scope) escalates — see EMPLOYEE_HANDBOOK.md for how escalation is supposed to feel from the inside.

Task lifecycle, in Plane terms

A single Task moves through these Plane states. Exact label/status names are defined in PLANE.md; this is the semantic flow every role needs to agree on:

Backlog → Todo → In Progress → In Review → QA → Done
                      ▲                      │
                      └──────── Reopened ────┘

Backlog → Todo: Project Manager prioritizes it into the active sprint.
Todo → In Progress: an engineer claims it.
In Progress → In Review: a PR is opened and linked to the Task.
In Review → QA: the PR is approved and CI passes.
QA → Done: QA Engineer verifies against acceptance criteria and signs off.
QA → Reopened: QA rejects; a bug may be filed (templates/BUG.md); Task returns to "In Progress" for the original or a reassigned engineer.

Sprint cadence

Sprints are opened and closed by the Project Manager, scoped from Stories the CEO has prioritized.
Sprint length is a Project Manager judgment call, not fixed by policy in this document — record the reasoning for unusual lengths in memory/lessons-learned.md so future sprints benefit from it.
Burndown and velocity are tracked in Plane directly (see PLANE.md) — not duplicated in a Markdown file. This repository records policy, Plane records state.

Retrospectives

Every sprint close is followed by a retrospective using templates/RETROSPECTIVE.md. The output that matters is not the ceremony — it's what gets written into memory/lessons-learned.md. A retrospective that produces no memory update didn't accomplish its job.

Escalation paths during execution

Engineer  ──technical question──▶  Architect
Engineer  ──priority/assignment question──▶  Project Manager
Architect/Project Manager  ──unresolved/scope change──▶  CEO
CEO  ──strategic/direction question──▶  Founder
Security Engineer  ──standing block on any merge, overridable only by Founder──▶  (halts merge)
QA Engineer  ──standing reject authority on any task──▶  (returns task to In Progress)

See EMPLOYEE_HANDBOOK.md for the behavioral expectations behind each of these arrows — this document defines the paths; that one defines how to walk them.

5.3 KiB Raw Blame History Unescape Escape