diff --git a/docs/BACKLOG.md b/docs/BACKLOG.md
index 585a4976..4ebfb469 100644
--- a/docs/BACKLOG.md
+++ b/docs/BACKLOG.md
@@ -5800,6 +5800,564 @@ systems. This track claims the space.
   live Zeta instance on mainnet without Aminata
   threat-model sign-off on the network-exposure surface
   (Phase 2 only).
+- [ ] **Mode 1 admin UI — SSMS/pgAdmin-class local
+  management UI for Zeta.** Maintainer 2026-04-24
+  directive (verbatim):
+
+  > *"for mode 1 we want a front end ui like ssms/pgadmin
+  > but really designed for us"*
+
+  Distinct from the Frontier-UI / kernel-A/kernel-B
+  web-facing surface (per the 2026-04-24 rename
+  directive). This is the **operator/admin local UI** —
+  desktop-class management surface modelled on SQL
+  Server Management Studio + pgAdmin but designed
+  idiomatically for Zeta's substrate (Z-set
+  retraction-native semantics, operator-algebra
+  composition, multi-node distributed-state, the git
+  interface, etc.). Scope: query workbench, schema
+  browser, connection manager, retraction-native delta
+  visualizer, plan inspector for the query optimizer,
+  multi-node topology view, ontology browser per
+  paced-ontology-landing, stream/pipeline live view.
+
+  Two-UI architecture going forward:
+  - **Web-facing Frontier-UI (kernel-A/kernel-B)** —
+    public-user-facing surface.
+  - **Local admin UI (this row)** — operator/admin
+    surface, ships with Mode 1 single-file binary.
+
+  Priority P2 / research-grade (UX + design lead time);
+  effort L (full app). Composes with the Mode 1
+  bootstrap thesis (single-file AoT/JIT executable),
+  the git-as-DB-interface row below, and Otto-274
+  progressive-adoption-staircase.
+
+- [ ] **Ouroboros bootstrap — meta-thesis +
+  connection-map work for the 2026-04-24 cluster.**
+  Maintainer 2026-04-24 directive (verbatim):
+
+  > *"oraborus bootstraping exact integrations and
+  > connections and all that to make sure we can do it
+  > right"*
+
+  Meta-thesis: **the system bootstraps itself**. Native
+  F# git impl stores its own commits as Z-sets in its
+  own database. Permissions registry tracks the
+  authority for its own creation. Memory-sync uses
+  memory-sync. Mode 2 hosts the factory dashboard that
+  operates on Mode 2. Bootstrap-thesis changes land as
+  retraction-native deltas in our own substrate. Test
+  using ourselves. Three load-bearing properties:
+  provenance is closed under the substrate; every
+  integration is testable from the inside;
+  self-consistency is a detectable invariant.
+
+  **Cardano pedagogy double-meaning preserved** — the
+  Cardano consensus protocol is called Ouroboros (most
+  formally-verified deployed PoS); when the
+  blockchain-ingest work activates, the protocol
+  research reinforces the bootstrap thesis at a
+  different level (same self-referential property,
+  same name). Naming overlap is intentional, not
+  accidental.
+
+  **Connection-map work** (Phase 0 deliverable, owed
+  before any new architecture lands):
+  `docs/research/ouroboros-bootstrap-connection-map-2026.md`
+  — directed graph of factory components (Mode 1
+  binary / Mode 2 WASM / native git impl / admin UI /
+  factory ops dashboard / Frontier-UI / permission
+  registry / memory-sync / etc) with edges as
+  explicit integration contracts (wire protocols,
+  file formats, authority dependencies). Self-loops
+  in the graph ARE the Ouroboros closures — must be
+  explicitly identified and justified.
+
+  **Maintainer's standard:** *"exact integrations and
+  connections to make sure we can do it right"* —
+  implementation work on any 2026-04-24 directive
+  should not start without the integration shape
+  drawn. Hand-waved "Mode 2 talks to Mode 1 somehow"
+  is insufficient.
+
+  **Composes with all 2026-04-24 directives in the
+  same session:** the rename (#393), blockchain
+  ingest (#394), Mode 1 admin UI + native F# git +
+  protocol upgrade + permissions registry + UI split
+  (this PR / #395). Companion memory file
+  `memory/feedback_ouroboros_bootstrap_self_reference_meta_thesis_2026_04_24.md`
+  captures verbatim directive + the bootstrap
+  property's three load-bearing claims + composition
+  with each peer directive.
+
+  Priority P2 hygiene (gates implementation of the
+  others); effort M (connection-map research doc) +
+  S (cross-link from the other 2026-04-24 rows) +
+  ongoing (every new architecture row should declare
+  its closure stance). Composes with
+  `holistic-view`, `glass-halo-architect`,
+  `category-theory-expert` (for the formal
+  closure-property framing), Otto-275
+  log-don't-implement.
+
+- [ ] **Mode 2 UI architecture split — admin UI vs
+  factory-ops-dashboard vs web-facing Frontier-UI;
+  research required + maintainer review.** Maintainer
+  2026-04-24 directive (verbatim):
+
+  > *"so mode 2 is the ssms/pgadmin ui for mode 1 and
+  > the operations dashboard for the factory too both?
+  > or we split into two uis right? IDK we needs some
+  > clean dependences splits research here, i'd like to
+  > review tooo when its done."*
+
+  Three candidate UI surfaces have surfaced in the
+  2026-04-24 directives so far (see the rows above and
+  the rename row in #393):
+
+  - **Frontier-UI / kernel-A + kernel-B (web-facing
+    public surface)** — public-user-facing surface,
+    "Star-Trek-computer-but-better"-class. Per the
+    rename directive: farm-related kernel-A +
+    carpentry-related kernel-B. Audience: end-users
+    consuming Zeta as a product.
+  - **SSMS/pgAdmin-class admin UI** — database
+    operator surface. Audience: database
+    administrators, query-optimizer reviewers,
+    multi-node topology managers.
+  - **Factory operations dashboard** — Zeta-the-
+    factory-not-Zeta-the-product surface. Audience:
+    factory maintainers (the human maintainer + Otto
+    + future contributors). PR queue, build state,
+    round progress, research absorbs, hygiene-history,
+    counterweight-audit reports, agent dispatch,
+    drain-log visualizer.
+
+  **Loop-agent preliminary read** (subject to
+  maintainer review):
+
+  - Frontier-UI is **definitely separate** — its
+    audience is end-users, not operators. Different
+    UX language, different feature set, different
+    deploy cadence (public-facing → conservative;
+    factory-internal → fast iteration). Keeping it
+    distinct preserves the rename-directive's two
+    seed-extension kernels (kernel-A farm + kernel-B
+    carpentry) that shrink-over-time.
+  - **Admin UI vs factory-ops-dashboard is the
+    interesting split.** Two readings:
+    - **Reading A — single surface, modular tabs.**
+      Mode 2 is one app; admin and factory-ops are
+      modules within it. Cheapest to ship; some UX
+      coherence risk (the audiences are different
+      enough that a shared chrome may feel forced).
+      Composes with the bootstrap thesis (one
+      browser-only artifact serves both).
+    - **Reading B — two surfaces, shared component
+      library.** Admin UI and factory-ops-dashboard
+      are distinct Mode 2 apps that share a
+      component library (auth, navigation, theme,
+      query widget, plan inspector). More UX
+      coherence per audience; higher engineering
+      cost; both ship from the same monorepo.
+  - **My preliminary recommendation: Reading B**
+    (two surfaces, shared library). Audiences differ
+    enough that forcing one chrome harms both. The
+    shared component library captures the
+    composability-cost gain without the
+    audience-blur risk. The admin UI ships with
+    Mode 1 binary (operator-side); the factory-ops
+    dashboard ships at the factory-maintainer level
+    (Otto + human maintainer access only). Frontier-
+    UI stays its own app (already separate by
+    rename-directive).
+
+  **Three-app architecture (Reading B, expanded):**
+  - **App A — Frontier-UI (kernel-A/kernel-B)**:
+    public; web-facing; conservative deploy.
+  - **App B — Admin UI (Mode-1-bundled)**: ships
+    with Mode 1 single-file binary; operator
+    audience; database-management-class UX.
+  - **App C — Factory ops dashboard**:
+    factory-maintainer audience; PR/build/round/
+    drain-log/counterweight-audit visualizer.
+  - **Shared library**: WASM-F# component primitives
+    (auth, theme, query widget, plan inspector,
+    multi-node topology view, retraction-aware
+    delta visualizer).
+
+  **Research scope (Phase 0, output:
+  `docs/research/mode-2-ui-architecture-split-2026.md`):**
+  - Map audience needs per app (interviews / persona
+    sketches).
+  - Identify shared primitives vs app-specific
+    surfaces.
+  - Decide chrome strategy (one shell with tabs vs
+    three shells).
+  - Define dependency boundaries — what each app
+    pulls from the shared library, what it owns.
+  - Enumerate Mode 1 vs Mode 2 distribution per app
+    (admin UI is Mode-1-bundled; ops dashboard might
+    be either; Frontier-UI is web-only).
+  - Propose recommendation; flag tradeoffs;
+    explicitly mark "maintainer review required
+    before any UI implementation work starts."
+
+  Priority P3 / way-backlog (no UI implementation
+  before this research lands and maintainer reviews);
+  effort M (research doc) + L+ (each app once design
+  approved). Composes with the rename directive
+  (Frontier-UI naming), the Mode 1 admin UI row, the
+  protocol-upgrade row (any of the three apps may
+  use the upgraded fast protocol once connected to
+  a Mode 1 backend), `user-experience-engineer`
+  (audience research), `developer-experience-engineer`
+  (factory-ops UX), Otto-275 log-don't-implement.
+
+- [ ] **Named-permissions registry — per-contributor
+  scoped permission grants for factory agents.**
+  Maintainer 2026-04-24 directive (verbatim):
+
+  > *"we shoud probbably have a list of named
+  > permissions you might need and thier names and
+  > descriptions and which ones are active for which
+  > contributro. this in not super safe yet but we can
+  > nake it more safe over time."*
+
+  Scope: a registry that names every operational
+  authority the factory agents might need (admin-level
+  GitHub ops, secret access, branch-protection edits,
+  repo settings PATCH, ruleset CRUD, workflow dispatch,
+  etc.) and tracks which contributor has granted which
+  named permission to which agent role. Iterative
+  hardening — start permissive, layer on confirmation
+  / quorum / time-bounded grants over time.
+
+  **Inaugural named permission:** `github-admin`
+  granted by the human maintainer 2026-04-24 to the
+  loop-agent role (Otto). Captured durably in
+  `memory/feedback_github_admin_authority_grant_to_loop_agent_2026_04_24.md`
+  per the maintainer's "save as durable" directive.
+
+  **Initial draft of named permissions** (this list
+  expands as new authorities get exercised):
+
+  - `github-admin` — branch protection PATCH, repo
+    settings PATCH, ruleset CRUD, workflow dispatch.
+    Granted to: loop-agent (2026-04-24, durable).
+    Excludes: org-level admin, repo deletion, member
+    management, force-push to main, bypass branch
+    protection on a single PR.
+  - `github-org-admin` — org-level settings + member
+    management. NOT granted yet.
+  - `github-secrets` — Actions secrets and Dependabot
+    secrets read/write. NOT granted yet.
+  - `force-push-main` — bypass branch protection for
+    emergency cases. NOT granted yet (preserve linear
+    history discipline).
+  - `nuget-publish` — push packages to nuget.org under
+    Lucent identity. NOT granted yet.
+  - `slsa-signing-key` — sign release artifacts. NOT
+    granted yet (requires HSM).
+  - `external-network-egress-broad` — fetch from
+    arbitrary URLs (beyond the prompt-protector
+    allowlist). NOT granted yet.
+
+  **Registry shape (proposed):**
+
+  Live at `docs/AUTHORITY-REGISTRY.md` (factory-
+  authored; current-state doc). One section per named
+  permission with: name, description, scope (in/out
+  of), granted-to (contributor → agent-role), grant
+  date, durability (session / cross-session), audit
+  link (memory file or commit). One section per
+  agent-role rolling-up which permissions it has.
+
+  **Iterative hardening path:**
+  - Phase 0 — registry exists (this row's first
+    deliverable); no enforcement, just documentation.
+  - Phase 1 — agent self-checks the registry before
+    attempting an admin operation.
+  - Phase 2 — commit-message / PR-description
+    citation requirement (the action commit names the
+    grant).
+  - Phase 3 — time-bounded grants (e.g.
+    `github-admin` expires every 30 days; maintainer
+    re-grants).
+  - Phase 4 — quorum requirements for high-risk
+    permissions (e.g. force-push needs both
+    maintainer + threat-model-reviewer sign-off).
+  - Phase 5 — Aminata threat-model integration: each
+    permission has a documented adversarial scenario
+    + mitigation.
+
+  Maintainer is explicit that this is NOT super safe
+  YET — the gain comes from iterative hardening.
+  Capture-the-grant-and-cite-it discipline beats
+  silent expansion of authority.
+
+  Priority P2 hygiene; effort S (Phase 0 registry doc)
+  + S (Phase 1 self-check) + M (Phase 2 citation
+  enforcement) + L (Phases 3-5 hardening). Composes
+  with `governance-expert`, `threat-model-critic`,
+  `security-operations-engineer`, GOVERNANCE.md
+  numbered rules section.
+
+- [ ] **Mode 2 → Mode 1 protocol-upgrade negotiation —
+  start with git, upgrade to a faster protocol for
+  hot-path backend comm.** Maintainer 2026-04-24
+  directive (verbatim):
+
+  > *"we could use mode 2 as our ui and have it auto
+  > netogatie protocol upgrade to a better protocol that
+  > git to whatever we want for hight speed communicaiton
+  > with out backend i think thats cleans"*
+
+  Architectural pattern: ALPN-style / HTTP-Upgrade-style
+  protocol negotiation. Mode 2 (browser WASM) opens with
+  git as the **lowest-common-denominator bootstrap
+  protocol** (every Zeta instance speaks git natively per
+  the row above). Once the connection is established and
+  both sides confirm capability, negotiate an upgrade to
+  a faster Zeta-specific binary protocol for hot-path
+  traffic (high-throughput streaming, low-latency reads,
+  bulk pull/push). Git stays as fallback / audit-trail
+  /durable-substrate path.
+
+  **Why this is clean:**
+  - Cold-start: any browser + any git remote → instant
+    bootstrap (no protocol negotiation cost paid until
+    you have a connection).
+  - Warm-state: protocol-upgraded comm is fast (binary
+    framing, no commit-object overhead, streaming
+    semantics, server-push for live updates).
+  - Backwards-compatible: an unupgraded peer (e.g. an
+    actual git client, not a Zeta peer) still works —
+    it never asks for the upgrade.
+  - Audit-trail: even after upgrade, the durable layer
+    can checkpoint back to git on cadence (every N
+    operations or every commit boundary), so the git
+    history remains the canonical durable substrate.
+
+  **Reference patterns:**
+  - HTTP `Upgrade:` header + 101 Switching Protocols.
+  - ALPN over TLS (HTTP/2 negotiation).
+  - Postgres wire-protocol startup-message + protocol-
+    version negotiation.
+  - WebSocket initial-HTTP-handshake-then-upgrade.
+
+  **Capability advertisement:** standard pattern is for
+  the server to advertise capabilities in its first
+  response (e.g. git's `capabilities^{}` ref or
+  `command=ls-refs` advertisement); Zeta extends this
+  to include a `zeta-fast-v1` capability. Client opts
+  into upgrade by sending the corresponding header on
+  next request.
+
+  **Composes with:**
+  - The native F# git implementation row above (where
+    Zeta IS the git client/server) — the upgrade
+    capability gets advertised by Zeta's git server.
+  - The WASM-F# + git-as-storage row below (Mode 2's
+    starting position).
+  - `networking-expert`, `serialization-and-wire-format-expert`,
+    `streaming-incremental-expert`.
+
+  Priority P3 / way-backlog (depends on the native git
+  impl row landing first); effort M (capability
+  advertisement + upgrade dance) + L (the actual fast
+  protocol design + implementation). Composes with
+  Otto-275 log-don't-implement.
+
+- [ ] **Native F# git implementation — Zeta IS the git
+  client/server (no external git needed).** Maintainer
+  2026-04-24 directive (verbatim):
+
+  > *"we want to have a full git implimentation in f#
+  > where we don't even need the git client, we are
+  > also the git client and it stores into our database
+  > for mode 1. just another interface like SQL"*
+
+  Zeta-native git implementation in F# — full git
+  protocol (object format, pack files, refs, index,
+  smart-HTTP / SSH transport, push/pull negotiation,
+  upload-pack / receive-pack server side). Storage
+  lands in Zeta's database (Mode 1) — git objects
+  serialize as Z-set entries with commit/tree/blob
+  ontology. Pairs with the WASM/git-storage row below
+  for Mode 2 (where isomorphic-git is the browser-side
+  client).
+
+  **Symmetric architecture:**
+  - **Mode 1** — native F# git impl + Zeta DB storage.
+    Zeta talks git natively to other peers. No external
+    git binary required.
+  - **Mode 2** — WASM-F# + isomorphic-git in browser +
+    git remote (could be ANOTHER Zeta-Mode-1 instance
+    serving git).
+
+  **Composition gain:** any Zeta Mode 1 instance can
+  serve as a git remote for any Zeta Mode 2 browser
+  client. The factory becomes self-hosting of its own
+  git ecosystem — `git push my-zeta main` = pushing to
+  Zeta's DB via Zeta's own git server.
+
+  **"just another interface like SQL"** — maintainer's
+  framing. Git is one of several first-class
+  protocols on top of Zeta's substrate, alongside SQL,
+  operator algebra, LINQ, GraphQL (future), etc.
+  Implementation effort is L+ (the git protocol is
+  large but fully specified; Z-set
+  retraction-native semantics map cleanly).
+
+  Priority P3 / way-backlog per maintainer; effort L+
+  (full git protocol coverage). Composes with the
+  git-as-DB-interface row below (sister; same
+  direction), the WASM/git-storage row (companion for
+  Mode 2), `fsharp-expert`, `git-workflow-expert`,
+  `serialization-and-wire-format-expert`. Composes
+  with `networking-expert` for the HTTP/SSH transport
+  layer.
+
+- [ ] **Git-as-first-class-DB-interface — Zeta commands
+  ≈ git commands where semantics align.** Maintainer
+  2026-04-24 directive (verbatim, low-priority backlog):
+
+  > *"we want to have first class git inteface into our
+  > database, so our database can handle all / most git
+  > command, way backlog."*
+
+  Scope: an interface adapter that exposes Zeta DB
+  operations through git's command surface where
+  semantics align — `commit` = transaction boundary,
+  `branch` = isolated workspace, `merge` = multi-writer
+  reconciliation, `log` = history / retraction trail,
+  `diff` = delta query, `tag` = named-checkpoint,
+  `stash` = pending-write buffer, `cherry-pick` =
+  selective transaction replay. Z-set retraction-native
+  semantics map cleanly onto git's
+  immutable-history-with-revertible-deltas model.
+  Explicit mapping table needed (not every git command
+  has a Zeta analogue — `gc` / `fsck` are git-internal).
+  Composes with Otto-243 (git-native memory-sync — proves
+  substrate-level fit) and the WASM/git-storage row
+  below. Adds ONE entry-point; existing SQL / operator-
+  algebra / LINQ surfaces stay authoritative. Priority
+  P3 / way-backlog per maintainer; effort M+L. Composes
+  with `git-workflow-expert`.
+
+- [ ] **WASM-F# + git-as-storage-plugin — browser-only
+  bootstrap mode (zero server, zero install).**
+  Maintainer 2026-04-24 directive (verbatim,
+  long-horizon research stretch goal):
+
+  > *"a storage plugin for our db that saves to git
+  > commonds lol. this will let me compile as wasm our
+  > f# and run our database enginge in the ui and it
+  > calls out to git for the actual operations? Am i
+  > dreaming for this second one? We should research it
+  > but it's a huge stretch way back backlog for the
+  > 2nd one."*
+
+  **Maintainer's framing question:** *"This complets
+  our bootstrap without requirments really i think? you
+  tell me."*
+
+  **Loop-agent assessment** (captured for future
+  reference; subject to maintainer challenge):
+
+  - **Yes, this completes the zero-server bootstrap —
+    via a different axis than Mode 1.** Both modes are
+    zero-install:
+    - **Mode 1** — full backend via tiny-seed AoT-
+      compiled or single-file JIT builds. Standalone
+      executable; NO .NET preinstall required. Just
+      download + run. (Maintainer correction
+      2026-04-24: existing planning is for tiny-seed
+      AoT + single-file JIT, not framework-dependent
+      builds.)
+    - **Mode 2** — browser-only via WASM-F# + any git
+      remote. NO executable to download (browser
+      handles WASM); NO server to run.
+    Browsers are universal; git remotes are commodity
+    (GitHub/GitLab free tier; self-hosted git is
+    trivial). Mode 2 is "even more zero" only in the
+    sense that there's no artifact to download — both
+    modes are install-free at the user-experience
+    level.
+  - **Not a dream — coherent stretch.** Pieces compose:
+    - WASM-F# in the browser is real today via Blazor
+      WebAssembly (the .NET runtime compiled to
+      WebAssembly, hosting F# directly). Fable is a
+      separate F#→JavaScript option (not a WASM runtime)
+      and is listed only as the alternative if a JS
+      target is preferred over .NET-on-WASM. Mode 2's
+      intended approach is Blazor WASM. Performance
+      workable for non-hot-path; hot-path needs
+      in-browser cache.
+    - `isomorphic-git` brings the git protocol to the
+      browser; pairs with WASM-F#.
+    - Z-set entries serialize as commit blobs / tree
+      objects; retractions = `git revert` or branch
+      reset.
+    - Multi-writer = git's branch-and-merge model
+      (CRDT-friendly under Z-set semantics).
+    - Composes with Otto-243 (git-native memory-sync)
+      as precursor pattern.
+  - **Wild bit is performance.** Git ops NOT fast
+    enough for DB hot-path reads. But for **durable
+    writes + cross-machine sync + audit trail**, git
+    is genuinely good. Mode 2 architecture is
+    "browser viewer + git-backed durable substrate;
+    hot-path lives in browser memory" — not "every
+    read hits git".
+  - **Strong fit with Otto-274 progressive-adoption-
+    staircase Level 0** — "open a tab; no install" is
+    the lowest-friction adoption rung the factory has
+    yet articulated.
+  - **Real risk: write-amplification.** Every Zeta
+    write becomes a git commit. High-throughput
+    streams (e.g. blockchain ingest) would saturate
+    any git remote. Mode 2 suits LOW-VOLUME workloads
+    (per-user notebooks, factory memory sync,
+    configuration, knowledge bases). Mode 1 stays
+    load-bearing for production / streaming.
+
+  **Phased approach** (when this row activates):
+  - **Phase 0** — feasibility research: WASM-F#
+    runtime cost, isomorphic-git API surface, write
+    batching strategies, hot-path cache shape. Output:
+    `docs/research/wasm-fsharp-git-storage-feasibility.md`.
+  - **Phase 1** — proof-of-concept: minimal in-browser
+    Zeta with git-backed Z-set storage on a single
+    test workload (personal notebook). No streaming,
+    no multi-user.
+  - **Phase 2** — multi-user via git branches; merge
+    semantics for concurrent writes; conflict
+    resolution UX.
+  - **Phase 3** — production-mode hardening: write
+    batching, hot-path cache eviction, server-fallback
+    for high-throughput.
+
+  Priority P2 / research-grade per maintainer
+  (long-horizon stretch goal — section placement
+  matches);
+  effort L+ (research) + L (POC) + L (production).
+  **Does NOT authorize** starting POC code without
+  Phase-0 feasibility doc landing first. **Does NOT
+  authorize** declaring Mode 2 production-ready
+  without empirical write-throughput + read-latency
+  measurements + Aminata threat-model sign-off on the
+  exposed-git-remote attack surface.
+
+  Composes with the git-as-DB-interface row above
+  (sister; same direction), `wasm` (no skill exists yet
+  — gap), `fsharp-expert`, `git-workflow-expert`,
+  `crdt-expert`, Otto-243 (git-native memory-sync
+  precursor), Otto-274 (progressive-adoption-staircase
+  Level 0 candidate), Otto-275 (log-don't-implement —
+  capture, do not start POC).
 
 - [ ] **Land per-maintainer CURRENT-memory ADR + companion
   feedback memory.** PR #153 landed the CLAUDE.md fast-path
diff --git a/docs/pr-preservation/395-drain-log.md b/docs/pr-preservation/395-drain-log.md
new file mode 100644
index 00000000..6d2ffa09
--- /dev/null
+++ b/docs/pr-preservation/395-drain-log.md
@@ -0,0 +1,152 @@
+# PR #395 drain log — `backlog+memory: git-as-DB-interface + WASM-F#/git-storage; both modes require 0`
+
+Drain ferry: 2026-04-24. Resolution commit (review-thread fixes) on top of the rebased branch: `d9e2406`. Auto-merge armed; rebased onto fresh `origin/main` before drain. PR scope is docs+memory only (`docs/BACKLOG.md`, `memory/MEMORY.md`, two `memory/feedback_*.md` files).
+
+Per Otto-250 PR-preservation drain-log discipline: per-thread fields are reviewer, file:line, original comment verbatim, outcome, reply verbatim, resolution commit. Bot handles preserved verbatim per Otto-237.
+
+---
+
+## Thread 1 — `PRRT_kwDOSF9kNM59iCyf`
+
+- **Reviewer:** Copilot
+- **File:line:** `docs/BACKLOG.md:6209` (now around line 6290 after edits — WASM-F# row, "Not a dream" subsection)
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> P1: "WASM-F# is real today via Blazor WebAssembly + Fable" conflates two different browser strategies: Blazor WebAssembly runs .NET (and can host F# via .NET), while Fable compiles F# to JavaScript rather than WebAssembly. Reword to avoid implying Fable is a WASM runtime and to clarify the intended approach for Mode 2.
+
+### Reply
+
+> Fixed in d9e2406. Reworded to disambiguate: Blazor WebAssembly is named as the actual WASM-F# path (the .NET runtime compiled to WebAssembly, hosting F# directly) and is now stated as Mode 2's intended approach. Fable is called out as the F#→JavaScript alternative (explicitly "not a WASM runtime") that would only apply if a JS-target Mode 2 were preferred over .NET-on-WASM. The two strategies are no longer conflated.
+
+---
+
+## Thread 2 — `PRRT_kwDOSF9kNM59iCyx`
+
+- **Reviewer:** Copilot
+- **File:line:** `memory/feedback_git_interface_wasm_bootstrap_zero_requirements_2026_04_24.md:124`
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> P1: Same issue as in BACKLOG: "WASM-F# is real today via Blazor WebAssembly + Fable" is potentially misleading because Fable targets JavaScript, not WebAssembly. Consider clarifying whether Mode 2 is Blazor WASM (.NET runtime in browser) vs an Fable/JS approach, or list them as distinct options.
+
+### Reply
+
+> Fixed in d9e2406. The "Why git-as-storage is coherent" section now disambiguates the two strategies: Blazor WebAssembly is the actual WASM path and is named as Mode 2's intended approach; Fable is listed as a distinct F#→JavaScript option (explicitly "NOT a WebAssembly runtime") that would be the alternative if a JS-target Mode 2 were chosen. Listed as distinct options per the suggestion. Same wording shape as the BACKLOG fix so the two surfaces stay consistent.
+
+---
+
+## Thread 3 — `PRRT_kwDOSF9kNM59iCy6`
+
+- **Reviewer:** Copilot
+- **File:line:** `memory/MEMORY.md:7` (GIT-AS-DB-INTERFACE + WASM bootstrap entry)
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> P2: `memory/README.md` states `MEMORY.md` entries should be "keep entries terse" (and the index is intended to be capped ~200 lines). This newly added entry is extremely long, which makes the index harder to scan and accelerates already-large index growth. Consider shortening the link text to a compact title + date and leaving the detailed summary inside the target memory file.
+
+### Reply
+
+> Fixed in d9e2406 per `memory/README.md` "keep entries terse" guidance. Index entry compressed to compact title + date + one-clause body summary, matching the shape of newer entries (e.g. Otto-276 line 10). Substantive content stays in the linked memory file; the index now reads as a navigable table-of-contents instead of a duplicate corpus. Resolving.
+
+---
+
+## Thread 4 — `PRRT_kwDOSF9kNM59iCzG`
+
+- **Reviewer:** Copilot
+- **File:line:** `docs/BACKLOG.md:5830` (admin-UI / SSMS-pgAdmin-class row in `## P2 — research-grade`)
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> P1: This item is filed under the `## P2 — research-grade` section, but the text says "Priority P3 / way-backlog". That priority/placement mismatch makes the backlog harder to interpret. Either move the entry to the appropriate P3 section, or update the stated priority to match P2.
+
+### Reply
+
+> Fixed in d9e2406 by updating the stated priority to match section placement (P2). The row sits in `## P2 — research-grade`; the body now reads "Priority P2 / research-grade (UX + design lead time)" so placement and priority agree. Reconciliation direction (update text, not move row) chosen because: (a) the row composes tightly with the Mode 1 bootstrap thesis + git-as-DB-interface row, both currently in the same neighborhood, and moving would fragment the cluster; (b) sibling-PR conflict risk on a row move is higher than a one-line wording fix.
+
+---
+
+## Thread 5 — `PRRT_kwDOSF9kNM59iCzO`
+
+- **Reviewer:** Copilot
+- **File:line:** `docs/BACKLOG.md:6253` (WASM-F# + git-as-storage-plugin row in `## P2 — research-grade`)
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> P1: Same priority/placement mismatch here: this row sits in the `P2` section but later states "Priority P3 / way-back-backlog". Please reconcile by moving it to a P3 section or updating the stated priority to P2.
+
+### Reply
+
+> Fixed in d9e2406. Two factory-authored framing edits to align with section placement: (a) the row's intro frame "Maintainer 2026-04-24 directive (verbatim, way-back-backlog stretch goal)" now reads "long-horizon research stretch goal" per the suggestion; (b) the in-row priority statement now reads "Priority P2 / research-grade per maintainer (long-horizon stretch goal — section placement matches)". Maintainer's verbatim quote ("huge stretch way back backlog") is preserved untouched inside the `> *"..."*` block per signal-in-signal-out discipline; only factory-authored framing was edited. Same reconciliation direction as Thread 4.
+
+---
+
+## Thread 6 — `PRRT_kwDOSF9kNM59iF6C`
+
+- **Reviewer:** Copilot
+- **File:line:** `memory/feedback_github_admin_authority_grant_to_loop_agent_2026_04_24.md:90`
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> P1: `GOVERNANCE §31` is cited here as "factory-managed external surfaces", but in `GOVERNANCE.md` item 31 is specifically about Copilot instructions being factory-managed. Please either update this reference to the correct GOVERNANCE rule (and name it accurately) or remove the section number to avoid future readers relying on a wrong citation.
+
+### Reply
+
+> Fixed in d9e2406. Verified GOVERNANCE.md §31 in-tree: it is specifically the "Copilot instructions are factory-managed" clause, not a generic "factory-managed external surfaces" rule. The bullet now reads: "GOVERNANCE — factory-managed external surfaces discipline (the broader pattern; GOVERNANCE §31 itself is specifically the Copilot-instructions case)." This preserves the analogy the original bullet was reaching for (the github-admin grant fits the same shape as factory-managed external surfaces) without misciting §31 as the source of a generic rule.
+
+---
+
+## Thread 7 — `PRRT_kwDOSF9kNM59iF6H`
+
+- **Reviewer:** Copilot
+- **File:line:** `memory/MEMORY.md:6` (OUROBOROS BOOTSTRAP and AUTHORITY GRANT entries — top of index)
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> P1: `memory/MEMORY.md` index entries are expected to be one-line and terse (per `memory/README.md`), but these two new bullets are very long and include a lot of detail that already lives in the linked memory files. Consider shortening each entry to a brief title + 1 short clause, and keep the rest of the detail inside the memory file itself (also avoids embedding references like `docs/AUTHORITY-REGISTRY.md` before that doc exists).
+
+### Reply
+
+> Fixed in d9e2406. Both entries shortened to compact title + date + one-clause body, matching the shape suggested. OUROBOROS BOOTSTRAP entry no longer duplicates the three load-bearing properties or the Cardano double-meaning (those live in the linked memory file). AUTHORITY GRANT entry no longer enumerates the specific PATCH endpoints (those live in the linked memory file too) and no longer pre-references `docs/AUTHORITY-REGISTRY.md` from the index. The detail is preserved in the linked feedback files exactly as before; only the index projection is leaner. Same fix shape as Thread 3 applied to the third long entry.
+
+---
+
+## Thread 8 — `PRRT_kwDOSF9kNM59iF6I`
+
+- **Reviewer:** Copilot
+- **File:line:** `docs/BACKLOG.md:6068` (now line 6135 — protocol-upgrade-negotiation block, "Backwards-compatible" bullet)
+- **Outcome:** FIX
+- **Resolution commit:** `d9e2406`
+
+### Original comment
+
+> Typo: "an ungraded peer" reads like a grading term rather than "not upgraded". Should likely be "an unupgraded peer" (or similar) since this section is about protocol upgrade negotiation.
+
+### Reply
+
+> Fixed in d9e2406 with the reviewer's suggested wording: "an unupgraded peer". The section is about protocol-upgrade negotiation between Zeta peers and unmodified git clients; "unupgraded" matches the protocol-upgrade vocabulary used in the surrounding bullets ("Cold-start", "Warm-state", "Audit-trail").
+
+---
+
+## Drain summary
+
+- **Threads:** 8 unresolved at start, 8 resolved at end.
+- **Outcome distribution:** 8 FIX (every thread).
+- **Rebase:** Clean. Rebased the 5-commit branch onto fresh `origin/main`; no conflicts.
+- **Resolution commit:** `d9e2406` (single fix commit on top of the rebased branch).
+- **Build gate:** N/A — docs+memory-only change.
+- **Auto-merge:** armed pre-drain; expected to land once `required_conversation_resolution` clears.
diff --git a/memory/MEMORY.md b/memory/MEMORY.md
index ea7d34c9..ebf7bb41 100644
--- a/memory/MEMORY.md
+++ b/memory/MEMORY.md
@@ -2,6 +2,9 @@
 
 **📌 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.
 
+- [**OUROBOROS BOOTSTRAP — self-reference meta-thesis; the system bootstraps itself; connection-map work owed before any 2026-04-24 directive implementation; Aaron 2026-04-24**](feedback_ouroboros_bootstrap_self_reference_meta_thesis_2026_04_24.md) — Meta-frame for 2026-04-24 directives in #393/#394/#395.
+- [**AUTHORITY GRANT — github-admin granted to loop-agent durably across sessions; first explicit named-permission grant; Aaron 2026-04-24**](feedback_github_admin_authority_grant_to_loop_agent_2026_04_24.md) — Composes with named-permissions-registry design (iterative Phase 0→5 hardening).
+- [**GIT-AS-DB-INTERFACE + WASM bootstrap zero-requirements — both modes require 0; Aaron 2026-04-24**](feedback_git_interface_wasm_bootstrap_zero_requirements_2026_04_24.md) — Mode 1 = download one binary; Mode 2 = open one tab. Composes with Otto-243 git-native memory-sync precursor + Otto-274 progressive-adoption-staircase Level 0 + blockchain-ingest absorb.
 - [**BLOCKCHAIN INGEST — first-class BTC/ETH/SOL streaming into Zeta's distributed DB; two motivations (Aurora prep + DB stress test); BTC→ETH→SOL priority; NOT fork of bitcoind/geth/solana-labs — on top of Zeta distributed DB; freeloader-detection research required (BTC net_processing.cpp / ETH devp2p+Snap / SOL turbine-shred); upload-side interfaces first-class on par with SQL; Phase 0 research gate + Phase 1 post-install ingest + Phase 2 conditional full-node + Phase 3 cross-chain bridge + Phase 4 UI; additional chains (Cosmos/Polkadot/Cardano/Avalanche/L2s) evaluated later; Otto-275 log-don't-implement; Aaron 2026-04-24**](feedback_blockchain_ingest_btc_eth_sol_first_class_db_support_aurora_prep_2026_04_24.md) — Verbatim directive captured. Phase 0 research gate = read actual client source per chain to map freeloader detection (determines whether Phase 2 upload-side is required to stay in-network). Architecturally on top of Zeta's multi-node primitives (distributed-node support from start). Composes with Aurora substrate + paced-ontology-landing + distributed-consensus-expert + GOVERNANCE §24 + Otto-175c rename (Frontier-UI → kernel-A/B).
 - [**RENAME Starboard → two seed-extension kernels (farm + carpentry) shrink-over-time; KEEP all nautical/Elron research (Otto-237 mention vs adoption); "big bangs at every layer" metaphor liked; 2 Google AI slates received (batch 1 general farm, batch 2 Q/Z algebraic); Siliqua-Core + Zeta-ic Yield + Zanja flagged as notable resonances; naming-expert triage before any rename PR; Otto-275 log-don't-implement; reverses Otto-175c Starboard adoption; Aaron 2026-04-24**](feedback_rename_starboard_to_farm_carpentry_seed_extension_kernels_2026_04_24.md) — Directive verbatim: *"Instead of Starboard lets go with someting farm related and carperntry related since those will be our two seed extenion kernels we can shrink over time..."*. Two kernels, shrink-over-time property, substrate preserved, iterate don't auto-adopt. Carpentry-side slate not yet proposed; future work scope. Composes with Otto-168/170/175/237/244/275.
 - [**Otto-276 NEVER PRAY AUTO-MERGE COMPLETES — when polling a BLOCKED PR, ALWAYS inspect statusCheckRollup + reviewThreads + reviewDecision; "summary says BLOCKED, must be CI" is prayer not diagnosis; RECURRING class (#190 #385 #388); Aaron 2026-04-24**](feedback_never_pray_auto_merge_completes_inspect_actual_blockers_otto_276_2026_04_24.md) — DST "observable state" = check-level detail not summary. Inspect before concluding either success or failure.
diff --git a/memory/feedback_git_interface_wasm_bootstrap_zero_requirements_2026_04_24.md b/memory/feedback_git_interface_wasm_bootstrap_zero_requirements_2026_04_24.md
new file mode 100644
index 00000000..29b4f384
--- /dev/null
+++ b/memory/feedback_git_interface_wasm_bootstrap_zero_requirements_2026_04_24.md
@@ -0,0 +1,236 @@
+---
+name: GIT-AS-DB-INTERFACE + WASM-F#-IN-BROWSER + GIT-AS-STORAGE — two stretch directives 2026-04-24; both modes (tiny-seed AoT exe AND browser-WASM) require ZERO install at user-experience level; bootstrap thesis = both require 0; Mode 1 single-file artifact, Mode 2 open-tab; git-native fits Z-set retraction-native semantics; Otto-275 log-don't-implement; way-back-backlog
+description: Maintainer 2026-04-24 directive. Two related stretch goals filed as way-back-backlog. (1) git-as-first-class-DB-interface — Zeta commands ≈ git commands where semantics align. (2) WASM-F# + git-as-storage-plugin — browser-only bootstrap mode. Maintainer correction: Mode 1 is tiny-seed AoT or single-file JIT (NOT framework-dependent), so BOTH modes require zero install. Bootstrap thesis confirmed.
+type: feedback
+---
+
+## The directives (verbatim)
+
+Maintainer 2026-04-24, first share (low-priority backlog):
+
+> *"we want to have first class git inteface into our
+> database, so our database can handle all / most git
+> command, way backlog."*
+
+Maintainer 2026-04-24, second share (way-back-backlog
+stretch goal):
+
+> *"a storage plugin for our db that saves to git
+> commonds lol. this will let me compile as wasm our f#
+> and run our database enginge in the ui and it calls
+> out to git for the actual operations? Am i dreaming
+> for this second one? We should research it but it's a
+> huge stretch way back backlog for the 2nd one. and
+> just low pritoriy backlog for first one. This complets
+> our bootstrap without requirments really i think? you
+> tell me."*
+
+Maintainer correction 2026-04-24 (after my draft
+assessment characterized Mode 1 as ".NET runtime
+required"):
+
+> *"Mode 1 you remember we are planning tiny seed with
+> AoT and also single file Jit based builds that don't
+> need dotnet"*
+
+Maintainer punchline 2026-04-24:
+
+> *"so both require 0"*
+
+Maintainer follow-up 2026-04-24 (expanding Mode 1):
+
+> *"for mode 1 we want a front end ui like ssms/pgadmin
+> but really designed for us. also we want to have a
+> full git implimentation in f# where we don't even
+> need the git client, we are also the git client and
+> it stores into our database for mode 1. just another
+> interface like SQL"*
+
+Two pieces in the follow-up:
+
+1. **Mode 1 admin UI** — SSMS/pgAdmin-class local
+   management UI for Zeta. Distinct from the
+   web-facing Frontier-UI (kernel-A/kernel-B per the
+   2026-04-24 rename directive). This is the
+   operator/admin desktop-class surface, ships with
+   the Mode 1 single-file binary. Two-UI architecture
+   confirmed: web-facing (Frontier) + local-admin
+   (this).
+2. **Native F# git implementation** — Zeta IS the git
+   client AND server. No external git binary
+   required. Git objects (commit/tree/blob) serialize
+   as Z-set entries with retraction-native semantics.
+   Maintainer framing: *"just another interface like
+   SQL"* — git is one of several first-class protocols
+   on top of Zeta's substrate.
+
+**Symmetric architecture gain:** any Zeta Mode 1
+instance can serve as a git remote for any Zeta Mode 2
+browser client. `git push my-zeta main` = pushing to
+Zeta's DB via Zeta's own git server. The factory
+becomes self-hosting of its own git ecosystem.
+
+Maintainer follow-up 2026-04-24 (after Mode 1 admin UI
++ native F# git impl):
+
+> *"we could use mode 2 as our ui and have it auto
+> netogatie protocol upgrade to a better protocol that
+> git to whatever we want for hight speed communicaiton
+> with out backend i think thats cleans"*
+
+**Mode 2 → Mode 1 protocol-upgrade negotiation.** Mode
+2 (browser WASM UI) opens with git as the
+lowest-common-denominator bootstrap protocol. Once the
+connection establishes and both sides confirm
+capability, negotiate an upgrade to a faster
+Zeta-specific binary protocol for hot-path traffic
+(streaming, low-latency reads, bulk pull/push). Git
+stays as fallback / audit-trail / durable-substrate.
+ALPN-style / HTTP-Upgrade-style pattern.
+
+**Why this is clean:**
+- Cold-start: zero protocol negotiation cost paid
+  until you have a connection.
+- Warm-state: upgraded comm is fast.
+- Backwards-compatible: an actual git client (not a
+  Zeta peer) still works — never asks for upgrade.
+- Audit-trail: durable layer can checkpoint to git
+  on cadence; git history stays canonical.
+
+This combines Mode 2 (browser-only UX) with Mode 1
+(native server) into a coherent client-server
+architecture where the WASM frontend talks to a Mode 1
+backend over an upgraded fast protocol AFTER the
+git-bootstrap handshake. Three architectural slots:
+1. Browser UI (Mode 2 WASM-F#)
+2. Backend server (Mode 1 native F#)
+3. Wire protocol (git → upgraded fast binary)
+
+## The bootstrap thesis (confirmed)
+
+**Both modes require zero install at the user-experience
+level:**
+
+- **Mode 1** — tiny-seed AoT-compiled standalone
+  executable OR single-file JIT-based build. NO .NET
+  preinstall required. Download + run.
+- **Mode 2** — WASM-F# in browser + any git remote
+  for storage. NO executable to download (browser
+  handles WASM); NO server to run.
+
+Both modes are install-free. Browsers and git remotes
+are commodity infrastructure.
+
+## My assessment that Aaron corrected
+
+I drafted the BACKLOG row characterizing Mode 1 as
+"requires .NET runtime + server." That was wrong —
+existing factory planning is explicit that Zeta will
+ship as tiny-seed AoT or single-file JIT. The
+correction lands forward in this memory + the BACKLOG
+row. Future Otto: do NOT recharacterize Mode 1 as
+runtime-required without checking AoT / single-file
+plans first.
+
+## Why this matters
+
+The bootstrap thesis is the **adoption-friction
+collapse**:
+- Mode 1: download one file, run it (commodity-OS only)
+- Mode 2: open a tab (commodity-browser only)
+
+Strong fit with **Otto-274 progressive-adoption-
+staircase Level 0** — "open a tab; no install" is the
+lowest-friction adoption rung the factory has
+articulated, and Mode 1's "download one binary" is the
+SECOND-lowest. Both rungs exist now in the planned
+architecture.
+
+## Why git-as-storage is coherent (not a dream)
+
+The maintainer asked whether the WASM + git-storage
+combination is dreaming. Honest answer: NO, it's a
+coherent stretch.
+
+- **WASM-F# is real** today via **Blazor WebAssembly**
+  — the .NET runtime compiled to WebAssembly, which
+  hosts F# directly. Mode 2's intended approach is
+  Blazor WASM. **Fable** is a distinct option that
+  compiles F# to **JavaScript** (NOT a WebAssembly
+  runtime); it would be the alternative if a JS-target
+  Mode 2 were preferred over .NET-on-WASM. Performance
+  workable for non-hot-path; hot-path needs in-browser
+  cache.
+- **`isomorphic-git`** brings the git protocol to the
+  browser; pairs with WASM-F#.
+- **Z-set semantics fit git's model.** Retractions =
+  `git revert` or branch reset; multi-writer = git's
+  branch-and-merge model (CRDT-friendly under Z-set
+  semantics); audit trail = git history natively.
+- **Otto-243 git-native memory-sync** is the precursor
+  pattern — already proves substrate-level fit.
+
+**The wild bit isn't WASM-F# or git in the browser —
+both exist.** It's the assertion that **git ops are
+fast enough for DB hot-path reads**. They aren't. Mode
+2 architecture must be "browser viewer + git-backed
+durable substrate; hot-path lives in browser memory" —
+NOT "every read hits git."
+
+## Real risk: write-amplification
+
+Every Zeta write becomes a git commit. High-throughput
+streams (e.g. blockchain ingest, see the parallel
+2026-04-24 BTC/ETH/SOL absorb) would saturate any git
+remote. Mode 2 suits **low-volume workloads**:
+per-user notebooks, factory memory sync, configuration,
+knowledge bases. Mode 1 stays load-bearing for
+production / streaming.
+
+## Phased approach (when activated)
+
+For the WASM + git-storage row:
+
+- **Phase 0** — feasibility research: WASM-F# runtime
+  cost, isomorphic-git API surface, write batching
+  strategies, hot-path cache shape. Output:
+  `docs/research/wasm-fsharp-git-storage-feasibility.md`.
+- **Phase 1** — POC: minimal in-browser Zeta with
+  git-backed Z-set storage on a single test workload
+  (personal notebook). No streaming, no multi-user.
+- **Phase 2** — multi-user via git branches; merge
+  semantics for concurrent writes; conflict resolution
+  UX.
+- **Phase 3** — production-mode hardening: write
+  batching, hot-path cache eviction, server-fallback
+  for high-throughput.
+
+## Composes with
+
+- **Otto-243** (git-native memory-sync precursor)
+- **Otto-274** (progressive-adoption-staircase — both
+  modes are Level-0 candidates)
+- **Otto-275** (log-don't-implement; this memory + the
+  two BACKLOG rows are the capture, NOT the kickoff)
+- **Mode 1 plans** (tiny-seed AoT + single-file JIT —
+  the existing planning that I forgot and Aaron
+  corrected; future Otto: check before
+  recharacterizing)
+- **Z-set retraction-native semantics** (the algebraic
+  fit that makes git-backed storage coherent)
+- **2026-04-24 blockchain ingest absorb** (companion
+  directive in same session — high-throughput case
+  where Mode 1 is required)
+
+## Future Otto reference
+
+When tempted to characterize Mode 1 as "runtime-
+required": STOP. Tiny-seed AoT + single-file JIT are
+the existing planning. Both modes require ZERO install.
+The bootstrap thesis is THE thesis — it's not
+qualified.
+
+When reviewing whether the WASM + git-storage is a
+dream: it's not. Cite this memory + Otto-243. The
+performance question is the real one — write
+amplification is the actual gate.
diff --git a/memory/feedback_github_admin_authority_grant_to_loop_agent_2026_04_24.md b/memory/feedback_github_admin_authority_grant_to_loop_agent_2026_04_24.md
new file mode 100644
index 00000000..c2effad2
--- /dev/null
+++ b/memory/feedback_github_admin_authority_grant_to_loop_agent_2026_04_24.md
@@ -0,0 +1,108 @@
+---
+name: AUTHORITY GRANT — github admin granted to loop-agent (Otto) by maintainer 2026-04-24; durable across sessions; covers admin-level GitHub operations (branch protection, repo settings, ruleset management); first explicit named-permission grant; future-self can run admin-level gh api commands without per-call permission prompts; harness-level deny may still trigger and require maintainer to add a Bash permission rule
+description: Maintainer 2026-04-24 explicitly granted github-admin authority to the loop-agent. Save as durable per maintainer directive. Used 2026-04-24 to update branch-protection required-checks for #375 unblock. Composes with the BACKLOG row for the named-permissions-registry design (per-contributor scoped permissions, iterative hardening).
+type: feedback
+---
+
+## The grant (verbatim)
+
+Maintainer 2026-04-24:
+
+> *"i give you github admin"*
+
+Then immediately after I asked whether to durabilize it:
+
+> *"save my permission as durable yes"*
+
+Plus directive on the broader design:
+
+> *"we shoud probbably have a list of named permissions
+> you might need and thier names and descriptions and
+> which ones are active for which contributro. this in
+> not super safe yet but we can nake it more safe over
+> time."*
+
+## Scope of the grant
+
+**github-admin** (named permission, this entry's
+inaugural use):
+
+- Branch protection PATCH (required status checks,
+  required reviews, enforce admins, admin overrides).
+  Verified working 2026-04-24 by updating
+  `repos/Lucent-Financial-Group/Zeta/branches/main/protection/required_status_checks`
+  to migrate from `build-and-test (ubuntu-22.04)` to
+  the new 7-context list, unblocking PR #375.
+- Repo settings PATCH (visibility, default branch,
+  feature flags, security/SSH/Pages).
+- Ruleset CRUD if needed (rulesets API).
+- Workflow dispatch + cron triggers via `gh workflow run`.
+- Branch-protection-related ops via `gh api`.
+
+**NOT in scope** (separate grants required):
+- Org-level admin (org settings, org-level rulesets).
+- Repo deletion / transfer.
+- Member management.
+- Force-push to main.
+- Bypass branch protection on a single PR.
+
+## Used 2026-04-24
+
+First use: PATCH `required_status_checks` on
+`Lucent-Financial-Group/Zeta` `main` branch. Replaced
+[`build-and-test (ubuntu-22.04)`, 4 lint contexts] with
+[`build-and-test (macos-26)`, `build-and-test
+(ubuntu-24.04)`, `build-and-test (ubuntu-24.04-arm)`,
+4 lint contexts]. Unblocked PR #375 which had been
+wedged for hours on the chicken-and-egg problem (PR
+renamed matrix; live protection still required old
+name).
+
+## Harness-level deny risk
+
+Even with this grant, harness-level Bash permission
+checks may still deny specific gh api PATCH calls
+because the harness scans for "Security Weaken /
+Permission Grant on shared infrastructure" patterns.
+**The grant is at the maintainer-policy layer; the
+harness is a separate enforcement layer.** When the
+harness denies despite this grant being in place:
+
+1. Re-attempt with explicit-language confirmation in
+   the recent maintainer message (the harness may
+   require both the grant AND a recent
+   explicit-authorization message).
+2. If still denied, paste the exact command for the
+   maintainer to run themselves.
+3. If a pattern repeats often, ask the maintainer to
+   add a Bash permission rule to settings.
+
+Not a bug — defense in depth.
+
+## Composes with
+
+- **BACKLOG row** for the named-permissions-registry
+  design (per-contributor scoped permissions, iterative
+  hardening).
+- **Otto-244 no-symlinks** (cross-cutting authority
+  pattern — different domain but same "named-policy
+  with explicit scope" shape).
+- **GOVERNANCE** — factory-managed external surfaces
+  discipline (the broader pattern; GOVERNANCE §31
+  itself is specifically the Copilot-instructions case).
+- **Aminata threat-model** — any expansion of granted
+  permissions deserves an adversarial review pass.
+
+## Future Otto reference
+
+When attempting an admin-level GitHub operation: cite
+this grant in the action's commit message or
+PR-description so the audit trail is clear. Don't
+expand scope silently — if a new admin op needs
+authority that isn't in the listed scope above, ask
+the maintainer first.
+
+If the harness blocks despite this grant being on
+file, retry once with maintainer's explicit
+re-authorization in the recent context window; if that
+fails, paste the command for them to run.
diff --git a/memory/feedback_ouroboros_bootstrap_self_reference_meta_thesis_2026_04_24.md b/memory/feedback_ouroboros_bootstrap_self_reference_meta_thesis_2026_04_24.md
new file mode 100644
index 00000000..ec88c011
--- /dev/null
+++ b/memory/feedback_ouroboros_bootstrap_self_reference_meta_thesis_2026_04_24.md
@@ -0,0 +1,147 @@
+---
+name: OUROBOROS BOOTSTRAP — meta-thesis 2026-04-24; the system bootstraps itself; Zeta is built using Zeta; native-F#-git is git-impl-stored-in-git-impl; factory uses its own substrate; "exact integrations and connections to make sure we can do it right"; Cardano pedagogy double-meaning preserved; meta-frame for all 2026-04-24 same-day directives in #395 cluster
+description: Maintainer 2026-04-24 directive — Ouroboros bootstrapping. The factory's deep architectural property: Zeta substrate boots itself. Native-F#-git impl stores its own commits as Z-sets. Factory's permission registry tracks itself. Memory-sync uses memory-sync. Exact integrations + connections must be modeled correctly. Composes with all 2026-04-24 directives (bootstrap thesis, native git, protocol upgrade, UI split, permissions, blockchain ingest). Double meaning preserved — Cardano's Ouroboros consensus is a pedagogical reference too.
+type: feedback
+---
+
+## The directive (verbatim)
+
+Maintainer 2026-04-24:
+
+> *"oraborus bootstraping exact integrations and
+> connections and all that to make sure we can do it
+> right"*
+
+## What Ouroboros bootstrapping means here
+
+The snake eats its own tail. In bootstrap context: **the
+system uses its own substrate to bootstrap itself**.
+Concrete instances within Zeta:
+
+- **Native-F# git impl stores its own commits as Z-sets
+  in its own database.** When Zeta's git server commits
+  changes to its own source code, the resulting commit
+  objects land in the same Z-set tables that any other
+  git operation would use. The substrate that defines
+  the system stores the system's definition.
+- **Factory's permission registry tracks itself.** The
+  named-permissions-registry (`docs/AUTHORITY-REGISTRY.md`)
+  documents which permissions are granted; the
+  registry's own creation requires the maintainer's
+  authority; the registry tracks that grant in itself.
+- **Memory-sync uses memory-sync.** The git-native
+  memory-sync mechanism (Otto-243) syncs the memory
+  files that document how memory-sync works.
+- **Mode 2 hosts the factory dashboard that operates
+  on Mode 2.** The factory ops dashboard runs in Mode
+  2 WASM and shows the state of Mode 2 development.
+- **Bootstrap thesis is itself a Z-set retraction** —
+  if we change our bootstrap mode, the change lands
+  as a retraction-native delta in our own substrate.
+- **Test using ourselves.** The blockchain-ingest
+  absorb's "DB stress test" motivation tests Zeta by
+  using Zeta to ingest blockchains.
+
+## Why this matters
+
+Ouroboros bootstrapping has THREE properties that pure
+self-reference doesn't:
+
+1. **Provenance is closed under the substrate.** Every
+   piece of state the system manages is also a piece
+   of state the system can prove itself responsible
+   for. No "external authority" gap.
+2. **Every integration is testable from the inside.**
+   If Zeta speaks git natively AND uses git for its
+   own source control, every code change exercises the
+   git interface. Integration tests are continuous.
+3. **Self-consistency is a load-bearing invariant.**
+   The system can't drift from its own substrate
+   because the substrate IS the system. Drift would
+   require the system to forget its own definition —
+   which is detectable.
+
+## Maintainer's directive applied
+
+> *"exact integrations and connections and all that to
+> make sure we can do it right"*
+
+Translation: when designing each piece of the
+2026-04-24 cluster (Mode 1 admin UI, native F# git,
+protocol upgrade, WASM, permissions registry, UI
+split, blockchain ingest), the integration MAP must be
+explicit. We can't hand-wave "Mode 2 talks to Mode 1
+somehow" or "the UI shows the factory state somehow."
+The exact wire shapes, dependency arrows, and
+self-reference closures must be drawn before
+implementation.
+
+This is meta-architectural work: produce a connection
+map that shows how each piece references every other
+piece, and prove the closure is a true Ouroboros (no
+external break in the loop).
+
+## Cardano pedagogy double-meaning
+
+Cardano's consensus protocol is also called Ouroboros
+(the most formally-verified deployed PoS protocol; see
+the blockchain-ingest absorb where Cardano was flagged
+as Phase 3+ pedagogy candidate). The naming overlap is
+PRESERVED — when the blockchain-ingest work activates
+and Cardano comes into scope, the Ouroboros-protocol
+research will reinforce the Ouroboros-bootstrap thesis
+linguistically + conceptually. Same word, same
+self-referential property at different levels.
+
+## The connection map work (BACKLOG row owed)
+
+When this row activates: produce
+`docs/research/ouroboros-bootstrap-connection-map-2026.md`
+that diagrams every 2026-04-24 directive's integration
+points. Mandatory inputs: the rows added to BACKLOG.md
+in the same session (#393 rename, #394 blockchain
+ingest, #395 cluster — git interface + WASM + admin
+UI + native git + protocol upgrade + permissions
+registry + UI split).
+
+Output shape: a directed graph where nodes are
+factory components (Mode 1 binary, Mode 2 WASM,
+native git impl, admin UI, factory ops dashboard,
+Frontier-UI, permission registry, memory-sync, etc.)
+and edges are explicit integration contracts (wire
+protocols, file formats, authority dependencies). The
+self-loops in the graph ARE the Ouroboros closures —
+explicitly identify them.
+
+## Composes with
+
+- **Bootstrap thesis** (2026-04-24): both modes
+  require 0; the Ouroboros frame is WHY zero is
+  achievable (each mode's requirements are met by
+  another part of the same system).
+- **Native F# git implementation** (#395): stores its
+  own commits.
+- **Mode 2 → Mode 1 protocol upgrade** (#395): the
+  upgrade is negotiated by Zeta talking to Zeta.
+- **Named-permissions registry** (#395): registry
+  tracks the authority for its own creation.
+- **Mode 2 UI architecture split** (#395): factory
+  ops dashboard surfaces the factory's own state.
+- **Blockchain ingest** (#394): tests Zeta's DB by
+  using Zeta to ingest external chains; Phase 3
+  cross-chain bridge is Z-set composition over Z-sets.
+- **Otto-243 git-native memory-sync** (precursor):
+  early Ouroboros instance; we already do it.
+- **Otto-275 log-don't-implement**: this memory + the
+  BACKLOG row are the capture; the connection-map
+  research is owed but not started.
+
+## Future Otto reference
+
+When designing or reviewing factory architecture: ASK
+"is this an Ouroboros closure?" If yes, it's natural
+and load-bearing. If no, ASK why — does the external
+break introduce trust assumptions or drift risk that
+could be eliminated by closing the loop? The
+maintainer's frame is that closures should be
+explicit; gaps require justification.