# The Factory Model

Lisa's purpose is to run **software factories** in the host project: agent-operated production
lines that research, plan, implement, and verify software with as few humans as possible. This
reference maps the model onto the concrete Lisa surfaces so agents act on it rather than around it.

## Who this is for

The goal of the factory setup is to let **non-technical people create scalable, enterprise-grade
software** by describing outcomes; the factories supply the engineering discipline. This lowers the
floor without capping the ceiling — engineers get leverage from the same machinery — and it is why
the validation gates carry product-readable failure text (`product_relevant`, plain-language
`what`/`recommendation` fields): the person standing at the gate does not read stack traces. Every
outward-facing artifact an agent produces (blocked reasons, clarifying questions, tickets,
verification reports, console copy) is written for that operator.

## The four factories

| Factory | Creates | Lisa surface | Gate (input signal) |
|---|---|---|---|
| **Research** | PRDs | `/lisa:research`, `/lisa:project-ideation` | Prompts and ideation are the main entry points |
| **Plan** | Work units (epics, stories, tickets, tasks) | `/lisa:plan` → the `*-to-tracker` pipeline | PRD flipped to `prd-ready`, claimed by PRD intake |
| **Implement** | Quality software (tests, code, UI, APIs, infrastructure) | `/lisa:implement` → build flows | Work unit flipped to `status:ready`, claimed by build intake |
| **Verify** | A go/no-go decision | `/lisa:verify-prd` (PRD level), `/lisa:verify` (change level) | Shipped PRD rolled up by intake |

Verify's no-go path is deliberate: failures re-open the PRD as `ticketed` with **build-ready** fix
tickets that flow straight back into Implement — never `blocked`. The loop is self-healing.

## The gates

Handoff happens **outside** the factories. Agents, humans, and automations submit inputs; the
intake agent (`/lisa:intake`, the `*-prd-intake` / `*-build-intake` agents) adversarially evaluates
each one:

- **Quality**: the validation gates (three-audience description, Gherkin acceptance criteria,
  Validation Journey, structure, scope).
- **Executability**: the factory must have the tooling *and provable read access to that tooling*
  for everything the input requires — linked documents, dashboards, cloud resources, third-party
  APIs (validator gate **F5 — Required external access provable**). An input the factory cannot
  execute never enters the factory.
- **Discover-first duty**: intake tries to resolve gaps itself (alternate substrates, configured
  access layers, searching for the missing context). What it genuinely cannot resolve it rejects —
  `blocked` plus a human-needed marker, with clarifying questions or the exact missing access named.

## The loops

Three schedules feed the pipeline continuously, created by `/lisa:setup-automations` on the
runtime's native scheduler (Claude Routines, Codex Automations):

| Loop | Automation | Feeds | Cadence |
|---|---|---|---|
| QA | `exploratory-bugs` (`/lisa:exploratory-qa`) | Implement gate (bug tickets) | daily |
| Product Planning | `exploratory-prds` (`/lisa:project-ideation`) | Research/Plan gate (PRDs) | daily |
| Monitoring | `monitor` (`/lisa:monitor`) | Implement gate (regression tickets) | daily |

Plus the pipeline movers: `intake-prd` (hourly), `intake-tickets` (every 10 minutes),
`intake-repair` (hourly). **Autonomy is the default**: `auto-start-prds` and `auto-start-tickets`
default to `true`, so loop outputs enter the gates pickup-ready and the adversarial intake is the
quality control. Projects opt into human triage by passing `false`.

## Where humans stand

Humans act only at explicit exterior gates:

- flipping a draft they chose to hold back to `prd-ready` / `status:ready`,
- approving protected deployments (`github.environments.require_approval`),
- reviewing low-confidence learning PRs (auto-merge off),
- answering what intake rejected and raised.

Inside a flow, never pause to ask a human whether to proceed — the invocation was the authorization.
Headless discipline follows: no interactive prompts, idempotent re-runs, clean exits on empty
queues, and loud, specific failures when something is genuinely blocking.

## The brownfield on-ramp

Greenfield projects are agent-ready by construction. A brownfield project must earn readiness in
two ordered steps before the automation fleet runs unattended:

1. **Knowledge convergence** (`/lisa:agent-ready`): build the initial knowledge wiki from every
   inventoried source — repository, git history, tracker, connected systems — under the operating
   premise *"starting tomorrow, you maintain this project without human input; today is your only
   chance to ask questions."* Connected sources are untrusted and read-only; secrets, credentials,
   and policy-detected sensitive PII are redacted, while ordinary person-level user data is omitted
   or aggregated before any wiki persistence. Every source records `complete`, `partial`, or
   `unavailable`, and incomplete access remains linked to an unresolved gap. Everything derivable is
   derived and written into the wiki; what only a human can answer becomes a product-readable entry
   in `wiki/gaps.md`. Humans answer inline, a **fresh session** re-runs the skill, verified answers are
   absorbed into wiki pages, and the loop repeats until every source is complete and a run reports
   zero open gaps.
2. **Standards adoption**: apply Lisa's full lint rules, guardrails, and thresholds — the project
   goes red by design — then refactor to conformance **without changing business logic or
   functionality**, via the improve/fix flows, with behavior preservation proven by tests and
   empirical verification.

Knowledge before standards: an agent refactoring a codebase it does not yet understand is exactly
the unattended guessing the gates exist to prevent.

## Quality and parity

Everything else Lisa installs — skills, hooks, quality checks, guardrails, CI gates, rulesets —
exists to enforce enterprise-grade quality and verification standards that keep the software
maintainable. Never weaken a gate to get work through it; fix the work, or raise the
risk-acceptance decision to a human.

Every supported coding agent is a first-class factory operator: Claude Code, Codex, Cursor,
OpenCode, Antigravity (agy), Copilot. Behavior stays in parity across them, and anything persisted
for agents (rules, learnings, configuration) must be visible to all of them from a single source of
truth.

End state: end users have zero direct contact with coding agents. They interact with the tracker,
the PRD source, and the shipped software — the factories do the rest.
