diff --git a/‎.changeset/tidy-moons-repeat.md‎
Lines changed: 42 additions & 0 deletions b/‎.changeset/tidy-moons-repeat.md‎
Lines changed: 42 additions & 0 deletions
diff --git a/‎packages/metadata-protocol/src/protocol.bulk-record-not-found.test.ts‎
Lines changed: 163 additions & 0 deletions b/‎packages/metadata-protocol/src/protocol.bulk-record-not-found.test.ts‎
Lines changed: 163 additions & 0 deletions
diff --git a/‎packages/metadata-protocol/src/protocol.ts‎
Lines changed: 60 additions & 2 deletions b/‎packages/metadata-protocol/src/protocol.ts‎
Lines changed: 60 additions & 2 deletions
@@ -0,0 +1,42 @@
+---
+'@objectstack/metadata-protocol': patch
+---
+
+`POST /api/v1/data/{object}/batch` with `operation: "delete"` stops reporting a deletion it
+did not perform.
+
+This is the third and last of the by-id delete doors to read the engine's answer — the
+single-record `DELETE` and `deleteMany` already do. Each row of the batch answered
+`success: true` for every engine result that was not the driver contract's `false`. The
+`false` arm — "no row matched" — has reported honestly since #4435 and #5088; the other
+ending had not: a row that MATCHED and was deliberately NOT removed was counted in
+`succeeded` and reported as deleted, byte-identical to a real deletion.
+
+`sys_permission_set` is the shipped shape of it. Deleting a package-declared set is an
+ADR-0005 RESET: the overlay tombstones and the record re-projects to the declared body
+instead of vanishing. That behaviour is unchanged and deliberate — what was wrong is the
+answer, and on a security-configuration write it told an operator a permission set was gone
+while it was still being enforced.
+
+`IDataEngine.delete` declares `Promise<boolean | number>` — the driver boolean for a by-id
+write, a count of rows removed otherwise — so a numeric zero is the one value that positively
+means the record is still there. The per-row `success` now reads that count instead of being
+a literal.
+
+On the wire, for one row of a `delete` batch:
+
+- removed — `success: true`, counted in `succeeded` (unchanged);
+- matched but not removed — `success: false`, counted in `failed`, and no `errors[]` entry:
+  a surviving record is an outcome, not a fault, and this envelope's two per-row codes
+  (`ROLLED_BACK`, `NOT_ATTEMPTED`) both describe a row that never ran;
+- unknown id — `success: false` with `errors[0].code: RECORD_NOT_FOUND` (unchanged);
+- an off-contract `undefined` from a third-party driver keeps its #4435 reading.
+
+Because `succeeded` and `failed` partition `results`, a surviving row also makes the
+request-level `success` false, and an `atomic` batch containing one now rolls back rather
+than committing under a response that called every row deleted. A non-atomic batch is not
+stopped by it: nothing was thrown, so the `continueOnError` stop does not apply and the
+remaining records are still attempted. `returnRecords: false` keeps `success`, so the honest
+value survives that projection too.
+
+Clause-②: no
@@ -424,6 +424,169 @@ describe('[#5088] batchData delete — the driver`s return decides, as in delete
     });
 });
 
+describe('[#19433] batchData delete — a row that MATCHED and was deliberately NOT removed', () => {
+    /**
+     * The THIRD by-id delete door, and the last one still pushing the literal.
+     * The single-record face (#19306) and `deleteManyData` (#19412) both learned
+     * to read the engine's answer; this branch — "the OTHER by-id bulk delete,
+     * ten lines from it", as its own comment calls it — kept `success: true` for
+     * every result that was not the driver contract's `false`.
+     *
+     * `IDataEngine.delete` declares `Promise<boolean | number>`
+     * (`packages/spec/src/contracts/data-engine.ts`), and `isDeleteResultShape`
+     * admits the number arm at the ADR-0112 hook gate, so an `afterDelete`
+     * handler — or a non-ObjectQL engine — may legally answer `0` today. A
+     * numeric zero is the one value that positively means "the row is still
+     * there", which is what a package-declared `sys_permission_set` delete is:
+     * an ADR-0005 RESET, where the overlay tombstones and the record re-projects
+     * to the declared body instead of vanishing.
+     *
+     * Measured on the unfixed base for this door, one record:
+     *
+     *   `true` / `1` / `0` / `undefined` -> `success: true`, `succeeded: 1`
+     *   `false` -> `success: false` + `RECORD_NOT_FOUND` (#5088, unchanged)
+     *
+     * The `0` column is the lie: the row matched, the write ran, the record
+     * survived, and the envelope was byte-identical to a real deletion.
+     */
+
+    /**
+     * A `makeStoreEngine` whose delete speaks the COUNT arm instead of the
+     * harness's `{ deleted: 1 }`: an unknown id keeps the contract's `false`,
+     * `survivor` matches and is deliberately kept (`0`), everything else really
+     * goes (`1`). Same store, so `atomic` rollback is still observed on rows.
+     */
+    function makeCountingEngine(survivor: string) {
+        const t = makeStoreEngine();
+        t.engine.delete = vi.fn(async (_object: string, options?: any) => {
+            assertEngineDeleteDispatch(options);
+            const id = options?.where?.id;
+            if (!t.rows.has(id)) return false;
+            if (id === survivor) return 0;
+            t.rows.delete(id);
+            return 1;
+        });
+        return t;
+    }
+
+    it('the row is NOT reported as a deletion, and gets no `errors[]` entry', async () => {
+        const t = makeCountingEngine('t1');
+        const p = new ObjectStackProtocolImplementation(t.engine);
+
+        const res: any = await p.batchData({
+            object: 'showcase_task',
+            request: { operation: 'delete', records: [{ id: 't1' }] },
+        } as any);
+
+        // Pre-#19433: { success: true, succeeded: 1, failed: 0, results: [{ success: true }] }.
+        expect(res).toMatchObject({ success: false, operation: 'delete', total: 1, succeeded: 0, failed: 1 });
+        expect(res.results).toHaveLength(1);
+        expect(res.results[0]).toMatchObject({ id: 't1', success: false, index: 0 });
+        // NOT the not-found row. A surviving record and a record that never
+        // existed are opposite facts about the same id, and a caller branching
+        // on `errors[0].code` must not read one as the other. A surviving row
+        // is an OUTCOME, not a fault; this envelope's two per-row codes
+        // (`ROLLED_BACK`, `NOT_ATTEMPTED`) both describe a row that never ran.
+        expect(res.results[0].errors).toBeUndefined();
+        // And the record really is still there — that is what `0` asserted.
+        expect(t.rows.has('t1')).toBe(true);
+        expect(t.engine.delete).toHaveBeenCalledTimes(1);
+    });
+
+    it('CONTROL: a positive count still reports a deletion', async () => {
+        // Without this leg the pin above can pass vacuously — `deleted !== 0`
+        // must not collapse into "a number is never a deletion".
+        const t = makeCountingEngine('none_of_them');
+        const p = new ObjectStackProtocolImplementation(t.engine);
+
+        const res: any = await p.batchData({
+            object: 'showcase_task',
+            request: { operation: 'delete', records: [{ id: 't1' }] },
+        } as any);
+
+        expect(res).toMatchObject({ success: true, operation: 'delete', total: 1, succeeded: 1, failed: 0 });
+        expect(res.results[0]).toMatchObject({ id: 't1', success: true });
+        expect(t.rows.has('t1')).toBe(false);
+    });
+
+    it('a mixed batch separates the rows that went from the row that stayed', async () => {
+        // Both directions in ONE run, so neither a blanket `true` nor a blanket
+        // `false` can pass, and the counters still PARTITION `results` (#7539).
+        const t = makeCountingEngine('t2');
+        const p = new ObjectStackProtocolImplementation(t.engine);
+
+        const res: any = await p.batchData({
+            object: 'showcase_task',
+            request: { operation: 'delete', records: [{ id: 't1' }, { id: 't2' }, { id: 't3' }] },
+        } as any);
+
+        expect(res.results.map((r: any) => [r.id, r.success])).toEqual([
+            ['t1', true], ['t2', false], ['t3', true],
+        ]);
+        expect(res).toMatchObject({ success: false, total: 3, succeeded: 2, failed: 1 });
+        expect(res.succeeded + res.failed).toBe(res.total);
+        // A surviving row is not a THROW, so the `continueOnError` stop in the
+        // catch never fires: `t3` was still attempted and really went, without
+        // the flag being set. Measured, not inherited from `deleteMany`.
+        expect(t.engine.delete).toHaveBeenCalledTimes(3);
+        expect(t.rows.has('t2')).toBe(true);
+        expect(t.rows.has('t3')).toBe(false);
+    });
+
+    it('atomic: a surviving row aborts the batch, and the earlier delete is undone', async () => {
+        // This one is FORCED by the partition, and it is a real change of
+        // ending: `runAtomicBatch` aborts on `outcome.failed > 0`, so an atomic
+        // batch holding a package-declared set no longer commits under a
+        // response that called every row deleted. Before: committed,
+        // `succeeded: 3`, `t2` silently still present.
+        const t = makeCountingEngine('t2');
+        const p = new ObjectStackProtocolImplementation(t.engine);
+
+        const res: any = await p.batchData({
+            object: 'showcase_task',
+            request: {
+                operation: 'delete',
+                records: [{ id: 't1' }, { id: 't2' }, { id: 't3' }],
+                options: { atomic: true },
+            },
+        } as any);
+
+        expect(res).toMatchObject({ success: false, total: 3, succeeded: 0, failed: 3 });
+        expect(res.results.map((r: any) => r.errors?.[0]?.code)).toEqual([
+            'ROLLED_BACK', undefined, 'ROLLED_BACK',
+        ]);
+        // Still no `errors[]` on the surviving row, on this arm too.
+        expect(res.results[1]).toMatchObject({ id: 't2', success: false });
+        expect(res.results[1].errors).toBeUndefined();
+        // Rolled back for real: every row is back.
+        expect(t.rows.has('t1')).toBe(true);
+        expect(t.rows.has('t2')).toBe(true);
+        expect(t.rows.has('t3')).toBe(true);
+    });
+
+    it('`returnRecords: false` still carries the honest per-row `success`', async () => {
+        // `batchData`'s envelope is its own: `deleteManyData` has no such flag.
+        // The projection drops `data` and keeps `success`/`index`, so the value
+        // this card moves is the one key that survives it.
+        const t = makeCountingEngine('t1');
+        const p = new ObjectStackProtocolImplementation(t.engine);
+
+        const res: any = await p.batchData({
+            object: 'showcase_task',
+            request: {
+                operation: 'delete',
+                records: [{ id: 't1' }],
+                options: { returnRecords: false },
+            },
+        } as any);
+
+        expect(res).toMatchObject({ success: false, succeeded: 0, failed: 1 });
+        expect(res.results[0]).toMatchObject({ id: 't1', success: false, index: 0 });
+        expect(res.results[0].errors).toBeUndefined();
+    });
+});
+
+
 describe('[#5100] an id-less row is a CALLER error on both by-id update faces', () => {
     it('updateMany: VALIDATION_FAILED/400 before any engine read or write', async () => {
         const t = makeStoreEngine();
 
@@ -12566,8 +12566,66 @@ export class ObjectStackProtocolImplementation implements
                         // spurious 404.
                         const deleted = await this.engine.delete(object, { where: { id: record.id }, ...ctxOpt } as any);
                         if (deleted === false) throw recordNotFoundError(object, record.id);
-                        results.push({ id: record.id, success: true, index });
-                        succeeded++;
+                        // [#19433] The SECOND half of this site, and the THIRD and
+                        // last of the by-id delete doors to learn it — the
+                        // single-record face (#19306) and `deleteManyData` (#19412)
+                        // both already read the engine's answer. The paragraph
+                        // above fixed "no match"; this is "matched, and
+                        // deliberately NOT removed", where `success` was still a
+                        // LITERAL for every result that was not the contract's
+                        // `false`, so that row was reported as a deletion too.
+                        //
+                        // `sys_permission_set` is the shipped shape of it: deleting
+                        // a package-declared set is an ADR-0005 RESET — the overlay
+                        // tombstones and the record re-projects to the declared body
+                        // instead of vanishing — so the row MATCHED, the write ran,
+                        // and the record is still there. On a security-configuration
+                        // write this envelope told an operator a permission set was
+                        // gone while it was still being enforced.
+                        //
+                        // The defect rests on the CONTRACT, not on any shipped
+                        // handler: `IDataEngine.delete` declares
+                        // `Promise<boolean | number>` — the driver's boolean for a
+                        // by-id write, a COUNT of rows removed otherwise — and
+                        // `isDeleteResultShape` admits the number arm at the
+                        // ADR-0112 hook gate, so an `afterDelete` handler or a
+                        // non-ObjectQL engine may legally answer `0` today.
+                        //
+                        // ⛔ Not the `false` arm: that is spoken for by the 404
+                        // above, about a record this caller can still GET, and
+                        // answering it here would trade one wrong answer for a
+                        // louder one. Everything else keeps its #4435 reading, an
+                        // off-contract `undefined` from a third-party driver
+                        // included: only a POSITIVE zero is read as "not removed".
+                        //
+                        // ⛔ And the row gets NO `errors[]` entry. A surviving
+                        // record is an OUTCOME, not a fault — the single-record door
+                        // answers the same case with a bare `success: false` on a
+                        // 200 — and the two per-row codes this envelope owns
+                        // (`ROLLED_BACK`, `NOT_ATTEMPTED`) both describe a row that
+                        // never ran. Minting one for this ending is an
+                        // ERROR_CODE_LEDGER widening in `packages/spec`, and belongs
+                        // to the spec lane.
+                        //
+                        // This envelope's own consequences, measured here rather
+                        // than inherited from `deleteManyData`: the row is counted
+                        // in `failed` because `succeeded` and `failed` PARTITION
+                        // `results` (#7539, `reconcileStoppedBatch`, shared by all
+                        // three bulk faces), which makes the request-level `success`
+                        // false and, on the `atomic` arm, aborts the batch through
+                        // `runAtomicBatch`'s `failed > 0` — so an atomic batch
+                        // holding a package-declared set now rolls back instead of
+                        // committing under a response that called every row deleted.
+                        // It does NOT stop a non-atomic run: the `continueOnError`
+                        // stop belongs to the catch below and nothing was thrown, so
+                        // every remaining record is still attempted. `returnRecords:
+                        // false` keeps `success`, so the honest value survives that
+                        // projection too. Only this `case` is touched — the sibling
+                        // arms of this shared loop keep their own counters.
+                        const removed = deleted !== 0;
+                        results.push({ id: record.id, success: removed, index });
+                        if (removed) succeeded++;
+                        else failed++;
                         break;
                     }
                     default: