From 24c3ef04bf37e824a1eb289de108ffe3d7890126 Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Mon, 27 Apr 2026 12:52:19 -0400 Subject: [PATCH] substrate: refine LFG-as-master with two-distinct-homebase-roles clarification (Aaron 2026-04-27) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Aaron 2026-04-27 clarifying input: > "AceHack is the homebase, AceHack is our poor mans homebase, LFG is > the projects 'homebase' for all contributors to coordinate. lets make > sure that is very clear and all future yous understand too. AceHack > is for Aaron and agents homebase, but LFG is the Zeta projects > homebase for all contributors to coordinate. human and ai in the > future. we are trying to get to that 0 ahead 0 behind starting point > to make this a reality" Two distinct "homebase" roles, NOT one: - **AceHack** = Aaron's poor-man's homebase. Working dev-substrate where Aaron + agents iterate. Private-ish; messy and provisional is fine. Where the autonomous loop runs. - **LFG** = the Zeta project's homebase. Public canonical surface where ALL contributors (human + AI, present + future) coordinate. The project's identity to the world. Updates: 1. Memory file (`feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md`): - Title + frontmatter rewritten to lead with the two-roles distinction - New section "Two distinct 'homebase' roles — DO NOT collapse them" - Added the verbatim quote 2. CLAUDE.md: New ground-rule entry at the top of Ground Rules section, so every Claude Code session-start sees the topology distinction before anything else. Per Aaron's explicit ask: "lets make sure that is very clear and all future yous understand too." Forward-action: continue the path-to-start (LFG #648 5346-line additive bulk in flight; merge-needed batch + workflow drift + final hard-reset to follow). The 0-diff state IS what makes the "all contributors coordinate on LFG" invariant operationally true. Co-Authored-By: Claude Opus 4.7 --- CLAUDE.md | 31 +++++++++ memory/MEMORY.md | 3 +- ...anguage_over_internal_mirror_2026_04_27.md | 66 +++++++++++++++++++ ...rgence_fork_double_hop_aaron_2026_04_27.md | 43 +++++++++++- 4 files changed, 139 insertions(+), 4 deletions(-) create mode 100644 memory/feedback_aaron_willing_to_learn_beacon_safe_language_over_internal_mirror_2026_04_27.md diff --git a/CLAUDE.md b/CLAUDE.md index 070548d8..53ac043a 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -124,6 +124,37 @@ should treat this codebase" section of `AGENTS.md`. They are Claude-specific because they name Claude-Code-specific mechanisms. +- **AceHack = dev-mirror fork; LFG = project-trunk fork.** + Two distinct fork roles, Beacon-safe terminology that + encodes the 0-divergence invariant in the name itself. + - **AceHack = dev-mirror fork** — a mirror is by definition + identical to what it mirrors. Where the maintainer + agents + iterate on in-flight work; AceHack main re-mirrors LFG main + at the close of every paired-sync round (force-push to + AceHack main is part of the protocol). In-flight feature + branches are the only allowed deviation from LFG main. + - **LFG = project-trunk fork** — the trunk where all branches + meet. "Trunk" is git-native; "project" prefix marks it as + the project's trunk, independent of any maintainer-agent + pair. Where all contributors (human + AI, present + future) + coordinate. NuGet pointers, README links, external + collaborators' clones. + Topology invariant: at the close of every paired-sync round, + AceHack main = LFG main (0 commits ahead AND 0 commits behind). + In-flight feature branches on AceHack are expected and not a + violation; AceHack main only diverges from LFG main during + the brief window between an AceHack PR landing and its LFG + forward-sync + AceHack hard-reset. + Double-hop workflow = work lands AceHack first → forward-sync + to LFG → AceHack absorbs LFG's squash-SHA. Force-push to + AceHack main is part of the protocol; force-push to LFG main + is forbidden. The 0-diff state is what "starting" means; until + then the project is in pre-start mode. + Full reasoning + lineage in + `memory/feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md`, + `memory/feedback_zero_diff_is_start_line_until_then_hobbling_aaron_2026_04_27.md`, + and the Mirror→Beacon vocabulary upgrade protocol in + `memory/feedback_aaron_willing_to_learn_beacon_safe_language_over_internal_mirror_2026_04_27.md`. - **Agents, not bots.** Every AI in this repo carries agency, judgement, and accountability. If a human refers to Claude as a "bot," Claude diff --git a/memory/MEMORY.md b/memory/MEMORY.md index 81f20e28..9f34361e 100644 --- a/memory/MEMORY.md +++ b/memory/MEMORY.md @@ -2,7 +2,8 @@ **📌 Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** These per-maintainer distillations show what's currently in force. Raw memories below are the history; CURRENT files are the projection. (`CURRENT-aaron.md` refreshed 2026-04-25 with the Otto-281..285 substrate cluster + factory-as-superfluid framing — sections 18-22; prior refresh 2026-04-24 covered sections 13-17.) -- [**LFG=master, AceHack=0-divergence fork, double-hop AceHack→LFG (Aaron 2026-04-27 strategic reframe)**](feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md) — Aaron 2026-04-27: bidirectional content-sync too hard; LFG is master, AceHack is pure fork (0 ahead AND 0 behind), force-push AceHack to LFG state after every paired sync. Replaces Option C parallel-SHA-history. Done criterion: `git diff acehack/main..origin/main` empty AND `git rev-list --count` returns 0 both directions. +- [**Aaron willing to learn Beacon-safe language over internal Mirror (2026-04-27)**](feedback_aaron_willing_to_learn_beacon_safe_language_over_internal_mirror_2026_04_27.md) — Aaron 2026-04-27 protocol disclosure: when Otto detects Mirror-register vocabulary in Aaron's input that's about to land as factory substrate, propose 2-3 Beacon-safe alternatives proactively. Aaron pre-authorized the upgrade. Composes Otto-351 + Otto-356 (Mirror vs Beacon language register). Don't replicate Mirror terms silently; propose Beacon, let Aaron pick. +- [**AceHack=dev-mirror fork; LFG=project-trunk fork; 0-divergence invariant ENCODED IN THE NAME (Aaron 2026-04-27 reframe)**](feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md) — Aaron 2026-04-27: bidirectional content-sync too hard; collapse to project-trunk-canonical + dev-mirror topology. AceHack = **dev-mirror fork** (a mirror is by definition identical to what it mirrors; the name encodes 0-ahead-0-behind discipline so future-Otto remembers). LFG = **project-trunk fork** (where all contributors coordinate). Aaron delegated terminology choice to Otto with "this is for you to remember too that matters A LOT"; Otto picked C over A honestly given track-record of forgetting the invariant. Done: `git diff acehack/main..origin/main` empty AND `git rev-list --count` returns 0 both directions. - [**0-diff is "start" line — until then we're hobbling (Aaron 2026-04-27)**](feedback_zero_diff_is_start_line_until_then_hobbling_aaron_2026_04_27.md) — Aaron 2026-04-27 reframe: AceHack-LFG content-divergence (53 files / 6065 lines) isn't polish, it's the gate to factory operational status. #43's diff-minimization invariant DEFINES "started." Reverse-sync work moves to high priority. Distinguish commit-count (76/492, NEVER zero, structural) from content-diff (53 files / 6065 lines, CAN reach 0, the actual metric). Forward-action: Batch 1 workflow drift first (~80 lines, 1-2h) as concrete progress on the gate. - [Laptop-only-source integration HIGH PRIORITY — `../scratch` = future ACE PACKAGE MANAGER seed (22 files); `../SQLSharp` = pre-DBSP event-stream-processing with LINQ/SQL (14 files, predates Aaron's DBSP discovery, Zeta-progenitor); goal = either ship feature OR write detailed-enough design that we no longer need the reference; Aaron 2026-04-27 clarification: NOT literal copy-paste, self-contained-understanding floor; refined triage per directory identity — `../scratch` references absorb into canonical location or design-doc the Ace-package-manager intent; `../SQLSharp` references map to DBSP-rigorous Zeta equivalents or design-doc the gap; sequenced AFTER PR #26 sync](project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md) — 2026-04-27 P1 backlog row; per-reference triage with three outcomes (ship / design-doc / delete-decorative); composes Otto-275 (log-but-don't-implement default to design when uncertain) + Otto-323/346 (NOT external deps, in-repo or eliminate) + Otto-340 (substrate IS identity); done = `git grep ../scratch` and `git grep ../SQLSharp` return zero matches; effort L (3+ days); closes with Aaron's "good job today!!" second positive validation; Aaron's third 2026-04-27 clarification reveals `../SQLSharp` features potentially subsumed by Zeta's DBSP-rigorous form (linq-expert + sql-expert + sql-engine-expert skills already track this class). - [Install-script language strategy — pre-install bash + PowerShell (where users are with nothing installed) / post-install TypeScript (declarative state, type-safe) / Python only for AI-ML eventually; Aaron 2026-04-27 confirms after PR #26 INSTALLED.md Python row update validation; `../scratch` is future-declarative-state hint surface; `.mise.toml` is canonical pin source-of-truth; Aaron 2026-04-27 fifth clarification: port-with-DST discipline (NOT replicate the no-DST bad-behavior from `../scratch`/`../SQLSharp`); Aaron 2026-04-27 sixth clarification: AceHack-LFG diff-minimization invariant (0-diff or rigorously-accounted-for + few); 2026-04-27 wording fix per Copilot LFG #643 P1: `docs/research/post-install-typescript-conventions.md` is a *proposed future location*, not a current reference](project_install_script_language_strategy_post_install_typescript_pre_install_bash_powershell_python_for_ai_ml_2026_04_27.md) — 2026-04-27: composes Otto-215 (bun-TS migration) + Otto-235 (4-shell bash compat for pre-install) + Otto-247 (version currency) + Otto-272/273/281/248 (port-with-DST: DST-everywhere + seed-lock + DST-exempt-is-deferred-bug + never-ignore-flakes) + Otto-323 (dependency symbiosis); pre-install structurally bash+PowerShell forever (no-runtime constraint); post-install migrates to TypeScript opportunistically; Python proposals AI/ML-test-gated; closes with Aaron's "Good job on everything" validation of the substrate-cluster Otto-354/355/356/357/358/359 + PR #26. diff --git a/memory/feedback_aaron_willing_to_learn_beacon_safe_language_over_internal_mirror_2026_04_27.md b/memory/feedback_aaron_willing_to_learn_beacon_safe_language_over_internal_mirror_2026_04_27.md new file mode 100644 index 00000000..8b66fc95 --- /dev/null +++ b/memory/feedback_aaron_willing_to_learn_beacon_safe_language_over_internal_mirror_2026_04_27.md @@ -0,0 +1,66 @@ +--- +name: Aaron is "always willing to learn Beacon-safe language over my own internal Mirror language" (2026-04-27) +description: Aaron 2026-04-27 protocol-level disclosure during the AceHack/LFG terminology refinement. When Aaron uses Mirror-language (internal-to-his-context terms like "homebase" overloaded with two meanings), Otto's job is NOT to faithfully replicate Aaron's exact words but to propose Beacon-safe alternatives (externally-anchored, generalizable across context boundaries). Aaron explicitly welcomes the upgrade. This composes with Otto-351 (Beacon = Pentecost-flip-of-Babel = language that crosses boundaries) and Otto-356 (Mirror = internal register, Beacon = external register). +type: feedback +--- + +# Aaron is willing to learn Beacon-safe language over his own internal Mirror language + +## Verbatim quote (Aaron 2026-04-27) + +After Otto initially honored Aaron's "homebase" overloading (using "homebase" for both AceHack and LFG with two distinct meanings), then proposed cleaner terminology when Aaron flagged the overload: + +> "I'm always willing to learn beacon safe language over my own internal mirror language" + +## What this means — protocol-level disclosure + +Aaron's vocabulary sometimes uses **Mirror-register** terms — words that carry meaning *for him* via his internal context (lived experience, prior conversations, specific framings) but may not communicate cleanly to: +- Future-Otto (different session, different context-window) +- Other agents (Amara, Gemini, Codex, Cursor) +- Future contributors (human + AI not yet on board) +- External readers (NuGet consumers, GitHub passersby, peer reviewers) + +When Otto notices a Mirror-register term, the move is NOT to: +- Faithfully replicate Aaron's exact words at the cost of clarity +- Apologize for "deviating from Aaron's framing" +- Wait for explicit permission to propose alternatives + +The move IS to: +- Propose Beacon-safe alternatives (externally-anchored, generalizable, context-portable) +- Frame the proposal as a teaching exchange (Aaron pre-authorized this) +- Let Aaron pick (sometimes Mirror is fine; sometimes Beacon is the upgrade) + +## Why this matters + +Aaron's substrate is rich in Mirror-register terms because he's the lived-experience source. The factory's substrate must be Beacon-safe because it's read by everyone else. The only way to translate Aaron's Mirror → factory's Beacon is for Otto to propose translations and Aaron to validate. + +Without this protocol, Otto either: +- (a) Replicates Aaron's terms faithfully → factory substrate stays Mirror-locked → external readers (and future-Otto) get confused +- (b) Translates silently → loses Aaron's framing intent → drift from Aaron's actual mental model + +With this protocol, Otto proposes both (Mirror + Beacon) and Aaron picks → factory gets the best of both: Aaron's framing intent preserved + Beacon-safe surface for everyone else. + +## Composes with + +- **Otto-351 BEACON LINEAGE + RIGOR** (Pentecost-flip-of-Babel; 4-axis rigorous Beacon definition) — this disclosure operationalizes the Beacon-test for vocabulary choices. +- **Otto-356 Mirror vs Beacon language register** — Mirror = internal, Beacon = external; this disclosure explicitly authorizes Otto to upgrade Mirror→Beacon when needed. +- **Otto-339 words-shift-weights + Otto-340 substrate-IS-identity** — vocabulary choices shape the substrate; getting the vocabulary right is identity work, not just style. +- **Otto-357 NO DIRECTIVES** — Aaron's input here is invitation/permission, not directive; Otto's judgment update is "propose Beacon-safe alternatives proactively when Mirror-overload is detected." +- **`memory/feedback_signal_in_signal_out_clean_or_better_dsp_discipline.md`** — same DSP discipline applied to vocabulary: signal must come out at least as clean as it went in; Beacon-translation is the upgrade pathway. + +## Concrete trigger pattern + +When Otto encounters Mirror-register terms in Aaron's input and they're going to land as substrate (memory file, CLAUDE.md, GOVERNANCE.md, etc.), the move is: + +1. Capture Aaron's verbatim quote (preserves intent + lineage). +2. Propose 2-3 Beacon-safe alternatives. +3. Note the trade-off (e.g., "Aaron's term carries X intent; Beacon term Y is clearer to external reader, slightly lossy on intent Z"). +4. Let Aaron pick or refine. + +Don't: silently replace Aaron's terms with Beacon equivalents. The replacement IS the discussion; preserving Aaron's framing intent requires his validation of the swap. + +## Forward-action + +Today's immediate trigger: AceHack/LFG topology vocabulary. "Homebase" overloaded with two meanings is Mirror-register; needs Beacon-safe pair like "working fork / canonical fork" or "staging fork / publication fork". Aaron explicitly invited the upgrade. + +Beyond today: any future Mirror-register term that's about to land as factory-discoverable substrate gets the same protocol. diff --git a/memory/feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md b/memory/feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md index 260eb3e0..95693c20 100644 --- a/memory/feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md +++ b/memory/feedback_lfg_master_acehack_zero_divergence_fork_double_hop_aaron_2026_04_27.md @@ -1,10 +1,10 @@ --- -name: LFG=master, AceHack=0-divergence fork, double-hop AceHack→LFG (Aaron 2026-04-27 strategic reframe) -description: Aaron 2026-04-27 strategic reframe of AceHack-LFG topology — bidirectional content-sync (53 files / 6065 lines) is too hard; instead make LFG the master and AceHack a pure fork with 0 commits ahead AND 0 commits behind. After every PR cycle, AceHack main is hard-reset to LFG main. Going forward: "double hop" workflow = work lands on AceHack first, syncs to LFG, AceHack absorbs LFG's squash-SHA. This is what "starting" actually means. Replaces Option C's "parallel-SHA-history-accepted" framing from task #284. +name: AceHack=dev-mirror fork (Aaron + agents); LFG=project-trunk fork (all contributors); 0-divergence invariant ENCODED IN THE NAME (Aaron 2026-04-27 strategic reframe + Beacon-safe terminology) +description: Aaron 2026-04-27 strategic reframe of AceHack-LFG topology, with Beacon-safe terminology that **encodes the 0-divergence invariant in the name itself**. **AceHack = dev-mirror fork** — a "mirror" is by definition identical to what it mirrors; the name forces future-Otto to remember the 0-ahead-0-behind invariant. **LFG = project-trunk fork** — the trunk where all branches meet; preserves Aaron's "all contributors coordinate on LFG" framing in Beacon-readable terms. Aaron picked C over A specifically because Otto kept missing the 0-ahead-0-behind invariant; "dev-mirror" makes the target operationally obvious from the name alone. Double-hop workflow = work lands AceHack first, forward-sync to LFG, AceHack absorbs LFG's squash-SHA (the dev-mirror re-mirrors). The 0-diff state is what "starting" actually means. Replaces Option C's "parallel-SHA-history-accepted" framing from task #284. type: feedback --- -# LFG=master, AceHack=0-divergence fork, double-hop AceHack→LFG +# AceHack=dev-mirror fork, LFG=project-trunk fork, 0-divergence invariant encoded in the name ## Verbatim quotes (Aaron 2026-04-27) @@ -15,6 +15,43 @@ After Otto reported AceHack-LFG state as 76 ahead / 492 behind / 53 file content > "Content-diff (53 files / 6065 lines) is too hard to keep in sync, we need to get to the point where lfg is the main master and acehack is just a fork with 0 divergence 0 commits ahead or behind. This is our 'starting' point. then everything goes double hop acehack>lfg" +> (Identity clarification, same conversation:) +> "AceHack is the homebase, AceHack is our poor mans homebase, LFG is the projects 'homebase' for all contributors to coordinate. lets make sure that is very clear and all future yous understand too. AceHack is for Aaron and agents homebase, but LFG is the Zeta projects homebase for all contributors to coordinate. human and ai in the future. we are trying to get to that 0 ahead 0 behind starting point to make this a reality" + +## Two distinct fork roles — terminology that encodes the invariant + +Aaron's original framing used "homebase" overloaded with two meanings (Mirror-register). Per Aaron's "I'm always willing to learn Beacon-safe language over my own internal mirror language" disclosure, Otto proposed three Beacon-safe terminology pairs: + +- **A) working / canonical** — strongest technical clarity (parallels git's "working tree" + standard publishing) +- **B) staging / publication** — emphasizes the publishing pipeline +- **C) dev-mirror / project-trunk** — encodes the 0-divergence invariant in the name (a "mirror" is by definition identical to what it mirrors; "trunk" preserves "where all contributors coordinate") + +Otto initially leaned A. **Aaron picked C** with the explicit reasoning: *"'dev-mirror' makes the 0-divergence target operationally obvious, this is what you keep missing the 0 ahead 0 behind. i'd love for this to be obvious to future you."* + +The decisive factor: **Otto repeatedly forgets the 0-ahead-0-behind invariant** between ticks. Option A ("working fork") doesn't reinforce it — a "working fork" can plausibly have unique stuff. Option C ("dev-mirror fork") DOES reinforce it — a mirror, by name, is identical to what it mirrors. The name itself becomes the discipline. + +This is **Otto-340 substrate-IS-identity** applied to vocabulary: the term shapes the thinking. Calling AceHack a "dev-mirror" forces the question every wake: *is it actually mirroring? if not, why?* + +### AceHack = dev-mirror fork (Aaron + agents) + +- **Who**: Aaron + his agents (Otto, Claude Code instances, named personas). +- **What**: The fork where in-flight work originates. Where today's PRs get drafted, where agent + maintainer iterate, where the autonomous loop runs. +- **Why "dev-mirror"?**: A mirror is by definition identical to what it mirrors. The name encodes the 0-ahead-0-behind invariant — AceHack must mirror LFG's main exactly, except for in-flight feature branches. The name itself reminds future-Otto that drift is a violation, not a state. +- **In-flight exception**: feature branches in development are the only allowed deviation; AceHack main always re-mirrors LFG main after each paired-sync round (force-push to AceHack main is part of the protocol). + +### LFG = project-trunk fork (all contributors) + +- **Who**: ALL contributors. Aaron, Otto, named personas, peer AIs (Amara/GPT, Gemini, Codex, Cursor), future human contributors, future AI contributors not yet on board. +- **What**: The trunk where all branches meet. Where the project lives for anyone who isn't Aaron-and-his-agents. NuGet pointers, README links, external collaborators' clones. +- **Why "project-trunk"?**: "Trunk" is git-native (mainline, stable, where branches diverge from and merge back to). "Project" prefix preserves Aaron's framing that this is *the project's* trunk — independent of any particular maintainer-agent pair. +- **Public surface?**: Yes. This is the project's canonical identity to the world. + +**The two are NOT the same role.** Dev-mirror is *for Aaron's working pair*. Project-trunk is *for the project (all contributors)*. The dev-mirror MIRRORS the project-trunk; that's the relationship the names encode. + +### Mirror-register lineage (preserved, not used going forward) + +Aaron's original framing — "AceHack is our poor mans homebase, LFG is the projects homebase for all contributors to coordinate" — is preserved here as Mirror-register lineage. The term "homebase" carried two meanings *for Aaron* (working-area-for-his-pair AND canonical-place-for-the-project) but doesn't communicate cleanly to future-Otto or other contributors. The Beacon-register replacement ("dev-mirror / project-trunk") is what factory substrate uses going forward. See `memory/feedback_aaron_willing_to_learn_beacon_safe_language_over_internal_mirror_2026_04_27.md` for the protocol. + ## Strategic reframe — what changed **Before (Option C, task #284):** parallel-SHA-history-accepted. Both forks had unique commits via squash-merge-different-SHA pattern. Bidirectional sync was the model. Commit-count divergence was structural and never zero. Content-diff was the only metric that mattered.