refactor(sql-fs): centralize sandbox fencing policy

Merged
HA
5d ago
+743-200

Why

Five composite filesystem operations duplicated the sandbox fence policy. Share that policy while preserving the executed SQL, lock order, transaction context, and statement counts.

What changed

  • Keep the fence policy in sandbox.ts and use lazy SQL fragments in namespace operations.
  • Add Postgres regression coverage for stale writes, transaction context, hardlinks, and observed lock waits under READ COMMITTED and REPEATABLE READ. Extend the architecture checker to reject copied policy and raw SQL access in its consumers.
  • Fix verify helper SIGPIPE failures, report missing server builds, and add a patch changeset.

Scope

  • Postgres fencing and its verification tools.
  • No API contract, schema, or dependency changes.

Tradeoffs

Keep context setup inline. A separate context query adds statements and changes how a mismatched existing sandbox context behaves.

Blast Radius

Filesystem mutations share one fence builder, so a policy regression could affect several operations. SQL equivalence checks and real Postgres tests cover the preserved behavior.

Verification

  • pnpm check passed with 2,334 unit tests, both SDK checks, and builds.
  • pnpm verify:architecture passed with 279/279 integration tests and zero skips. Contracts, live SDKs, worker failures, stream finalization, input budgets, and tenant isolation passed.
  • The verify stack passed 41 journey assertions and the cross-client filesystem drive. Fresh correctness/security and code quality reviews found no blockers.