Component Architecture¶
This governance repo no longer maintains a component catalog¶
This venture previously maintained a pre-specified "component catalog"
(components/component-catalog.md) — 24 speculative, unbuilt UI/calculation
patterns intended for products to adopt. It was retired 2026-07-27 (see
ADR-0017):
nothing in it was ever built, and the venture's first real product
(llc-accounting-tracker, in the devonside-labs implementation repository) was
built without adopting it, reusing its own proven patterns directly instead (see
that repository's docs/ai/decisions.md, "LLC Accounting Tracker built without
adopting the component catalog").
How reuse actually works now¶
Reuse happens entirely within the venture's implementation repository
(devonside-labs), driven by proof, not pre-specification:
- A pattern is built once, inside a single product, to solve that product's actual problem.
- If a second product genuinely needs the same pattern, it's promoted into a real shared module in the implementation repository — not copied, and not routed through a pre-built catalog entry that may not match what was actually needed.
- A pattern used in only one product stays part of that product. It is never described as "the standard component for X" until a second product actually depends on it.
devonside-labs' own docs/ai/architecture.md and docs/ai/coding-standards.md
document this mechanism concretely — e.g. the llc-accounting-tracker-lite
generator reusing llc-accounting-tracker's helpers.py and
formula_storage.py directly via sys.path, with an explicit note that a third
product needing the same logic should trigger promoting it to a real shared
module instead of a second reach-through.
Reuse without forcing uniformity¶
Consistent with ../strategy/product-philosophy.md, reuse is a judgment call, not an obligation. A product with needs that don't fit an existing pattern should implement something product-specific rather than distorting an existing pattern to fit.