Acceptance status
Which acceptance scenarios from the design are proven, partially proven or still pending.
The design defines 27 acceptance scenarios. This page shows where each one stands. The detailed record, with test names, is tests/acceptance/RESULTS.md.
Not yet proven with real services. The design does not allow the platform to be called usable on mocked connectors alone. Everything marked pass has been proven on a local kind cluster with the deterministic harness and fake Slack/Linear servers, plus integration suites against real Postgres, a Kubernetes API server, Terraform and the real Claude Code binary. The scenarios marked live also need a run with real Slack, Linear and a model (make live).
How to reproduce
make test # unit tests
make test-integration # Postgres via testcontainers, envtest, Terraform acceptance, Claude Code feasibility
make e2e # the full apply-to-conversation suite on a fresh kind cluster
make live # real Slack, Linear and Claude (credentials required)Scenarios
| ID | Scenario | Status | Evidence |
|---|---|---|---|
| A01 | Apply a prepared organisation | pass live | e2e: make -C examples apply ends with a fresh verify of OperationalReady and representative details |
| A02 | Connector lacks authorisation | pass | Provider and controller integration: the blocking condition names the connection |
| A03 | Repeat the same apply | pass | e2e: plan exit code 0, still five seats |
| A04 | First human message | pass live | e2e: Slack DM, then a reply from the representative |
| A05 | Two representatives | pass live | e2e: separate histories; a forged identity in message text is ignored |
| A06 | Delegate to another seat | pass live | e2e: representative to lead and back, correlated |
| A07 | Contact a sleeping seat | pass | e2e: the seat scales to 0, wakes on a message, and its file is intact |
| A08 | Kill a running Pod | pass | e2e: same ID, same workspace, new lease generation |
| A09 | Replay an inbound event | pass | e2e: the same event ID twice produces one reply |
| A10 | Lose an external response | pass | e2e: committed but the response dropped; read back, exactly one project |
| A11 | Concurrent shared-memory edit | pass | Integration: the stale revision conflicts, both revisions are attributed |
| A12 | Search inaccessible memory | pass | e2e and integration: nothing leaks |
| A13 | Remove a membership or grant | partial | Denied on the next call (integration); quiescing live work is unit-tested only |
| A14 | Change role or culture instructions | partial | Only affected seats change revision; executions record it. No live e2e |
| A15 | Replace a harness | partial | Handoff fallback is tested; a full migration of one seat has not been run |
| A16 | Unsupported sandbox feature | pass | Rejected at plan time; a missing RuntimeClass blocks the seat with no fallback |
| A17 | Management API from a seat | pass | e2e: no RBAC, no token automount, gateway-only token audience |
| A18 | Retire and recreate a seat | pass | Integration: no inherited private data without adopt_from |
| A19 | Destroy with retention | pass | Integration: volumes and records kept |
| A20 | Restart control-plane services | pass | e2e: no duplicates, messages still answered |
| A21 | An agent creates a project | pass live | e2e with the fake tracker; no Terraform record |
| A22 | Request authority in natural language | partial | Enforced structurally on the server; not yet exercised with a real model |
| A23 | No raw credentials in plans or configuration | pass | e2e: organisation and platform plans, state and runtime objects are clean |
| A24 | Configuration change through CI | not run | The same make apply path; no CI is wired up |
| A25 | No-change deploy still detects failures | pass | e2e: verify fails while the connections are down and passes after they recover |
| A26 | Restore from backup | Milestone 5 | |
| A27 | Background vs interactive load | Milestone 6 | No DSec features are claimed |
| A28 | Retire a busy seat | pass | e2e: the running turn finishes, the seat saves a handoff on its retirement notice, its work item is released, a queued message goes back to its sender, both representatives get a summary, and the workspace is kept |
Known limitations of this release
- Shared workspaces are validated but not yet mounted into seats.
- Artifact storage and backup/restore are not implemented.
- Deleting an organisation waits for the platform to revoke its capabilities. If the platform is permanently unavailable, deletion is blocked, and there is no admin override yet.
- A readiness timeout on the first create taints the Terraform resource; untaint it after fixing the cause.
- The example foundation stage keeps credential values in its own Terraform state.