Architectural rule for Helix going forward: absorb DATA + RULES + SPEC…
Decision
Architectural rule for Helix going forward: absorb DATA + RULES + SPECS from compatible-license tools; DO NOT absorb their RUNTIMES/DAEMONS. Catalog (DESIGN.md), rules (anti-slop), specs (frontmatter, importer schema), reference impls (.ts files for study) are “in”; long-running daemons, web servers, IPC bridges are “out”.
Rationale
First-principles decomposition (thought 390deec0) identified three irreducible facts: (a) MIT-license cost-of-absorption is zero, so absorption beats build-from-scratch unless quality/fit/maintenance argument exists; (b) Helix is meta-framework, open-design is single-station — wholesale daemon adoption inverts the relationship; (c) Helix’s defining strength is COMPOSITION not CATALOG, so absorbing catalog layers preserves the core while absorbing runtime layers dilutes it. This rule explains the 11-wave outcome (W1+W3 mostly catalog/spec absorption — clean wins; W2 partial because slop-lint is rules-as-code (in-scope), agent-router transport adapters are runtime (correctly scaffolded-not-impl), collab-primitives schemas are spec (in-scope) but integration is runtime (correctly deferred)). Going forward, this rule prevents future sessions from accidentally absorbing the open-design daemon or open-codesign Electron shell — both would invert Helix’s compositional position. Confidence 0.82 — high because the rule is derived from first-principles, not pattern-matched; lowered from 1.0 because it’s a NEW rule not battle-tested across multiple absorption decisions.
Alternatives Rejected
Outcome
Pending