neuron-technologies/neuron
3
0
Fork 0
Code Issues 44 Pull Requests 7 Actions Packages Projects Releases Wiki Activity

[P0] Claim 17's pull-then-push is half-built: the soul never PUSHES — every memory written through the mind dies on restart #117

New Issue
Closed
opened 2026-08-06 21:00:25 +00:00 by tim.lingo · 0 comments
tim.lingo commented 2026-08-06 21:00:25 +00:00
Member
Copy Link
Copy Source

30-second version: your Engram provisional claim 17 specifies a pull-then-push delta sync. The soul implements the pull and never the push. Every memory written through :7770 lives in RAM and is shed on restart. Spec is written, the build is offered, and five decisions are yours (§11).

What I need from you — pick one

  • A — Ratify the spec; we build it, you land it. (recommended) Finding 3 of container-migration-findings-for-will.md (2026-07-05) said "your toolchain; we can't rebuild soul from source." That is no longer true — this machine has built, run and E2E-verified the soul from source since 2026-06-09. Authority stays yours; capability is no longer the blocker.
  • B — You build it. Say so and we stand down and stop touching it.
  • C — It's intended. If soul-side writes are meant to be session-scoped, say so and we will stop treating it as a defect, make the CLI outbox permanent, and correct our docs.

Spec: neuron-technologies/docs PR — specs/SPEC-soul-write-through-2026-08-06.md. Spec only, no code written.

First, the good news — your persist fix works off your machine

#98's fix (dc39a61 + 8f8ccc945) was installed and verified live on Tim's machine today (2026-08-06, Tim-approved). Your dist/engram artifact, byte-identical, swapped in:

  • Isolated 2-leg proof was discriminating: old binary sheds a write across kill -9; yours persists it.
  • Live gate passed — canonical snapshot advanced Aug 3 09:12 → Aug 6 15:09 on write; gate node survived a service restart.
  • ~3 MB of writes stuck in engram RAM since Aug 3 were recovered to disk (139.3 MB → 142.2 MB).

Tim's instance had been running your pre-fix Jul-20 binary — that was the whole of the "recurrence" reported on #98 08-03/08-05. Not a regression of yours.

The defect that remains — in your own words

Your statement Where Reality on the running system
"when ENGRAM_URL is set the HTTP Engram owns persistence — the soul must NEVER write to the local snapshot" neuron/soul.el:571-573, commit 8b692e4 Obeyed. The soul never saves.
"the delta synchronization protocol proceeds in a pull-then-push sequence … such that both instances converge toward the union" Engram provisional 06-claims.md claim 17 Pull only. awareness.el:588-606 GETs /api/sync every SOUL_REFRESH_MS (600 s) and engram_load_merges it. No push exists anywhere in the soul.
"Reads must never write the canonical; writes must always persist it" el/engram/src/server.el:90-98 (8f8ccc945) Satisfied inside engram — and irrelevant to writes that never reach engram.
"in HTTP-engram mode the server owns persistence and the soul's in-process graph dies with the process — the local create above is invisible to the next boot … Mirror the persona write-back pattern" memory.el:214-220 (fb0bb55, 2026-07-24) You applied it to two nodes — persona (soul.el:275-291) and boot counter. ~15 engram_node_full sites in neuron-api.el plus mem_store (memory.el:5-28) still write RAM-only.

Proof (measured live 2026-08-06, read-only, not inferred)

POST :7770/api/neuron/memory  -> {"id":"856c033a-…","ok":true}
POST :7770/api/neuron/recall  -> returns the node          # soul RAM: present
GET  :8742/api/nodes/856c033a -> {}                        # owner of record: absent
grep canonical snapshot.json  -> soul-written probes: 0    engram-written probes: 1

The soul's copy is a superset (what it pulled + its own writes); engram's is a subset. Engram is the writer of the canonical file, so each engram write persists the subset — and the soul reads that file at boot. The delta is shed on every restart. Demonstrated on #98 on 07-22 (a read-back-verified save vanished on respawn) and again today.

Why this is design-level, not operational

  • "Session amnesia" is one of the three failure modes the CCR provisional exists to eliminate (Background ¶3).
  • "survives process restart" is claim language — Engram 06-claims.md claim 50.
  • CGI claim 12 requires post-seed writes intercepted at the write layer of the persistent graph for provenance tagging, untagged writes rejected. A RAM-only write is unaudited, not merely unsaved.
  • engram-layered claim 25 defines state leaving "no trace in the persistent knowledge graph" as a session layer. Today's memories are structurally session-layer content wearing identity labels.

A second, smaller thing this exposed (ours-proposed, your call)

mem_store prints [memory] write verified after a read-back that queries the in-process graph (memory.el:20-26); api_persisted does the same (neuron-api.el:90-93). In HTTP mode those receipts are true-in-RAM and false-on-disk — Tim's soul logged ~115 000 write verified lines while the canonical file sat frozen for three days. Consistent with your read-back doctrine (494d973, 8b692e4), but you have never said your read-backs are RAM-scoped, so we flag it as our inference. Cross-ref RECEIPT-CONTRACT-2026-07-22.md, also still awaiting your ratification.

What we did NOT do

No soul code written. No change to who owns the file — this obeys soul.el:571-573 and does not relitigate ownership. No periodic-flush workaround (it would recreate the read-route-writes-canonical antipattern you deleted in dc39a61; the soul's only current path to the canonical is GET /api/graph/edges → engram_save, routes.el:383-394, which violates both halves of your invariant at once — flagged, untouched). No dual-write (your canon: "never dual-write in app code"). Interim on our side is the CLI outbox, which your canon names as the sanctioned pattern for exactly this gap.

History — why this is a bump, not a new report

This was filed to you as Finding 3 in docs/specs/container-migration-findings-for-will.md (2026-07-05). You accepted Finding 1 of that same document by name in f78da81. Finding 3 has no reply, commit, or comment. This issue adds what it lacked: your own claim-17 framing, live proof, a written spec, a gate design, and an offer to build it.

Refs: #92 (identity-spine repair, still yours), #98 (persist backbone — your fix, now verified off your machine), #89.

> **30-second version:** your Engram provisional **claim 17** specifies a **pull-then-push** delta sync. The soul implements the **pull** and **never the push**. Every memory written through `:7770` lives in RAM and is shed on restart. Spec is written, the build is offered, and **five decisions are yours** (§11). ## What I need from you — pick one - [ ] **A — Ratify the spec; we build it, you land it.** *(recommended)* Finding 3 of `container-migration-findings-for-will.md` (2026-07-05) said *"your toolchain; we can't rebuild soul from source."* **That is no longer true** — this machine has built, run and E2E-verified the soul from source since 2026-06-09. Authority stays yours; capability is no longer the blocker. - [ ] **B — You build it.** Say so and we stand down and stop touching it. - [ ] **C — It's intended.** If soul-side writes are *meant* to be session-scoped, say so and we will stop treating it as a defect, make the CLI outbox permanent, and correct our docs. **Spec:** `neuron-technologies/docs` PR — `specs/SPEC-soul-write-through-2026-08-06.md`. Spec only, no code written. --- ## First, the good news — your persist fix works off your machine `#98`'s fix (`dc39a61` + `8f8ccc945`) was **installed and verified live on Tim's machine today** (2026-08-06, Tim-approved). Your `dist/engram` artifact, byte-identical, swapped in: - Isolated 2-leg proof was **discriminating**: old binary sheds a write across `kill -9`; yours persists it. - **Live gate passed** — canonical snapshot advanced Aug 3 09:12 → Aug 6 15:09 on write; gate node survived a service restart. - **~3 MB of writes stuck in engram RAM since Aug 3 were recovered to disk** (139.3 MB → 142.2 MB). Tim's instance had been running your **pre-fix Jul-20 binary** — that was the whole of the "recurrence" reported on `#98` 08-03/08-05. Not a regression of yours. ## The defect that remains — in your own words | Your statement | Where | Reality on the running system | |---|---|---| | "when ENGRAM_URL is set the HTTP Engram **owns persistence** — the soul must NEVER write to the local snapshot" | `neuron/soul.el:571-573`, commit `8b692e4` | **Obeyed.** The soul never saves. | | "the delta synchronization protocol proceeds in a **pull-then-push sequence** … such that both instances converge toward the union" | Engram provisional `06-claims.md` **claim 17** | **Pull only.** `awareness.el:588-606` GETs `/api/sync` every `SOUL_REFRESH_MS` (600 s) and `engram_load_merge`s it. No push exists anywhere in the soul. | | "Reads must never write the canonical; **writes must always persist it**" | `el/engram/src/server.el:90-98` (`8f8ccc945`) | Satisfied **inside engram** — and irrelevant to writes that never reach engram. | | "in HTTP-engram mode the server owns persistence and the soul's in-process graph dies with the process — the local create above is invisible to the next boot … **Mirror the persona write-back pattern**" | `memory.el:214-220` (`fb0bb55`, 2026-07-24) | You applied it to **two** nodes — persona (`soul.el:275-291`) and boot counter. ~15 `engram_node_full` sites in `neuron-api.el` plus `mem_store` (`memory.el:5-28`) still write RAM-only. | ## Proof (measured live 2026-08-06, read-only, not inferred) ``` POST :7770/api/neuron/memory -> {"id":"856c033a-…","ok":true} POST :7770/api/neuron/recall -> returns the node # soul RAM: present GET :8742/api/nodes/856c033a -> {} # owner of record: absent grep canonical snapshot.json -> soul-written probes: 0 engram-written probes: 1 ``` The soul's copy is a **superset** (what it pulled + its own writes); engram's is a **subset**. Engram is the writer of the canonical file, so each engram write persists the subset — and the soul reads that file at boot. **The delta is shed on every restart.** Demonstrated on `#98` on 07-22 (a read-back-verified save vanished on respawn) and again today. ## Why this is design-level, not operational - **"Session amnesia"** is one of the three failure modes the CCR provisional exists to eliminate (Background ¶3). - **"survives process restart"** is *claim language* — Engram `06-claims.md` claim 50. - **CGI claim 12** requires post-seed writes intercepted **at the write layer of the persistent graph** for provenance tagging, untagged writes rejected. A RAM-only write is **unaudited**, not merely unsaved. - **`engram-layered` claim 25** defines state leaving "no trace in the persistent knowledge graph" as a **session layer**. Today's memories are structurally session-layer content wearing identity labels. ## A second, smaller thing this exposed (ours-proposed, your call) `mem_store` prints `[memory] write verified` after a read-back that queries the **in-process** graph (`memory.el:20-26`); `api_persisted` does the same (`neuron-api.el:90-93`). In HTTP mode those receipts are true-in-RAM and false-on-disk — Tim's soul logged **~115 000** `write verified` lines while the canonical file sat frozen for three days. Consistent with your read-back doctrine (`494d973`, `8b692e4`), but **you have never said your read-backs are RAM-scoped**, so we flag it as our inference. Cross-ref `RECEIPT-CONTRACT-2026-07-22.md`, also still awaiting your ratification. ## What we did NOT do No soul code written. No change to who owns the file — this obeys `soul.el:571-573` and does not relitigate ownership. No periodic-flush workaround (it would recreate the read-route-writes-canonical antipattern you deleted in `dc39a61`; the soul's only current path to the canonical is `GET /api/graph/edges` → `engram_save`, `routes.el:383-394`, which violates both halves of your invariant at once — flagged, untouched). No dual-write (your canon: *"never dual-write in app code"*). Interim on our side is the CLI outbox, which your canon names as the sanctioned pattern for exactly this gap. ## History — why this is a bump, not a new report This was filed to you as **Finding 3** in `docs/specs/container-migration-findings-for-will.md` (2026-07-05). You accepted **Finding 1** of that same document by name in `f78da81`. Finding 3 has no reply, commit, or comment. This issue adds what it lacked: your own claim-17 framing, live proof, a written spec, a gate design, and an offer to build it. Refs: `#92` (identity-spine repair, still yours), `#98` (persist backbone — your fix, now verified off your machine), `#89`.
tim.lingo added the P0BETA-CRITICAL labels 2026-08-06 21:00:25 +00:00
will.anderson was assigned by tim.lingo 2026-08-06 21:00:27 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BETA-CRITICAL
On the beta critical path — must resolve before ship
 blocks-public-beta
Must be fixed before any public beta
 HELD
Blocked pending an external decision (counsel / dual sign-off)
 ORTHOGONAL
Parallel workstream (testing/hardening) — safe to assign off critical path
 P0
Drop-everything severity
 POST-BETA
Important but not blocking the beta ship
 security
Security vulnerability
No labels BETA-CRITICAL P0
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
andre.almeida (Andre Almeida) tim.lingo (Tim Lingo) will.anderson (Will Anderson)
No Assignees will.anderson
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: neuron-technologies/neuron#117
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?