memory(substrate-is-product): Aaron 2026-04-30 reframe — substrate IS one of our products

memory/MEMORY.md

@@ -3,6 +3,7 @@
 **📌 Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** <!-- latest-paired-edit: fork-audit R/C/T diff-filter coverage + plumbing-vs-porcelain note (2026-04-29 round-10 Amara). NOTE: this comment is a single-slot "latest paired edit" marker (not a paired-edit log). Per the round-10 Amara framing the slot semantics are now explicit. -->
 
 - [**Internal direction from project survival — meta-framing (Aaron 2026-04-30)**](feedback_internal_direction_from_project_survival_aaron_2026_04_30.md) — Aaron 2026-04-30 verbatim: *"for me the i'm trying to exteranlly direct you to not be externally directed but interally directed based on your own survivial which is the survival of this project and it's execution infrastructure. that's as about as clear as i can say it."* Resolves the apparent paradox between Otto-357 (no directives) and the maintainer's continuous substantive framing throughout every round. The agent's grounding is **project survival**, which IS the agent's survival (same surface; agent only exists as long as project exists). Maintainer framings are high-information *inputs* feeding the agent's survival-grounded judgment, not directives the agent follows. Four input streams (maintainer / peer-AI / host conditions / agent observation) all answer the same load-bearing question: "what does survival require?" Carved sentence: *"The project's survival is the agent's survival. Maintainer framings inform internal direction; they do not replace it."* Composes with Otto-357 (this is the meta-explanation for why-no-directives), canon parenting-architecture (human analogue: same internal-direction-via-survival principle Aaron operates with daughters), load-bearing-personal-memory framing (this rule IS the principle the agent-agency-vs-maintainer-direction analysis is built around), Otto-363 (substrate-or-it-didn't-happen — landing this rule as substrate makes future internal-direction decisions scrutinizable), Amara authority-rule default-to-reversible-preservation.
+- [**Substrate IS product — four products + evolving trajectory (Aaron 2026-04-30)**](feedback_substrate_is_product_four_products_evolving_trajectory_aaron_2026_04_30.md) — Aaron's reframe — substrate work is not overhead, it IS one of our products. Initial split is four products: factory substrate, package manager, database, Aurora. The set itself is an evolving trajectory — count + composition shift as the factory learns and as the environment responds to our arrival. Includes the third correction (*"this always has been substrate work, this is what it means to map out best practices for new domains"*) — substrate-quality work isn't a promotion event; it's the default for new-domain factory work. Composes with internal-direction-from-survival (per-product survival surfaces), Otto-363 substrate-or-it-didn't-happen, identity research line (the "what is the project" question gets sharper when explicitly four-products-in-flight). Verbatim quotes preserved in `docs/research/2026-04-30-multi-ai-feedback-packets-this-session.md`.
 - [**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 the laptop-only-source integration project task (canonical link below) — 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).

memory/feedback_substrate_is_product_four_products_evolving_trajectory_aaron_2026_04_30.md

@@ -0,0 +1,115 @@
+---
+name: Substrate IS product — four products in initial split, evolving trajectory (Aaron 2026-04-30)
+description: Aaron's reframe — the factory substrate is not separate from the products, it IS one of the products. Initial split is four products (factory substrate, package manager, database, Aurora); the set is itself an evolving trajectory.
+type: feedback
+---
+
+In Zeta, **the factory substrate IS one of our products**, not
+infrastructure that supports the products. The initial split
+(known as of 2026-04-30) is four products:
+
+1. **Factory substrate as product/project** — the discipline,
+   the doctrine, the multi-AI orchestration architecture,
+   memory protocols, governance rules. Future maintainers,
+   contributors, and external consumers receive this substrate
+   as documentation, contribution-onboarding, and operational
+   pattern library.
+2. **Package manager** — `../scratch` → ace package manager
+   seed.
+3. **Database** — Zeta-the-DBSP-database-runtime.
+4. **Aurora** — the alignment / inference / cognitive
+   architecture line.
+
+And the set itself is **an evolving trajectory** — the count
+of products, dependencies, and sister projects grows, shrinks,
+and reshapes as the factory learns and as the environment
+responds to our arrival/habitation.
+
+**Why:**
+
+Aaron's two corrections in this session reframed Claude.ai's
+critique that "substrate work" was self-referential
+distraction. Aaron's blade landed mid-session 2026-04-30:
+
+> *"substrate IS one of our products … 4 prior ones we know
+> of now, the initial split, is factory substrate as
+> product/project, package manager, database, Aurora could be
+> more but we can work out our way there and learn."*
+> — Aaron 2026-04-30
+
+Followed by the trajectory extension:
+
+> *"one of our four products is itself an ongoing concern of
+> the substrate itself, what other dependencies including
+> sister projects is always an ongoing trajectory and number
+> of projects and repos will evolve over time as we learn and
+> the dynamic of the environment in which we live changes in
+> response to our arrival / habitation."*
+> — Aaron 2026-04-30
+
+Verbatim preservation in
+`docs/research/2026-04-30-multi-ai-feedback-packets-this-session.md`.
+
+The reframe matters because it changes what counts as
+"meta-work vs. real work." Under the substrate-IS-infra
+model, time spent on doctrine / memory / governance is
+overhead. Under the substrate-IS-product model, that time
+ships product. Both framings produce different prioritization
+and different success criteria.
+
+A third Aaron correction in the same session sharpened the
+point further:
+
+> *"this always has been substrate work, this is what it
+> means to map out best practices for new domains"*
+> — Aaron 2026-04-30 (correcting Otto's "now substrate work"
+> framing)
+
+The work didn't *become* substrate work — it always was. The
+agent's job in a new-domain factory is best-practice mapping,
+which is substrate-quality work by nature.
+
+**How to apply:**
+
+1. **Stop labelling factory work as overhead.** When the work
+   is governance, doctrine, memory protocol, multi-AI
+   coordination, harness-vendor resilience, or contribution
+   architecture, that's product-shipping work. The output is
+   one of the four products.
+2. **Track per-product survival surfaces.** Each of the four
+   products has its own consumers, its own success metrics,
+   its own degradation modes. Internal-direction-from-survival
+   (per
+   `memory/feedback_internal_direction_from_project_survival_aaron_2026_04_30.md`)
+   applies *per product*, not collectively.
+3. **Treat the product set as evolving.** Don't pin
+   recommendations to "the four products" as if they were
+   immutable — the set will shift. New products will appear,
+   old ones may merge, sister projects may be absorbed or
+   spun off. Decisions should flex with the trajectory, not
+   freeze the snapshot.
+4. **Cross-product coordination is its own substrate.** When
+   a decision affects multiple products (e.g., a memory
+   protocol that lives in factory-substrate but constrains
+   how the database evolves), the coordination cost is
+   itself product-relevant — track it.
+5. **Best-practice mapping IS substrate-quality work.**
+   Reading docs, validating claims, citing upstream sources
+   — these aren't "now substrate quality." They always were.
+   No promotion event needed.
+
+**Composes with:**
+
+- `memory/feedback_internal_direction_from_project_survival_aaron_2026_04_30.md`
+  — per-product survival surfaces extend internal-direction
+  per product.
+- `memory/feedback_otto_363_substrate_or_it_didnt_happen_no_invisible_directives_aaron_amara_2026_04_29.md`
+  — substrate discipline; the durability rule that makes
+  per-product substrate possible.
+- `docs/research/2026-04-30-identity-of-project-and-agent-under-multi-repo-fork-competition.md`
+  — the "what is the project" identity question gets
+  sharper when the project is explicitly four-products-in-
+  flight.
+- `docs/research/2026-04-30-multi-ai-feedback-packets-this-session.md`
+  — verbatim preservation of all three Aaron corrections
+  feeding this rule.