integration(web): unify guided onboarding and Studio navigation on industrial candidate

docs/EXTERNAL_QUALIFICATION.md

@@ -40,3 +40,5 @@ For account-quota facts, consult the [official GitHub Actions billing documentat
 ## Qualification-soak duration is not optional
 
 The named workloads are immutable inputs: CI = 100K rows / 30 seconds of CDC, SMALL = 1M / 1 hour, MEDIUM = 10M / 24 hours, LARGE = 100M / 72 hours, INDUSTRIAL = 1B / 7 days. The separate production qualification class also requires the complete cumulative identity, authority, crash, content-verification and HA gates in the readiness plan. Overrides receive a CUSTOM label and **never** inherit an immutable workload claim. The direct `external-ci.sh` command only executes the CI workload by default; its success cannot certify any higher class. Long-duration workloads require real isolated infrastructure and independent attestation; if no environment can execute them, the claim remains NOT_QUALIFIED.
+
+A test-process exit status alone is insufficient: standalone PostgreSQL conformance and red-team runners emit Node TAP and must have nonzero executed passing tests with exactly zero skips, TODO, failed or cancelled cases. The fail-closed `assert-test-execution.js` rejects empty, truncated or contradictory output. Both the transcripts and verification logs are checksummed in the external evidence bundle. This rule is mandatory even when PostgreSQL tests contain environment-based `skip` branches.

docs/strict-local-authorization.md

@@ -0,0 +1,58 @@
+# Strict local migration scopes
+
+SPOOL's loopback daemon supports `requireMigrationScopes: true` for a
+fail-closed *local* operator deployment. It does not turn the daemon into a
+public network service or provide enterprise identity federation.
+
+```js
+import { createSpoolDaemon } from '../src/daemon/spoold.js';
+
+const daemon = createSpoolDaemon({
+  service, // your initialized SpoolCommandService
+  host: '127.0.0.1',
+  requireMigrationScopes: true,
+  localIdentities: [
+    {
+      token: process.env.SPOOL_OPERATOR_A_TOKEN,
+      principal: 'operator:alice',
+      commands: ['inspect', 'plan', 'status', 'approve', 'run', 'receipt'],
+      migrationIds: ['preprovisioned-migration-A']
+    },
+    {
+      token: process.env.SPOOL_OPERATOR_B_TOKEN,
+      principal: 'operator:bob',
+      commands: ['inspect', 'plan', 'status', 'receipt'],
+      migrationIds: ['preprovisioned-migration-A']
+    }
+  ]
+});
+```
+
+Each token must be a separate high-entropy secret at least 32 UTF-8 bytes long;
+do not embed it in a repository, URL, browser, or client-side bundle. Never
+configure the legacy shared `token` simultaneously with `localIdentities`.
+Startup fails if any strict identity has no explicit, nonempty migration
+allowlist. A matching bearer cannot execute ungranted commands, impersonate
+another `request.principal`, inspect another migration ID, or invoke a
+top-level cutover/status endpoint with a different migration ID. Mismatched
+`request.migrationId` and `migrationId` fail before dispatch. The API
+responds 403, with no corresponding command-service invocation.
+
+**Security boundary:** This is exact migration-ID authorization for one
+loopback process, *not* tenant data-source isolation. SPOOL's migration IDs and
+plan connection references may be supplied by callers; protecting customer
+data requires a separately trusted binding from each identity to immutable
+source and target resource identities. This setting does not implement
+OIDC/JWT verification, mTLS, global session revocation, approval separation
+between distinct humans, audit log export, or distributed role administration.
+The signed plan/repair approval record still binds to one request principal.
+For now a working local approve-and-run path needs that same bound principal,
+so the example grants Alice both commands. Bob's read-only identity illustrates
+migration-scoped visibility; it is **not** a second approving authority.
+Do **not** interpret separate `approve` and `run` grants as a completed
+two-person authorization workflow.
+
+Legacy single-token mode is retained for backwards compatibility and remains
+**unsuitable as proof of enterprise authorization**. Enable strict mode for
+scoped local operation only; production enterprise release remains gated on
+independent identity, policy, and separation-of-duties validation.