ng-eventually/.tasks/done/T01.b-what-the-orm-offers-for-writing-and-deleting.md

id, title, parent, depends_on, created, claimed_by, claimed_at, blocked

id	title	parent	depends_on	created	claimed_by	claimed_at	blocked
T01.b	What the ORM offers for writing and deleting, and what the three remaining symbols are	T01		2026-09-16	null	null	false

Description

Reconnaissance, not implementation. Piece 2 of the parent task rests on a fact nobody has established: upstream's shape for deletion. Specifying a wrapper before knowing it is how this project has invented before. This child establishes the facts and proposes the arbitrations; T01.e implements against its `## Result

Done: reconnaissance only, no product code. Findings: .project/concepts/app-contract/knowledge_what-the-orm-writes-and-deletes-upstream.md (nextgraph-rs read at 213338f697df15afc086c042f4bab1bffd01aa04).

1. Deletion — LEVEL 3 answers and is fully wired. DeepSignalSet.delete → {op:"remove", path:"/<graph>|<subject>"} → deepPatchesToWasm → ng.graph_orm_update → Verifier::orm_frontend_update → SparqlBuilder::remove_object, which deletes only the SHAPE's declared predicates. No document deletion exists at any level. Nothing to invent.
2. getObjects(shapeType, scope: Scope|string) returns a detached deepClone (mutations reach nothing); insertObject(shapeType, object) throws without @graph. docs/api-contract.md §6 checked — accurate, no drift.
3. Proposals (owner decides): publish OrmSubscription as-is — the read filter applies to signalObject exactly as surface/use-shape.ts already does. Do NOT publish DiscreteOrmSubscription (JSON-CRDT, no @graph, so a per-document filter has nothing to read) nor ngSession (hands the caller the SDK handle and the session — the rule's own tell).
4. useShape live: MEASURED, still broken, and the bug leaf's mechanism was FALSE. The name resolves; the deployed orm_start_graph takes config BEFORE the callback, so the published five-argument client lands its callback there. The deployment is AHEAD of the pinned @ng-org/*, not behind. Bug leaf rewritten, still open/major — T01.d's blocker STANDS.

Open question for the owner: the consumer reports ngSet.delete() "works again", yet no ORM subscription can start against this deployment. Which broker were they on?

Surprises: ORM writes go through graph_orm_update, NOT ng.sparql_update — so surface/ng-proxy.ts's emulated write guard never sees an ORM add or delete (VERIFIED). @ng-org/orm is an optional peer with no lock entry; only the new runner imports it.

Files: packages/polyfill/e2e/orm-live-read.ts, packages/polyfill/e2e/orm-live-entry.ts (new); .project/concepts/app-contract/{knowledge_what-the-orm-writes-and-deletes-upstream.md,bug_useshape-live-read-needs-a-newer-broker.md,_overview.md}; .project/concepts/e2e-harness/{_overview.md,knowledge_what-each-suite-judges.md}; _debt.md reconciled and deleted.

Gate: bun test → 397 pass, 0 fail. tsc -p packages/polyfill/tsconfig.json → exit 0. tsc -p packages/polyfill/e2e/tsconfig.json → exit 0. concept/lint.py → 0 ERROR. e2e: ══ Polyfill e2e summary: 42 passed, 0 failed, 42 total — batch 4.0 min, slowest cold sync 30s ══ (unchanged) and ══ ORM live-read summary: 2 passed, 4 failed, 6 declared — run 1.7 min ══ (the new measurement; non-zero exit is its verdict on the deployment).

Follow-ups: add @ng-org/orm to packages/polyfill devDependencies so the new runner survives a clean bun install; docs/api-contract.md says nothing about deletion or graph_orm_update — T01.e's call.