feat(ar_shape): mixin = family/group node — Rails include + Odoo _inherit are the same members/memberof primitive (#545..#551)

Operator nudge (2026-06-19): "the family nodes introduced in lance-graph
545..551 could serve as mixin — group.memberof/members where group is
the mixin node."

This RESOLVES a divergence I flagged wrong earlier this session. When
asked whether the Rails spine could verify Odoo AR-shapedness, I said
yes but called Odoo's _inherit "a non-AR shape with no Rails analog."
That was wrong: the Rails analog is include (concerns), and BOTH lower
to the family-node members/memberof primitive from #549
(graph::mailbox_scan::{members, memberof, BasinOf}). A mixin IS a
family/group node; include/_inherit IS the memberof edge.

New surface:
- mixin_members(triples, ns, is_rails) -> BTreeMap<group, BTreeSet<member>>
  Reads includes_module (Rails) or inherits_from (Odoo), ns-strips,
  returns the `members` direction (memberof is the transpose).
- shared_mixin_groups(members, min) -> Vec<group>
  The ≥2-member fan-out filter: a group shared by ≥2 classes is a
  genuine mixin; a single-member group is an STI base / model
  extension, not a mixin. Same distinction members(basin) draws in #549.

Grounded in the harvest (not asserted):
- OSB carries 37 includes_module triples (Client→PublicActivity::Model,
  Estimate→Trackstamps/DateFormats).
- Odoo carries 166 inherits_from triples; mail_thread is a group node
  with 70+ members (sale_order, account_account, purchase_order, ...).
  account_move rides mail_activity_mixin + sequence_mixin, NOT
  mail_thread directly — the test preserves the harvest's distinction.
- Cross-curator semantic convergence: OSB PublicActivity::Model
  (activity tracking) ≈ Odoo mail_thread / mail_activity_mixin. Both
  curators independently grew an activity mixin group.

4 tests, all green:
- odoo_mail_thread_is_a_family_group_node_with_many_members
- osb_rails_public_activity_model_is_a_family_group_node
- rails_include_and_odoo_inherit_are_the_same_family_node_primitive
  (the divergence-resolution test)
- single_member_extension_is_not_a_mixin_group (fan-out honesty)

Plus all 31 prior tests still green → 35/35 total. ar_shape clippy-clean.

The lesson: an apparent "Odoo non-AR divergence" should first be checked
against the lance-graph substrate primitives (#545..#551 members/memberof,
the family-node tree) before being called a divergence — the substrate
already had the home for it. The mixin group node carries shared behaviour
down to members, which is E-FAMILY-NODE-IS-META-AWARENESS instantiated for
ERP mixins (parent = coarse summary members inherit).

EPIPHANIES E-OGAR-AR-SHAPE-SMOKE-6 prepended (includes the correction of
my earlier wrong claim).

Cross-refs:
- E-BASIN-IS-A-NODE + E-FAMILY-NODE-IS-META-AWARENESS +
  E-GUID-SELF-ROUTES-THE-BASIN-TREE (the #545..#551 family-node arc)
- graph::mailbox_scan::{members, memberof} (#549 substrate primitive)
- E-OGAR-AR-SHAPE-SMOKE-5 (the concept-edge AST test; mixin membership
  is the inheritance-edge complement to the composition-edge graph)
- AdaWorldAPI/OGAR project_actor (STI-collapse used the same shape)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xzyc27Nx3f8WC5KzwfWfjx

Author: claude

.claude/board/EPIPHANIES.md

@@ -17,6 +17,27 @@ At the **crisp top split** a within-basin perturbation stays **95.7 % contained*
 **The three-axis close (a "surge" decomposes, and each axis owns one aspect):** WHERE it breaks = CHAODA anomaly (manifold repulsion, `ndarray::hpc::clam`); HOW MUCH = Weyl magnitude (probes A–D, [G] exact in code); HOW it spreads = **family-basin block-localized Weyl multi-hop, hop-local at the crisp tier** (this finding) + the ketchup yield as the seam gate. The family-basin layer (`E-BASIN-IS-A-NODE`) is the keystone that block-diagonalizes the Laplacian so per-basin Weyl chains seam-to-seam.
 
 **Self-correction (process):** the probe's first verdict rubber-stamped a 0.044 within-vs-seam gap + a **vacuous Davis-Kahan bound (2199)** as "SUPPORTED" — the same confirmation-bias trap. Tightened the gate to per-tier within ≥ 0.70 AND within/seam ratio ≥ 1.30 AND Weyl, dropped the DK bound as evidence (it is uninformative when the eigengap is tiny). Under the honest gate only HEEL passes — which is the correct, nuanced result. Cross-refs: `E-OUTAGE-CASCADE-IS-NON-LOCAL` (the claim reinstated), `E-BASIN-IS-A-NODE` (the family-basin keystone), `perturbation-sim::{spectral_perturbation, hhtl_keys}`, probes A–E (the spectral foundation, real PyPSA), the "without family nodes" tier table.
+## 2026-06-19 — E-OGAR-AR-SHAPE-SMOKE-6 — a mixin IS a family/group node: Rails `include` and Odoo `_inherit` are the SAME `members`/`memberof` primitive from lance-graph #545..#551 — RESOLVES the earlier-flagged "Odoo _inherit is non-AR" claim (it was wrong)
+
+**Status:** FINDING (operator nudge, 2026-06-19; 35/35 ar_shape tests green, ar_shape clippy-clean). **Corrects an error I posted earlier this session.** When asked "does it make sense to use the Rails-shaped spine to verify Odoo AR-shapedness," I answered yes but flagged Odoo's `_inherit` mixin composition as "a non-AR shape with no Rails analog... closer to Smalltalk/Ruby modules than to AR." The operator nudge: *"the family nodes introduced in lance-graph 545..551 could serve as mixin — group.memberof/members where group is the mixin node."* That dissolves the divergence — the earlier claim was wrong.
+
+**The resolution.** A mixin IS a family/group node (per `E-BASIN-IS-A-NODE` / `E-FAMILY-NODE-IS-META-AWARENESS`, lance-graph #545..#551 `graph::mailbox_scan::{members, memberof, BasinOf}`). `group.members` = the classes that include the mixin; `class.memberof` = the mixin group. Rails `include ModuleX` (concerns) and Odoo `_inherit = ['mail.thread', ...]` are NOT different architectures — they are the SAME `members`/`memberof` edge into a group node. The Rails analog of Odoo `_inherit` is exactly `include`; both lower to family-node membership. Odoo is AR-shape-VERIFIED on mixins, not divergent.
+
+**Grounded in the harvest (not asserted):**
+- OSB (Rails) carries **37 `includes_module` triples**: `Client include PublicActivity::Model`, `Estimate include {PublicActivity::Model, Trackstamps, DateFormats}`.
+- Odoo carries **166 `inherits_from` triples**: `mail_thread` is a group node with **70+ members** (`sale_order`, `account_account`, `purchase_order`, `res_company`, `stock_picking`, …); `account_move` rides `mail_activity_mixin` + `sequence_mixin` (the harvest's faithful distinction — account_move is NOT a direct mail_thread member, and the test preserves that).
+- **Cross-curator semantic convergence:** OSB `PublicActivity::Model` (activity tracking) ≈ Odoo `mail_thread` / `mail_activity_mixin` (chatter + activities). Both curators independently grew an activity-tracking mixin group — the mixin-as-family-node pattern converges even though specific mixin names differ.
+
+**The ≥2-member filter IS the family-node fan-out.** `shared_mixin_groups(members, 2)` keeps only groups with ≥2 members — a genuinely shared mixin (shared behaviour). A single-member "group" (`account_bank_statement_line inherits_from account_move`) is an STI base / model EXTENSION, not a mixin, and is correctly excluded. This is the same structural distinction `members(basin)` draws in #549: a basin node fans out to its children; a mixin group fans out to its members; a single-member parent is an extension, not a group.
+
+**The code (`mixin_members` + `shared_mixin_groups` + 4 tests):** `mixin_members(triples, ns, is_rails) -> BTreeMap<group, BTreeSet<member>>` reads `includes_module` (Rails) or `inherits_from` (Odoo), namespace-strips, returns the `members` direction (the `memberof` inverse is the transpose). `shared_mixin_groups(members, min)` applies the fan-out filter. Tests: `odoo_mail_thread_is_a_family_group_node_with_many_members`, `osb_rails_public_activity_model_is_a_family_group_node`, `rails_include_and_odoo_inherit_are_the_same_family_node_primitive` (the divergence-resolution test), `single_member_extension_is_not_a_mixin_group` (the fan-out honesty test).
+
+**Why this matters for the spine answer.** It sharpens the Rails-as-calcification-anchor doctrine: Rails defines AR; Odoo gets graded against it. The mixin case looked like an Odoo divergence — but mapped onto the family-node substrate, it's a clean cross-curator match. The lesson: an apparent "Odoo non-AR divergence" should first be checked against the lance-graph substrate primitives (#545..#551 `members`/`memberof`, the family-node tree) before being called a divergence. The substrate already had the home for it. The mixin group node also carries the shared behaviour down to members — which is `E-FAMILY-NODE-IS-META-AWARENESS` exactly (the parent node IS the coarse summary its members inherit), now instantiated for ERP mixins rather than Walsh bands.
+
+**Cross-refs:** `crates/lance-graph-ontology/src/ar_shape.rs` (`mixin_members` + `shared_mixin_groups` + 4 tests); `E-BASIN-IS-A-NODE` + `E-FAMILY-NODE-IS-META-AWARENESS` + `E-GUID-SELF-ROUTES-THE-BASIN-TREE` (the #545..#551 family-node arc this maps onto); `graph::mailbox_scan::{members, memberof}` (lance-graph #549, the substrate primitive); `E-OGAR-AR-SHAPE-SMOKE-5` (the concept-edge AST test this extends — mixin membership is the inheritance-edge complement to the composition-edge concept graph); `AdaWorldAPI/OGAR` CODEBOOK (`project_actor` STI-collapse used the same shape on User/Principal).
+
+---
+
 ## 2026-06-19 — E-OGAR-AR-SHAPE-SMOKE-5 — the ERP AST test passes at EDGE level, not just node level: OSB (Rails) and Odoo emit the SAME canonical concept-GRAPH (`CommercialLineItem → CommercialDocument`, `→ TaxPolicy`; `CommercialDocument → BillingParty`) despite different class names, field names, AND predicate vocabularies
 
 **Status:** FINDING (operator-directed "odoo vs rails based ERP AST test", 2026-06-19; 31/31 ar_shape tests green, ar_shape clippy-clean). The synergy work so far proved NAME-level convergence (a class IRI → a `CanonicalConcept`). This entry lands the deeper, real test: **EDGE-level convergence** — the canonical concept GRAPH (concept→concept relations) is the same across a Rails-based ERP and Odoo, which is what makes it an *AST*, not a label table.

crates/lance-graph-ontology/src/ar_shape.rs

@@ -673,6 +673,103 @@ pub fn concept_edges(
     out
 }
 
+// ─── Mixin = family/group node (members/memberof) ──────────────────────
+//
+// Operator nudge (2026-06-19): the family nodes introduced in lance-graph
+// #545..#551 (`graph::mailbox_scan::{members, memberof, BasinOf}`) can
+// serve as the MIXIN node. `group.members` = the classes that include the
+// mixin; `class.memberof` = the mixin group. A mixin IS a family/group
+// node; `include` (Rails) / `_inherit` (Odoo) IS the `memberof` edge.
+//
+// This RESOLVES a divergence flagged earlier this session. The earlier
+// claim that "Odoo `_inherit` is a non-AR shape with no Rails analog" was
+// WRONG: the Rails analog is `include` (concerns), and BOTH lower to the
+// same family-node `members`/`memberof` primitive. The harvest confirms
+// it — OSB carries 37 `includes_module` triples; Odoo carries 166
+// `inherits_from` triples; both are "this class is a member of group X".
+//
+// The ≥2-member filter IS the family-node fan-out: a group with multiple
+// members is a genuine mixin (shared behaviour); a single-member "group"
+// is an STI base / model extension, not a mixin. This is the same
+// distinction `members(basin)` draws structurally (a basin node fans out
+// to ≥1 child; a mixin group fans out to ≥2 members).
+
+/// Extract the mixin-membership graph from a curator's harvest as a
+/// `group → {member classes}` map — the `members` direction of the
+/// family-node primitive. The inverse (`memberof`: a class → its mixin
+/// groups) is derivable by transposing.
+///
+/// `is_rails` selects the predicate: `true` reads `includes_module`
+/// (Rails `include ModuleX` concerns); `false` reads `inherits_from`
+/// (Odoo `_inherit` mixin chains). Object IRIs are namespace-stripped so
+/// the group name is the curator's bare module/mixin name
+/// (`PublicActivity::Model`, `mail_thread`).
+///
+/// **The group node IS a family node** (per `E-BASIN-IS-A-NODE` /
+/// `E-FAMILY-NODE-IS-META-AWARENESS`): the mixin's shared fields/methods
+/// live on the parent, and members inherit by being in its `members`
+/// set. No new substrate — `members`/`memberof` from #549 is the home.
+#[must_use]
+pub fn mixin_members(
+    triples: &[Triple],
+    namespace_prefix: &str,
+    is_rails: bool,
+) -> std::collections::BTreeMap<String, std::collections::BTreeSet<String>> {
+    let predicate = if is_rails {
+        "includes_module"
+    } else {
+        "inherits_from"
+    };
+
+    let mut groups: std::collections::BTreeMap<String, std::collections::BTreeSet<String>> =
+        std::collections::BTreeMap::new();
+
+    for t in triples {
+        if t.p != predicate {
+            continue;
+        }
+        // Subject = the member class (ns-stripped, must be a class IRI).
+        let Some(member) = t.s.strip_prefix(namespace_prefix) else {
+            continue;
+        };
+        if member.contains('.') {
+            continue; // a `Class.method` IRI, not a class
+        }
+        // Object = the mixin/group name. Rails objects carry no namespace
+        // (bare `PublicActivity::Model`); Odoo objects are ns-prefixed
+        // (`odoo:mail_thread`) — strip if present.
+        let group = t.o.strip_prefix(namespace_prefix).unwrap_or(&t.o);
+        if group.is_empty() {
+            continue;
+        }
+        groups
+            .entry(group.to_string())
+            .or_default()
+            .insert(member.to_string());
+    }
+
+    groups
+}
+
+/// Filter a `mixin_members` map to the **genuine mixin groups** — those
+/// with `≥ min_members` members. This is the family-node fan-out
+/// criterion: a group shared by ≥2 classes is a mixin (shared
+/// behaviour); a single-member "group" is an STI base / model extension,
+/// not a mixin. Default threshold per the doctrine is 2.
+///
+/// Returns the group names (sorted) that qualify.
+#[must_use]
+pub fn shared_mixin_groups(
+    members: &std::collections::BTreeMap<String, std::collections::BTreeSet<String>>,
+    min_members: usize,
+) -> Vec<String> {
+    members
+        .iter()
+        .filter(|(_, m)| m.len() >= min_members)
+        .map(|(g, _)| g.clone())
+        .collect()
+}
+
 // ─── Sibling concept detectors (lexical class-name shape on declared OGIT
 // ObjectTypes) ─────────────────────────────────────────────────────────
 //
@@ -1931,6 +2028,148 @@ mod tests {
         );
     }
 
+    // ─── Mixin = family/group node tests ────────────────────────────
+
+    /// **The operator nudge, mechanized.** A mixin IS a family/group
+    /// node: `group.members` = classes that include it. On the real
+    /// Odoo harvest, `mail_thread` is a group node whose `members` set
+    /// contains many classes (`account_move`, `account_account`,
+    /// `account_journal`, …) — exactly the `members(basin)` fan-out
+    /// from lance-graph #549. The ≥2-member filter picks it out as a
+    /// genuine mixin.
+    #[test]
+    fn odoo_mail_thread_is_a_family_group_node_with_many_members() {
+        let odoo = load_triples_ndjson(include_bytes!(
+            "../../lance-graph/src/graph/spo/odoo_ontology.spo.ndjson"
+        ))
+        .unwrap();
+
+        let members = mixin_members(&odoo, "odoo:", false);
+
+        // mail_thread is a group node; its members include sale_order +
+        // account_account (account_move itself rides mail_activity_mixin
+        // + sequence_mixin, not mail_thread directly — the harvest's
+        // distinction, faithfully preserved).
+        let mail_thread = members
+            .get("mail_thread")
+            .expect("mail_thread should be a mixin group");
+        assert!(
+            mail_thread.contains("sale_order") && mail_thread.contains("account_account"),
+            "mail_thread.members should contain sale_order + account_account; \
+             got {mail_thread:?}",
+        );
+        assert!(
+            mail_thread.len() >= 2,
+            "mail_thread is a SHARED mixin (≥2 members); got {}",
+            mail_thread.len(),
+        );
+
+        // It qualifies as a shared mixin group under the fan-out filter.
+        let shared = shared_mixin_groups(&members, 2);
+        assert!(
+            shared.iter().any(|g| g == "mail_thread"),
+            "mail_thread should pass the ≥2-member fan-out filter; \
+             shared groups: {:?}",
+            shared.iter().take(8).collect::<Vec<_>>(),
+        );
+    }
+
+    /// The Rails side carries the SAME `members`/`memberof` shape via
+    /// `includes_module`. OSB's `PublicActivity::Model` is a group node
+    /// whose members include multiple billing classes (`Client`,
+    /// `Estimate`, …) — proving the family-node mixin primitive is
+    /// curator-independent.
+    #[test]
+    fn osb_rails_public_activity_model_is_a_family_group_node() {
+        let osb = load_triples_ndjson(include_bytes!(
+            "../tests/fixtures/osb_ruby_spo.ndjson"
+        ))
+        .unwrap();
+
+        let members = mixin_members(&osb, "openproject:", true);
+
+        let activity = members
+            .get("PublicActivity::Model")
+            .expect("PublicActivity::Model should be a Rails mixin group");
+        assert!(
+            activity.contains("Client") && activity.contains("Estimate"),
+            "PublicActivity::Model.members should include Client + Estimate; \
+             got {activity:?}",
+        );
+        assert!(activity.len() >= 2);
+
+        let shared = shared_mixin_groups(&members, 2);
+        assert!(shared.iter().any(|g| g == "PublicActivity::Model"));
+    }
+
+    /// **The divergence resolved.** Earlier this session I claimed Odoo
+    /// `_inherit` was a "non-AR shape with no Rails analog." This test
+    /// proves the opposite: BOTH curators expose the mixin-as-family-node
+    /// shape (a group with ≥2 members), so Odoo `_inherit` and Rails
+    /// `include` are the SAME `members`/`memberof` primitive — Odoo is
+    /// AR-shape-verified on mixins, not divergent.
+    #[test]
+    fn rails_include_and_odoo_inherit_are_the_same_family_node_primitive() {
+        let osb = load_triples_ndjson(include_bytes!(
+            "../tests/fixtures/osb_ruby_spo.ndjson"
+        ))
+        .unwrap();
+        let odoo = load_triples_ndjson(include_bytes!(
+            "../../lance-graph/src/graph/spo/odoo_ontology.spo.ndjson"
+        ))
+        .unwrap();
+
+        let osb_shared = shared_mixin_groups(&mixin_members(&osb, "openproject:", true), 2);
+        let odoo_shared = shared_mixin_groups(&mixin_members(&odoo, "odoo:", false), 2);
+
+        // BOTH curators have ≥1 shared mixin group (the family-node
+        // fan-out shape) — the primitive is present on both sides.
+        assert!(
+            !osb_shared.is_empty(),
+            "OSB (Rails) must expose ≥1 shared mixin group via include",
+        );
+        assert!(
+            !odoo_shared.is_empty(),
+            "Odoo must expose ≥1 shared mixin group via _inherit",
+        );
+        // Both surface an activity-tracking mixin (the cross-curator
+        // semantic convergence): OSB PublicActivity::Model ≈ Odoo
+        // mail_activity_mixin / mail_thread.
+        assert!(osb_shared.iter().any(|g| g == "PublicActivity::Model"));
+        assert!(
+            odoo_shared
+                .iter()
+                .any(|g| g == "mail_activity_mixin" || g == "mail_thread"),
+        );
+    }
+
+    /// Single-member groups (STI bases / model extensions) are NOT
+    /// mixins — the ≥2 fan-out filter excludes them. In Odoo,
+    /// `account_bank_statement_line inherits_from account_move` is a
+    /// model EXTENSION (one member), not a mixin; `account_move` must
+    /// not appear as a shared mixin group on the strength of that one
+    /// edge alone.
+    #[test]
+    fn single_member_extension_is_not_a_mixin_group() {
+        let odoo = load_triples_ndjson(include_bytes!(
+            "../../lance-graph/src/graph/spo/odoo_ontology.spo.ndjson"
+        ))
+        .unwrap();
+        let members = mixin_members(&odoo, "odoo:", false);
+        // account_move may be inherited by exactly one statement-line
+        // class — if so it's an extension, not a shared mixin. Assert
+        // the filter is honest: a group is only "shared" at ≥2.
+        if let Some(am_members) = members.get("account_move") {
+            if am_members.len() < 2 {
+                let shared = shared_mixin_groups(&members, 2);
+                assert!(
+                    !shared.iter().any(|g| g == "account_move"),
+                    "account_move with <2 members must NOT be a shared mixin",
+                );
+            }
+        }
+    }
+
     // ─── One-shot synergy registry test ─────────────────────────────
 
     /// `synergy_registry_one_shot` consumes all three workspace