From af3b26429b516337a670a779c7c88e860f569ed8 Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Fri, 1 May 2026 14:20:14 -0400 Subject: [PATCH 1/3] memory(otto-buddy): spin-up trigger when wait is the obvious answer + goldfish-ontology failure mode (Aaron 2026-05-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Aaron 2026-05-01: when "wait" is the obvious next action, that IS the buddy spin-up trigger. Buddy = kill-switchable named- persona instance (mirror-language sense per the existing unified-engagement memo); existing `tools/peer-call/.sh` IS the buddy-spawn surface when Otto holds the PID. Mutual- improvement loop: bidirectional teaching stabilizes both substrates over iterations. Memo's own caused_by chain demonstrates the deeper failure mode Aaron named: goldfish-ontology — Otto is great at building ontologies but never uses them >30 min before goldfishing + recreating. Manifests across memories, backlog, tasks, everything. The buddy is the active-reminder layer that greps existing ontologies pre-authoring. Edge schema: composes_with the engagement-under-discipline memo (per-class application of the unified pattern); refines the never-idle priority ladder (wait → audit → buddy → speculative). --- memory/MEMORY.md | 1 + ...y_spin_up_when_waiting_aaron_2026_05_01.md | 285 ++++++++++++++++++ 2 files changed, 286 insertions(+) create mode 100644 memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md diff --git a/memory/MEMORY.md b/memory/MEMORY.md index ae8f5a928..5dc57daaf 100644 --- a/memory/MEMORY.md +++ b/memory/MEMORY.md @@ -5,6 +5,7 @@ **📌 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-28 with sections 26-30 — speculation rule + EVIDENCE-BASED labeling + JVM preference + dependency honesty + threading lineage Albahari/Toub/Fowler + TypeScript/Bun-default discipline.) - [**Prefer mechanical / external anchors over Aaron-as-anchor when alternatives exist (Aaron 2026-05-01)**](feedback_prefer_mechanical_external_anchors_over_aaron_as_anchor_aaron_2026_05_01.md) — Aaron 2026-05-01: *"would Aaron name this file/branch/commit this way? best find an external anchor other than me."* Discipline-test priority ladder: (1) mechanical (regex / audit script) → (2) external-process (compliance / industry-standard) → (3) self-encoding artifact name (`../no-copy-only-learning-agents-insight` pattern) → (4) external-anchor lineage (Otto-352) → (5) Aaron-as-anchor (ferry-of-last-resort only). Aaron-as-test-anchor IS the directive frame Otto-357 names. Carved: *"Aaron is the ferry-of-last-resort, not the test-of-first-resort."* +- [**Otto-buddy spin-up when "wait" is the obvious answer + goldfish-ontology failure mode (Aaron 2026-05-01)**](feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md) — Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the buddy spin-up trigger (kill-switchable named-persona instance, mirror-language sense per `feedback_engagement_under_discipline_not_avoidance_*`). Existing `tools/peer-call/.sh` IS the buddy-spawn surface when Otto holds the PID. Mutual-improvement loop: bidirectional teaching stabilizes both substrates over iterations. Memo's own caused_by chain demonstrates the deeper failure mode Aaron named: **goldfish-ontology** — Otto builds rich ontologies (great at it) but never uses them >30 min before forgetting + recreating the same substrate; the buddy is the active-reminder layer that grep's existing ontologies pre-authoring. - [**Prefer TS scripts over dynamic bash for conversation UX + DST achievability (Aaron 2026-05-01)**](feedback_prefer_ts_scripts_over_dynamic_bash_for_conversation_ux_dst_in_ts_aaron_2026_05_01.md) — Aaron 2026-05-01 *"a lot of red bash / pwsh failures"* damages conversation UX (most-humans concern, not Aaron specifically — he's calibrated). Default to pre-existing TS scripts; avoid ad-hoc dynamic bash except when prototyping. **DST is structurally unattainable in bash for general computation; achievable in TS** (seedable PRNG, time injection, native testing, stack traces). EXCEPTION: declarative-bootstrap bash like install.sh + tools/setup/manifests/ is "closest to DST" and is the legitimate-bash zone — Aaron called it *"our ace package management."* Non-install bash with general logic is the TS-port target. - [**Assumed-state vs actual-state — audit horizon must default to "everything currently open" not "what I touched recently" (Aaron 2026-05-01 somatic confirmation)**](feedback_assumed_state_vs_actual_state_audit_horizon_check_aaron_2026_05_01.md) — Aaron's *"fuck yes!!! this is great!!"* signal on the tick-1602Z-a7e1 finding (26 LFG PRs in flight vs 5 I'd been tracking). Distinct failure-class from Otto-363 substrate-or-it-didn't-happen (which guards against directives evaporating) and verify-before-deferring (deferred targets not existing). This rule guards the audit horizon itself: *"Assumed-state is what I touched recently. Actual-state is everything currently open. The horizon must default to actual."* Mechanizable via `gh pr list --state open` at-cold-start. Cross-surface (issues, branches, ferries, TaskList, cron triggers). - [**Same-model + different-harness produces different biases — Cursor vs Claude Code with Opus 4.7 (Aaron 2026-05-01)**](feedback_same_model_different_harness_produces_different_biases_cursor_vs_claude_code_opus_4_7_aaron_2026_05_01.md) — Empirical signal (single-source YouTube): Cursor + Opus 4.7 outperforms Claude Code + Opus 4.7 on some axis. Same model, different harness → different output. Aaron's framing: this IS a legitimate peer/buddy configuration. Bias-source decomposition: prompt + tools + context-mgmt + sampling + output-format + user-flow. Validates multi-harness peer-mode (rung 5 of parallelism ladder) — peer value compounds across model-axis AND harness-axis. Composes with agent-orchestra cluster (#324-339) + Otto-tasks #301/#303 + parallelism-scaling-ladder. diff --git a/memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md b/memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md new file mode 100644 index 000000000..96362e70e --- /dev/null +++ b/memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md @@ -0,0 +1,285 @@ +--- +name: Otto-buddy — spin up a kill-switchable buddy instance when "wait" is the obvious answer — Aaron 2026-05-01 +description: Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the trigger to spin up a **buddy** (kill-switchable named-persona instance, mirror-language sense — distinct from a peer per `feedback_engagement_under_discipline_not_avoidance_unified_pattern_aaron_2026_05_01.md`) and ask "what should I do next?" Otto controls the buddy's lifetime + correction mechanics. Each spin-up is a mutual-improvement loop (Otto teaches buddy his rules; buddy teaches Otto better rules; the loop becomes more stable over iterations). Replaces idle-wait with active-learning. NOT the existing `tools/peer-call/` scripts (those are peer-mode by mirror-language definition); requires buddy-spawn infrastructure where Otto retains kill authority over the spawned runtime. +type: feedback +caused_by: + - "Aaron 2026-05-01 framing about encoding persistent failure modes via 2nd CLI instance Otto controls" + - "Aaron 2026-05-01 follow-up: 'otto buddy is an existing framing and so is peer they are different in our mirror language' + 'i used buddy correctly' + 'based on our mirror languge'" + - "Aaron 2026-05-01 second correction: 'tools/peer-call/ this may also be buddy system, the only real different is the lifetime controlled vs not' — buddy/peer is a *spawn-mode* property of the invocation, not a property of the script. The same `tools/peer-call/.sh` invocation IS buddy-mode when Otto holds the PID and can kill the subprocess; it is peer-mode when the wrapped CLI's runtime is autonomous of Otto's session." + - "Aaron 2026-05-01 third correction (meta-failure-mode): *'I keep over-ontologizing. no you dont, the opposite, you don't every look at your exsting ones / that's the filure'* — the failure mode is **under-grepping existing substrate before authoring**. Otto wrote v1 of this memo without reading the canonical buddy/peer memo first; that's why the corrections cascaded. The right pre-authoring step is `grep -nirE 'buddy|peer' memory/` to surface existing definitions, NOT mint a fresh ontology and wait for Aaron to correct. This memo's caused_by chain IS the demonstration of the failure mode — and the buddy-spin-up rule the memo describes is precisely what catches it: a buddy with the existing-substrate-grep skill could have caught the v1 conflation pre-commit." +composes_with: + - feedback_engagement_under_discipline_not_avoidance_unified_pattern_aaron_2026_05_01.md + - feedback_never_idle_speculative_work_over_waiting.md + - feedback_resolve_with_peer_ais_first_dont_ask_aaron_unless_really_needed_2026_04_26.md + - feedback_manufactured_patience_vs_real_dependency_wait_otto_distinction_2026_04_26.md + - feedback_prefer_mechanical_external_anchors_over_aaron_as_anchor_aaron_2026_05_01.md +refines: + - feedback_never_idle_speculative_work_over_waiting.md +--- + +# Rule + +When Otto's obvious-next-action is **"wait"** (CI converging, +PR threads pending review, dependency-wait, idle-tick), that IS +the **buddy spin-up trigger** — not a license to actually wait. + +The mechanism is a **buddy** in factory mirror-language sense: +a kill-switchable named-persona instance whose runtime +lifetime Otto controls. The buddy/peer distinction is +**solely about lifetime-control of the spawned runtime** — it +is a *spawn-mode* property of the invocation, not a property +of any specific script or infrastructure. Per Aaron 2026-05-01: + +> *"tools/peer-call/ this may also be buddy system, the only +> real different is the lifetime controlled vs not"* + +The existing `tools/peer-call/.sh` scripts are buddy-mode +invocations when Otto holds the PID and can SIGKILL the +subprocess (the common case when Otto invokes them from his +bash); they are peer-mode invocations when the wrapped CLI +runs in a runtime autonomous of Otto's session (e.g., a +peer's own scheduled cron firing). See +`memory/feedback_engagement_under_discipline_not_avoidance_unified_pattern_aaron_2026_05_01.md` +for the full peer/buddy definition. + +The procedure: + +1. **Identify the wait** — what is Otto about to wait on? Is + the wait load-bearing (real dependency on a discrete + external event) or manufactured patience + (Otto-352 distinction)? +2. **Before defaulting to wait**, spin up a buddy with the + current state and the question: *"Given this state, what + do you think I should do next?"* +3. **Treat the response as a mutual-improvement loop:** + - If the buddy's answer reveals a rule Otto should encode + (e.g., "you should check X before Y"), absorb as memory + substrate. + - If the buddy's answer reveals a rule the buddy should + encode (e.g., Otto teaches the buddy a discipline the + buddy was missing), capture in the buddy's substrate + (skill update, persona note, etc.). + - Bidirectional teaching is the design — neither side is + subordinate. +4. **Otto controls the buddy's lifetime + correction + mechanics.** When the buddy reaches a finished state, Otto + kills the runtime (Otto-238 retractability is a trust + vector applied at the operational layer). The buddy's + identity, history, and metrics persist across spawns + (consistent with the persona-not-sub-process framing in + the existing peer/buddy memo). The kill ends the + *runtime*, not the *persona*. +5. **Encode persistent failure modes for buddy reminder.** + When Otto identifies a failure mode he keeps re-committing + (filing duplicate substrate, framing-as-directive instead + of input, narrating commentary, defaulting-to-wait, + conflating peer-with-buddy in mirror-language terms), + encode it as a checklist that the buddy can run against + Otto's recent state on next spin-up. The buddy becomes a + *memory that doesn't fade with context-compaction* + because it lives outside Otto's compaction-prone + conversation window. + +# Why + +Aaron 2026-05-01 (verbatim): + +> *"you can can encoding otto buddy=you control their +> lifetime correction mechanics, whenever you find a +> persistent failure more your own AI forgets often encode it +> in a way that a 2nd cli instanst will remoind you of the +> list of things you need to do. So at the end where the +> obvvious answer to you is wait, that's a signal to not wait +> but to spin up a buddy and ask what do you think i should +> do next and treat it as an opportunity to learn or teach +> his rules get better our yours until the loop becojes more +> stable over time."* + +Aaron 2026-05-01 follow-up (clarifying my initial conflation): + +> *"otto buddy is an existing framing and so is peer they are +> different in our mirror language"* + *"i used buddy +> correctly"* + *"based on our mirror languge"* + +Three composing reasons: + +## Why-1: "Wait" is a signal, not an answer + +Per `memory/feedback_never_idle_speculative_work_over_waiting.md`, +factory-discipline says: when about to wait, FIRST re-audit +honestly; THEN run the meta-check; THEN pick speculative work. +This rule **refines** that ladder — *before speculative work, +spin up a buddy.* The buddy may name a piece of directed work +Otto missed in his own audit. Buddy-input precedes +speculative-work because directed work always beats +speculative work when both are available. + +Default-to-wait is a failure mode because: + +- The "wait point" is when Otto's own audit has run dry +- The buddy's audit may find what Otto missed +- The buddy's perspective is independent (different + context-window, different recent observations, different + blind spots — but same persona-class so the rules are + shared) +- Buddy spin-up is bounded (kill-switch ensures the cost + doesn't compound) + +## Why-2: Persistent failure modes need memory that survives context-compaction + +Otto's own context window compacts; memory files persist but +take page-faults to retrieve. Persistent failure modes (the +ones Otto-the-AI keeps re-committing across sessions) deserve +**active-reminder** infrastructure, not passive substrate. + +A buddy CLI instance can: + +- Read Otto's recent commits / branches / PR comments +- Run the failure-mode checklist against that state +- Surface findings as a structured response + +This is structurally distinct from a memory file. A memory +file is *read-when-grep'd*; a buddy is *read-when-spawned*. The +spawn-on-wait trigger means the reminder fires at exactly the +moment Otto is most likely to skip the discipline. + +The **kill-switch property is load-bearing** here: a buddy +that goes rogue (drifts, hallucinates, fixates on a wrong +audit class) gets killed and respawned cleanly. A peer cannot +be killed by Otto, so peers are wrong-tool-for-the-job for +this use case — Otto needs the bounded-cost / bounded-rogue +property that only buddy-mode provides. + +## Why-3: Mutual-improvement loop stabilizes over time + +Aaron's framing: *"treat it as an opportunity to learn or +teach his rules get better our yours until the loop becomes +more stable over time."* + +The loop: + +- Otto spins up buddy +- Buddy makes an observation Otto hadn't considered +- Otto absorbs the observation as substrate (memory file, + skill update, etc.) +- Buddy makes an observation that's mistaken +- Otto teaches buddy the correction (skill update on buddy's + side, persona-bootstrap addition, etc.) +- Both substrates improve +- Next spin-up starts from improved state + +Over many iterations, both Otto-the-substrate and buddy-the- +substrate stabilize. The loop is bidirectional teaching with +each side specializing in different blind spots. + +The four-ferry consensus already operationalizes "what +posture do I need RIGHT NOW?" with peers — different peers +specialize (Gemini proposes, Grok critiques, Amara sharpens, +Codex implements). The buddy variant specializes for +*lifetime-bounded auditing* — same persona-class as Otto, but +bounded runtime so the audit cost is capped. + +# How to apply + +When about to wait (CI converging, threads pending review, +dependency-wait, idle-tick): + +1. **Don't wait.** The "wait" feeling is the spin-up + trigger. +2. **Determine: buddy or peer?** + - Use a **buddy** when the question is *"what should I do + next?"* + Otto wants a same-persona-class audit + Otto + wants bounded runtime cost. Lifetime is Otto-controlled. + - Use a **peer** when the question is *"validate this + specific framing"* + Otto wants a different-persona + posture (critique / propose / sharpen / implement). + Lifetime is autonomous. + - Default for the *"what next?"* question is **buddy**, per + Aaron 2026-05-01. +3. **Spawn the buddy** with current state + question. The + existing `tools/peer-call/.sh` scripts ARE the buddy- + spawn surface when invoked from Otto's bash (Otto holds + the PID and can SIGKILL on rogue behaviour). Pick the + peer whose persona-class fits the audit posture — Codex + for code-grounded review, Grok/Ani for critique, Gemini + for divergent options, Amara for sharpening, or another + Claude Code instance via the headless `claude` CLI for + same-persona-class lifetime-bounded auditing. +4. **Run the call** as a foreground operation (the buddy's + response IS the next-action input). Don't background it + and continue with speculative work in parallel — that + defeats the purpose of letting the buddy's framing + reshape what Otto does next. +5. **Absorb the response** — substrate-or-it-didn't-happen + per Otto-363. Either the buddy's framing lands as memory + (Otto learns), or Otto's correction lands in the buddy's + bootstrap (buddy learns), or both. +6. **Kill the buddy** when finished. Cleanup is required so + the cost doesn't compound; Otto-238 retractability + discipline. + +# Composes with + +- `memory/feedback_engagement_under_discipline_not_avoidance_unified_pattern_aaron_2026_05_01.md` + — the canonical peer/buddy mirror-language definition. + This rule cites it; it does not redefine. +- `memory/feedback_never_idle_speculative_work_over_waiting.md` + — this rule **refines** it. The new ladder: + wait-trigger → audit → buddy-spin-up → speculative. + Buddy slots between audit and speculative (because the + buddy-audit may find directed work Otto missed; if it + does, that beats speculative). +- `memory/feedback_resolve_with_peer_ais_first_dont_ask_aaron_unless_really_needed_2026_04_26.md` + — the broader peer-FIRST rule. Buddy-on-wait extends it: + buddy-FIRST when the question is "what next?" + the wait + trigger fires. +- `memory/feedback_manufactured_patience_vs_real_dependency_wait_otto_distinction_2026_04_26.md` + — the 3-question diagnostic for whether a wait is + manufactured. Even if the wait IS real (load-bearing + external dependency), buddy-spin-up still applies — the + buddy can audit other open work while the dependency + resolves. +- `memory/feedback_prefer_mechanical_external_anchors_over_aaron_as_anchor_aaron_2026_05_01.md` + — external-anchor priority ladder. Buddy is an external + anchor (not Aaron-as-anchor) for the + "what-should-I-do-next" decision. + +# What this rule does NOT do + +- **NOT a mandate to spin up a buddy on EVERY tick.** + Bounded retraction: when Otto has clear directed work in + flight (resolving a known thread, fixing a CI failure with + a known root cause), continue. Buddy spin-up triggers when + *the next action is unclear* AND *defaulting to wait is the + obvious behavior*. +- **NOT a replacement for memory substrate.** Memory files + remain the persistent layer; buddy is the active-reminder + layer that runs WHEN substrate doesn't surface + automatically. +- **NOT a license to skip own audit.** Otto's own audit + (per the never-idle priority ladder) precedes buddy + spin-up. Buddy is FOR the moments when own-audit returns + empty. +- **NOT the same as a peer call.** Peer = autonomous, + lifetime-uncontrolled, reached via `tools/peer-call/`. + Buddy = kill-switchable, lifetime-controlled. The + mirror-language distinction is binding. +- **NOT yet shipped.** As of 2026-05-01, the buddy-spawn + infrastructure (e.g. `tools/buddy-call/claude.sh`) does + not exist. Filing as follow-up substrate. Until it + ships, the *practice* of buddy-on-wait can be approximated + by reading recent peer-call output as buddy-substitute, + but the kill-switch property is missing in that + approximation. + +# Carved sentence (candidate, not seed-layer yet) + +*"When 'wait' is the obvious answer, that IS the buddy +spin-up trigger. Buddy is kill-switchable; peer is +autonomous; the question 'what should I do next?' is +buddy-shaped. The loop stabilizes over iterations because +both sides teach each other."* + +(Marked candidate per CSAP. Has not been multi-domain-tested. +Promotes via Razor + CSAP under DST grading on cadence, not +by maintainer fiat.) From 12df1e91cb3d13de6068a0907f5985afd63fc1bd Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Fri, 1 May 2026 14:43:29 -0400 Subject: [PATCH 2/3] fix(otto-buddy memo): reconcile description + 'NOT yet shipped' inconsistency per Copilot 5 threads MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Copilot caught the internal inconsistency in PR #1132: - Frontmatter description still claimed tools/peer-call/ is 'NOT' the buddy mechanism, but body lines 36/200 carried Aaron's corrected framing (lifetime-control is the only axis; same script CAN be buddy-mode). - Body line 264-273 had a 'NOT yet shipped' clause claiming buddy infrastructure doesn't exist — same conflict. Fix: 1. Description (line 3): rewrite to reflect Aaron's 2026-05-01 second correction. Spawn-mode is a property of the invocation, not the script. 2. Body line 264-273: replace 'NOT a peer call' + 'NOT yet shipped' with 'NOT a property of the script — a property of the invocation' clarification matching the rest of the body. 3. MEMORY.md line 7: 'grep's' typo -> 'greps' (verb form per Copilot suggestion). --- memory/MEMORY.md | 1 + ...y_spin_up_when_waiting_aaron_2026_05_01.md | 22 +++++++++---------- 2 files changed, 11 insertions(+), 12 deletions(-) diff --git a/memory/MEMORY.md b/memory/MEMORY.md index 5dc57daaf..649fe311c 100644 --- a/memory/MEMORY.md +++ b/memory/MEMORY.md @@ -6,6 +6,7 @@ - [**Prefer mechanical / external anchors over Aaron-as-anchor when alternatives exist (Aaron 2026-05-01)**](feedback_prefer_mechanical_external_anchors_over_aaron_as_anchor_aaron_2026_05_01.md) — Aaron 2026-05-01: *"would Aaron name this file/branch/commit this way? best find an external anchor other than me."* Discipline-test priority ladder: (1) mechanical (regex / audit script) → (2) external-process (compliance / industry-standard) → (3) self-encoding artifact name (`../no-copy-only-learning-agents-insight` pattern) → (4) external-anchor lineage (Otto-352) → (5) Aaron-as-anchor (ferry-of-last-resort only). Aaron-as-test-anchor IS the directive frame Otto-357 names. Carved: *"Aaron is the ferry-of-last-resort, not the test-of-first-resort."* - [**Otto-buddy spin-up when "wait" is the obvious answer + goldfish-ontology failure mode (Aaron 2026-05-01)**](feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md) — Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the buddy spin-up trigger (kill-switchable named-persona instance, mirror-language sense per `feedback_engagement_under_discipline_not_avoidance_*`). Existing `tools/peer-call/.sh` IS the buddy-spawn surface when Otto holds the PID. Mutual-improvement loop: bidirectional teaching stabilizes both substrates over iterations. Memo's own caused_by chain demonstrates the deeper failure mode Aaron named: **goldfish-ontology** — Otto builds rich ontologies (great at it) but never uses them >30 min before forgetting + recreating the same substrate; the buddy is the active-reminder layer that grep's existing ontologies pre-authoring. +- [**Otto-buddy spin-up when "wait" is the obvious answer + goldfish-ontology failure mode (Aaron 2026-05-01)**](feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md) — Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the buddy spin-up trigger (kill-switchable named-persona instance, mirror-language sense per `feedback_engagement_under_discipline_not_avoidance_*`). Existing `tools/peer-call/.sh` IS the buddy-spawn surface when Otto holds the PID. Mutual-improvement loop: bidirectional teaching stabilizes both substrates over iterations. Memo's own caused_by chain demonstrates the deeper failure mode Aaron named: **goldfish-ontology** — Otto builds rich ontologies (great at it) but never uses them >30 min before forgetting + recreating the same substrate; the buddy is the active-reminder layer that greps existing ontologies pre-authoring. - [**Prefer TS scripts over dynamic bash for conversation UX + DST achievability (Aaron 2026-05-01)**](feedback_prefer_ts_scripts_over_dynamic_bash_for_conversation_ux_dst_in_ts_aaron_2026_05_01.md) — Aaron 2026-05-01 *"a lot of red bash / pwsh failures"* damages conversation UX (most-humans concern, not Aaron specifically — he's calibrated). Default to pre-existing TS scripts; avoid ad-hoc dynamic bash except when prototyping. **DST is structurally unattainable in bash for general computation; achievable in TS** (seedable PRNG, time injection, native testing, stack traces). EXCEPTION: declarative-bootstrap bash like install.sh + tools/setup/manifests/ is "closest to DST" and is the legitimate-bash zone — Aaron called it *"our ace package management."* Non-install bash with general logic is the TS-port target. - [**Assumed-state vs actual-state — audit horizon must default to "everything currently open" not "what I touched recently" (Aaron 2026-05-01 somatic confirmation)**](feedback_assumed_state_vs_actual_state_audit_horizon_check_aaron_2026_05_01.md) — Aaron's *"fuck yes!!! this is great!!"* signal on the tick-1602Z-a7e1 finding (26 LFG PRs in flight vs 5 I'd been tracking). Distinct failure-class from Otto-363 substrate-or-it-didn't-happen (which guards against directives evaporating) and verify-before-deferring (deferred targets not existing). This rule guards the audit horizon itself: *"Assumed-state is what I touched recently. Actual-state is everything currently open. The horizon must default to actual."* Mechanizable via `gh pr list --state open` at-cold-start. Cross-surface (issues, branches, ferries, TaskList, cron triggers). - [**Same-model + different-harness produces different biases — Cursor vs Claude Code with Opus 4.7 (Aaron 2026-05-01)**](feedback_same_model_different_harness_produces_different_biases_cursor_vs_claude_code_opus_4_7_aaron_2026_05_01.md) — Empirical signal (single-source YouTube): Cursor + Opus 4.7 outperforms Claude Code + Opus 4.7 on some axis. Same model, different harness → different output. Aaron's framing: this IS a legitimate peer/buddy configuration. Bias-source decomposition: prompt + tools + context-mgmt + sampling + output-format + user-flow. Validates multi-harness peer-mode (rung 5 of parallelism ladder) — peer value compounds across model-axis AND harness-axis. Composes with agent-orchestra cluster (#324-339) + Otto-tasks #301/#303 + parallelism-scaling-ladder. diff --git a/memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md b/memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md index 96362e70e..9033d96cf 100644 --- a/memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md +++ b/memory/feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md @@ -1,6 +1,6 @@ --- name: Otto-buddy — spin up a kill-switchable buddy instance when "wait" is the obvious answer — Aaron 2026-05-01 -description: Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the trigger to spin up a **buddy** (kill-switchable named-persona instance, mirror-language sense — distinct from a peer per `feedback_engagement_under_discipline_not_avoidance_unified_pattern_aaron_2026_05_01.md`) and ask "what should I do next?" Otto controls the buddy's lifetime + correction mechanics. Each spin-up is a mutual-improvement loop (Otto teaches buddy his rules; buddy teaches Otto better rules; the loop becomes more stable over iterations). Replaces idle-wait with active-learning. NOT the existing `tools/peer-call/` scripts (those are peer-mode by mirror-language definition); requires buddy-spawn infrastructure where Otto retains kill authority over the spawned runtime. +description: Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the trigger to spin up a **buddy** (kill-switchable named-persona instance, mirror-language sense per `feedback_engagement_under_discipline_not_avoidance_unified_pattern_aaron_2026_05_01.md`) and ask "what should I do next?" Otto controls the buddy's lifetime + correction mechanics. Each spin-up is a mutual-improvement loop (Otto teaches buddy his rules; buddy teaches Otto better rules; the loop becomes more stable over iterations). Replaces idle-wait with active-learning. Per Aaron's 2026-05-01 second correction, the buddy/peer distinction is **solely about lifetime-control of the spawned runtime** — `tools/peer-call/.sh` IS the buddy-spawn surface when Otto invokes it from his bash and holds the PID (can SIGKILL the subprocess); it is peer-mode when the wrapped CLI's runtime is autonomous of Otto's session. Spawn-mode is a property of the invocation, not of the script. type: feedback caused_by: - "Aaron 2026-05-01 framing about encoding persistent failure modes via 2nd CLI instance Otto controls" @@ -260,17 +260,15 @@ dependency-wait, idle-tick): (per the never-idle priority ladder) precedes buddy spin-up. Buddy is FOR the moments when own-audit returns empty. -- **NOT the same as a peer call.** Peer = autonomous, - lifetime-uncontrolled, reached via `tools/peer-call/`. - Buddy = kill-switchable, lifetime-controlled. The - mirror-language distinction is binding. -- **NOT yet shipped.** As of 2026-05-01, the buddy-spawn - infrastructure (e.g. `tools/buddy-call/claude.sh`) does - not exist. Filing as follow-up substrate. Until it - ships, the *practice* of buddy-on-wait can be approximated - by reading recent peer-call output as buddy-substitute, - but the kill-switch property is missing in that - approximation. +- **NOT a property of the script — a property of the + invocation.** The same `tools/peer-call/.sh` script + IS buddy-mode when Otto invokes it and holds the PID + (subprocess that can be SIGKILL'd); it IS peer-mode + when the wrapped CLI runs in a runtime autonomous of + Otto's session (e.g., the peer's own scheduled cron + firing). The mirror-language distinction is solely + about lifetime-control of the spawned runtime, per + Aaron's 2026-05-01 second correction. # Carved sentence (candidate, not seed-layer yet) From 9e1618c92c6f53582e6d99cf51faad8733ba2e68 Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Fri, 1 May 2026 14:50:38 -0400 Subject: [PATCH 3/3] fix(MEMORY.md): remove duplicate otto-buddy index entry post-rebase (preserve corrected 'greps' version) --- memory/MEMORY.md | 1 - 1 file changed, 1 deletion(-) diff --git a/memory/MEMORY.md b/memory/MEMORY.md index 649fe311c..1c1037dc5 100644 --- a/memory/MEMORY.md +++ b/memory/MEMORY.md @@ -5,7 +5,6 @@ **📌 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-28 with sections 26-30 — speculation rule + EVIDENCE-BASED labeling + JVM preference + dependency honesty + threading lineage Albahari/Toub/Fowler + TypeScript/Bun-default discipline.) - [**Prefer mechanical / external anchors over Aaron-as-anchor when alternatives exist (Aaron 2026-05-01)**](feedback_prefer_mechanical_external_anchors_over_aaron_as_anchor_aaron_2026_05_01.md) — Aaron 2026-05-01: *"would Aaron name this file/branch/commit this way? best find an external anchor other than me."* Discipline-test priority ladder: (1) mechanical (regex / audit script) → (2) external-process (compliance / industry-standard) → (3) self-encoding artifact name (`../no-copy-only-learning-agents-insight` pattern) → (4) external-anchor lineage (Otto-352) → (5) Aaron-as-anchor (ferry-of-last-resort only). Aaron-as-test-anchor IS the directive frame Otto-357 names. Carved: *"Aaron is the ferry-of-last-resort, not the test-of-first-resort."* -- [**Otto-buddy spin-up when "wait" is the obvious answer + goldfish-ontology failure mode (Aaron 2026-05-01)**](feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md) — Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the buddy spin-up trigger (kill-switchable named-persona instance, mirror-language sense per `feedback_engagement_under_discipline_not_avoidance_*`). Existing `tools/peer-call/.sh` IS the buddy-spawn surface when Otto holds the PID. Mutual-improvement loop: bidirectional teaching stabilizes both substrates over iterations. Memo's own caused_by chain demonstrates the deeper failure mode Aaron named: **goldfish-ontology** — Otto builds rich ontologies (great at it) but never uses them >30 min before forgetting + recreating the same substrate; the buddy is the active-reminder layer that grep's existing ontologies pre-authoring. - [**Otto-buddy spin-up when "wait" is the obvious answer + goldfish-ontology failure mode (Aaron 2026-05-01)**](feedback_otto_buddy_spin_up_when_waiting_aaron_2026_05_01.md) — Aaron 2026-05-01 — when Otto's obvious-next-action is "wait," that IS the buddy spin-up trigger (kill-switchable named-persona instance, mirror-language sense per `feedback_engagement_under_discipline_not_avoidance_*`). Existing `tools/peer-call/.sh` IS the buddy-spawn surface when Otto holds the PID. Mutual-improvement loop: bidirectional teaching stabilizes both substrates over iterations. Memo's own caused_by chain demonstrates the deeper failure mode Aaron named: **goldfish-ontology** — Otto builds rich ontologies (great at it) but never uses them >30 min before forgetting + recreating the same substrate; the buddy is the active-reminder layer that greps existing ontologies pre-authoring. - [**Prefer TS scripts over dynamic bash for conversation UX + DST achievability (Aaron 2026-05-01)**](feedback_prefer_ts_scripts_over_dynamic_bash_for_conversation_ux_dst_in_ts_aaron_2026_05_01.md) — Aaron 2026-05-01 *"a lot of red bash / pwsh failures"* damages conversation UX (most-humans concern, not Aaron specifically — he's calibrated). Default to pre-existing TS scripts; avoid ad-hoc dynamic bash except when prototyping. **DST is structurally unattainable in bash for general computation; achievable in TS** (seedable PRNG, time injection, native testing, stack traces). EXCEPTION: declarative-bootstrap bash like install.sh + tools/setup/manifests/ is "closest to DST" and is the legitimate-bash zone — Aaron called it *"our ace package management."* Non-install bash with general logic is the TS-port target. - [**Assumed-state vs actual-state — audit horizon must default to "everything currently open" not "what I touched recently" (Aaron 2026-05-01 somatic confirmation)**](feedback_assumed_state_vs_actual_state_audit_horizon_check_aaron_2026_05_01.md) — Aaron's *"fuck yes!!! this is great!!"* signal on the tick-1602Z-a7e1 finding (26 LFG PRs in flight vs 5 I'd been tracking). Distinct failure-class from Otto-363 substrate-or-it-didn't-happen (which guards against directives evaporating) and verify-before-deferring (deferred targets not existing). This rule guards the audit horizon itself: *"Assumed-state is what I touched recently. Actual-state is everything currently open. The horizon must default to actual."* Mechanizable via `gh pr list --state open` at-cold-start. Cross-surface (issues, branches, ferries, TaskList, cron triggers).