Round 33 — VISION.md v3: SQL frontend in v1, Reaqtor niche identified, 5 answers locked by AceHack · Pull Request #15 · Lucent-Financial-Group/Zeta

AceHack · 2026-04-19T02:02:31Z

Aaron's second pass of vision edits. SQL frontend + LINQ + EF + F# DSL now v1 scope. Bitemporal first-class v2. Reaqtor research surfaced 'Rx + durability + retraction-native' as a genuine open niche. Commercial trigger pinned. See VISION.md + BACKLOG.md additions.

🤖 Generated with Claude Code

…wers locked Aaron's second round of vision edits lands five big resolutions: 1. **Zeta name is locked** (was: rename possible?). 2. **SQL frontend is v1**, not post-v1. With: - Tight LINQ integration (`IQueryable<T>` roots). - Multiple SQL dialect targets (T-SQL, PostgreSQL, MySQL, SQLite, DuckDB) via shared query IR. - Entity Framework Core provider first, then other ORMs. - F# DSL reimagining SQL — extension of the existing `circuit { ... }` computational-expression seed. 3. **Commercial trigger**: when Aaron can use Zeta in a real project for its database. Concrete milestone replacing the prior "some future event" placeholder. 4. **Bitemporal + time-travel queries: first-class v2.** Aaron: "yes I want this haha." Framing distinction (first-class vs speculative) was noise. 5. **"C# stored procedures" = Reaqtor-shaped niche**. Research done this round (see commit body): Reaqtor is MIT, maintained by endjin, dormant-but-stable; ships IReactiveQbservable + durable query engine; Rx + durable but not retraction-native. "Rx + durability + retraction- native" is genuine open territory. Post-v1 research target — not a v1 commitment. ## VISION.md v3 changes - v1 subset now lists SQL frontend + LINQ + EF provider + F# DSL under "what makes Zeta.Core 1.0.0." - Multi-node moved from "open question" to "firmly in scope." - Post-v1 lists bitemporal (first-class v2), additional ORM providers, Reaqtor-inspired durable-Rx research. - Commercial posture section names the trigger event explicitly. - Resolved-this-round section replaces prior gap list. - New remaining gaps: SQL dialect ordering, license shape (Apache/MIT/LGPL/AGPL+commercial), EF provider surface breadth, F# DSL name. ## BACKLOG.md additions New P1 section "SQL frontend + query surface (round-33 vision, v1 scope)" with six entries: - Shared query IR - LINQ IQueryable integration - Multi-dialect SQL parser (T-SQL/PG/MySQL/SQLite/DuckDB) - EF Core provider - F# DSL reimagining SQL - Additional ORM providers (post-EF) New P2 section "Post-v1 query-surface research": - Reaqtor-inspired durable-Rx stored procedures design doc - Bitemporal + time-travel queries v2 design Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…e, columnar Aaron's third pass adds three corrections/expansions: 1. **.NET stored procedures, not just C#.** C# + F# both. "i should have said dotnet stored procedures c#/f# whoops lol." 2. **Zeta is BOTH event-sourcing and regular database.** A façade/abstraction hides the eventing/retraction machinery so Zeta can be used "like a normal non- eventing database as well." Aaron: "it should be both, i can replace my database and my event store with Zeta." 3. **Event streaming + regular DB + likely columnar.** Columnar storage alongside row-oriented Spine — OLAP/analytics/wide-row sparse-projection workloads. ## VISION.md v4 New "Both modes" subsection under Product 1: event-sourcing mode (native DBSP) + regular-database mode (façade hiding deltas/retractions) + columnar substrate likely in scope. Same operator algebra + query IR feeds both modes. Reaqtor-niche entry updated to ".NET stored procedures (C# + F# both)" from "C# stored procedures." Resolved-this-round list extended with the three new items. ## BACKLOG.md additions Two new P2 entries: - Regular-database façade design doc with design questions: separate NuGet or default surface? How does INSERT/UPDATE/ DELETE map to deltas without leaking retractions? Transaction model? - Columnar storage substrate design doc with references: DuckDB, Arrow, Parquet, ClickHouse, Feldera. Can retraction-native columnar expose Z-set deltas? How does planner pick row vs column per query? ## Known flake (unrelated) PR #15 ubuntu-22.04 failed on `Zeta.Tests.Properties.FuzzTests. fuzz: HLL estimate within theoretical error bound` — known probabilistic bound occasionally exceeded with unlucky seed. Flake logged for round 34 DEBT cleanup. Main should be green on next push. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…e, columnar, log-as-truth principle Aaron's third pass adds three corrections/expansions: 1. **.NET stored procedures, not just C#.** C# + F# both. "i should have said dotnet stored procedures c#/f# whoops lol." 2. **Zeta is BOTH event-sourcing and regular database.** A façade/abstraction hides the eventing/retraction machinery so Zeta can be used "like a normal non- eventing database as well." Aaron: "it should be both, i can replace my database and my event store with Zeta." 3. **Event streaming + regular DB + likely columnar.** Columnar storage alongside row-oriented Spine — OLAP/analytics/wide-row sparse-projection workloads. ## VISION.md v4 New "Both modes" subsection under Product 1: event-sourcing mode (native DBSP) + regular-database mode (façade hiding deltas/retractions) + columnar substrate likely in scope. Same operator algebra + query IR feeds both modes. Reaqtor-niche entry updated to ".NET stored procedures (C# + F# both)" from "C# stored procedures." Resolved-this-round list extended with the three new items. ## BACKLOG.md additions Two new P2 entries: - Regular-database façade design doc with design questions: separate NuGet or default surface? How does INSERT/UPDATE/ DELETE map to deltas without leaking retractions? Transaction model? - Columnar storage substrate design doc with references: DuckDB, Arrow, Parquet, ClickHouse, Feldera. Can retraction-native columnar expose Z-set deltas? How does planner pick row vs column per query? ## Known flake (unrelated) PR #15 ubuntu-22.04 failed on `Zeta.Tests.Properties.FuzzTests. fuzz: HLL estimate within theoretical error bound` — known probabilistic bound occasionally exceeded with unlucky seed. Flake logged for round 34 DEBT cleanup. Main should be green on next push. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…C byte encoding Two new Codex P1 findings on the BLAKE3 receipt-hashing v0 doc: P1 (line 226) — replay determinism vs current signer set: The req #4 said "compare commitment vs CURRENT signer-view", which makes receipt validity time-dependent — the moment the live signer set rotates, every prior receipt becomes invalid. Replay-determinism breaks. Fix: validate against the signer set authoritative at the receipt's claimed `policy_version` (recoverable from `policy_version` + dispute-process commitment-opening). Receipt-creation-time race-checking is moved to the receipt-creation step; the replay gate catches *forged* commitments only. P1 (line 157) — canonical text-to-byte mapping: The `len:u32-be ∥ bytes` framing for variable-length identifiers (`budget_id`, `policy_version`, `node_id`) specified the framing but not how to derive `bytes` from the identifier string. Added explicit binding: `bytes = NFC-normalised UTF-8 octets` — Unicode Normalization Form C per Unicode Annex #15, then UTF-8 encoded. NFC fixes visually-identical-but-byte-different forms (e.g., precomposed vs decomposed accents); UTF-8 is the canonical text→byte map. EOF

…th-ferry candidate #3) (#268) * research: BLAKE3 receipt-hashing v0 design input to lucent-ksk ADR (7th-ferry candidate #3) Responds to Amara's 7th-ferry BLAKE3 proposal (PR #259) + Aminata's Otto-90 critiques (PR #263) flagging it belongs in lucent-ksk rather than Zeta + naming side-channel-leakage and cryptographic-agility gaps + Otto-91 addition of parameter_file_sha binding for replay determinism. v0 hash input set (8 fields, changes marked): h_r = BLAKE3( hash_version // NEW — crypto-agility ∥ h_inputs ∥ h_actions ∥ h_outputs ∥ budget_id ∥ policy_version ∥ parameter_file_sha // NEW — Otto-91 ∥ approval_set_commitment // CHANGED — side-channel ∥ node_id ) Signature structure adds *_key_version to each signature tuple for per-key-rotation without breaking historical receipts. Addresses Aminata's 3 findings: - Side-channel leakage: raw approval_set → Merkle/sorted-hash commitment; read-only observers see a hash, dispute process opens it. - Cryptographic-agility: hash_version prefix + *_key_version binding; algorithm downgrade blocked because version is inside the hash. - Approval-withdrawal race (top-3 #2): commitment mismatch at replay-time invalidates the receipt. 4 replay-deterministic harness requirements for Zeta-module consumer side: 1. Same fields = same materialised views byte-for-byte. 2. Unknown hash_version = halt-and-report. 3. Unresolvable parameter_file_sha = halt-and-report. 4. Mismatched approval_set_commitment = reject receipt. Explicit NOT-scope: - Doesn't decide signature algorithm (Ed25519 is v0 assumption, scheme accommodates later). - Doesn't define hash_version / parameter_file registries (lucent-ksk governance artifacts). - Doesn't define commitment scheme specifics (Merkle vs sorted-hash-list; affects dispute only). - Doesn't implement rotation runbook. - Doesn't include Bitcoin anchoring (separate trust-model). 7 dependencies to adoption in priority order; Aminata 2nd pass first; cross-repo lucent-ksk ADR second; Max-specific asks framed per Otto-90 specific-ask-channel calibration. This is Zeta-SIDE design input. Canonical ADR belongs in lucent-ksk per Aminata Otto-90 framing. No adoption until cross-repo ADR lands. Max attribution preserved first-name-only. Cross-repo work on lucent-ksk does not touch Max's substrate directly until actual coordination warrants — specific-ask channel is the right escalation. Archive-header format self-applied — 10th aurora/research doc in a row. Lands within-standing-authority per Otto-82/90 calibration. Closes 7th-ferry absorb candidate #3 of 5. Remaining: - #1 KSK-as-Zeta-module implementation (L) Otto-92 tick primary deliverable. * drain(#268 P2+P2+style+P1 Codex/Copilot): field count + version notation + canonical encoding Four threads on the BLAKE3 receipt-hashing v0 design doc, all on the same file. P2 (lines 120 + 126): "8 fields" header / count text vs the formula's 9 actual binding inputs (`hash_version` + 8 content hashes). Reconciled to "9 fields" — the formula was the source of truth, the count text was the lag. Style (line 236): version notation inconsistency — `0x01` in some places, `v0x02` / `v0x01` in others. Standardized on the byte-literal hex notation `0x01` / `0x02` everywhere; the "v" prefix doubled up with `hash_version =` already in the formula and added no information. P1 (line 132): hash binding used raw `∥` concatenation of variable-length fields, opening a length-extension / boundary-shift adversary surface. Added an explicit `encode(·)` wrapper per field with a canonical-encoding section: 1-byte version, 32-byte fixed-width digests for content/policy/commitment hashes, and `len:u32-be ∥ bytes` length-prefix framing for variable-length identifiers (budget_id, policy_version, node_id). Forward-compatibility preserved — future schemes (`hash_version >= 0x02`) can pick different framing (CBOR / Protobuf / RFC 8949 §3.1 TLV) and the version prefix tells verifiers which framing applies. All 4 Codex/Copilot threads (PRRT_kwDOSF9kNM59SMrz, PRRT_kwDOSF9kNM59SNsm, PRRT_kwDOSF9kNM59SNsy, PRRT_kwDOSF9kNM59SNs2) addressed in this commit. * drain(#268 lint): MD032 — line-leading + interpreted as list bullet (wrap fix) * drain(#268 P1+P1 Codex): replay-determinism on signer view + UTF-8/NFC byte encoding Two new Codex P1 findings on the BLAKE3 receipt-hashing v0 doc: P1 (line 226) — replay determinism vs current signer set: The req #4 said "compare commitment vs CURRENT signer-view", which makes receipt validity time-dependent — the moment the live signer set rotates, every prior receipt becomes invalid. Replay-determinism breaks. Fix: validate against the signer set authoritative at the receipt's claimed `policy_version` (recoverable from `policy_version` + dispute-process commitment-opening). Receipt-creation-time race-checking is moved to the receipt-creation step; the replay gate catches *forged* commitments only. P1 (line 157) — canonical text-to-byte mapping: The `len:u32-be ∥ bytes` framing for variable-length identifiers (`budget_id`, `policy_version`, `node_id`) specified the framing but not how to derive `bytes` from the identifier string. Added explicit binding: `bytes = NFC-normalised UTF-8 octets` — Unicode Normalization Form C per Unicode Annex #15, then UTF-8 encoded. NFC fixes visually-identical-but-byte-different forms (e.g., precomposed vs decomposed accents); UTF-8 is the canonical text→byte map. EOF * drain(#268 P1+P2 Codex): correct adversary terminology + decouple CBOR/TLV citations P1 (line 144) — terminology correction: "length-extension / boundary-shift adversary surface" incorrectly conflated two distinct attacks. BLAKE3 is built on a tree-hash construction with finalisation flags — it is NOT vulnerable to length-extension the way SHA-256 and MD5 are. The actual risk in raw concatenation is boundary-shift / collision-by-reframing only. Updated the wording to name that risk explicitly and added a parenthetical noting that length-extension is NOT a concern with BLAKE3. P2 (line 162) — CBOR vs TLV reference correction: 'domain-separated TLV per RFC 8949 §3.1' conflated two distinct concepts: RFC 8949 is CBOR (tagged data items), and 'domain-separated TLV' is a separate framing concept. Split into two parallel options: 'CBOR per RFC 8949' (one option) and 'a domain-separated TLV scheme' (another, no specific RFC attached because TLV is generic). Future ADR can pick either or define a custom TLV; the v0 doc no longer mis-cites. * drain(#268 P1×3 Codex): version-policy gate + retired-key restriction + signed key-version Three substantive Codex P1 findings on the v0 receipt-hashing design: P1 (line 229) — version policy gate beyond unknown: Req #2 only fail-closed on unknown hash_version. Updated to also reject DEPRECATED versions per a policy registry (lucent-ksk governance artifact). Prevents forgery under an old-but-still-mechanically-recognised version that was retired due to weakness. Historical receipts remain verifiable for audit; new receipts under deprecated versions are refused. P1 (line 211) — retired key versions: Rotation introduced agent_key_version/node_key_version but didn't restrict NEW receipts from using retired key versions. Added: separate registry of retired key versions blocks creation of new receipts under retired versions; historical receipts under retired versions remain verifiable (replay-determinism preserved) but the signing path refuses to produce more. P1 (line 203) — signed key-version (authenticated metadata): The notation `Sign_{sk, *_key_version}(h_r)` was ambiguous about whether *_key_version was authenticated. If it's unsigned metadata, an attacker can swap the declared version to one that points at a public key for a different signature algorithm. Fix: bind the version INSIDE the signed message (`Sign_{sk}(version ∥ h_r)`) and verify by recomputing the signing input from the declared version. Verification block added showing the explicit lookup + recompute pattern. Also reframed line 120 to make the field-count reasoning explicit (Amara's 7 base + hash_version + parameter_file_sha = 9 v0 fields) so the count claim isn't load-bearing on the preceding paragraph alone. * drain(#268 P1+P1 Codex): u32-be encoding for key-version + issuance-epoch gate on deprecated hash_version Two more substantive Codex P1 findings: P1 (line 208) — canonical encoding for key-version: The signature scheme bound *_key_version into the signed message but didn't specify the byte encoding. Added explicit `encode_u32_be` wrapper + an Encoding section: 4-byte big-endian unsigned integer, monotonic from 1, with version 0 reserved for uninitialised. Fixed-width avoids needing a length prefix (every version is exactly 4 bytes). P1 (line 260) — issuance-epoch gate on deprecation: Unconditionally rejecting receipts with deprecated hash_version breaks audit/replay of historical receipts that were valid when issued. Updated to issuance-epoch gate: receipts issued BEFORE the version's deprecation cutoff remain valid for audit; receipts claiming an issuance epoch AFTER the cutoff under that version are rejected. Registry stores (version, deprecated_after_epoch) tuples; verifier compares claimed issuance epoch against deprecation epoch for that version.

#521) * tools(hygiene): lost-files common-locations catalog (Otto-329 Phase 8 substrate) 15 location-classes where lost files commonly accumulate, sorted roughly by yield-density. Each class has a survey command + triage protocol. Aaron's ask (Otto-329 Phase 8 + same-tick reminder): "you keep a list of lost file common locations i asked you to write it." I had started Phase 8 by jumping into the search activity without first creating the catalog. Aaron's catch: the list IS the substrate; the search is the activity. This file is the catalog. Searched for an existing version Aaron mentioned ("you created it and extended it and split into usefulness tiers") — could not locate it in repo, drop/, or .playwright-mcp/. May exist in Aaron's external notes (ChatGPT, Slack) or a previous session that got lost. If a prior version surfaces, this file can be merged with it (extend, don't replace). Location classes covered: 1. Closed-not-merged PRs (most fertile) 2. Orphan branches (remote) 3. Deleted files in git history 4. Reflog entries (local-only) 5. Stash entries 6. Untracked working-directory artifacts 7. Subagent worktree remnants 8. GitHub draft PRs (unpublished) 9. Closed PR discussion threads 10. Squash-merge intermediate commits 11. Force-pushed-over content 12. Courier-ferry artifacts (drop/) 13. External-tool exports never committed 14. Deleted-PR-description content 15. Memory-file deletions (cross-tree drift) Per Otto-293: "ask" not "directive" — bidirectional language. Composes with: Otto-329 Phase 8 (the larger lost-files-search ask), Otto-262 (trunk-based-development branch hygiene), Otto-257 (clean- default smell triggers audit), Otto-238 (retractability — deletions should leave visible trails), Otto-324 (mutual-learning — past mistakes compound into substrate), tools/hygiene/audit-memory- references.sh (already covers location-class #15), tools/hygiene/ audit-git-hotspots.sh (proxy for high-deletion-risk files). Owed follow-up: tools/hygiene/audit-lost-files.sh executable form covering all 15 survey commands. Per Otto-327: ordinary substrate / hygiene catalog, not ambitious empirical claim. Auto-merge default applies. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(B-0019): #521 review-thread catches — orphan-branch survey corrected, name attribution → role-ref Two valid catches resolved: 1. Orphan-branch survey command was wrong — comm-pipe just diffs name sets between GitHub branches and origin/* refs; doesn't actually check unmerged-status or no-PR-status. Replaced with: - Unmerged: `git for-each-ref --no-merged origin/main` - No-PR: comm vs gh pr list (corrected version) - True orphan = intersection of both 2. Name attribution "Aaron's ask" violates AGENT-BEST-PRACTICES "No name attribution in code, docs, or skills" since tools/hygiene/** is not an exempt history surface. Replaced with "Human maintainer ask"; full provenance lives in the matching memory/feedback_otto_329_*.md file (exempt history). Per Otto-313 decline-as-teaching: both catches were correct; applying fixes rather than declining is the right shape. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

AceHack force-pushed the round-33-vision-v3 branch from 8a2ebc1 to 8c6e8a1 Compare April 19, 2026 02:03

AceHack merged commit 13eaa15 into main Apr 19, 2026
5 of 6 checks passed

AceHack deleted the round-33-vision-v3 branch April 19, 2026 03:09

AceHack mentioned this pull request Apr 26, 2026

tools(hygiene): lost-files common-locations catalog (Otto-329 Phase 8) #521

Merged

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Round 33 — VISION.md v3: SQL frontend in v1, Reaqtor niche identified, 5 answers locked#15

Round 33 — VISION.md v3: SQL frontend in v1, Reaqtor niche identified, 5 answers locked#15
AceHack merged 1 commit intomainfrom
round-33-vision-v3

AceHack commented Apr 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

AceHack commented Apr 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant