# plugin factory

_Status: direction — as of 2026-07-16_
_Connects to: [deterministic-gates](deterministic-gates.md), [self-improvement-loops](self-improvement-loops.md), [pipeline-stages](pipeline-stages.md), [overview](../OVERVIEW.md)_

## Purpose

States that os-sdlc is the same factory cc-os uses to build its own `os-*` plugins, not a
separate meta-tool — and how that reflexive use case is possible without a second pipeline.
Load this before scaffolding a new `os-*` plugin, or before designing anything that looks
like a "plugin builder" separate from the ticket pipeline in
[pipeline-stages](pipeline-stages.md).

## Design

- **The same factory builds cc-os plugins from a PRD.** This works because the green command
  is pluggable per project (see [deterministic-gates](deterministic-gates.md)): for a normal
  application repo it's `rake test` + lint; for an AiDD-type project (a cc-os plugin) **the
  eval harness IS the test suite**. TDD becomes eval-driven development — write the eval,
  watch it fail for the right reason, build the skill until it passes — with no separate
  pipeline, no special-cased plugin-building mode. The pipeline stages in
  [pipeline-stages](pipeline-stages.md) run unchanged; only the green-command config value
  differs.
- **Plugins self-evolve after they ship.** Once a plugin exists, its own operation becomes
  input back into the same factory: audits of sessions it participated in (loop a),
  ADR-corpus audits touching its decisions (loop b), its own eval-harness regressions (loop
  c), and direct user feedback all generate improvement tickets. Those tickets re-enter
  factory intake exactly like any other ticket — a plugin is never "done," it's a standing
  client of its own factory. See [self-improvement-loops](self-improvement-loops.md) for the
  four loops that produce this feedback.
- This closes the loop cc-os has been running informally (build a plugin, notice drift in
  use, fix it in a follow-up session) into something the factory itself can drive
  end-to-end: PRD → spec → tickets → implement → ship → audit → new tickets.

## Open questions

- PRD template for plugins specifically — likely narrower than a general product PRD (needs
  to name: the eval harness location, the green command, which existing `os-*` plugins it
  composes with per ADR-0037's composability constraint).
- Eval-first scaffolding: the red-assert analog for eval-driven development — does
  `to-tickets`/`/implement` need a variant stage that writes the eval scenario before the
  skill exists, mirroring the test-writer stage in [pipeline-stages](pipeline-stages.md)?
- How improvement tickets are auto-generated from audit findings — format, who/what creates
  the issue (a code-actor script parsing an audit report, or an agent stage), and how
  duplicate/overlapping findings across the four loops get deduplicated before hitting the
  tracker.

## Sources

- ADR-0037 (`docs/adr/0037-os-sdlc-lives-inside-cc-os-as-a-new-plugin-not-a-separate-cc-sdlc-marketplace.md`)
- `plugins/os-sdlc/OVERVIEW.md`
- `plugins/os-vault/eval/`, `plugins/os-adr/eval/`, `plugins/os-context/eval/`
- 2026-07-16 design session (this doc's origin)