fix(verify): isolate the RLS-proof stack; document write-transform fidelity gaps

Surfaced by running `objectstack verify` against the real third-party hotcrm app:

- The CLI ran data-fidelity and RLS proofs against the SAME in-process stack, so
  the RLS phase's admin-creates collided with rows the fidelity phase had already
  written on unique-constrained fields (e.g. a unique `sku`/`account_number`) →
  a 409 that silently skipped those objects' authorization check. Boot a separate
  pristine stack for the RLS phase. hotcrm `--rls --multi-tenant` goes from
  5-consistent/3-skipped(409) to 8-consistent/0-holes.
- Document the known limitation that fields normalized on write (uppercase/trim
  hooks, canonicalizing formulas) read back as `fidelity-gaps` even when working
  as designed (hotcrm's `sku`/`account_number` uppercase hooks).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: os-zhuang

packages/cli/src/commands/verify.ts

@@ -58,20 +58,33 @@ export default class Verify extends Command {
       String(readEnvWithDeprecation('OS_MULTI_ORG_ENABLED', 'OS_MULTI_TENANT') ?? 'false').toLowerCase() !==
         'false';
 
-    const stack = await bootStack(config, { multiTenant });
-
+    // Data fidelity runs on its own pristine stack.
     let crud: VerifyReport;
-    let rls: RlsReport | undefined;
-    try {
-      const adminToken = await stack.signIn();
-      crud = await runCrudVerification(stack, adminToken, config);
+    {
+      const stack = await bootStack(config, { multiTenant });
+      try {
+        const adminToken = await stack.signIn();
+        crud = await runCrudVerification(stack, adminToken, config);
+      } finally {
+        await stack.stop();
+      }
+    }
 
-      if (flags.rls) {
-        const memberToken = await stack.signUp('verify-member@objectstack.test');
-        rls = await runRlsProofs(stack, adminToken, memberToken, config);
+    // The RLS proofs run on a SEPARATE, fresh stack. Reusing the fidelity stack
+    // would let the RLS phase's admin-creates collide with the rows the fidelity
+    // phase already wrote on unique-constrained fields (e.g. a unique `sku` or
+    // `account_number`) — a 409 that silently skips the object instead of
+    // proving its authorization.
+    let rls: RlsReport | undefined;
+    if (flags.rls) {
+      const rlsStack = await bootStack(config, { multiTenant });
+      try {
+        const adminToken = await rlsStack.signIn();
+        const memberToken = await rlsStack.signUp('verify-member@objectstack.test');
+        rls = await runRlsProofs(rlsStack, adminToken, memberToken, config);
+      } finally {
+        await rlsStack.stop();
       }
-    } finally {
-      await stack.stop();
     }
 
     // Failure contract: a "real" runtime break the app's author must see.

packages/verify/README.md

@@ -100,3 +100,17 @@ isolation policies actually apply.
 
 `bootStack` options: `admin`, `authSecret`, `security` (a custom `SecurityPlugin`
 for owner-scoped fixtures), `multiTenant`.
+
+## Known limitations
+
+- **Intentional write-transforms read back as fidelity gaps.** The fidelity
+  check asserts an *exact* round-trip, so a field normalized on write — an
+  `uppercase`/`trim` hook, a canonicalizing formula — is reported as a
+  `fidelity-gaps` mismatch (e.g. `sku`: wrote `"abc-1"` → read `"ABC-1"`) and
+  fails the run, even though the app behaves as designed. The report shows the
+  exact `wrote → read` diff so it's diagnosable; letting an app declare such
+  fields so the verifier can allow them is a planned enhancement.
+- **The auto-derived sweep is coarser than a hand-written matrix.** It exercises
+  one synthesized record per object and skips fields it can't synthesize
+  (required lookups / master-detail, media, computed). It's a broad runtime
+  smoke test, not a substitute for targeted golden tests of specific behavior.