docs(adr): V3 as spine + polyglot transpiler (Rust/Python/C#)#130
Conversation
![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: bf8402137e
ℹ️ 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".
| > Reconciliation with current code: today `NodeRow` = `key(16) | edges(16) | | ||
| > value(480)` with `value` **opaque**. The `[Facet; 32]` / `tenant_schema` is | ||
| > the typed schema this ADR imposes on those same bytes — `ClassView` is the | ||
| > missing brick that turns the 480-byte slab into 30 typed tenant slots. |
There was a problem hiding this comment.
If a follow-up implementation follows this reconciliation block, it will reserve a 16-byte EdgeBlock and expose only a 480-byte value slab, but the current P0 canon in CLAUDE.md:51-52 defines a 16-byte key plus a 496-byte value, and docs/NODEGUID-CANON-AUDIT.md:92-100 records the old 12+4 EdgeBlock as superseded. That makes this ADR a stale wire contract: tenant slots would be offset and sized against the wrong record layout, so generated tenant schemas would not match existing NodeGuid consumers.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed & merged: ADR now follows the key(16)+value(496) canon; 12+4 EdgeBlock recorded as superseded (F-5). Resolving.
Generated by Claude Code
| `ClassView::tenant_schema(classid) -> [TenantRole; 32]`, **static per classid** | ||
| (keeps each tenant a homogeneous, SIMD-scannable GUID column). Roles: |
There was a problem hiding this comment.
This new ClassView::tenant_schema API contradicts the existing ClassView materialization contract: docs/integration/CLASSVIEW-MATERIALIZATION-PLAN.md:68-73 says Class carries types while ClassView is label-only, and docs/integration/CLASSVIEW-MATERIALIZATION-PLAN.md:269-278 calls adding type information to ClassView an anti-pattern because codegen should use Class. If the follow-up implements tenant typing on ClassView, render consumers that rely on the label-only field-mask contract will be coupled to storage/codegen semantics the repo explicitly keeps out of that trait.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed & merged: tenant typing moved onto Class (label-only ClassView untouched), per CLASSVIEW-MATERIALIZATION-PLAN §3 + AP#2. Resolving.
Generated by Claude Code
…+-only; extract() is todo!()) — mirrors ruff #32 Codex fixes
…ck superseded (F-5); tenant typing on Class not ClassView; cite ≤64/paginate-via-hierarchy canon
|
Thanks @codex — both correct against canon; fixed in the commit above.
Bonus: that same plan (§5, Generated by Claude Code |
|
To use Codex here, create an environment for this repo. |
1 participant
Summary
Proposed ADR (
docs/V3-TRANSPILER-ADR.md) that (1) makes V3 — thecontent-addressed rail record — the spine, demoting SurrealQL/ClickHouse/PG/
TTL DDL to peer adapters (closing the open question in
SURREAL-AST-AS-ADAPTER.md+SURREAL-AST-TRAP-PREFLIGHT.md); (2) specifiesthe dual-mode facet (
12 B = 6×16 cascade | 4×24 triplet, classid-tagged)and the 512-byte record as 32 tenants with
ClassView::tenant_schemanaming the
Do/Think/Adapterplanes; (3) names the polyglot transpilersuperpower —
LangBackendadapters re-emit Rust/Python/C# source from theshared IR, generalizing the existing
ruff_cpp_codegen → Rustbackend.Includes the honest boundaries from the cross-repo verification: structure
transpiles, behaviour does not; the rail is a CAM key not the content;
minting governance must be CI-enforced before scale; the substrate is ~11 K
nodes today (not the aspirational 2 M); capacity overflow is the
separation-of-concerns lint (the
256-cap-is-a-lintlaw already exists as afalsifier and should be promoted to a real diagnostic).
Documentation only, authored via API without a build environment — it ships
the design contract for a typed follow-up, not unverified code. Companion
implementation plan lives in the
ruffRFC PR.Status
Proposed / RFC — seeking review on the spine-vs-adapter decision and the
dual-mode + tenant record contract before any code lands.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Mwq1QKpw4zRd6oaGRoJhF2
Generated by Claude Code