docs(od-ontology): repatriation frame — lance-graph → (OGAR + odoo-rs + ruff)

[AdaWorldAPI]

What

The north star for the multi-PR repatriation of ~14 000 LOC of Odoo-specific
content currently misplaced in lance-graph. Operator framing, captured AS the
frame — not as a migration plan.

"The problem is NOT the code; the problem is that it landed in lance-graph
and nothing in odoo-rs nor OGAR. ODOO teaches us to become better than
Palantir Foundry, but they need to be reusable and the shapes need to be
universal and the fact that it is odoo-rs lives in classes and codebooks and
odoo-rs."

Three altitudes, four homes

Altitude	Home	What lives there
Identity	OGAR Class + codebook	OdooPort::class_id("account.move") → 0x0202. Already canonical (#93/#94/#95/#97/#98).
Empowerment (reusable idea factories)	OGAR universal class shapes	The patterns Odoo taught us — alignment via owl:equivalentClass, ORM lifecycle predicate vocabulary, MRO/inheritance, SPO→ActionDef lowering — parameterised so any consumer reuses them.
Muscle memory	odoo-rs	The specifics — the .ndjson, the l1..l15 blueprints, alignment-table content, namespace strings.
Generic spine	lance-graph	What's left over after the rest is repatriated. Zero Odoo.

The "vastness in simplicity": once identity + empowerment land in OGAR, the
14K LOC of odoo_blueprint/l1..l15.rs collapses to Class definitions ×
empowerment instantiation. Same job, fraction of the LOC, because the shapes do
the work instead of copy-pasted Odoo specifics.

Inventory re-sorted per shape, not per file

The doc enumerates every Odoo-specific file in lance-graph (odoo_ontology.rs,
odoo_blueprint/{l1..l15,…}.rs, odoo_alignment.rs, hydrators/{odoo, dolce_odoo}.rs) and identifies what each thing actually is (empowerment vs
muscle memory vs identity), then names the right home. No file-by-file
move-orders — those come per-phase.

Ruff implication (the keystone for shrinking everything)

"ruff might need an ogar class detection"

If the harvester emits OGAR-class-shaped output natively, every
ogar-from-<lang> shrinks to a thin pass-through (the precedent:
ogar-from-rails is 986 LOC because ruff_ruby_spo does the heavy lift).
Filed as its own producer-side ask.

Pragmatic ordering (operator-named)

"It's probably cleaner to move the migrated to odoo-rs because it's
impossible to do it at once."

1. Pull Odoo-specific content from lance-graph into odoo-rs (bounded,
   reversible — no architectural commitment yet about empowerment vs muscle).
2. In odoo-rs, separate empowerment from muscle memory (easier once the
   content sits with its consumer).
3. Push the separated empowerments to OGAR as universal Class shapes.
4. Push universal predicates to ruff.
5. lance-graph becomes generic by subtraction, not by an explicit move.

Per-phase PRs are bounded; the whole effort is not one PR.

Why now

I noted the duplicated ActionDef in lance-graph-contract and the
Odoo-specific files in lance-graph earlier in the session and didn't act on
them. The operator's reminder corrected the altitude: not "migrate the code"
but "separate empowerment from muscle memory." This puts the frame on the
record before any per-phase PR, so the next session has the north star instead
of re-deriving it.

Doc-only. Builds on the consistent across-session governance:
SURREAL-AST-TRAP.md (#6), W3-BEHAVIORAL-ARM-SCOPE.md (#7),
UPSTREAM_WISHLIST.md (#11). OGAR refs: #93/#94/#99/#100/#102. lance-graph:
#587/#589/#591/#592.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.