Activate ATT NLSpecs + integration plans + odoo_alignment cache#409
Merged
Conversation
Wire the three Attractor-style NLSpecs (autoattended-orchestrator,
anti-skim-agent, agent-coordination-mcp) into this repo's bootload
and governance surfaces so the spec actually governs agent behavior,
not just exists in the tree.
- .claude/settings.json: add Edit/Write/MultiEdit deny rules for the
8 append-only bookkeeping files. Closes coordination-mcp-spec §7.2
/ §9 DoD ("append-only governance enforced at the settings layer")
and brings actual enforcement in line with what BOOT.md already
claims is enforced.
- .claude/agents/BOOT.md: new "ATT NLSpec Coupling" section maps the
four quality-lifecycle agents (convergence-architect, preflight-
drift-auditor, baton-handoff-auditor, brutally-honest-tester) to
ATT slots PP-14/16/15/13 with non-overlapping verdict vocabularies.
- .claude/BOOT.md: "Existing content" section now points at both
.claude/EN/ (operator cheat-sheet) and .claude/ATT/ (engineering
spec) and names the three NLSpecs.
- .claude/hooks/session-start.sh: SessionStart additionalContext
surfaces the ATT pointer + ACTIVATION receipt so new sessions
see them on turn 1.
- .claude/ATT/ACTIVATION.md (new): honest DoD audit per spec.
Records which items are satisfied (e.g., append-only governance,
4-savant non-overlap, handover schema), which are partial (DOT
plans, BAP/PD enumerations), and which are gaps (status.json +
proof-of-read schema, sentinel tokens, tool-call loop detection).
No code under crates/ touched. Single-repo activation per user
direction; other repos in the 26-repo rollout activate via their
own branches.
…on + per-repo lance-graph wiring Drafted four planning documents under .claude/plans/, indexed at the end of .claude/board/INTEGRATION_PLANS.md per the workspace's APPEND-ONLY governance rule (tee -a, no Edit). - unified-bridge-consumer-migration-v1.md (257 lines): convergence of woa-bridge / smb-bridge / medcare-bridge onto a single constructor pattern returning lance_graph_callcenter::UnifiedBridge<NB>. CAM codebook + schema + label + verbs from OGIT + OWL/DOLCE materialised as OgitFamilyTable, persisted append-only in a LanceDB column under the lance-cache feature. D-UB-1..11 across 4 tiers; D-UB-7 (fix ontology_dto.rs:85 in MedCare-rs) is the critical path; D-UB-8 (RLS coverage for Treatment / Visit / VitalSign) is safety-critical. - lance-graph-in-woa-rs-v1.md (132 lines): greenfield 6-phase lift from zero (OGIT TTL + sea-orm/MySQL writer-parity) to ontology + RBAC + Lance-third-writer + optional Cypher/CAM-PQ surface. Phase 0 mechanical (vendor + exclude); Phase 1 lands woa-bridge + woa-ontology crates mirroring MedCare-rs and smb-office-rs; Phase 4-5 opt-in. Respects 2026-05-15 DualSink-Pivot. - lance-graph-in-smb-office-rs-v1.md (91 lines): 5-phase completion of what unified_bridge_wiring.rs's doc-comments already promise. Phase A ships dedicated SmbBridge upstream; Phase B authors OGIT/NTO/SMB/ TTL + SMB-shaped role groups (tax_clerk / partner / client_user / audit_observer) per D-SDR-2 + swaps smb_unified_bridge to UnifiedBridge<SmbBridge>; Phase C consolidates rich auth::TenantId with transparent callcenter::TenantId; Phases D-E opt-in. - lance-graph-in-medcare-rs-v1.md (129 lines): 7-phase completion of the post-#355 migration. Critical path on Phase 1 (fix the broken lance-phase2 build at ontology_dto.rs:85) + Phase 2 (close RLS fail-OPEN window — safety-critical for HIPAA conformance). Phase 5 unblocks LanceProbe M2..M6 via 5 medcare-rs endpoints (D-LGMC-7..11 = D-SDR-35..39 in super-domain plan). Two-branch reality respected: main vs claude/scaffold-medcare-rs-rZD5A. All four plans cross-reference super-domain-rbac-tenancy-v1.md as the substrate spec. No code touched; documentation only.
… sea-orm+MySQL cold
User clarification 2026-05-21: woa-rs already has sea-orm as the DTO
layer + the MySQL bridge. lance-graph-ontology is the read hot path
(O(1) ontology resolution via OgitFamilyTable; UnifiedBridge::authorize
masked-predicate combine; CAM-PQ similarity over the Lance projection;
Cypher / SPARQL via the planner). sea-orm + MySQL is the cold path
(writer-parity authoritative per the 2026-05-15 DualSink-Pivot;
byte-exact row values; system of record for parity tests + DATEV /
X-Rechnung / PDF generation).
§9 adds: the hot-path operation inventory (kind / label / authorize /
similarity / referral / role redaction / Cypher); the cold-path
operation inventory (insert/update/delete / read for byte-exact
parity / DATEV export / migrations / bulk audit); the three concrete
bridges between them (write-through projection, boot-time projection,
drift reconciler); phase remapping; explicit clarification that the
Lance projection is a READ replica, NOT a third writer (the
DualSink-Pivot writer-parity contract stays exactly two writers:
Python + Rust, both to MySQL).
§9 also tightens D-WLG-9 scope (the Lance projection is replicate,
not source — MySQL wins on drift) and sharpens the Phase 4 ceiling
("rewrite the 6-8 cross-entity queries that produce the most join
code, leave the rest").
The existing §1-§8 framing remains valid; §9 is additive in the
same shape as super-domain-rbac-tenancy-v1.md §13-§19 session
appendices.
… MongoDB alt cold path
Two user clarifications, both incorporated:
1. The sink-with-diff-monitoring infrastructure is already shipped
(the original Phase 5 framing overstated the gap):
- lance_graph_callcenter::transcode::parallelbetrieb (376 LOC)
defines DriftKind / DriftField / DriftEvent / Reconciler.
- medcare-analytics::mysql_reconciler::MedcareMysqlReconciler
(461 LOC) ships Round-1 Patient on /api/patient/{id} with 11
unit tests + pluggable PatientFetcher for testability.
- smb_bridge::mongo_reconciler::SmbMongoReconciler (395 LOC) is
the sister C2 reconciler over MongoDB.
- MedCareV2 LanceProbe (M1 complete) speaks the same DriftEvent
JSON shape.
- medcare-server::routes::parity ships POST /api/__parity/csharp
ingest + GET /api/__parity dashboard (admin-only, 1024-event
ring buffer in OnceLock<Mutex<VecDeque>>).
- 5-phase F1-F5 narrative in docs/medcare-umstellung.md.
Status update on the original D-LGMC-7..11:
- D-LGMC-7 (ingest endpoint): SHIPPED — drop.
- D-LGMC-8 (dashboard): SHIPPED — drop.
- D-LGMC-9 (DTO contracts doc): still open.
- D-LGMC-10 (TripleDES fallback flag): still DRAFT.
- D-LGMC-11 (telemetry endpoint): still open.
New Phase 5b deliverables: D-LGMC-15..18 grow the existing
reconciler shell from Round-1 (Patient) to Round-2
(Lab/Vital/Diagnosis/Prescription) — only the per-route
dispatch table grows. D-LGMC-19 wires production query
handles. D-LGMC-20 centralises the canonicalizer table
upstream. D-LGMC-21 replaces the in-process ring buffer
with LanceAuditSink.
2. MongoDB is added as an ALTERNATIVE cold path (alongside MySQL,
not replacing it — Iron Rule 1 preserved). Propagated from
smb-office-rs's three-layer shape:
- D-LGMC-22 (NEW crates/medcare-mongo/): mirrors smb-mongo
(MongoImporter + MigrationStats), ~200 LOC + 4 tests.
- D-LGMC-23 (NEW crates/medcare-bridge/src/mongo.rs): mirrors
smb-bridge::mongo (MongoConnector impl of EntityStore +
EntityWriter), ~250 LOC + 6 tests, gated [features] mongo.
- D-LGMC-24 (NEW crates/medcare-analytics/src/mongo_reconciler.rs):
mirrors smb-bridge::mongo_reconciler 1:1 with healthcare
entities substituted, ~400 LOC + 11 tests.
- D-LGMC-25 (cold-path selection config): deployment picks
MySQL, MongoDB, or both, ~50 LOC + 2 tests.
- D-LGMC-26 (dual-reconciler mode): when both cold paths
active, triple-redundancy with 3 pairwise comparisons
(MySQL↔Lance, MongoDB↔Lance, MySQL↔MongoDB), ~100 LOC + 4 tests.
Hot/cold framing updated: hot = lance-graph-ontology + Lance
projection; cold (A) = sea-orm + MySQL (legacy oracle, Iron
Rule 1 permanent); cold (B) = MongoDB (alternative, NEW).
User direction 2026-05-21: adaworldapi/ractor is not yet in the
session's MCP github scope ("forgot to put it in scope"); add it
as a vendor import "for now" until the scope is updated.
Imported via anonymous public zipball:
https://api.github.com/repos/AdaWorldAPI/ractor/zipball/HEAD
Source SHA: a50c675 (zipball top-level dir name; matches the SHA
file at /home/user/ractor/.vendor-import-sha.txt).
Layout follows the existing workspace convention from
MedCare-rs/vendor/ — softlinks to sibling clones at /home/user/<name>/:
vendor/.gitkeep (track empty dir)
vendor/README.md (explains the temporary-import
status + replacement path when
MCP scope is added + wiring
instructions for path deps)
vendor/ractor -> ../../ractor (softlink; target is /home/user/ractor)
No Cargo.toml touched — this is source-only vendoring; the
[workspace] exclude block + path-dep wiring lands in the consumer's
Cargo.toml when a crate actually depends on ractor.
ractor itself ships a workspace with 7 members (ractor,
ractor_cluster, ractor_cluster_derive,
ractor_cluster_integration_tests, ractor_example_entry_proc,
ractor_playground, xtask). The exclude block will be required at
that wiring step to avoid the "multiple workspace roots found"
cargo error documented in MedCare-rs/Cargo.toml.
Cross-ref: the convergence-v1 plan
(.claude/plans/cognitive-substrate-convergence-v1.md +
causaledge64-mailbox-rename-soa-v1.md) names ractor as the actor
substrate carrying CausalEdge64 emissions; this vendor import
unblocks that work without waiting for MCP scope expansion.
…st PR #407) PR #407 + the ~11 preceding bO-* feature commits shipped the concrete OWL/DOLCE/OGIT cross-walk hydrators in lance_graph_ontology::hydrators::*. §4 of this plan referenced those surfaces abstractly; this commit tightens to concrete type pointers. §4.1 (OWL/DOLCE cross-walk surface) — table now names the hydrator that populates each MetaAnchors field: - owl_upper_class + dolce_marker → hydrate_dolce (OGIT::DOLCE_V1, inherits_from: None, 17-IRI edge whitelist covering rdfs:subClassOf + owl:equivalentClass + DnS classify/role-binding + dul:hasPart/isPartOf + dul:hasTimeInterval/isObservableAt; note the canonical DOLCE+DUL Endurant→Object/Perdurant→Event rename). - foundry_object_type → hydrate_schemaorg + hydrate_fibo_be for the upper-class anchors Foundry typically maps to. - wikidata_qid → not yet in the hydrator surface; deferred until a tenant requests Wikidata sync (~50 LOC glue). §4.3 (NEW — Hydrator inventory) — full surface map: - Generic substrate: OwlHydrator (the bO-* scaffold every hydrator instantiates), MetaStructureHydrator trait, ContextBundle, EntityId, OntologySlot, HydrateErr. - Layered ontologies (L1 → L4 sector): · L1: hydrate_dolce (root, inherits_from: None) · L2: hydrate_owltime / hydrate_provo / hydrate_qudt (all inherits_from: Some(OGIT::DOLCE_V1.0)) · L3: hydrate_schemaorg (commercial-web) · Sector: hydrate_skos, hydrate_fibo_fnd, hydrate_fibo_be (FIBO BE inherits FND) - Dedicated (non-OWL): SchematronHydrator, XsdHydrator + collect_xsd_files, SkrHydrator + hydrate_skr03/skr04/skr03_bau + the three IRI prefix constants. - ZUGFeRD/Factur-X: hydrate_zugferd + hydrate_zugferd_rules (XSD + Schematron over EN16931). - Full re-export surface from the crate root shown as a single `use` block for consumer ergonomics. §4.3 also maps each plan deliverable to the hydrators it uses: - D-UB-1 names the producer-side shape. - D-UB-2 (SmbBridge) declares no hydrator dep until OGIT/NTO/SMB/ ships. - D-UB-3 (lance_cache::ontology_cache_schema) persists each hydrator's ContextBundle output as the Lance column rows. - D-UB-4..6 (per-consumer constructors) take an already-hydrated Arc<OntologyRegistry>; deployment chooses the menu: · woa-rs: dolce + provo + qudt + schemaorg + fibo_fnd + skr03/skr04 + future OGIT/NTO/WorkOrder. · smb-office-rs: same minus WorkOrder, plus skr03_bau + zugferd + zugferd_rules. · MedCare-rs: dolce + owltime + provo + qudt + skos + future OGIT/NTO/Healthcare. No deliverable IDs renumbered; this is a clarification of §4's referenced surface against the now-shipped types. Other plan sections unchanged.
…O(1) inheritance from family buckets Two user clarifications, folded into §4: 1. The OWL/DOLCE cross-walk table is not "interop crutches" — it is the SOURCE MATERIAL from which lance-graph-ontology constructs the OGIT/OWL/DOLCE mapping. The hydrators are the construction tool; the cross-walk standards (DOLCE+DUL, OWL-Time, PROV-O, QUDT, schema.org, FIBO, SKOS, Schematron, XSD, SKR DATEV, ZUGFeRD) are the bricks; OGIT canonical surface (per-family codebook + inherits-from DAG + edge whitelists at OGIT::*_V1 slots) is the synthesis. 2. The hydrators + inherits_from + per-family codebook + family- bucket dense array TOGETHER form the spine that makes schema / label / codebook inheritance O(1) cheap at lookup time. §4.1 rewritten as "the source material for the OGIT mapping" — direction-of-build diagram added showing how each external standard flows through its hydrator into its OGIT::*_V1 G-slot. The MetaAnchors fields (foundry_object_type, owl_upper_class, dolce_marker, wikidata_qid) are reframed as the runtime READ SURFACE over the constructed mapping, not as the populated target. DolceMarker enum naming open question (Endurant/ Perdurant vs Object/Event per canonical DUL rename) called out explicitly as a decision needed before D-UB-3. §4.3 lead-in reframed from "the cross-walk surface is now concrete" to "the construction tool that builds the OGIT mapping is now concrete in lance_graph_ontology::hydrators::*". PR #408 reference added (NamespaceRegistry::seed_defaults wires the corresponding G-slots at boot). §4.4 NEW — locks the O(1) inheritance property: - Schema inheritance: inherits_from chain flattened into FamilyEntry.axiom_blob at hydration; query-time cost is one masked u16 + one array index = O(1). Zero chain-walks at query time. - Label inheritance: rdfs:label per-locale collapsed during the subClassOf walk at hydration; FamilyEntry.label_* reads are O(1) array index. Zero parent lookup at query time. - Codebook inheritance: per-family centroid references parent codebook by u8 offset when content distributions overlap (with Jirak-aware Berry-Esseen bound per I-NOISE-FLOOR-JIRAK). One indirection max. - Why family buckets vs flat dict: ~5ns L1-cache-resident two array indices vs ~50-100ns hash + collision + cache miss = 20× cost gap. Co-design between construction tool (hydrators) and runtime substrate (family buckets) — neither earns the property alone. Concrete consumer-side payoffs spelled out for woa-bridge, medcare-bridge, smb-bridge: pre-baked schema / label / codebook inheritance means route handlers read one FamilyEntry per row identity; no OWL reasoning, no rdfs:label walk, no Schematron re-parse at query time.
…r codes (NOT random bitpacking) User correction: lance-graph is supposed to think in "bar codes" (CAM content-addressable memory), NOT random bitpacking. The §4 framing through 4.4 risked reading as "OwlIdentity is a u16 with high/low byte slices stuffed in for storage convenience" — which would be random bitpacking. The correct framing is: OwlIdentity IS the bar code; the per-family codebook IS the CAM substrate; the 256-slot dense array IS the CAM addressed by the bar code; hydrators ISSUE bar codes from external standards; the inherits-from chain PROPAGATES content-addressability through the hierarchy. §4.5 NEW — locks the substrate framing: - Side-by-side wrong-vs-right framing table for: OwlIdentity (bar code, not bitpack), FamilyEntry (what bar code resolves to via CAM, not packed beside the u16), codebook (IS the CAM substrate, not quantisation table), 256-slot dense array (IS the per-family CAM, not storage-density optimisation), hydrators (issue bar codes from external standards, not "populate fields"), inherits-from chain (propagates content-addressability, not parent-pointer for reasoning). - Cross-reference to CLAUDE.md I-VSA-IDENTITIES iron rule (2026-04-21): "VSA operates on IDENTITY fingerprints that POINT TO content. Never on content's bitpacked/quantized register itself." Register-loss problem is the same failure mode this section prevents; OwlIdentity is a Vsa16k-shaped identity at u16 scale. - Four CAM tests (per I-VSA-IDENTITIES Test 0..3) applied directly to the OwlIdentity design: register laziness (URI for schema-authoring, bar code for runtime), bundle size (N=1, no VSA superposition on bar codes), role orthogonality (high byte enforces disjoint family spaces), cleanup codebook (per-family PerFamilyCodebook IS the cleanup codebook). - Concrete diagnostic for PR review — anti-pattern examples (manual bit-unpack of owl.0; ad-hoc OwlIdentity::from_parts in business logic; sidecar HashMaps keyed by OwlIdentity that bypass the family codebook) and positive patterns (bridge.entity(name) → CAM-keyed EntityRef; hydrators issue starting_entity_id integers as CAM coordinates, not payloads). - Cross-tier consistency note: the Lance-cache persistence (§4.2) works because the column store IS a CAM at rest. Hot-path CAM and cold-path CAM are the same shape, just different storage tiers — no semantic translation between them. This explains why §4.4's O(1) inheritance property holds: it holds because the substrate IS a CAM, addressed by bar codes. Random bitpacking would forfeit both the O(1) property and the inheritance-propagation property.
…caches stay clean only because writes are governed
User correction: the OWL maps can be cached in lance-graph + OGIT
(the §4.5 CAM substrate makes it cheap), but it would become
dirty quickly if everyone could edit the authoritative spine.
§4.5 explained why the spine CAN be cached; §4.6 locks in why
those caches stay clean — one controlled write path.
§4.6 NEW — covers:
- The substrate property (§4.5) and the governance property
are co-load-bearing: CAM alone yields drift under ad-hoc
edits; governance alone forfeits the O(1) gain. Together
they yield stable bar codes + clean inheritance chains +
fast lookups + trust the spine is what the spine says.
- The one controlled write path (ASCII diagram): external
standards → producer (hydrator / scanner / admin form) →
MappingProposal stream with proposal_sha256 dedup →
OntologyRegistry::append_proposals → Lance dataset (cold
CAM) → boot-time scan → in-memory OgitFamilyTable (hot
CAM) → consumer bridges READ ONLY.
- Three properties enforced: single producer surface
(MappingProposal is the only mutable DTO); idempotent
dedup at boundary (proposal_sha256 keyed); versioned
G-slots (OGIT::*_V1.1 carries the version field; V2
ships alongside V1 for controlled migration).
- Concrete failure cascade if a consumer edits the spine
ad-hoc: bar code reshuffle → cross-consumer cache
incoherence → spine collapses to mass of locally-true
views that don't intersect cleanly. Multiply by 75
families × 256 slots × N consumers = no spine.
- Enforcement surfaces (3 checkpoints, all shipped):
source-of-truth TTL in AdaWorldAPI/OGIT (PR-reviewed
merges); OntologyRegistry write API only via
append_proposals; NamespaceBridge trait surface
exposes only read methods.
- Legitimate change path: upstream standard ships new
version → TTL update in AdaWorldAPI/OGIT (PR review) →
new hydrator at OGIT::<NAME>_V2.0 → consumers opt-in
at boot → side-by-side until full migration → V1
deprecated. Same governance pattern as
I-LEGACY-API-FEATURE-GATED for CausalEdge64.
- Three new TODO items added:
· D-UB-12 — lock read-only invariant in trait surface;
gate any pub-mutation methods on OntologyRegistry to
pub(crate) or #[doc(hidden)]. ~30 LOC + 2 tests.
· D-UB-13 — proposal_sha256 idempotency test (re-hydrate
same TTL → 0 new rows). ~40 LOC test.
· D-UB-14 — versioned G-slot migration smoke test;
pin-V1 vs pin-V2 consumers in same registry don't
cross-contaminate. ~80 LOC test.
This is the runtime/data-layer analogue of the bookkeeping
append-only governance (settings.json Edit/Write deny on the
8 board files per the ATT activation). Same discipline, different
substrate.
…M per-OGIT (when in doubt, that keeps things tidy)
User directive: "if in doubt store the CAM per OGIT so everything
is tidy." Locking the default storage rule for any CAM-shaped
artifact in the spine.
§4.7 NEW — covers:
- Per-OGIT-G-slot storage table for: PerFamilyCodebook,
OgitFamilyTable.entries[256], edge IRI whitelists, Lance-cache
partitioning, hydration-filter namespaces, per-super-domain HKDF
context. Each row: where it lives tidily vs where it would live
messily if globally pooled.
- Six reasons per-OGIT is the tidy default:
1. Cache invalidation stays scoped — one hydrator update = one
G-slot rebuild, no blast across the spine.
2. Versioning is local — DOLCE_V1 + DOLCE_V2 coexist physically
separate; consumer-pinned migration, not workspace-wide.
3. Hot-path locality matches read patterns — consumer loads
only the G-slots it touches; cold G-slots stay on disk.
4. Authorship boundary aligns with cache boundary — hydrate_dolce
is sole writer of DOLCE_V1's CAM; per-OGIT IS the lock
granularity.
5. Storage layout aligns with the read-only consumer surface
— NamespaceBridge.g_lock() already returns the G-slot; consumer
working set IS the G-slot CAM.
6. Discovery + governance + caching share the G-slot as one
organizational primitive.
- Why global storage is wrong: bar-code address space is local
(slot 17 in DOLCE ≠ slot 17 in PROV-O); cross-family inheritance
via inherits_from is explicit not transitive; updates to one
family's codebook would invalidate every other family's bar
codes.
- Rule of thumb for new §5 deliverables: any CAM-shaped artifact
defaults to per-OGIT-G-slot storage. Global storage requires
written justification in the deliverable spec.
Cross-references:
- §4.6 governs WHO writes; §4.7 governs WHERE writes land.
- super-domain-rbac-tenancy-v1.md §13.4 hard-lock crypto barrier:
per-OGIT storage is the substrate that makes per-super-domain
HKDF derivation work at storage-partition time (not
row-decryption time).
- CLAUDE.md Mandatory Board-Hygiene Rule: per-board-file
append-only governance is the doc-layer analogue of per-OGIT
CAM storage. Same partitioning instinct.
…d on UnifiedBridge, otherwise quickest target) User observation: MedCare-rs is behind on the UnifiedBridge migration but other than that it's the quickest of the three consumer plans to land. §9 locks this ranking. §9 covers: - Work-remaining ranking table across all three consumers (MedCare-rs < smb-office-rs < woa-rs in total work-remaining) with substrate maturity + UnifiedBridge constructor status + net effort per consumer. - Concrete framing of "behind on UnifiedBridge": medcare_unified_bridge constructor doesn't exist (D-UB-6 = D-LGMC-4). Today consumers take &MedcareBridge for resolution + &medcare-rbac for RLS separately; target is state.unified_bridge.authorize(owl, row_tenant, op) as one 4-stage call. SMB has its constructor in-tree (parameterised over OgitBridge placeholder); MedCare doesn't. - Why MedCare is still quickest despite being behind: the scaffolding gap that makes woa-rs Phase 0+1 expensive (~13 days) is already done in MedCare-rs (medcare-bridge crate, vendor symlinks, MedcareRegistry helper, lance-phase2 feature, medcare-rbac sister, LanceProbe parity, parity ingest endpoint, F1-F5 narrative all shipped). Remaining gap is wire-up, not scaffolding: ~570 LOC + ~25 tests across 5 commits. Plausibly a 1-2 day session. - Sequencing recommendation: MedCare-rs is the right target for the "prove the unified-bridge story end-to-end" micro-sprint. Demonstrates parallelbetrieb loop + 4-stage authorize + Lance-cache persistence + cross-language diverse- redundancy witness + HIPAA compliance regime. Suggested PR sequence: D-LGMC-1 → D-LGMC-4 → D-LGMC-2 + D-LGMC-3 → smoke test against LanceProbe ingest. - Phase status revision: D-LGMC-4 is now flagged HEADLINE GAP (was buried in Phase 3 of §2). Critical path remains D-LGMC-1 → D-LGMC-4 → D-LGMC-2/3. This complements §8 (parallelbetrieb shipped + MongoDB alt cold path) by adding the positional framing: §8 says what's already done; §9 says what that means for sequencing.
…e template source
User correction: smb-office-rs is empty (no live business data;
the inherited C# WinForms ERP runs in prod, smb-office-rs is the
pre-prod Rust refactor) AND already carries the unified-bridge
template; that's a different "quickest" than MedCare-rs's
"quickest target for end-to-end proof."
§7 NEW — covers:
- The empty-system property (3 consequences):
1. No business data to migrate (smb-mongo::MongoImporter is
one-shot; not witnessing live writes).
2. No reconciler imperative — SmbMongoReconciler exists as
the SISTER template for medcare's MysqlReconciler, but
no live parallelbetrieb runs until C# WinForms cutover.
3. No live-system constraint on D-LGSMB-3 type-param swap
(free 15-LOC change; no production callers to ripple
through).
- The UnifiedBridge template property:
smb-bridge/src/unified_bridge_wiring.rs::smb_unified_bridge
is THE canonical reference (the only existing
<repo>_unified_bridge function in any consumer crate
today). Referenced by unified-bridge-consumer-migration-v1
§3 as "the working reference"; by lance-graph-in-medcare-rs-v1
D-LGMC-4 as the mirror source; by lance-graph-in-woa-rs-v1
D-WLG-3 as the template. The doc-comments on lines 9-14 +
16-25 + 27-33 are the forward-looking design map other
consumers absorb.
- Three different "quickest" stories spelled out:
· MedCare-rs: quickest TARGET for end-to-end proof
(mature substrate, ~570 LOC wire-up gap)
· smb-office-rs: quickest SOURCE for template harvesting
(empty system, canonical reference constructor)
· woa-rs: slowest but clearest scope (greenfield,
mechanical mirror-from-templates, ~13 days Phase 0-3)
- Harvest order diagram: smb-office-rs ships SmbBridge
upstream + role groups + type-param swap → MedCare-rs and
woa-rs copy by mirroring smb_unified_bridge. MedCare-rs
first (substrate exists to plug into), woa-rs after
(needs Phase 0+1 scaffolding first).
- Status reframing: §1 was right about smb-office-rs being
"most-progressed consumer outside MedCare-rs" at the
bridge-substrate level; §7 clarifies the business-data
level (empty there). §2's Phase A-E deliverables unchanged;
§7 adds the propagation context (D-LGSMB-3 unlocks the
template harvest, not just smb's own integration).
…lready in sea-orm at the cold path
User correction: woa-rs is ontology-virgin at the
lance-graph-ontology hot path BUT it already has OGIT
baked into sea-orm entities at the cold path. The MedCare-rs
MysqlReconciler pattern transfers 1:1 with sea-orm fetchers
because sea-orm is ergonomic and self-explaining.
§10 NEW — covers:
- Cold-path inventory: vendor/ogit/v02-harvest/entities/*.ttl
is the source the existing sea-orm entities were
generated/hand-mirrored from. Customer / WorkOrder /
Position / Tenant / User / Mahnung / Logbook /
Dokument / Einsatz / Stundenzettel-Eintrag entities all
derive from OGIT TTL per RFC v02-006's layer table.
- "Ontology virgin" framing corrected: true at the HOT
path (no woa-bridge crate, no OntologyRegistry consumption,
no UnifiedBridge<WoaBridge> constructor); FALSE at the
cold path (sea-orm entities are the OGIT structure
already in tree, just not codegen'd yet).
- MedCare-rs MysqlReconciler pattern transfer: PatientFetcher
trait + canned-row testing pattern transfers directly
with sea-orm find_by_id substituted for
medcare_db::queries::*. Reconciler shell (parse_route +
diff_rows + build_event) verbatim from MedCare-rs.
- Two-axis harvest order updated:
· smb-office-rs → bridge-wiring template
(smb_unified_bridge reference)
· MedCare-rs → reconciler-pattern (MysqlReconciler shell)
woa-rs absorbs both axes; the sea-orm cold path it
already has makes the MedCare-rs axis particularly
clean to copy.
- Phase 0-3 closure revised from ~13 days to ~9-10 days:
Phase 1 drops from 3 days to 2 days (sea-orm authoring
already done; just helpers + constructor + ontology
declarations). Phase 2 drops from 4 to 3 days (fewer
initial handlers since RFC v02-006 codegen will absorb
most route-shape work). Phase 3 drops from 5 to 3-4 days
(D-WLG-9 Lance projection IS the WoaMysqlReconciler).
- Three new deliverables added:
· D-WLG-15 — WoaMysqlReconciler mirroring
MedcareMysqlReconciler 1:1, Round-1 = Customer
(/api/customers/{kdnr}), ~80 LOC + 11 tests
· D-WLG-16 — Production query-handle wiring with
sea-orm find_by_id, ~50 LOC + 2 tests
· D-WLG-17 — Drift-event dashboard endpoint
(no C# parity tool for woa; sink directly to
LanceAuditSink), ~40 LOC + 2 tests
- Mirror source for woa-rs is MedCare-rs (sea-orm + MySQL
homologous to medcare_db + MySQL), NOT smb-office-rs
(MongoDB + BSON). smb-office-rs is the template SOURCE
for bridge-wiring; for the storage-tier MIRROR, MedCare
is the right reference.
…arget harvesting XRechnung + parallelbetrieb User strategic reframe: MedCare-rs and smb-office-rs are transcodes that never worked as Rust (pre-prod Rust ports of C# WinForms apps whose UIs can't move to web cheaply). woa-rs is different — it's a web application transcode (Python/Flask → Rust/axum), so the same engineering work produces VISIBLE WEB-UI feedback per PR instead of test-report-only changes. That asymmetry makes woa-rs the rewarding integration target even though §10 named MedCare-rs the quickest substrate- complete target. Engineering completeness ≠ user-visible reward. §11 NEW — covers: - The transcode-vs-webapp asymmetry: woa = minutes-per-PR visible feedback; SMB + MedCare = days-to-weeks (customer surface is C# WinForms outside the port's scope). - Three-harvest diagram: HARVEST 1 from smb-office-rs (hydrate_zugferd + hydrate_zugferd_rules + SchematronHydrator + XsdHydrator → woa-rs XRechnung/ Factur-X invoice generation, visible as downloadable EN16931-conformant XML+PDF); HARVEST 2 from MedCare-rs (MedcareMysqlReconciler shell + parallelbetrieb trait → WoaMysqlReconciler with sea-orm fetchers + /api/__parity drift dashboard); HARVEST 3 from in-tree (vendor/ogit + sea-orm entities + lance-graph-ontology hydrators → /api/__ontology + /api/__graph routes). - 9-rung PR ladder where each rung produces a screenshot: PR-1/2 scaffolding (build green); PR-3/4 ontology hydration (/api/v1/health + /api/__ontology visible); PR-5 XRechnung visible reward (Stefan downloads EN16931 invoice); PR-6 parity dashboard visible reward (admin sees drift status); PR-7 tenant RLS (cross-tenant 404 visible); PR-8 Cypher playground (opt-in); PR-9 similarity (opt-in). - Resolution of the three "right target" framings across the plans: smb is right for the bridge-wiring TEMPLATE + XRechnung flow; MedCare is right for the reconciler SHELL + parity-dashboard pattern; woa is right for the CUSTOMER-VISIBLE INTEGRATION. Different questions, three right answers, not a linear ranking. - Harvest shape correction: NOT linear (smb → MedCare → woa); it's fan-IN to woa. SMB and MedCare ship patterns in parallel; woa absorbs both + adds the web-UI surface. - What stays unchanged: §9 hot/cold split + §10 effort estimate (~9-10 days Phase 0-3) + D-WLG-1..17 deliverable IDs. §11 specifies SHIPPING ORDER by visible-reward, not per-PR cost.
…et vs per-handler integration
User architecture clarification: smb-office-rs and MedCare-rs
both scraped business logic from already-working C# WinForms
apps. woa-rs is different — it transcoded from Python
(Flask/SQLAlchemy), uses reusable SoC + DTO mapping, and has
660 routes already harvested from Python source via codegen
into Jinja → askama templates (per RFC v02-006).
That changes the unified-bridge integration approach. §11
framed each integration step as "handler-level" — that's
right at the user-visible layer but incomplete at the
implementation layer. The actual change for most of the 660
routes is per-BUCKET via codegen, not per-handler.
§12 NEW — covers:
- Three-way source/reference table:
· smb-office-rs: ~13 MongoDB collections, hand-mirror from C#
· MedCare-rs: 104 MySQL tables → 7 Healthcare OGIT entities,
hand-port + parity-witness via LanceProbe
· woa-rs: 660 routes across 13 buckets, codegen-emitted from
Python source per RFC v02-006
- Per-bucket codegen integration map (all 13 buckets covered):
csrf_form_post_engine_call (194) + ajax_json (105) +
list_for_tenant (80) + form_get_post (55) + detail_for_tenant
(43) + soft_delete (41) + sa_admin_view (34) +
download_blob (31) + pdf_render (22) + template_get (22) +
signed_link_action (15) + get_redirect_shortcut (11) +
other (0). One codegen-template edit propagates to every
route in the bucket.
- PR-7 RLS unification reframed as THE BIG ONE: one codegen
edit to list_for_tenant + detail_for_tenant +
csrf_form_post_engine_call buckets replaces ~317 hand-written
tenant_get_or_404 call sites with state.unified_bridge.
authorize(...). One PR, ~317 routes upgraded.
- SoC + DTO seam is the right MIRROR target: WoaMysqlReconciler
diffs DTOs (CanonicalCustomerRow per RFC v02-006 layer table),
not entity rows. Reconciler doesn't author entity shapes; it
consumes them.
- Effort estimate refined: Phase 0-3 closure narrows from §10's
~9-10 days to ~7-8 days because route-handler integration is
codegen-template work (~6 hours for 3 buckets), not per-
handler edits (~3 days originally).
- §11 PR ladder retained; §12 refines the implementation shape
per rung. PR-5 (XRechnung) lands in pdf_render bucket. PR-6
(parity dashboard) lands in sa_admin_view bucket. PR-7 (RLS
unification) is the cross-bucket codegen edit.
The codegen + SoC + DTO architecture is the force multiplier
that makes woa-rs the rewarding integration target despite
its scale (660 routes vs MedCare's ~30-50 codebook slots).
…6 months of substrate
User strategic stakes: lance-graph was worked on Claude-Code-
intensively for up to 6 months. In that window, the project
produced no end-user visible result — only mock GUIs, dashboards,
unit tests, and the substrate itself. Wiring the lance-graph
business-logic surface into woa-rs is therefore not just one
consumer-integration plan among three; it IS the POC for the
entire 6-month substrate effort.
§13 NEW — covers:
- 6-month substrate inventory: 22 crates, VSA bundling + Jirak
+ CAM-PQ + 7 GraphBLAS semirings + palette codec + attention
table lookup + 36 thinking styles + MUL + 16-strategy planner
+ NARS + AriGraph + CausalEdge64 v2 + 4 substrate iron rules +
10+ ontology hydrators + 5 tenant bridges + 12-worker sprints
+ 4-savant ensemble + ATT NLSpec activation + sea-orm DTOs
+ parallelbetrieb + MongoDB bridge + OGIT TTL. End-user
visible from any of this so far: mock GUIs only.
- Five POC criteria woa-rs uniquely meets:
1. Real customer (Stefan deploys WoA in prod)
2. Real business logic (660 routes, ~20 functional families)
3. Real visibility (every PR has a URL)
4. Real failure modes (drift, RLS fail-OPEN, hydrator non-
idempotency surface at customer-load)
5. Real economic feedback (Stefan's time saved is the metric)
- Why MedCare and SMB don't substitute: MedCare has a real
customer but the Rust port doesn't replace anything user-
visible (C# WinForms still in use; LanceProbe is ops-visible);
SMB is pre-prod (no customer exposed). Both are substrate
proofs for internal audiences; only woa-rs is a substrate
proof for a paying customer.
- PR-5 elevated to "the moment lance-graph stops being substrate-
only and starts being a customer-deliverable system." Smallest
POC slice: one route handler + one customer-visible artefact
(EN16931 XRechnung XML + Factur-X PDF). DATEV/X-Rechnung
validation tools become the external success indicator.
- P0/P1/P2 priority ranking across the three consumer plans:
P0 = woa-rs Phase 0-3 + PR-5 (~7-8 days, POC milestone).
P1 = woa-rs PR-6/7 + MedCare-rs Phase 1-3 + SMB-office-rs
Phase A-B.
P2 = post-POC opt-in features (Cypher, similarity, cross-
consumer parity test).
The lance-graph substrate ledger entries this PR-5 produces are
the first "real-load test" entries for every primitive that
participates: hydrator X, planner strategy Y, unified-bridge
stage Z, RLS predicate W. If any regresses, PR-5 surfaces it
the day it ships — that's the POC's diagnostic value.
…mer-visible artefact
User directive: refer to open plans + status in lance-graph
board / plans dirs, add priorities, make an integration plan
using the provided framing. Plus three attached distillation
docs (DOLCE hydrator spec, Odoo work-steal, ERP Foundry HHTL
L1-L4 distillation) folded in.
NEW lance-graph-business-logic-poc-via-woa-rs-v1.md (236 LOC):
- §1 Why: 6 months of substrate work, zero customer-visible
outcomes; this plan locks the first POC slice.
- §2 POC milestone: woa-rs PR-5 (XRechnung visible reward).
Maps 1:1 to "First Foundry-style projection: fibo:Transaction"
from the third attached distillation doc Phase 9.
- §3 Priority ranking with concrete effort estimates:
· P0: woa-rs Phase 0-3 + PR-5 (~7-8 days, POC milestone)
· P1: woa-rs PR-6/7 + MedCare Phase 1-3 + SMB Phase A-B
(~15-20 days net)
· P2: opt-in Cypher / similarity / cross-consumer parity test
· P3: Odoo work-steal extraction (parallel stream)
- §4 Integrated 9-rung PR ladder where each rung produces a
screenshot or external-validation result.
- §5 L1-L4 layered ontology dependency map per the third
distillation doc. Status post-PR-407+408: L1+L2+L3+L4
partial; gaps in L3 (UBL, ISO 20022, XBRL GL→OWL mappers)
and L4 (HGB/UStG/GoBD/Datev DTVF) are P2/P3 fill-in AFTER
POC ships.
- §6 Cross-plan D-id index by priority (no new D-ids; this
plan re-indexes existing IDs).
- §7 Parallel substrate dependencies (active plans that
interact with the POC path); single non-trivial coordination
is the unpushed D-SDR-3/4/5 follow-on PR.
- §8 Risk register (9 risks; mitigations named per risk).
- §9 Success criteria: four observable surfaces green
simultaneously for ≥1 calendar day after PR-5 ships.
- §10-§12 Open questions + status + references (source plans
+ attached distillation docs + external validation targets:
xeinkauf.de XRechnung validator + Mustang reference).
INTEGRATION_PLANS.md appended with the new plan entry (tee -a;
the file is in the deny list for Edit per the ATT activation).
The three user-attached distillation docs are now referenced
by file ID for future session-load (not committed to the repo;
they're in /root/.claude/uploads/).
…tream feeding cognitive models
User strategic reframe: the Odoo-harvested OWL glue isn't a P3
nice-to-have — it's immediately important because the cognitive
models need to be built AROUND it. In the end it's the most
rewarding outcome once wired into lance-graph.
§3 priority ranking originally put Odoo at P3 (parallel stream
after POC). §14 elevates to P1 (parallel substrate stream
running concurrent with the POC).
§14 NEW — covers:
- The structural claim: cognitive substrate is only as
semantically grounded as the OWL it reasons over. L1-L4
hydrators (post-PR-407/408) give the formal ontology
spine; they DON'T give the operational ERP vocabulary
the cognitive models need (Partner, Account, Invoice,
Stock, BOM, etc.). Odoo's 20+ years of ERP work IS that
vocabulary, formalized as Python models + XML data files.
- What "OWL glue" means concretely: alignment TTL that ties
Odoo URIs to upstream OWL classes via owl:equivalentClass
/ owl:equivalentProperty (odoo:res.partner ↔ vcard:Kind,
odoo:account.move ↔ gl-cor:entryHeader + fibo:Transaction,
odoo:product.template ↔ schema:Product, etc.). The glue
is what types semantic objects so the cognitive shader's
16-bit DOLCE slot classifier can run.
- Why "build cognitive models around it" matters structurally:
table of 6 cognitive layers showing what each does WITHOUT
OWL glue (opaque strings, no semantic prior, undifferentiated
row types, undefined DOLCE slots, edges without semantic
identity) vs WITH OWL glue (FIBO-typed entities, dispatch
by OWL type, per-super-domain MUL profile, pre-classified
DOLCE slots at hydration time, semantically-identified edges).
- The wiring path: Odoo source → crates/odoo-extract/ Rust
AST walker → per-module TTLs → hand-curated alignment TTLs
→ hydrate_odoo_* functions → OntologyRegistry per-OGIT G-slots
→ cognitive substrate consumes OWL types natively at every
decision point.
- 10 new D-ODOO-* deliverables ranked by priority:
· D-ODOO-1..5 + D-ODOO-7 = P1 (parallel with POC), ~10-12
days net total. D-ODOO-7 (Odoo→ZUGFeRD alignment) gated
on PR-5 for cross-attribution.
· D-ODOO-6 = P2 (SKR03/04 refresh; substrate already
covered by in-tree hydrate_skr03/04 from DATEV CSV).
· D-ODOO-8/9/10 = P2 (broader Odoo coverage + Python
adapter + end-to-end demo).
- §3 priority table updated: Odoo elevated from P3 to P1
parallel-concurrent-with-POC stream.
- §14.7 names the rewarding end-state: once D-ODOO-10 lands,
lance-graph reasons about ERP entities natively — Cypher
queries cross-walk Odoo + DATEV SKR04 + FIBO in one query;
NARS dispatches different evidence-update rules per OWL
type; MUL picks per-super-domain threshold profile by OWL
super-domain; cognitive shader's DOLCE slot pre-classifies
every Odoo entity at hydration time per §4.4 O(1)
inheritance; Foundry-style typed-object surface becomes
navigable across Odoo's full operational vocabulary.
- §14.8 what this DOES NOT change: PR-5 stays the POC
milestone; L1-L4 layered map stays (Odoo lands on top via
inherits_from); §4.6 read-only spine + §4.7 per-OGIT
storage governance both apply to Odoo extraction (emits
MappingProposal streams via append_proposals; lands at
OGIT::ODOO_<MODULE>_V1 per-module G-slots).
The reward shape: PR-5 is the proof the wiring works on
ONE route; D-ODOO-10 is the proof the wiring works on the
entire ERP semantic surface.
…for OGIT/OWL/DOLCE + WoA work-steal map User request: analyse how Odoo OWL and Palantir Foundry ontology converge; what we can learn for the long run with OGIT/OWL/DOLCE; what WoA could wire/repurpose/work-steal/reinvent from Odoo and smb-office-rs. §15 NEW — covers: §15.1 Convergence map (Odoo OWL ↔ Palantir Foundry) — 13-row table showing structural homology at the typed-object surface despite radically different runtimes (Odoo Python+PostgreSQL vs Foundry proprietary Spark-shaped). Both reduce to OWL/SHACL/ SKOS+PROV-O; OGIT is positioned to host both as projections. §15.2 Divergences and what each teaches — 8 axes where they diverge (authoring style, runtime coupling, granularity, versioning, schema evolution, licensing, naming, reasoning depth). Headline lesson: Odoo gives operational coverage at the cost of runtime coupling; Foundry gives loose coupling at the cost of curated authoring. OGIT decouples authoring from coverage by accepting both into one CAM-addressable substrate, plus adds the cognitive layer neither has. §15.3 Six long-run lessons for OGIT/OWL/DOLCE: 1. Typed-object surface IS a projection, not a separate ontology 2. Operational vocabulary needs an extraction source 3. DOLCE-as-root is the structural decision that makes everything compose (16-bit cognitive shader slot is defined relative to DOLCE) 4. Alignment TTL is the "glue"; authoring workflow matters (mechanical for obvious; human-judgement for subtle) 5. Per-OGIT storage + read-only spine + CAM bar codes compose into a self-reinforcing pattern 6. PROV-O is non-optional for any regulated domain §15.4 WoA work-steal map from Odoo — 16-row entity-by-entity table mapping WoA's sea-orm entities to Odoo modules: - Customer ← res.partner + res.partner.bank (WORK-STEAL) - Tenant ← res.company (WORK-STEAL) - User ← res.users + res.partner linked (WORK-STEAL) - WorkOrder ← account.move dual-nature + sale.order (WORK-STEAL the dual-projection pattern) - Position ← account.move.line + sale.order.line (WORK-STEAL) - Mahnung ← (OCA account_due_list or hand-roll) (REPURPOSE) - Stundenzettel-Eintrag ← hr.timesheet / account.analytic.line (WORK-STEAL) - Einsatz ← project.task + helpdesk.ticket + mrp.workorder (REPURPOSE) - Logbook-Eintrag ← mail.thread mixin (WORK-STEAL) - Dokument ← ir.attachment (WORK-STEAL) - Setting / tenant_settings ← ir.config_parameter (REINVENT per RFC-001 — keep typed-struct discipline) - SKR03/SKR04 chart ← l10n_de_skr03/04 (ALREADY WIRED via hydrate_skr03/04) - DATEV Steuerschlüssel ← l10n_de tax templates (PARTIALLY WIRED) - ZUGFeRD/XRechnung generator ← Odoo e-invoicing (ALREADY WIRED via hydrate_zugferd + hydrate_zugferd_rules) - Computed-field dependency graph ← @api.depends (REINVENT as SHACL sh:rule + SPIN) §15.5 WoA work-steal map from smb-office-rs — 14-row artifact-by-artifact table: - woa-bridge / woa-ontology crate skeleton (WIRE 1:1) - woa_unified_bridge constructor (WIRE 1:1 mirror with WoaBridge type-param swap) - WoaMysqlConnector EntityStore impl (REINVENT for sea-orm/ MySQL — trait surface transfers, impl differs from MongoDB) - WoaMysqlReconciler shell (WORK-STEAL shell + reinvent fetchers) - sea-orm-schema-warden agent (REINVENT for sea-orm) - transcode-auditor agent (WIRE with woa-specific reference path) - unified_bridge_wiring.rs design-map doc-comments (WIRE with substitutions) - Iron Rule "lance-graph is additive-only" (WIRE as policy) - Per-customer binary pattern (WIRE LATER — P3, not POC scope) - FFI to WinForms (DO NOT TAKE — WoA has web UI not desktop) - MongoDB connector (DO NOT TAKE — WoA cold path is MySQL) - BSON-schema-specific Customer canonical row (REINVENT with WoA field set) §15.6 The unified roadmap implication — WoA's POC path is mostly composition, not invention. Actual invention surface is ~5 deliverables totalling ~250 LOC: sea-orm fetchers for the reconciler; Mandant.id → TenantId mapping; permission to actor_role mapping; ~9 routes in security-critical buckets that aren't bucket-generic; askama templates for new WoA- specific UI views (e.g., /admin/parity). Everything else is harvest. Explains why the POC achieves in ~7-8 days net. §15.7 One-line summary: typed-object surface IS a projection; operational vocabulary needs an extraction source; DOLCE-as- root is load-bearing; alignment TTL authoring matters; per-OGIT + read-only + CAM compose into self-reinforcement; PROV-O is non-optional. WoA work-steals ~80% from Odoo + smb; actual invention surface ~5 deliverables / ~250 LOC.
…ontology schema lookup module User question: how should the WoA Python original proceed when integrating Odoo, while aligning with the plans — especially around a "cheap Odoo Ontology Schema lookup store"? Architecture: build-time-extracted Python lookup module (woa-ontology-lookup) that mirrors the TTL files Rust's lance-graph-ontology::OntologyRegistry already consumes. Same TTL source feeds both languages; each gets a native reader; no Odoo runtime dependency on either side. §16 NEW — covers: §16.1 Architecture diagram showing the same TTL files in lance-graph/data/ontologies/ feeding both the Rust hydrators (per PR-407/408) and a new Python build script that emits a flat _data.py module with module-level constants. The Python lookup module is READ-ONLY DATA generated at build time; never parses TTL at request time. §16.2 Cost table for "cheap": O(1) dict access; ~1-5 MB resident; one pip install dep; ZERO additional runtime deps; ~5-30s build-time CPU. Stefan's deployment gets one pip install. No new services / ports / workers. §16.3 Four-phase Python rollout (~5-6 days total): - P1 bootstrap (~1 day): woa-ontology-lookup package skeleton + build_lookup.py consuming OGIT WoA + DOLCE + PROV-O + QUDT TTL files (already shipped post-PR-407). - P2 Odoo integration (~1 day, gated on D-ODOO-2/3 Rust-side): extend build script to consume Odoo base extraction + alignment files. lookup adds odoo_equivalent field. - P3 runtime integration (~1-2 days, gated on P2): add helper methods to WoA models; REST API responses include JSON-LD @context; structured logging carries ontology URIs. - P4 federation surface (~2 days, gated on P3): /api/<entity>/ <id>/rdf endpoints emit Turtle/JSON-LD/N-Triples via rdflib; optional /sparql endpoint. §16.4 Concrete Python package shape: dataclass OntologyMapping; lookup(table, column) → Optional[OntologyMapping]; module-level LOOKUP, TABLE_TO_OGIT_URI, OGIT_URI_TO_FIBO, CONTEXT_JSONLD constants in _data.py. ~250 entries covering all WoA entities. §16.5 Ownership map: - lance-graph (this repo): source-of-truth TTL + python/woa_ontology_lookup/ sub-tree with build script; publishes versioned package. - WoA Python: single requirements.txt line; pure consumer. - woa-rs: already consumes via OntologyRegistry. Both languages are native readers of one source of truth. §16.6 Payoffs for WoA Python BEFORE Rust port replaces anything: 1. Schema-conscious API responses (JSON-LD @context) 2. Odoo parity drift checks at build time 3. Federation via standard linked-data tools 4. Schema-drift detection earlier in pipeline than WoaMysqlReconciler catches it 5. Cognitive-model preparation: Python exports via federation surface; Rust cognitive cascade ingests; two-version bridge from Odoo distillation §"The two-version bridge". §16.7 What this DOES NOT do: - Does NOT change WoA's data model (Iron Rule №5 preserved) - Does NOT add Odoo runtime deps (no odoo-bin, XML-RPC, ORM) - Does NOT introduce reasoning into Python (no OWL reasoner, no SPARQL engine, no SHACL validator at runtime) - Does NOT compete with woa-rs §16.8 Cross-references to §14.5 D-ODOO-1..10, §4.2/4.6/4.7 governance, the Odoo work-steal distillation §"The two-version bridge", and the woa-rs/CLAUDE.md Iron Rules envelope. The constraint envelope: WoA Python stays canonical (Iron Rule №2); doesn't break the source repo (Iron Rule №5); gets schema awareness via build-time extraction; ships independently of the Rust port progress; benefits Stefan even before woa-rs PR-5 lands.
…n Python today; backport to smb-office-rs x-rechnung-rs) User scenario: Stefan is conservative, wants least-invasive route, needs ZUGFeRD/E-Rechnung as German law sales pitch, optionally backport synergies for smb-office-rs crates. Two findings drive the answer: 1. smb-office-rs/crates/x-rechnung-rs/ ALREADY EXISTS as a tenant-agnostic 73-line skeleton naming WoA (WT-30) + SAP (SIMAFPort-Rust) + SMB-Office C# (future FFI) as planned consumers. WT-30 sub-chunks (UBL/CII XML types + mapping + PDF/A-3 embed + CLI bin) are pending. 2. WoA Python uses fpdf2==2.8.3 for PDF today; NO ZUGFeRD/ factur-x library installed yet. So the answer is: Stefan ships ZUGFeRD via Python factur-x TODAY (conservative, days-out, no Rust dep), and his real- customer-validated WOA_TO_CII_MAPPING becomes the spec source for x-rechnung-rs WT-30 (multi-tenant from day 1). §17 NEW — covers: §17.1 Stefan's stack + what already ships in tree - WoA Python: Flask + SQLAlchemy + fpdf2; no factur-x - smb-office-rs: x-rechnung-rs skeleton + smb-woa (artikel+customer+auth) + customer-woa-bin - lance-graph: hydrate_zugferd + hydrate_zugferd_rules + SchematronHydrator + XsdHydrator (post-PR-407) - woa-rs: woa_pdf with GoBD Pflichtangaben reference (post PR #152) §17.2 Recommended path: factur-x Python library - Maintained by Alexis de Lattre (Akretion — same author as Odoo l10n_de_facturx); Odoo uses this library natively - Implements EN16931 + ZUGFeRD profiles (BASIC/EN16931/ EXTENDED/MINIMUM/factur-x 1.0.07) - Validates against EN16931 XSD + ZUGFeRD Schematron rules out of box — same surface lance-graph hydrators consume - Concrete code skeleton: WOA_TO_CII_MAPPING dict + build_cii_xml() + render_xrechnung() + 1 route handler; ~150 LOC total; existing WoaPDF stays unchanged §17.3 Sales pitch framing — German B-Rechnungspflicht timeline: - 2025-01-01: B2B must RECEIVE e-invoices - 2027-01-01: B2B > €800K turnover must ISSUE - 2028-01-01: ALL B2B must ISSUE Five pitch points: ahead of mandate by 2-3 years; zero customer manual work; EN16931-conformant validated at emit; drop-in for existing flow; free upgrade path to Rust later. §17.4 The high-leverage move: Stefan's WOA_TO_CII_MAPPING Python dict becomes the canonical spec for x-rechnung-rs WT-30 sub-chunk #2 (SemanticType → CII element mapping). Per-row real-customer validation > clean-room Rust authoring. 7-step backport workflow: TOML transcription → CII builder port → PDF/A-3 embed → XSD validation (binds to hydrate_zugferd) → Schematron (binds to hydrate_zugferd_ rules) → CLI bin → customer-woa-bin wiring. ~1-1.5 weeks Rust backport effort. §17.5 Bidirectional value loop diagram: same mapping table feeds Python (Stefan today) + Rust (x-rechnung-rs WT-30) + future consumers (SAP SIMAFPort-Rust, SMB-Office C# via FFI, direct Rust lib imports). Convergence point. §17.6 What NOT to do: don't reimplement EN16931 from XSD; don't adopt Mustang (Java/JVM dep); don't wait for woa-rs PR-5; don't build Rust before Python validation baseline; don't change WoA data model (Iron Rule №5); don't add direct lance-graph dep to Python (Iron Rule №2). §17.7 7-week sequencing: Stefan ships Week 1; Sonnet subagent transcribes mapping Week 2; x-rechnung-rs WT-30 sub-chunks land Weeks 3-6; optional Python→Rust swap via CLI subprocess Week 7+. Stefan never blocks on Rust; Rust never blocks on Stefan. §17.8 One-line summary: pip install factur-x + 1 Python file + 1 route + 1 mapping table = sales-pitch-ready ZUGFeRD in ~1 week; mapping backports to x-rechnung-rs as canonical spec source; byte-identical EN16931 output across both runtimes; consumers pick impl that fits their deployment. The convergence is structural: x-rechnung-rs already plans WoA as first tenant; Stefan's real-customer validation becomes the spec source the Rust port references. Both ship value; neither blocks the other.
…est BRIEFING assumes The odoo-richness harvest BRIEFING (woa-rs/.claude/odoo/) documents an "already built" odoo_alignment.rs with resolve_odoo / resolve_odoo_to_family / dolce_odoo — but it never existed in either repo. This builds it for real as the single-source spine module (consumers depend on it; no skr_data mirror, per the per-OGIT-storage / read-only-spine invariant). Two O(1) legs: odoo class --owl:equivalentClass--> OWL pivot --> OGIT family+slot --> FamilyEntry - resolve_odoo(class) -> Option<OwlPivot>: leg 1 (static seed). - resolve_odoo_to_family(class, &table): both legs, confirmed live against the family's hydrated OgitFamilyTable (wrong-family-safe, no panic). - resolve_odoo_entry(class, &table) -> Option<&FamilyEntry>: lands on the inline entry the lanes read for inherited thinking style. - dolce_odoo(class): DOLCE marker from suffix rules. - seed_family_table(&mut table): populate foundry slots (hydration overlay/tests). Option B (no minted family/slot): the four foundry family bytes are restated from data/family_registry.ttl (BillingCore 0x61, SMBAccounting 0x62, SmbFoundryCustomer 0x80, SmbFoundryInvoice 0x81) and asserted against it in a test. Seed rows: res.partner->fibo:LegalEntity, account.move->fibo:Transaction, account.move.line->fibo:JournalEntryLine, account.account->fibo:Account, account.account.template(SKR)->fibo:Account, product.*->schema:Product. Unmapped classes (stock.move, sale.order, hr.*, account.reconcile.model) resolve to None — the Layer-2-axiom signal, not an invented family. 9 unit tests; cargo check + clippy + fmt clean.
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughThis PR activates the ATT (Automated Testing Traceability) framework for lance-graph, wires it across configuration and bootload files, defines five cross-consumer integration plans for unified-bridge migration across three Rust consumer workspaces, implements an Odoo→OWL→OGIT alignment bridge module with family seeding and resolver functions, and adds vendor directory documentation with symlink setup for ractor dependency management. ChangesLance-Graph ATT Activation, Consumer Integration Plans, and Odoo Alignment
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ecb92c012b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pub fn seed_family_table(table: &mut OgitFamilyTable) { | ||
| for row in ODOO_SEED { | ||
| if row.family == table.family { | ||
| table.set(row.slot, row.entry()); |
There was a problem hiding this comment.
seed_family_table unconditionally calls table.set(row.slot, row.entry()), so if this runs on an already hydrated OgitFamilyTable (the doc says the TTL overlay path calls it), it overwrites existing slots with stripped-down FamilyEntry values (owl_characteristics, axiom_blob, and verbs are reset to empty). That silently discards canonical ontology metadata and can change what resolve_odoo_entry returns for the same slot; this should only fill missing slots or merge without clobbering hydrated fields.
Useful? React with 👍 / 👎.
This was referenced May 27, 2026
Merged
AdaWorldAPI
added a commit
that referenced
this pull request
May 28, 2026
…att-k2pHI Activate ATT NLSpecs + integration plans + odoo_alignment cache
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This branch carries one session's work across three piles:
.claude/ATT/so the spec actually governs agent behavior in this repo:ACTIVATION.mdreceipt (which DoD items are met / partial / gap),BOOT.md, agentBOOT.md, asession-start.shhook, andsettings.jsondeny-rules enforcing the append-only governance on bookkeeping files..claude/plans/) — the UnifiedBridge consumer-migration plan plus per-repo lance-graph wiring plans for woa-rs, smb-office-rs, medcare-rs, and a consolidating POC roadmap (woa-rs PR-5 / XRechnung as the first customer-visible artefact). Framing locked over the session: hot/cold split, CAM bar codes (not bitpacking), read-only spine + governed write path, per-OGIT storage.odoo_alignmentcache (the only code change) — the OGIT→OWL→odoo alignment module the odoo-richness harvest BRIEFING assumed already existed but never did.The code change —
crates/lance-graph-callcenter/src/odoo_alignment.rsSingle-source spine module (consumers depend on it; no
skr_datamirror — the spine goes dirty the moment two copies drift). Two O(1) legs:resolve_odoo(class) -> Option<OwlPivot>— leg 1 (static seed).resolve_odoo_to_family(class, &table)— both legs, confirmed live against the family's hydrated table (wrong-family-safe, never panics).resolve_odoo_entry(class, &table) -> Option<&FamilyEntry>— lands on the inline entry the lanes read for the inherited thinking style.dolce_odoo(class)— DOLCE marker from suffix rules.seed_family_table(&mut table)— populates foundry slots (hydration overlay / tests).Option B (no minted family/slot): the four foundry family bytes are restated from
data/family_registry.ttl(BillingCore0x61, SMBAccounting0x62, SmbFoundryCustomer0x80, SmbFoundryInvoice0x81) and asserted equal to the registry in a test. Seed rows match the BRIEFING (res.partner→fibo:LegalEntity, account.move→fibo:Transaction, account.move.line→fibo:JournalEntryLine, account.account→fibo:Account, SKR→fibo:Account, product.*→schema:Product). Unmapped classes (stock.move,sale.order,hr.*,account.reconcile.model) resolve toNone— the Layer-2-axiom signal, not an invented family.Test plan
cargo check -p lance-graph-callcenter— clean (pre-existingttl_parse.rsdeprecation warnings only).cargo test -p lance-graph-callcenter odoo_alignment— 9/9 pass.cargo clippy -p lance-graph-callcenter— no findings on the new module.cargo fmt -p lance-graph-callcenter --check— clean.Note for reviewers
The BRIEFING (on woa-rs
main) still claims this cache "was just built" with awoa-rs/crates/skr_data/src/odoo_alignment.rsmirror. That mirror was deliberately not created (single-source invariant); the BRIEFING wording can be corrected in a follow-up woa-rs change.Generated by Claude Code
Summary by CodeRabbit
New Features
Documentation