Merge remote-tracking branch 'origin/main' into agent-2/issue-27-implement-additem-additem2-removeitem

docs/GatewayTesting.md

@@ -0,0 +1,51 @@
+# Gateway Testing
+
+Gateway tests run without installed MXAccess by using fake workers, fake
+transports, and in-process gRPC service fakes. Live MXAccess verification belongs
+in opt-in integration tests because it depends on installed COM components and
+provider state.
+
+## Fake Worker Harness
+
+`FakeWorkerHarness` in `src/MxGateway.Tests/Gateway/Workers/Fakes/` provides an
+in-process worker side for named-pipe IPC tests. It uses the same
+`WorkerFrameReader`, `WorkerFrameWriter`, and `WorkerEnvelope` contract as the
+gateway so tests exercise real frame validation and worker-client state changes.
+
+Use the harness when a gateway or session test needs worker behavior without
+starting `MxGateway.Worker.exe` or loading MXAccess COM. The harness scripts:
+
+- `WorkerHello` and `WorkerReady` startup,
+- command replies with matching correlation ids,
+- ordered `WorkerEvent` frames,
+- `WorkerFault` frames,
+- shutdown acknowledgements,
+- malformed protobuf payloads and oversized frame headers,
+- slow or hung workers by withholding a reply.
+
+Session-level tests can connect the harness to the pipe created by
+`SessionWorkerClientFactory` with `ConnectToGatewayPipeAsync`. Lower-level
+`WorkerClient` tests can use `CreateConnectedPairAsync` to create both pipe ends
+inside the test.
+
+## Focused Commands
+
+Run the fake worker tests after changing gateway worker IPC, session startup, or
+event streaming behavior:
+
+```bash
+dotnet test src/MxGateway.Tests/MxGateway.Tests.csproj --filter FullyQualifiedName~FakeWorkerHarnessTests
+dotnet test src/MxGateway.Tests/MxGateway.Tests.csproj --filter FullyQualifiedName~SessionWorkerClientFactoryFakeWorkerTests
+```
+
+Run the gateway test project after shared gateway test infrastructure changes:
+
+```bash
+dotnet test src/MxGateway.Tests/MxGateway.Tests.csproj
+```
+
+## Related Documentation
+
+- [Gateway Process Design](./gateway-process-design.md)
+- [Worker Frame Protocol](./WorkerFrameProtocol.md)
+- [MXAccess Worker Instance Detailed Design](./mxaccess-worker-instance-design.md)

docs/gateway-dashboard-design.md

@@ -257,19 +257,18 @@ Do not show API key secrets or pepper values.
 
 ## Authentication And Authorization
 
-Dashboard access should use the same API-key authentication model as gRPC where
+Dashboard access uses the same API-key authentication model as gRPC where
 practical.
 
-Recommended v1 behavior:
+Implemented v1 behavior:
 
-- dashboard disabled by default unless configured,
 - when enabled, require API key auth,
 - require `admin` scope for dashboard access,
-- accept API key through a secure cookie established by a simple login form, or
-  through reverse-proxy/header configuration for local deployments,
-- do not put API keys in query strings.
+- accept API key through a secure cookie established by a simple login form,
+- do not put API keys in query strings,
+- validate anti-forgery tokens for login and logout posts.
 
-Simplest implementation path:
+The implementation path is:
 
 1. Add `/dashboard/login`.
 2. User submits API key over HTTPS.
@@ -281,6 +280,13 @@ Simplest implementation path:
 For local development, allow an explicit `Dashboard:AllowAnonymousLocalhost`
 option. It must default to false.
 
+`DashboardAuthenticator` keeps API-key validation outside UI components. It
+formats the submitted key as a bearer authorization header for
+`IApiKeyVerifier`, rejects non-admin keys when `Dashboard:RequireAdminScope` is
+enabled, and creates the dashboard cookie principal without storing raw API key
+material. `DashboardAuthorizationHandler` enforces the cookie, admin-scope, and
+explicit loopback bypass decisions for all protected dashboard routes.
+
 ## Configuration
 
 Suggested configuration:

docs/gateway-process-design.md

@@ -663,6 +663,16 @@ server-streaming calls and stores the authenticated `ApiKeyIdentity` in
 `Authentication:Mode` set to `Disabled` bypasses API-key verification for local
 development only.
 
+Dashboard authentication reuses the API-key verifier and scope model. The
+dashboard login endpoint accepts the key in a form post, checks `admin` scope
+when `Dashboard:RequireAdminScope` is enabled, and signs in with the
+`MxGateway.Dashboard` cookie scheme. The cookie is HTTP-only, secure, strict
+SameSite, and scoped with the `__Host-MxGatewayDashboard` name. Logout clears
+that cookie. Login and logout posts use anti-forgery validation, and dashboard
+API keys are not accepted in query strings. `Dashboard:AllowAnonymousLocalhost`
+allows only loopback requests to bypass the dashboard cookie requirement and
+defaults to `false`.
+
 Recommended scopes:
 
 - `session:open`
@@ -881,6 +891,11 @@ behavior unless an explicit non-parity backend is designed.
 Gateway tests should be able to run without installed MXAccess by using fake
 workers and fake transports.
 
+Use `FakeWorkerHarness` for tests that need real gateway-to-worker framing,
+handshake, command, event, fault, or malformed-protocol behavior without loading
+MXAccess COM. See [Gateway Testing](./GatewayTesting.md) for the harness scope
+and focused test commands.
+
 Focused tests:
 
 - session state transitions,