feedback_v2_clean_break_from_v6_6

INHERIT v2 + InheritKit are a clean break from v6.6.

Rich’s 2026-04-22 directive, given in response to my observation that ~/openinherit/code-standard/v3/extensions/ already contains mature faith-tradition extensions (islamic-succession 421 LOC; hindu-succession 295 LOC; jewish-succession 334 LOC) plus 18 other extensions that could inform v2’s domain-modeling:

• v2 INHERIT will live in its own self-contained repo.
• InheritKit will live in its own self-contained repo.
• v6.6 may be used for inspiration / reference during the build.
• v2 must NOT depend on v6.6 at go-live. No imports, no schema references, no URI pointers back to openinherit.org/v3/*, no runtime coupling.
• Josh’s LL v1 continues on v6.6 independently. Two separate tracks per brand-architecture.md §6.4.

Why: Clean-break avoids bidirectional coupling that would compromise either track. v6.6’s evolutionary path is constrained by existing LL v1 users + stealth discipline; v2’s rebuild path needs freedom to restructure at the architectural level (per the Scale-3 Z-file decision, Option B direction). A dependency either way hobbles both.

How to apply:

• During the build (now through v2 general release): agents can READ v6.6 extension JSON + schema files for inspiration, extract patterns, cite structural choices. Treat as library-corpus material — reference, not substrate.
• When estimating v2 LOC / scope: do NOT shrink estimates on the assumption that v6.6 primitives are reusable. v2 Catala modules + v2 JSON Schema are ground-up fresh. If a pattern from v6.6 (e.g. extensionType: "tradition" vs "geographic" split; compatibleWith interaction declarations; $comment-based “jurisdictional codification not religious doctrine” framing) informs v2, the pattern is replicated as fresh v2 artifact — not imported.
• When writing spec / design documents: cite v6.6 as reference not dependency. Cross-reference allowed for lineage-tracking; runtime-coupling forbidden.
• When proposing repository structure: v2 INHERIT gets a new repo (candidate locations: ~/testatetech/code-inherit-v2/ or ~/openinherit/code-standard-v2/ — TBD with Rich). InheritKit gets its own separate repo. Neither imports from openinherit/code-standard.
• At go-live: v2 must be able to run with openinherit/code-standard offline / unreachable / deleted. If anything in v2 needs a file, pattern, or concept from v6.6, that content is copied + adapted into v2’s own artifacts before release.

Do NOT:

• Propose importing v6.6 extensions into v2 via git submodule / npm / schema-registry pointer.
• Cite v6.6 URIs (openinherit.org/v3/extensions/...) in v2 authoritative artifacts.
• Design v2 Catala modules that call into v6.6 schema primitives at runtime.
• Assume v6.6 evolution will wait for v2 — Josh’s LL v1 continues on v6.6 at Josh’s cadence; v2 must not block or fork that track.

Cross-reference:

• brand-architecture.md v1.15 §6.1 + §6.4 + §6.5 already establishes v6.6 / v2 as separate tracks — this memory adds the operational precision “v6.6 reference during build; zero dependency at go-live”.
• docs/superpowers/specs/2026-04-22-inherit-v2-architecture-proposal.md v1.1+ captures this as §“Clean-Break Discipline”.
• The v6.6 faith-tradition extensions are reference-only corpus for Q2’s β→ε trajectory — the Catala layer is built fresh, inspired by but not importing the v6.6 structure.