news / engineering

the gear train: five departments in one plugin

how four sibling repos became one factory in five releases — the gear train as an integration pattern.

absorbing four sibling repos into a single plugin in five releases is an integration problem with one durable answer: name the seam first, ship the seam first, ship the contents second. between 2026-05-20 and the same day’s evening cut, the factory absorbed Intake, Research, Product, and Design into the development plugin and emerged with a five-department gear train that runs end-to-end under one install. the property that made the absorption tractable was that the seam — the routing-matrix and marker contract — was defined before any of the four department codebases were vendored.

the resulting pipeline reads as a chain of phase transitions, each owned by one role, each gated by one marker:

Intake (Fit Check) ─▶ Research (Atomic)
                  └▶ Product (PRD / signoff)
                          ▶ Design (Brief)
                                  ▶ Development (loswf)
                                          ▼
                  Planning ─▶ Red-team ─▶ Plan-review ─▶
                  Decomposing ─▶ Building ─▶ Review ─▶
                  Ship ─▶ Rollup

the five releases that produced this chain — v0.4.0 through v0.4.4 — landed within hours of each other, each one a single-department absorption with its own PR and its own marker addition. v0.4.0 brought loswf-researcher and three skills from gears-playground/Research: research-plan, desk-researcher, research-reporter. v0.4.1 added loswf-product and the PRD v1 generator. v0.4.2 wired the design-brief skill to loswf-designer. v0.4.3 added the fit-check screen to intake. v0.4.4 closed the loop by making the entire roster externally grounded — nine of seventeen agents got external sources cited in their prompts.

the absorption worked because the seam was the routing matrix in docs/GEAR-TRAIN.md. that matrix specifies, for each issue type, which phase the issue enters first and which phase it routes to next. before any of the four sibling repos were vendored, the matrix was committed:

issue typeafter intakethen
featureproduct (PRD v1)planning → red-team → plan-review → decomposing → building → review → ship → rollup
researchresearchingproduct (PRD v1 or informational → done) → planning
bug / spike / investigateinvestigatingconfirmed → product (lightweight signoff) → planning
chore / refactor / docsproduct (lightweight signoff)planning → red-team → plan-review → decomposing → building → review → ship → rollup

the matrix is small. every cell maps to a phase label and a marker. the post-agent hook reads the marker and advances the phase. that two-line contract — emit one marker per agent, advance one phase per marker — is what made each absorption a single PR rather than a multi-week integration. the absorbed department’s agent did its work; emitted its marker; the hook routed to the next phase; the next department’s agent picked up.

the marker contract is concrete:

<!-- loswf:investigation:confirmed -->        investigator → product
<!-- loswf:research:complete -->              researcher   → product or done
<!-- loswf:product:prd-v1 -->                 product      → planning or researching
<!-- loswf:product:signoff -->                product      → planning or needs-attention
<!-- loswf:plan -->                           planner      → red-team
<!-- loswf:red-team -->                       red-team     → plan-review
<!-- loswf:decomposer --> no-decompose        decomposer   → building
<!-- loswf:fit-check -->                      intake       → (advisory)

each absorbed department contributed exactly one entry to the table. the entry specifies the marker shape, the verdict variants, and the routing for each variant. that is the entire integration contract per department. everything else — the agent’s prompt, the skills it uses, the templates it loads — is internal to the department and does not affect any other department’s contract.

the reason codes followed the same shape. each absorbed department added its own outcomes to .loswf/tools/loswf_reason_codes.py with a stable (reason_code, retry_class, category) triple. the Gear Train integration added 11 new outcomes across three categories: research, product, red-team. each outcome is a tuple. the hook reads the tuple, decides whether the outcome is terminal or retryable, and applies the corresponding label. the absorbed department needs no knowledge of how reason codes are routed — it just emits the right tuple.

the policy that made the chain enforceable was the v0.5.0 product sign-off gate. effective 2026-05-20, every factory:type:* issue routes through factory:phase:product before reaching planning. two product modes — full PRD v1 for features, lightweight signoff for chores and bugs. without that gate, the chain would have a default-deny rule but no positive constraint that “every task must touch the product role.” with the gate, the chain is exhaustive: there is no path from intake to planning that does not pass through product.

a property worth naming explicitly: the absorption did not require any of the absorbed departments to know they had been absorbed. gears-playground/Research still exists upstream. its README and CLAUDE.md remain authoritative for the Atomic Research model and the Perplexity-API executor. the factory vendored the agent prompts and skills; it did not fork the methodology. when the upstream repo evolves, the factory’s copy is the older version of one specific thing — the prompts and skills — not a competing methodology. the marker contract is the firewall that lets the upstream evolve independently.

the meta-question the absorption answered was whether five departments could share one plugin install without becoming a monolith. the answer is yes, provided the seam is the marker contract and the contract is the only cross-department surface. each department keeps its agents, its skills, its templates. the plugin keeps the routing matrix, the reason-code table, and the post-agent hook. those are the three pieces that, together, are the gear train. the rest is per-department, and the per-department code can be added, removed, or upgraded independently because the contract on either side does not change.

the meta-lesson is that integration scope is set by contracts, not by codebases. four codebases absorbed in five releases is unusual because most integrations couple at the codebase level — the absorbed repo’s internals become the absorbing repo’s internals, and every refactor ripples both ways. the gear train coupled at the marker level. each department’s internals are still its own. the contract — eight marker shapes, eleven reason codes, four routing rules — is small enough to fit on one page and is the entire integration surface. the cost of adding a sixth department, if one ever shows up, is one row in each of those three tables, and the day it lands, the chain is six departments long instead of five.