docs(od-ontology): pull SPO schema from lance-graph + name the compiler-AST frame

[AdaWorldAPI]

What

Phase-1 of the repatriation (per REPATRIATION-FRAME.md shipped in #12).
Pulled the rich SPO predicate-schema documentation from
lance_graph::graph::spo::odoo_ontology (wrong-altitude: generic graph spine
carrying a per-app vocabulary) into triple.rs — the consumer that USES the
vocabulary now owns its docs. Additive only; lance-graph's copy stays in place
to be subtracted in a later phase.

The compiler-AST frame (operator-named)

"lance-graph on OGAR is acting like a compiler, so the AST needs to think
like that."

Made explicit at the head of triple.rs:

Odoo source ─[ruff + odoo-blueprint-extractor]→ AST (this corpus)
                            │
                            │ frontend:  parse_ndjson (this module)
                            ▼
                       Vec<Triple>  (the typed AST)
                            │
                            │ lowering passes:
                            │   schema_to_classes  → ogar_vocab::Class    (structure)
                            │   corpus_to_actions  → ogar_vocab::ActionDef (behaviour)
                            ▼
                        OGAR IR
                            │
                            │ codegen:
                            │   ogar-adapter-surrealql → DEFINE TABLE / FIELD
                            ▼
                        Target

• odoo-rs = the Odoo language frontend of the OGAR compiler.
• OGAR Class/ActionDef = the IR.
• lance-graph + adapters = the middle / back end.
• The 13 predicates = the AST node-type set. A 14th is a language change,
  not a doc update.
• The 4 truth bands = provenance on every AST node.
• Slices reference externs resolved by the symbol table (OGAR ClassView),
  not by the slice.

What landed in triple.rs

• Full 13-predicate × subject-shape × object-shape × provenance-band schema
  table.
• The four truth-value provenance bands (corrected from lance-graph's
  incomplete 3-band claim — the corpus carries (1.0, 1.0) declaration AND
  (1.0, 0.95) membership; the new test caught the omission).
• The "a + b → c through d?" Foundry query pattern — what the corpus is FOR.
• Two enrichment layers (target / inverse_name; deep reads_field) +
  _inherit-only / multi-emitter corrections.

What landed in tests/corpus_schema_pin.rs

10 invariant pins, all green against both shipped corpora (slice-1 and
slice-2). Catches:

• undocumented predicate appearing in the corpus;
• truth band outside the four documented;
• structural band leaking into a non-structural predicate;
• inherits_from / reads_field self-loops;
• target carrying an odoo: prefix;
• validation_kind drift outside the recognised five;
• raises outside the exc: namespace;
• the canonical convergence-pin deep read (_compute_amount cross-model).

Three pins shifted in scope from lance-graph's originals (the AST-view
made them demand things the slice corpora can't deliver):

lance-graph claim	corrected slice-aware claim
every inherits_from base is a declared ObjectType in this corpus	well-formed odoo:<name> IRI (slice externs are AST-valid; resolved via the symbol table)
target object always contains a dot	no odoo: prefix (single-word comodels like website are valid)
structural band = rdf:type + has_function (one band)	declaration band (1.0, 1.0, rdf:type only) + membership band (1.0, 0.95, has_function only)

Full-corpus integrity claims belong on the full corpus, not on slices.

Tests

39 lib + 7 bin + 10 corpus-pin + all integration green; clippy 0;
fmt-clean. Builds on merged #12 (the frame).

[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.