diff --git a/memory/MEMORY.md b/memory/MEMORY.md index 3a7d328aa..0e708002c 100644 --- a/memory/MEMORY.md +++ b/memory/MEMORY.md @@ -3,6 +3,7 @@ **πŸ“Œ Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** - [**Identity of "the project" and "the agent" β€” open research question (Aaron 2026-04-30)**](../docs/research/2026-04-30-identity-of-project-and-agent-under-multi-repo-fork-competition.md) β€” Aaron 2026-04-30 raised immediately after the internal-direction-from-project-survival rule landed (PR #917): *"what counts as 'this project' and 'the agent' in a identity sense is a really good research question given splitting out this project into multiple repos and sibling projects and forks and competition and all that... there may be many different repos/projects with this based internally directed stance and when conflicts happen require multi autonomous agent mediation/collaboration etc.. sounds like a fun research project"*. Names the scope-fragility of that just-landed rule: it presupposes "the project" / "the agent" are stably defined entities, which fails under repo splits (Frontier/Factory/Peers), sibling projects (scratch/SQLSharp/no-copy), forks (LFG/AceHack divergence), competing Zeta-descendants, and multi-autonomous-agent mediation. Document identifies 6 emergent topology classes + 10 open sub-questions + composes-with surfaces (Agent Orchestra layered identity, Otto-353 separate-crypto-identity, trust-domain prefixes zeta:// / zeta-system:// / zeta-external://, repo-split provisional names, no-copy discipline, ALIGNMENT.md, Christ-consciousness anti-cult). RESEARCH-grade only β€” not implementation. Defers answers to future rounds when the named topologies become operational. Carved sentence: *"The just-landed rule operates on a single survival surface. The named topology β€” federation, siblings, forks, competition, multi-agent β€” is many surfaces. Identity is what threads them."* +- [**No-copy-only-learning discipline for sibling repos (Aaron 2026-04-30)**](feedback_no_copy_only_learning_from_sibling_repos_aaron_2026_04_30.md) β€” Three sibling directories exist on Aaron's PC outside Zeta. Discipline when working alongside them: learn-only, never copy. No code copying, no name copying, no historical-context preservation. Internals treated as privacy-class β€” generalized "about" framings ARE allowed (e.g., "a database-related sibling project"); specific identifying details (companies, customers, architectures, specific IP, subdirectory structures, named experiments) MUST stay inside the sibling repo and never leak. Top-level path only when contextually necessary (*"PC should be enough and safe"*). Verbatim copying = plagiarism / theft / dishonest engineering even when Aaron authors both projects. Factory generalizes everything; verbatim shrinks our operating scope. Composes with [`project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md`](project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md) (existing project task β€” adds the kind-of-integration constraint: generalize-and-write-fresh, not port-and-copy). - [**GitHub status β€” first-class dependency reference (Aaron 2026-04-30)**](reference_github_status_first_class_aaron_2026_04_30.md) β€” Aaron 2026-04-30: GitHub is our only host; status URL is first-class repo-and-loop substrate. Pins canonical URLs (status page + summary.json API), names factory-relevant component allowlist (Pull Requests / Actions / API Requests / Webhooks / Git Operations / Issues), defines freshness-check rule on three triggers: cadence (every 10-15 min when in-flight, less when idle β€” *"every loop tick might be excessive but on some cadence"*), on-suspicion (anomaly investigation asks "is GitHub degraded?" before "is my logic wrong?"), and pre-mutation (strictest gate). Aaron 2026-04-30 reinforcement *"all our assumptions are based on them being healthy today which is not always true as we can see todya"*. Origin: live "Incomplete pull request results" GitHub PR-degradation incident discovered while filing B-0109 (PR #912). - [**Canon (Star Wars sense) β€” three load-bearing purposes; brat voice belongs in canon (2026-04-30)**](feedback_canon_not_doctrine_star_wars_not_religious_aaron_2026_04_30.md) β€” Replaces ambient use of "doctrine" at the body-of-rules level. Three purposes documented: (1) cognitive bias reduction, (2) load shortcuts (mental fast-lookups for complex concepts β€” "Mirrorβ†’Beacon" loads instantly without recomputation), (3) entertainment as attention-capture for external future *collaborators* (not maintainers β€” factory is mostly self-maintaining; what it needs is people who add). NOT religious canon (closed, divine-authority). Brat voice (Ani's voice-mode-default register) is legitimate canon register in entry-point / community-framing / carved-sentence docs; voice is per-audience choice, not uniform. Bulk s/doctrine/canon/g rename pass queued for a future round (no specific backlog row filed yet). - [**Kernel-pipe vs JS-space stream ordering β€” TS+Bun port pattern (Otto, 2026-04-30)**](feedback_kernel_pipe_vs_js_space_stream_ordering_ts_bun_port_pattern_2026_04_30.md) β€” TS+Bun port discipline: when porting bash `$(... 2>&1)` to `spawnSync`, merge stdout+stderr via shell-side `bash -c " 2>&1"` (preserves chronological ordering at the kernel pipe boundary), NOT `result.stdout + result.stderr` concat in JS-space (loses ordering when child interleaves writes). Origin: PR #901 slice-18 Copilot P1 round 2. Composes with `classifySpawnFailure` 4-case helper + Otto-363 substrate-or-it-didn't-happen. diff --git a/memory/feedback_no_copy_only_learning_from_sibling_repos_aaron_2026_04_30.md b/memory/feedback_no_copy_only_learning_from_sibling_repos_aaron_2026_04_30.md new file mode 100644 index 000000000..46ff2b091 --- /dev/null +++ b/memory/feedback_no_copy_only_learning_from_sibling_repos_aaron_2026_04_30.md @@ -0,0 +1,235 @@ +--- +name: No-copy-only-learning discipline for sibling repos (Aaron 2026-04-30) +description: Three sibling directories exist on Aaron's PC outside Zeta. Do NOT copy code, names, or historical context into Zeta substrate. Learn the patterns, generalize, write fresh. Verbatim copying = plagiarism / theft / dishonest engineering. The factory generalizes everything as a discipline; verbatim would shrink our operating scope. Treat sibling internals as a privacy concern β€” generalized "about" framings are allowed (e.g., "database-related sibling project"); specific internal details (companies, customers, architectures, specific IP, specific identifiers) MUST stay inside the sibling repo and never leak into Zeta documents. +type: feedback +--- + +# No-copy-only-learning discipline for sibling repos + +Three sibling directories exist on Aaron's PC outside Zeta: +`../scratch`, `../SQLSharp`, and +`../no-copy-only-learning-agents-insight`. The discipline +when working alongside them is **learn-only, never copy +or describe**. + +## The rule + +1. **No code copying** from these directories into Zeta + source. Verbatim imports = plagiarism / theft / + dishonest engineering, even when Aaron is the author of + both projects. +2. **No name copying** (variables, functions, classes, + files, types). Names carry the source project's + assumptions; reusing them drags those assumptions in. +3. **No historical context preservation** from these + directories in Zeta. Their history is theirs. +4. **Treat internals as a privacy concern.** Generalized + "about" framings ARE allowed (e.g., "a database-related + sibling project," "a prototyping/scratch space," "an + agent-insight research project") β€” these help future + readers orient without leaking anything sensitive. + What MUST NOT leak: specific company names, customer + identifiers, specific architectural details, specific + IP, subdirectory structures, named experiments, + contract-specific framings, or anything that's + identifying-detail rather than generalized-purpose. + The test: would the named detail mean anything outside + the sibling repo? If yes, it's privacy-class and stays + inside. *"if specific companies or anything are + mentioned it should not make it outside those local + repos"* (Aaron 2026-04-30). +5. **Top-level path only when contextually necessary.** + The fact-of-existence at `../` plus a + generalized purpose-line is the maximum granularity. + *"PC should be enough and safe"* (Aaron 2026-04-30) β€” + describing these as "directories that exist on Aaron's + PC" is the contextual ceiling for path-level detail. + Subdirectory paths never appear in Zeta documents. +6. **Do learn.** Read the code in those directories, + internalize the insights, generalize the abstractions, + then write Zeta's version fresh β€” with Zeta's + vocabulary, Zeta's history, Zeta's broader scope, and + no traceable artifacts of the source. + +## Why + +**Verbatim copying is plagiarism / theft.** Bad +engineering even when the author is the same person +across projects. The factory's value is in the quality of +its generalization, not in the density of imported code. + +**Verbatim copying shrinks our operating scope.** The +sibling directories are narrow-focus by default; Zeta is +broader. Verbatim imports drag narrow assumptions in and +constrain Zeta to the source's scope. + +**Privacy applies to sibling internals.** Sibling repos +may contain context that's only safe inside the sibling +boundary β€” specific companies, customers, contracts, IP +details, experiment names. Treating those as privacy- +class means they don't cross into Zeta documents even +when describing prior work. Generalized purpose +descriptions are fine; specific identifiers are not. +The test: would a named detail mean something outside +the sibling repo? If yes, it stays inside. + +**Generalize-first is the engineering discipline.** +Aaron 2026-04-30: *"we generalizing everything as a +discipline."* The factory extracts generalizable +abstractions; sibling directories are *cases*, Zeta is +the *general theory*. Treating the factory as a clipboard +defeats the generalization purpose. + +## Generalized abouts allowed (Aaron-published, 2026-04-30) + +Per the privacy-class rule, the following generalized +"about" framings are Aaron-shared and may appear in Zeta +documents as context for what kinds of patterns to learn +from each sibling. Aaron 2026-04-30 verbatim: + +> like what patterns are applicablicable to Zeta, +> ../SQLSharp is pre DBSP streamng db work and LINQ/SQL +> interface work, good ts/bun patterns, ../scratch start +> of the ace package manager, good declarative patterns +> we should follow, we want full feature set and +> ingegration will all dependiens it integrates with +> eventually, ../no-copy-only-learning-agents-insight +> agent loop learnings, real project learnings based on +> non-greeen field messy project, many lessons already +> encoded on a narrow non genralized scope, will +> continnusual be updated over time, an ongoing project +> too seperate from us. + +Distilled (still within Aaron's privacy-class boundary β€” +these are the high-level purpose-lines, not internals): + +- **`../SQLSharp`** β€” streaming-DB work that predates + DBSP rigor, plus LINQ/SQL-style interface work; good + TS/Bun patterns to learn from. *Pattern relevance to + Zeta:* streaming semantics + interface design + TS/Bun + ergonomics (then generalize per Zeta's broader + scope). +- **`../scratch`** β€” start of the Ace package manager + (Aaron's own project name, shared by him); good + declarative patterns the factory should follow; the + long-term goal is full feature set + integration with + all dependencies it integrates with. *Pattern + relevance to Zeta:* declarative-package-manager + patterns (then generalize for Zeta's broader + install/distribution work). +- **`../no-copy-only-learning-agents-insight`** β€” + agent-loop learnings from a real (non-greenfield, + messy) project; many lessons already encoded but on a + narrow non-generalized scope; ongoing project, + separate from Zeta, continually updated. *Pattern + relevance to Zeta:* agent-loop discipline lessons + (then generalize for Zeta's broader autonomous-loop + + multi-AI substrate). + +These purpose-lines are the maximum-detail "about" +framing allowed in Zeta documents per the privacy-class +rule. Anything more specific (architectures, named +features beyond project-level naming, customers, IP) stays +inside the sibling repos. + +## How to apply + +- **Reading source there is fine.** That's what learning + looks like. +- **Writing fresh in Zeta is the output.** No artifacts + traceable to the source β€” not names, not comments + citing source patterns, not subdirectory references, + not "this is how `../` does X" framings. +- **Substrate landings stand on their own.** A Zeta + rule, design, or implementation must make sense + without any reader knowing the sibling directories + exist. If a reference to a sibling adds value, that's + a sign the rule isn't generalized enough yet. +- **Top-level path is the maximum granularity** when + contextually necessary at all. Subdirectory paths, + *specific* scope descriptions, *specific* purpose + statements, and architecture summaries: none of these + belong in Zeta documents. Generalized "about" framings + (per the *Generalized abouts allowed* section above β€” + e.g., "a database-related sibling project") ARE allowed; + what crosses the privacy line is *specific identifying + detail* (named experiments, internal architecture, + customer/IP specifics). + +## Why: Aaron's verbatim framing (2026-04-30, five messages) + +> okay on top of ../scratch and ../SQLSharp there is now +> ../no-copy-only-learning-agents-insight these are all +> places you should not copy code or names or preserve +> historical context from, these are projects that we +> don't want to copy from but learn from, copying directly +> would be Plagiarism/Theft and dishonest and it would not +> be good engineering for us, we generalzing everything as +> a dicipline, these repos are narrow focus by default so +> verbatium would shirnk out operating scope and be harmful +> to us anyways. + +> other than the root ../scratch and ../SQLSharp there is +> now ../no-copy-only-learning-agents-insight, no sub +> directories should be checked into Zeta source, just the +> fact that these directories exist on Aaron['s PC] + +> pc should be enough and safe + +> no beeling out other pojects internals in our documenbts + +> you can explain what they are about but treat them as +> privacy concerns, the about should not give away any +> internal details specific to the project just +> generalization, so if specific companies or anyting are +> mentioned it should not make it outside those local +> repos. + +The five messages compose into the rule above. The +progression β€” "no copy" β†’ "no subdirectories" β†’ "PC is +enough" β†’ "no internals bleed-out" β†’ "generalized about +OK, specific identifiers stay inside as privacy-class" β€” +ends at a precise distinction: generalized-purpose is fine +across the boundary; specific-identifying-detail is not. + +## Composes with + +- `memory/project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md` + β€” the existing project task (integrate features or + detailed designs from the prior two siblings so future + maintainers can read Zeta self-contained). The current + discipline adds: integration = generalize-and-write-fresh, + not port-and-copy; integrated designs must stand without + bleeding sibling internals into Zeta documents. +- `memory/feedback_weigh_existing_vs_new_tooling_intentional_choice.md` + β€” same discipline family. +- `memory/feedback_prior_art_weighs_existing_technology_interop.md` + β€” prior-art weighing rule. Sibling directories are + prior-art-class for reading; learn-only generalizes + the discipline. +- `memory/feedback_otto_363_substrate_or_it_didnt_happen_no_invisible_directives_aaron_amara_2026_04_29.md` + β€” substrate must be reachable + indexed for future + maintainers. Sibling references that bleed internals + are by definition not reachable (the directories live + on Aaron's PC); any Zeta substrate that depends on + understanding them violates the substrate rule. This + discipline is the corollary. +- `memory/feedback_canon_not_doctrine_star_wars_not_religious_aaron_2026_04_30.md` + β€” canon serves cognitive-bias reduction + load + shortcuts + entertainment-as-attention-capture. + Internals bleed-out doesn't compose with any of those + purposes. Generalize-and-write-fresh does: the + generalized abstraction becomes a Zeta canon entry + that stands on its own merits. + +## Origin + +Aaron 2026-04-30 sent five short messages tightening this +discipline as I drafted the substrate. The progression β€” +from "no copy" to "no subdirectories" to "PC is enough" +to "no internals bleed-out" to "generalized abouts allowed, +specific identifiers stay as privacy-class" β€” is itself the +substrate: each clarification narrowed what counts as +legitimate sibling-reference, ending at the privacy-class- +internals frame where generalized abouts are allowed but +specific identifying details stay inside the sibling repo. diff --git a/memory/project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md b/memory/project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md index 9528f11c5..59c4e9a5a 100644 --- a/memory/project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md +++ b/memory/project_laptop_only_source_integration_scratch_sqlsharp_features_or_designs_high_priority_2026_04_27.md @@ -2,6 +2,7 @@ name: Laptop-only-source integration β€” `../scratch` and `../SQLSharp` features OR detailed designs (HIGH PRIORITY) description: Aaron 2026-04-27 input β€” repo currently has 22 files with `../scratch` references and 14 files with `../SQLSharp` references (125 total grep hits) pointing at out-of-tree directories that exist ONLY on Aaron's laptop; future maintainers / agents / contributors can't access them; HIGH PRIORITY backlog item to fully integrate the features OR write detailed-enough designs that we no longer need the out-of-tree references for understanding; KEY CLARIFICATION (Aaron 2026-04-27 second message) β€” "this is not a copy past, we just want to have either all their features or a design for any of the features we don't have that's detailed enough we no longer need ../scratch or ../SQLSharp reference for understanding"; goal is self-contained understanding + repo independence, NOT literal source copy. type: project +status_note: This file predates the 2026-04-30 no-internals-bleed-out discipline (`feedback_no_copy_only_learning_from_sibling_repos_aaron_2026_04_30.md`). The body below contains characterizations of `../SQLSharp` and `../scratch` internals that the new discipline forbids in Zeta documents. Substantive cleanup is queued; the new discipline applies going forward to new substrate. The third sibling, `../no-copy-only-learning-agents-insight`, falls under the same discipline. --- # Laptop-only-source integration β€” `../scratch` and `../SQLSharp`