@@ -60,29 +60,45 @@ separate from the scenario's allowed service traffic.
6060
6161## Isolated Console application
6262
63- This is the highest-value missing harness. Current full local mode uses shared dev resources; retain its reservation and
64- setup rules until the isolated path exists.
63+ The first isolated browser journey is available through the private Console database runner. It uses a disposable
64+ PostgreSQL container, the real Console UI and Fastify router, and locally signed Cognito-shaped tokens. It does not
65+ replace shared dev for hosted sign-in, callbacks, AWS execution or deployed configuration.
6566
66- Implement incrementally:
67+ ``` sh
68+ pnpm --filter @stacktape/console-api-app test:db --isolated-browser
69+ ```
70+
71+ The runner owns PostgreSQL and verifies container removal. The test owns a scratch database, API server, Vite process
72+ and browser; it disposes each after success or failure. Two independently seeded tenant journeys run concurrently. Each
73+ resolves an issue through the UI, checks the database, reloads, and checks the persisted state. A second signed identity
74+ is denied through the same HTTP server both before and after its own organization membership check. The local session
75+ fixture writes Amplify's token keys before page startup, and an assertion checks that the UI sends the accepted bearer
76+ token. Only the test startup substitutes PostgreSQL's TLS connection options; Prisma, token verification, authorization
77+ and the production router remain real. The lane has no shared-dev reservation or AWS credential requirement.
78+
79+ Run the command twice to check repeatability. ` STP_ISOLATED_BROWSER_FAIL_AFTER_START=1 ` triggers a deliberate failure
80+ after all services start, for checking teardown; that invocation must fail while still reporting removal of its owned
81+ database container. The fixture currently tests one issue flow. Extend it only for cases that need a
82+ browser/API/database boundary; keep provider and hosted identity qualifications in their existing lanes.
83+
84+ When extending this pilot:
6785
68861 . Reuse the real migrated PostgreSQL and locally signed-token setup already demonstrated by the incident-agent tests.
6987 The normal verifier must still check signatures, token use, issuer, audience and expiry. Local issuance qualifies our
7088 verification and authorization logic, not Cognito's hosted login or federation.
71892 . Reuse the production-router HTTP bootstrap in
72- [ incident-agent runtime tests] ( ../../apps/console/api/scripts/incident-agent-runtime.test.ts ) . For reusable startup,
73- replace the database-factory module mock with a narrow connection/configuration seam where needed. Keep the real
74- router and token verifier. Do not add an auth bypass, test-only public endpoint, mutable global table of mocked
75- services or a second implementation of permission checks.
90+ [ incident-agent runtime tests] ( ../../apps/console/api/scripts/incident-agent-runtime.test.ts ) . Keep the real router
91+ and token verifier. Do not add an auth bypass, test-only public endpoint, mutable global table of mocked services or
92+ a second implementation of permission checks.
76933 . Start the real UI against that API. Seed an organization, project and restricted identities. The UI uses Amplify's
7794 Cognito token storage, ` fetchAuthSession ` for bearer headers, and its own stored email for initial UI state. First
78- prototype a test-owned session fixture compatible with those consumers, using newly issued synthetic ID/access tokens
79- and the configured test pool/client. Verify the actual client sends an accepted request after reload without reaching
80- Cognito; an arbitrary JWT in local storage is insufficient. Keep storage details inside one helper and check it when
81- upgrading Amplify. If a narrow identity adapter is needed, wire it only into the isolated app startup. Expiry/refresh
82- and hosted sign-in/sign-out need separate scenarios; Amplify may refresh expired tokens over the network.
83- [ Amplify session behavior] ( https://docs.amplify.aws/javascript/frontend/auth/manage-user-sessions/ ) .
84- 4 . First prove a small flow such as changing an issue's state, rereading it over HTTP, and seeing the persisted value
85- after browser reload. A second identity from another project/organization must be denied through the same server.
95+ session fixture uses newly issued synthetic ID/access tokens and the configured test pool/client. Verify the actual
96+ client sends an accepted request after reload without reaching Cognito. Keep storage details inside one helper and
97+ check it when upgrading Amplify. If a narrow identity adapter is needed, wire it only into the isolated app startup.
98+ Expiry/refresh and hosted sign-in/sign-out need separate scenarios; Amplify may refresh expired tokens over the
99+ network. [ Amplify session behavior] ( https://docs.amplify.aws/javascript/frontend/auth/manage-user-sessions/ ) .
100+ 4 . Keep the issue flow's state change, database read and persistence after browser reload. A second identity from
101+ another project/organization must be denied through the same server.
861025 . Run two independent scenarios concurrently and repeat them from clean state. Verify all child processes, containers
87103 and data are disposed, including after an intentionally failed assertion. Only then expand parallel coverage.
88104
0 commit comments