@@ -0,0 +1,31 @@
+---
+'@objectstack/plugin-security': patch
+'@objectstack/metadata-protocol': patch
+---
+
+`DELETE /api/v1/data/sys_permission_set/{id}` stops reporting a deletion it did not perform.
+
+A package-declared permission set cannot be deleted from an environment: its delete is an
+ADR-0005 RESET — the overlay tombstones and the record re-projects to the declared body.
+That behaviour is unchanged and deliberate. What was wrong is the answer: the door replied
+`200 {"object":…,"id":…,"success":true}`, byte-identical to a real deletion, so a caller
+that meant to revoke a permission set was told it was gone while it was still enforced, and
+a UI fired a success toast and showed the row again on refresh.
+
+The write-through's delete leg now reports how many of the addressed records actually went,
+and `deleteData` maps that onto the already declared `success` key instead of hard-coding
+`true`. No key is added to `DeleteDataResponseSchema`.
+
+On the wire:
+
+- packaged set — `200 {"success":false}`, the record still present with the same id (was
+  `success: true`);
+- environment-authored set — `200 {"success":true}`, the record really gone (unchanged);
+- unknown id — `404 RECORD_NOT_FOUND` (unchanged: zero-removed is deliberately not read as
+  not-found, because the record is still there to GET).
+
+The read-back that decides this is fail-closed: a read that cannot answer reports the record
+as NOT deleted and warns on the durability channel, because "the read failed" and "the row is
+gone" are opposite facts and only the second may claim a deletion.
+
+Clause-②: no
@@ -161,6 +161,29 @@ describe('[#4435] deleteData reports what actually happened', () => {
     await expect(p.deleteData({ object: 'task', id: 'whatever' } as any))
       .resolves.toMatchObject({ success: true });
   });
+
+  it('a row that MATCHED and was NOT removed answers `success: false`, not a deletion', async () => {
+    // The same measurement one outcome over. `success` stayed a LITERAL for
+    // every answer that was not the contract's `false`, so a write that found
+    // its row and deliberately did not remove it still reported a deletion.
+    //
+    // `sys_permission_set` is the shipped case: deleting a package-declared
+    // set is an ADR-0005 RESET — the record re-projects to the declared body
+    // instead of vanishing — and its envelope was byte-identical to a real
+    // delete's, so a UI fired a success toast and showed the row again on
+    // refresh. The engine's delete result declares a COUNT arm beside the
+    // driver boolean, and zero rows removed is the one value that positively
+    // means "the row is still there".
+    const engine = {
+      registry: { getObject: () => SCHEMA },
+      delete: vi.fn(async () => 0),
+    };
+    const p = new ObjectStackProtocolImplementation(engine as any);
+    const res = await p.deleteData({ object: 'task', id: 'still_there' } as any);
+    // Not a 404 either: the caller can still GET this record, so reading zero
+    // as not-found would trade one wrong answer for a louder one.
+    expect(res).toEqual({ object: 'task', id: 'still_there', success: false });
+  });
 });
 
 describe('[#4435] deleteManyData reports per id, not per request', () => {
 
@@ -11436,10 +11436,33 @@ export class ObjectStackProtocolImplementation implements
         // POSITIVE not-found signal, and inventing a 404 out of it would break
         // deletes against third-party drivers rather than report honestly.
         if (deleted === false) throw recordNotFoundError(request.object, request.id);
+        // The same measurement, one outcome over: `success` was still a
+        // LITERAL for every answer that was not the contract's `false`, so a
+        // row that MATCHED and was deliberately NOT removed reported a
+        // deletion. `sys_permission_set` is the shipped case — a
+        // package-declared set's delete is an ADR-0005 RESET, the record
+        // re-projects to the declared body instead of vanishing — and the
+        // envelope was byte-identical to a real delete, so a UI fired a
+        // success toast and showed the row again on refresh.
+        //
+        // `success` is declared "Whether deletion succeeded", and this is the
+        // only key on `DeleteDataResponseSchema` that can carry the
+        // difference; zero rows removed is a deletion that did not succeed.
+        // The engine's delete result declares two arms — the driver's boolean
+        // for a by-id write, a COUNT of rows removed otherwise — so a numeric
+        // zero is the one answer that positively means "the row is still
+        // there", and it is what the middleware that performs a reset now
+        // returns. It cannot say so with `false`: that value is spoken for by
+        // the not-found 404 above, which would be a second lie about a record
+        // this caller can still GET.
+        //
+        // Everything else keeps its #4435 reading, including an off-contract
+        // `undefined` from a third-party driver: only a POSITIVE zero is read
+        // as "not removed".
         return {
             object: request.object,
             id: request.id,
-            success: true
+            success: deleted !== 0
         };
     }
 
 
@@ -887,6 +887,133 @@ describe('createPermissionSetWriteThrough (data door → metadata store)', () =>
     expect(ql.permRows[0].managed_by).toBe('package');
   });
 
+  it('the delete OUTCOME tells a real deletion apart from a packaged RESET', async () => {
+    // Both endings above are correct — a runtime-only set goes, a packaged one
+    // re-projects to its declaration. What the CALLER could not do was tell
+    // them apart: the outcome this middleware wrote was `true` on every path
+    // (it started there and the loop could only ever assign `true` again), so
+    // the data door answered `200 {"success":true}` for both. A UI fired a
+    // success toast on a permission set it had not deleted and showed the row
+    // again on refresh — the two legs' own assertions above stayed green
+    // throughout, because they read the STORE and never the answer.
+    //
+    // ⛔ The reset's outcome must not be `false` either: that value is the
+    // driver contract's "no row matched", which `deleteData` turns into a
+    // `404 RECORD_NOT_FOUND` — about a record this same caller can still GET.
+    // Zero rows removed is the other declared arm and the only one that says
+    // "it is still there"; `metadata-protocol`'s own
+    // `protocol.record-not-found.test.ts` pins the mapping onto `success`.
+
+    // Leg 1 — runtime-only definition: the record really goes.
+    const envQl = makeQl();
+    const envProtocol = makeProtocol(envQl);
+    registerPermissionSetProjection(envProtocol, { ql: envQl });
+    await envProtocol.saveMetaItem({ type: 'permission', name: 'organization_admin', item: envBody() });
+    const envCtx: any = {
+      object: 'sys_permission_set',
+      operation: 'delete',
+      options: { where: { id: envQl.permRows[0].id } },
+      context: userCtx,
+    };
+    await run(makeMiddleware(envQl, envProtocol), envCtx);
+    expect(envQl.permRows.length, 'control: the env-authored record really went').toBe(0);
+    expect(envCtx.result, 'a completed delete keeps answering the boolean arm').toBe(true);
+
+    // Leg 2 — artifact-backed definition: the record survives the RESET.
+    const pkgQl = makeQl();
+    const declaredBody = envBody({ name: 'crm_rep', systemPermissions: ['pkg.baseline'] });
+    (pkgQl as any).registry = { listItems: (t: string) => (t === 'permission' ? [declaredBody] : []) };
+    const pkgProtocol = makeProtocol(pkgQl, { crm_rep: declaredBody });
+    registerPermissionSetProjection(pkgProtocol, { ql: pkgQl });
+    pkgQl.permRows.push({
+      id: 'ps_pkg', name: 'crm_rep', managed_by: 'package',
+      package_id: 'com.example.crm', system_permissions: '["pkg.baseline"]',
+    });
+    seedLegacyOverlay(pkgQl, 'crm_rep', envBody({ name: 'crm_rep', systemPermissions: ['customized'] }));
+    await projectPermissionMutation(pkgProtocol, { ql: pkgQl }, { type: 'permission', name: 'crm_rep', state: 'active', organizationId: null });
+    const pkgCtx: any = {
+      object: 'sys_permission_set',
+      operation: 'delete',
+      options: { where: { id: 'ps_pkg' } },
+      context: userCtx,
+    };
+    await run(makeMiddleware(pkgQl, pkgProtocol), pkgCtx);
+    expect(pkgQl.permRows.length, 'the record survives — the designed ADR-0094 reset').toBe(1);
+    expect(
+      typeof pkgCtx.result,
+      'the COUNT arm — `false` would be read as not-found and 404 a record that is still there',
+    ).toBe('number');
+    expect(pkgCtx.result, 'zero records removed').toBe(0);
+
+    // The card's own claim, stated as an assertion: the two endings no longer
+    // hand the caller the same answer.
+    expect(pkgCtx.result).not.toEqual(envCtx.result);
+  });
+
+  it('a read-back that cannot ANSWER reports the record as NOT deleted (fail-closed)', async () => {
+    // The outcome above is read off the record, which puts the whole answer at
+    // the mercy of ONE read — and the obvious helper for it, `tryFind`, ends in
+    // `catch { return []; }`. Probing through that helper makes a FAILED read
+    // byte-identical to "the row is gone", so the door answers
+    // `200 {"success":true}` with the record sitting exactly where it was:
+    // this card's own lie, re-triggered by an outage instead of by a packaged
+    // set. Nothing else in this file would have said a word about it.
+    //
+    // `unknown` is therefore counted as a survivor. A caller told "not
+    // deleted" re-reads the record and learns the truth; a caller told
+    // "deleted" has no reason to look again.
+    const ql = makeQl();
+    const declaredBody = envBody({ name: 'crm_rep', systemPermissions: ['pkg.baseline'] });
+    (ql as any).registry = { listItems: (t: string) => (t === 'permission' ? [declaredBody] : []) };
+    const protocol = makeProtocol(ql, { crm_rep: declaredBody });
+    registerPermissionSetProjection(protocol, { ql });
+    ql.permRows.push({
+      id: 'ps_pkg', name: 'crm_rep', managed_by: 'package',
+      package_id: 'com.example.crm', system_permissions: '["pkg.baseline"]',
+    });
+
+    // Fail ONLY the read-back. Target resolution and the probe both read
+    // `sys_permission_set` by id, so they are told apart by ORDER: the first
+    // is the middleware resolving what the caller addressed, the second is the
+    // read-back under test. `byIdReads` is asserted below so that a change in
+    // that shape turns this test RED rather than leaving it vacuously green
+    // with an injection that never fired.
+    const realFind = ql.find.bind(ql);
+    let byIdReads = 0;
+    (ql as any).find = async (object: string, q: any) => {
+      if (object === 'sys_permission_set' && q?.where?.id !== undefined) {
+        byIdReads += 1;
+        if (byIdReads >= 2) throw new Error('db unavailable');
+      }
+      return realFind(object, q);
+    };
+
+    const warnings: { m: string; meta?: any }[] = [];
+    const mw = createPermissionSetWriteThrough({
+      ql, getProtocol: () => protocol,
+      logger: { info: () => {}, warn: (m: string, meta?: any) => warnings.push({ m, meta }) },
+    });
+    const opCtx: any = {
+      object: 'sys_permission_set',
+      operation: 'delete',
+      options: { where: { id: 'ps_pkg' } },
+      context: userCtx,
+    };
+    await run(mw, opCtx);
+
+    expect(byIdReads, 'the read-back really ran — otherwise this test proves nothing').toBeGreaterThanOrEqual(2);
+    expect(ql.permRows.length, 'the record is still right there').toBe(1);
+    expect(
+      opCtx.result,
+      '⛔ never `true`: that is the deletion claim this card exists to remove, and a failed read must not manufacture it',
+    ).not.toBe(true);
+    expect(opCtx.result, 'counted as a survivor').toBe(0);
+    expect(
+      warnings.some((w) => String(w.m).includes('could not read the sys_permission_set record back')),
+      'the degradation is reported, not swallowed',
+    ).toBe(true);
+  });
+
   it('SINGLE-STORE kernel (no protocol): package rows keep the legacy two-doors refusal', async () => {
     const ql = makeQl();
     ql.permRows.push({ id: 'ps_pkg', name: 'crm_rep', managed_by: 'package', package_id: 'com.example.crm' });
 
@@ -124,6 +124,33 @@ export async function tryFind(ql: any, object: string, where: any, limit = 100,
     return Array.isArray(rows) ? rows : [];
   } catch { return []; }
 }
+
+/**
+ * Is this record still on the table? THREE outcomes, not two.
+ *
+ * {@link tryFind} deliberately collapses a failed read into `[]` — right for
+ * every caller that wants "the rows I could see", wrong for anyone who has to
+ * decide whether a row is GONE. `[]` from that helper means "no row matched OR
+ * the read blew up", and a caller reading it as "gone" reports a deletion that
+ * an outage invented. `listSeedOrganizationIds` in `per-organization-catalog.ts`
+ * states the same rule for the same shape: zero organizations is "nothing to
+ * seed", an unreadable table is "we do not know".
+ *
+ * So `unknown` is its own answer and the caller must decide what it means —
+ * ⛔ never folded into `gone` here. The context and the read are otherwise
+ * IDENTICAL to `tryFind`'s (no `transaction` key, so an ambient handle still
+ * carries it), because the difference under test is the catch and nothing else.
+ */
+async function probeRecordSurvival(
+  ql: any,
+  object: string,
+  id: unknown,
+): Promise<'gone' | 'present' | 'unknown'> {
+  try {
+    const rows = await ql.find(object, { where: { id }, limit: 1 }, { context: seedCtx() });
+    return (Array.isArray(rows) ? rows : [])[0] ? 'present' : 'gone';
+  } catch { return 'unknown'; }
+}
 /**
  * ⛔ The `catch` RECORDS the refusal before it answers, when the caller passed
  * a log to record into.
@@ -1292,7 +1319,47 @@ export function createPermissionSetWriteThrough(
     // an ADR-0005 RESET — and the record re-projects to the declared body
     // instead of vanishing (a packaged definition cannot be deleted from the
     // environment).
-    let lastOutcome: any = true;
+    //
+    // The RESET is the designed outcome and stays exactly as it is. What this
+    // loop owes the CALLER is the ability to tell the two endings apart: the
+    // outcome below used to start at `true` and could only ever be assigned
+    // `true` again, so a reset answered the data door with the same
+    // `{"success":true}` a real deletion does — the difference was named only
+    // in the `logger.info` line above, which no caller can read. A machine
+    // surface that reports a refusal as a deletion is the one thing
+    // "machine-readable surfaces must not lie" forbids, and on a
+    // security-configuration write it tells an operator a permission set is
+    // gone while it is still being enforced.
+    //
+    // The outcome is therefore the COUNT of target RECORDS that actually went
+    // — the number arm of this engine method's declared result ("how many rows
+    // the delete removed"), which the data door turns into an honest
+    // `success: false` on a 200. Every target removed keeps answering `true`,
+    // the boolean arm's value for a completed by-id delete, so a real deletion
+    // is unchanged on the wire.
+    //
+    // ⛔ NOT `false` for the reset: the boolean arm's `false` is the driver
+    // contract's "no row matched", which the data door turns into a
+    // `404 RECORD_NOT_FOUND` — and the record is still right there, so that
+    // would trade this lie for a louder one and hand a UI a reason to drop the
+    // row it must keep showing.
+    //
+    // Zero also covers every other way a record survives this loop: a metadata
+    // delete that lands on a package-owned RECORD (left to the package door),
+    // a retire whose `ql.delete` failed, and a read-back that could not answer
+    // at all. All three leave the row in place — or leave us unable to say it
+    // does not — and none is a deletion the caller should be told happened.
+    //
+    // ⛔ The outcome is read off the RECORD, never off the re-projection's own
+    // `deleted` counter. On a kernel wired to the ADR-0094 AWAITED projector —
+    // the production shape — `deleteMetaItem` has already retired the record
+    // by the time control returns here, so the idempotent re-projection below
+    // finds no row and legitimately reports `deleted: 0` for a delete that
+    // really happened. Reading that counter would have answered
+    // `success: false` for EVERY delete, which is the same defect with its
+    // sign flipped: honest about the packaged set and a fresh lie about the
+    // ordinary one. `permission-set-projection.test.ts` holds both legs.
+    let removed = 0;
     for (const row of targets) {
       await protocol.deleteMetaItem({ type: 'permission', name: row.name, ...actorArg });
       const res = await projectPermissionMutation(protocol, deps, {
@@ -1301,9 +1368,37 @@ export function createPermissionSetWriteThrough(
       if (res && (res.seeded + res.updated) > 0) {
         logger?.info?.('[security] permission set reset to its declared baseline (artifact-backed; ADR-0094)', { name: row.name });
       }
-      lastOutcome = res?.deleted ? true : lastOutcome;
+      // The caller addressed a RECORD by id, so that is the question this
+      // answers: is it still there? A row re-projected under the same id is
+      // the reset; a row that is gone is the deletion.
+      //
+      // ⛔ The probe has THREE outcomes and this loop counts only ONE of them.
+      // Probing through `tryFind` — whose catch returns `[]` — would have made
+      // a FAILED read indistinguishable from "the row is gone", and answered
+      // `success: true` with the record sitting exactly where it was: this
+      // card's own lie with a different trigger (an outage instead of a
+      // packaged set). `unknown` is therefore counted as a SURVIVOR, the
+      // fail-closed direction: a caller told "not deleted" re-reads the record
+      // and finds out, a caller told "deleted" has no reason to look again.
+      // It is also the only direction that cannot be produced by a broken
+      // read — `gone` now requires a read that actually ANSWERED.
+      const survival = await probeRecordSurvival(ql, 'sys_permission_set', row.id);
+      if (survival === 'unknown') {
+        // Durability channel: the write half of this delete already ran, so
+        // the row's fate is decided and only our READING of it failed. Say so
+        // once, naming what the caller was told and how to settle it.
+        logger?.warn?.(
+          '[security] could not read the sys_permission_set record back after its metadata delete, so the ' +
+          'data-door answer reports it as NOT deleted (fail-closed). The delete itself already ran; re-read the ' +
+          'record to see whether it was removed or reset to its declared baseline.',
+          { name: row.name, id: row.id },
+        );
+      }
+      if (survival === 'gone') removed += 1;
     }
-    opCtx.result = lastOutcome;
+    // `targets` is non-empty here — the early return above sends an empty
+    // target set to the driver — so this is never the vacuous `true`.
+    opCtx.result = removed === targets.length ? true : removed;
     return;
   };
 }