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