> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Testing the architectural claims

Choose a test by the claim it must establish. Domain tests, adaptor tests and
real-service qualification provide different evidence.

| Claim                                           | Useful evidence                                   |
| ----------------------------------------------- | ------------------------------------------------- |
| An invariant rejects invalid state              | Domain transition tests                           |
| An application uses the intended owner port     | Handler tests with explicit collaborators         |
| State, receipts and intents commit together     | Restricted PostgreSQL atomicity and failure tests |
| Duplicate deliveries recover safely             | Broker redelivery and receipt tests               |
| A schema change preserves stored bytes          | Historical wire fixtures and compatibility checks |
| A browser recovers from stale delivery          | Authenticated browser and realtime tests          |
| A provider workflow is usable in an environment | Real-provider qualification and UAT               |

## Follow Party and Project

Start with Party's <a href="/source/services/beto/contexts/party_governance/domain/authentication_test.go.txt">authentication tests</a>
and Project's <a href="/source/services/beto/contexts/project/domain/project.go.txt">domain implementation</a>.
Read their context guides for the required native and broker lanes. Use
[TESTING.md](/reference/TESTING.md) for current commands and dev-box requirements.

## Exercises

1. Identify the aggregate that owns each Party access-state transition. Explain
   why an unchanged transition preserves the authentication generation.
2. Explain how `RestoreProject` treats invalid saved state and why it raises no
   creation fact. Find the test that establishes this behaviour.
3. Trace a complete Project observation from source validation through application
   admission, aggregate change and persistence. Identify the provider I/O boundary.
4. Lose a command reply after commit. State which identity, input and expected
   version the retry must retain.
5. Compare a Project material revision with its authority revision. Explain how a
   successful unchanged source read can affect one while preserving the other.
6. Trace an owner contract to the API and browser. Identify where server-authorised
   subscriptions and missing-resource behaviour are checked.

Record remaining qualification alongside the implementation. A passing fake-backed
handler test establishes no claim about PostgreSQL isolation or provider readiness.

Adapted from the [architecture reference](/learn/attribution.md), with Pharos examples.

<details class="page-source"><summary>Page source</summary>

<a href="/source/docs/content/learn/testing-and-exercises.md.txt">Source snapshot</a> · Revision `f928834c8`.

</details>