54 lines
3.1 KiB
Markdown
54 lines
3.1 KiB
Markdown
|
# 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)
|