From 0c31b0d70971f61e43f329d58c0d247e6aed281c Mon Sep 17 00:00:00 2001
From: Einar Ingebrigtsen <einari@me.com>
Date: Sun, 8 Mar 2026 12:04:56 +0000
Subject: [PATCH 1/2] Bootstrap Copilot sync workflows

---
 .github/instructions/concepts.instructions.md |  29 ---
 .github/instructions/csharp.instructions.md   |  22 ---
 .../documentation.instructions.md             |  45 -----
 .../instructions/efcore.specs.instructions.md |  12 --
 .../pull-requests.instructions.md             |   9 -
 .../instructions/specs.csharp.instructions.md | 170 ------------------
 .github/instructions/specs.instructions.md    |  96 ----------
 .../specs.typescript.instructions.md          | 151 ----------------
 .../propagate-copilot-instructions.yml        |  16 ++
 .../workflows/sync-copilot-instructions.yml   |  16 ++
 10 files changed, 32 insertions(+), 534 deletions(-)
 delete mode 100644 .github/instructions/concepts.instructions.md
 delete mode 100644 .github/instructions/csharp.instructions.md
 delete mode 100644 .github/instructions/documentation.instructions.md
 delete mode 100644 .github/instructions/efcore.specs.instructions.md
 delete mode 100644 .github/instructions/pull-requests.instructions.md
 delete mode 100644 .github/instructions/specs.csharp.instructions.md
 delete mode 100644 .github/instructions/specs.instructions.md
 delete mode 100644 .github/instructions/specs.typescript.instructions.md
 create mode 100644 .github/workflows/propagate-copilot-instructions.yml
 create mode 100644 .github/workflows/sync-copilot-instructions.yml

diff --git a/.github/instructions/concepts.instructions.md b/.github/instructions/concepts.instructions.md
deleted file mode 100644
index 338be7e..0000000
--- a/.github/instructions/concepts.instructions.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-applyTo: "**/*.cs"
----
-
-# 🧪 How to use Concepts
-
-- Don't use primitives like `string`, `int`, `Guid`, etc. directly in your domain models, commands, events, queries, etc.
-- Create a concept for the primitive type that encapsulates the value and provides domain-specific behavior.
-- Inherit from the appropriate base class provided by Cratis Concepts, such as `ConceptAs<T>`
-- `ConceptAs<T>` has a default conversion from `T` to `ConceptAs<T>`.
-- When creating a concept, add a implicit conversion operator from `ConceptAs<T>` to `T` for easy extraction of the underlying value.
-- Instead of using `null` values, add a static readonly value representing an empty or default state for the concept with appropriate naming for the context (e.g. `Empty`, `NotSet`).
-- Don't add Concepts to its own folder, place it in the folder that makes most sense for the context of the concept.
-
-Example of a concept:
-
-```csharp
-public record AuthorId(Guid Value) : ConceptAs<Guid>(Value)
-{
-    public static readonly AuthorId NotSet = new(Guid.Empty);
-    public static implicit operator AuthorId(Guid value) => new(value);
-
-    // If the concept is used as an identifier for an event source, you can add an implicit conversion to EventSourceId
-    public static implicit operator EventSourceId(AuthorId id) => new(id.Value.ToString());
-
-    // For convenience, you can add a method to create a new instance with a new unique value - if needed, makes things cleaner when creating new instances
-    public static AuthorId New() => new(Guid.NewGuid());
-}
-```
diff --git a/.github/instructions/csharp.instructions.md b/.github/instructions/csharp.instructions.md
deleted file mode 100644
index 6771936..0000000
--- a/.github/instructions/csharp.instructions.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-applyTo: "**/*.cs"
----
-
-# 🧪 Specific instructions for C#
-
-## Technology Stack
-
-- .NET 9 (specified in global.json)
-- C# 13
-- ASP.NET Core
-- MongoDB.Driver for C#
-- Entity Framework Core
-- xUnit for testing
-- NSubstitute for mocking
-- Cratis.Specifications for BDD-style tests
-
-## Building
-
-- Don't use the build tasks in Visual Studio. Use `dotnet build` from the command line instead.
-- Use `dotnet format` to format code.
-- Use `dotnet test` to run tests.
diff --git a/.github/instructions/documentation.instructions.md b/.github/instructions/documentation.instructions.md
deleted file mode 100644
index 001c5c6..0000000
--- a/.github/instructions/documentation.instructions.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-applyTo: "Documentation/**/*.md"
----
-
-# 🧪 How to Write Documentation
-
-- All documentation files live in the `Documentation/` folder.
-- Use [Markdown](https://www.markdownguide.org/basic-syntax/) for formatting.
-- Use [GitHub Flavored Markdown](https://github.github.com/gfm/) for additional features.
-- Use [Mermaid](https://mermaid-js.github.io/mermaid/#/) for diagrams.
-- Use [PlantUML](https://plantuml.com/) for UML diagrams.
-- Site is built using [DocFX](https://dotnet.github.io/docfx/).
-- Follow the [DocFX Markdown](https://dotnet.github.io/docfx/markdown/) guidelines for additional syntax.
-- Generate and maintain correct [DocFX TOC files](https://dotnet.github.io/docfx/docs/dotnet-yaml-format.html) for navigation.
-- Be consistent with formatting and style.
-- Use clear and concise language.
-- Be concise and to the point.
-- Be specific and avoid ambiguity.
-- Use examples and code snippets to illustrate concepts.
-- Do not add extraneous information.
-- Do not document the obvious.
-- Do not add documentation for internal or private APIs.
-- Do not document internal implementation details.
-- Focus on the public APIs and features of the project.
-- Do not document third party libraries or tools.
-- Use active voice and present tense.
-- Use proper grammar and spelling.
-- Use a friendly and approachable tone.
-- Create focused and well-scoped documents.
-- Use consistent terminology throughout the documentation.
-- Follow a logical structure and flow.
-- Don't be too verbose.
-- Use headings, lists, and code blocks to organize content.
-- Include links to relevant resources and references.
-- Always add an index.md file in each folder to serve as the landing page.
-- Maintain the index.md file to include links to all relevant subtopics.
-- Use relative links for internal documentation references.
-- Ensure all links are valid and up-to-date.
-- Use images and diagrams to enhance understanding.
-- Emphasize why something is done, not just how.
-- Always end the generated markdown with a single empty line inside the file content itself. Never try to add it by running commands like echo or printf — it must be part of the markdown text you output.
-- Never use shell commands or external tools to modify files after writing them. Everything, including the trailing newline, must be produced as part of the file’s content.
-- Every folder should have its own `toc.yml` file to define the structure of the documentation within that folder.
-- When linking to a folder in a `toc.yml` file, link to the `toc.yml` file in that folder, not to an `index.md` file.
-- Ensure that documentation is accurate according to the public APIs and features of the project.
diff --git a/.github/instructions/efcore.specs.instructions.md b/.github/instructions/efcore.specs.instructions.md
deleted file mode 100644
index 94476f7..0000000
--- a/.github/instructions/efcore.specs.instructions.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-applyTo: "**/for_*/**/*.cs, **/when_*/**/*.cs"
----
-
-# How to write Entity Framework Core Specs
-
-- Use Sqlite in-memory database for specs (tests) that involve `DbContext` operations. This allows for lightweight and fast testing without the need for a full database setup.
-- Ensure that the in-memory database is properly configured and disposed of after each test to avoid state leakage between tests.
-- When writing specs (tests) for units that leverage a `DbContext` or a derivative of it, remember that methods like `SaveChanges` or `SaveChangesAsync` are virtual and can be mocked.
-- Simulating failure on a `DbContext` operation can be achieved by mocking these methods to throw exceptions, allowing you to test error handling and recovery logic in your specs.
-- `DbSet` has most of its methods as virtual, which means you can mock them as needed for your tests.
-- A `DbContext` needs options passed into its constructor. When mocking with NSubstitute you simply pass the options when substituting it, e.g., `Substitute.For<YourDbContext>(options)`.
diff --git a/.github/instructions/pull-requests.instructions.md b/.github/instructions/pull-requests.instructions.md
deleted file mode 100644
index ddabcea..0000000
--- a/.github/instructions/pull-requests.instructions.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# 🧪 How to do pull requests
-
-- Follow the [pull request template](../pull_request_template.md).
-    - Primarily focus on the Added, Changed, Fixed, Removed, Security, and Deprecated sections. The summary can most likely be omitted.
-    - The description is used as the GitHub release description so make it nice and descriptive and to the point.
-- Ensure your code follows the project's coding standards and guidelines.
-- Write clear and concise commit messages.
-- Label your pull request appropriately according to semantic versioning for what type of improvement the PR is offering (major, minor, patch).
-- Add a link to the issue it addresses on every bullet-point added in parentheses (e.g., (#123)) at the end of the bullet point, if applicable.
diff --git a/.github/instructions/specs.csharp.instructions.md b/.github/instructions/specs.csharp.instructions.md
deleted file mode 100644
index f80d297..0000000
--- a/.github/instructions/specs.csharp.instructions.md
+++ /dev/null
@@ -1,170 +0,0 @@
----
-applyTo: "**/for_*/**/*.cs, **/when_*/**/*.cs"
----
-
-# 🧪 How to Write C# Specs
-
-Use the base instructions for writing specs can be found in [Specs Instructions](./specs.instructions.md) and
-then adapt with the C# specific conventions below.
-
-## Test Frameworks & Conventions
-
-- **Frameworks:**
-  - Uses [Xunit](https://xunit.net/) as test framework and execution.
-  - Uses [NSubstitute](https://nsubstitute.github.io/) for mocking.
-  - Uses [Cratis Specifications](https://github.com/Cratis/Specifications/blob/main/README.md) for BDD style specification by example testing.
-  - Use separate projects for specs, e.g. `Applications.Specs`.
-
-## Base class
-
-- At the root of inheritance, `Specification` must be the base class.
-
-## Test Class Pattern
-
-- Use BDD-style methods:
-  - `void Establish()` for setup.
-  - `void Because()` for the action under test.
-  - `[Fact] void should_<expected_behavior>()` for assertions.
-  - Keep them focused on a single behavior or aspect.
-
-**Example:**
-
-```csharp
-public class when_adding : Specification
-{
-    EventsToAppend events;
-    string @event;
-
-    void Establish()
-    {
-        events = [];
-        @event = "Forty Two";
-    }
-
-    void Because() => events.Add(@event);
-
-    [Fact] void should_hold_the_added_event() => events.First().ShouldEqual(@event);
-}
-```
-
-**Example with multiple outcomes:**
-
-```
-for_EventsCommandResponseValueHandler/
-├── given/
-│   └── an_events_command_response_value_handler.cs
-├── when_checking_can_handle/
-│   ├── with_valid_events_collection.cs
-│   ├── with_null_value.cs
-│   └── without_event_source_id.cs
-└── when_handling/
-    ├── empty_events_collection.cs
-    ├── single_event_collection.cs
-    └── multiple_events_collection.cs
-```
-
-Each test class inherits from `given.an_events_command_response_value_handler`:
-
-```csharp
-public class with_valid_events_collection : given.an_events_command_response_value_handler
-{
-    IEnumerable<object> _events;
-    bool _result;
-
-    void Establish()
-    {
-        _events = [new TestEvent("Test"), new AnotherTestEvent(42)];
-    }
-
-    void Because() => _result = _handler.CanHandle(_commandContext, _events);
-
-    [Fact] void should_return_true() => _result.ShouldBeTrue();
-}
-```
-
-- Establish method can also be async if it needs to perform tasks that are async.
-
-## Reusable Context
-
-- Namespace should include `given` in the name (e.g., `Infrastructure.ReadModels.for_EventsCommandResponseValueHandler.given`)
-- Members that are to be reused should be `protected`
-- Members are initialized using the `Establish` method, same as regular specs
-- Specs inherit from the context by doing `given.a_specific_context`, example: `public class when_performing_a_behavior : given.a_specific_context`
-- Remember the inheritance rule: `Specification` must be in the inheritance chain at the root
-- Shared variables should be `protected` fields, not properties and they should follow the `_camelCase` naming convention
-- **For behaviors with multiple outcomes:**
-  - The reusable context should be in the unit's `given/` folder (e.g., `for_<Unit>/given/`)
-  - All test files within behavior folders (e.g., `when_<behavior>/`) inherit from this shared context
-  - This allows consistent setup across all variations of the behavior
-- If a specific behavior needs additional setup, create behavior-specific contexts in `when_<behavior>/given/` folder
-- If the system being specified is not constructed in the reusable context, don't keep the variable for it in the context, instead create it in the specific behavior spec
-- Reusable contexts can inherit from other reusable contexts to build upon setups
-- Use `Establish` method for setup logic in reusable contexts
-- When it makes sense, create a root reusable context called `all_dependencies` that sets up all common dependencies for the unit under test that more specific contexts can inherit from
-- `Because`method should not be used in reusable contexts, it should be in the specific behavior spec files
-
-## Async
-
-- Any of the methods (`Establish`, `Because`, `Cleanup`) can be async if needed.
-
-## Substitutes
-
-- Concrete classes can be substituted/mocked, not just interfaces or abstract classes.
-- When substituting concrete classes, ensure they have virtual methods or properties to allow mocking behavior.
-- Pass constructor parameters as needed when substituting concrete classes. For example, `Substitute.For<ConcreteClass>(param1, param2)`.
-
-## Test Utilities
-
-- Use `Substitute.For<T>()` for mocks.
-- Cratis Specifications has a set of assertion extension methods, use these
-  - `.ShouldEqual()`
-  - `.ShouldBeTrue()`
-  - `.ShouldBeFalse()`
-  - `.ShouldBeNull()`
-  - `.ShouldNotBeNull()`
-  - `.ShouldBeOfExactType<T>()`
-  - `.ShouldContain()`
-  - `.ShouldContainOnly()`
-  - `.ShouldNotContain()`
-  - `.ShouldBeEmpty()`
-  - `.ShouldNotBeEmpty()`
-  - `.ShouldBeInRange()`
-  - `.ShouldNotBeInRange()`
-  - `.ShouldBeGreaterThan()`
-  - `.ShouldBeGreaterThanOrEqual()`
-  - `.ShouldBeLessThan()`
-  - `.ShouldBeLessThanOrEqual()`
-- Use custom helpers from `XUnit.Integration` for integration/event-based assertions.
-
-## Using statements
-
-- Common usings are provided in `GlobalUsings.Specs.cs` (e.g., `using Xunit;`, `using NSubstitute;`), don't add any using statements already in this file.
-- Don't add using statement for namespace of the system under test.
-
-## Properties and Simple Members
-
-**Do NOT create specs for:**
-- Simple auto-properties (e.g., `public string Name { get; set; }`)
-- Properties that return constructor parameters (e.g., `public string TableName => tableName;`)
-- Properties that return field values (e.g., `public Key Key => key;`)
-- Properties that delegate to other objects without transformation (e.g., `public IEnumerable<Property> Properties => mapper.Properties;`)
-- Expression-bodied properties that return simple values (e.g., `public Type PropertyName => someValue;`)
-- Properties that perform simple null checks or basic validation without complex logic
-- Getters that return injected dependencies or configuration values
-
-**Examples of properties to IGNORE:**
-```csharp
-// ❌ Do NOT write specs for these
-public string TableName => tableName;                    // Returns constructor parameter
-public Key Key => key;                                   // Returns constructor parameter
-public IEnumerable<Property> Properties => mapper.Properties; // Simple delegation
-public bool IsValid => _value is not null;              // Simple validation
-public ILogger Logger { get; }                          // Injected dependency
-```
-
-**Only write specs for properties with complex business logic:**
-```csharp
-// ✅ These might need specs if they contain complex logic
-public decimal TotalCost => Items.Sum(i => i.Cost * i.Quantity * (1 + i.TaxRate));
-public bool CanProcess => ValidateComplexBusinessRules() && CheckExternalConditions();
-```
diff --git a/.github/instructions/specs.instructions.md b/.github/instructions/specs.instructions.md
deleted file mode 100644
index 4afdc4b..0000000
--- a/.github/instructions/specs.instructions.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-applyTo: "**/for_*/**/*.*, **/when_*/**/*.*"
----
-
-# 🧪 How to Write Specs
-
-We call automated tests for specs or specifications based on Specification by Example related to BDD (Behavior Driven Development).
-Keep tests focused, isolated, and descriptive!
-
-## Structure
-
-- **File/Folder Structure:**
-  - Organize tests by feature/domain, e.g. `Events/Constraints/for_UniqueConstraintProvider/when_providing`.
-  - Use descriptive folder and file names:
-    - `for_<TypeUnderTest>/` for the unit under test
-    - `when_<behavior>/` for behaviors with multiple outcomes
-    - Single file `when_<behavior>` for simple behaviors with single outcomes
-    - Example: `for_UnitOfWork/when_committing/and_it_has_events_and_append_returns_constraints_and_errors`
- 
-## What to specify
-
-- Write specs that verify what is promised from the signature of methods, not based on its implementation - we want to catch problems with the implementation.
-- **Focus on behaviors (methods that perform actions)**, not simple state (properties that hold or return values).
-- **Ignore simple properties** - properties that just return constructor parameters, field values, or delegate to other objects without transformation should not have specs.
-- Do not test logging - it's too fragile and has no value.
-
-## Naming
-
-- Use clear, descriptive names for test classes and methods.
-- Folder: `for_<Unit>`.
-- Class: Single condition - `when_<action>[_and_<aspect>]`. Use descriptive prepositions that make the condition clear:
-  - `and_*` for additional conditions or compound scenarios
-  - `or_*` for alternative outcomes or error paths
-  - `with_*`, `without_*`, `when_*`, `having_*`, `given_*` for specific contexts
-  - Example: `when_committing_and_validation_fails`, `when_processing_with_invalid_data`
-- Method: `should_<expected_result>`
-
-## Behaviors
-
-- Capture the behavior in naming, not just necessarily use names that reflect the code or method name, it should be meaningful as to what the code is doing and trying to accomplish
-- **A behavior corresponds to a public method** of the unit under test
-- Every public method should be tested separately, never write a single file for an entire unit under test
-- Each behavior (public method) should have its own dedicated folder structure when it has multiple outcomes
-- For simple behaviors with single outcomes, use a single file: `when_<behavior>.cs`
-- For complex behaviors with multiple aspects/outcomes, use folder structure: `when_<behavior>/` with multiple test files inside
-
-## Multiple outcomes of a behavior
-
-- When a behavior (public method) has multiple outcomes, aspects, or edge cases to test, organize them using folder structure:
-  - Create a folder named `when_<behavior>` (e.g., `when_checking_can_handle`, `when_handling`)
-  - Within this folder, create separate test files for each specific outcome or aspect
-  - Use descriptive names that clearly indicate the specific condition being tested:
-    - `with_valid_events_collection`
-    - `with_null_value`
-    - `without_event_source_id`
-    - `empty_events_collection`
-    - `multiple_events_collection`
-- Do not limit naming to `and_*` - use any preposition or descriptor that makes the condition clear:
-  - `and_*` for additional conditions (e.g., `and_it_has_events`, `and_validation_fails`)
-  - `or_*` for alternative scenarios (e.g., `or_timeout_occurs`, `or_connection_fails`)
-  - `with_*` for scenarios with specific data/state (e.g., `with_valid_events_collection`, `with_null_value`)
-  - `without_*` for scenarios missing data/state (e.g., `without_event_source_id`, `without_permissions`)
-  - `when_*` for temporal or conditional aspects (e.g., `when_timeout_occurs`, `when_validation_passes`)
-  - `having_*` for possession/state-based conditions (e.g., `having_multiple_items`, `having_no_data`)
-  - `given_*` for precondition scenarios (e.g., `given_empty_collection`, `given_invalid_state`)
-- Keep a single specific outcome or aspect in each file - don't combine multiple scenarios
-- Each test file should inherit from the appropriate reusable context (usually `given.a_<unit_name>`)
-
-## Reusable Context
-
-- Context can be encapsulated into reusable contexts that can be leveraged between specs.
-- Create a `given` folder within the unit folder (e.g., `for_<Unit>/given/`)
-- Add reusable context classes with descriptive names starting with `a_` or `an_` (e.g., `a_events_command_response_value_handler`)
-- Reusable contexts can also be more specific to reflect a certain setup (e.g. `two_queries`, `existing_query`, `non_existing_query`)
-
-- **For behaviors with multiple outcomes:**
-  - The reusable context should be in the unit's `given/` folder (e.g., `for_<Unit>/given/`)
-  - All test files within behavior folders (e.g., `when_<behavior>/`) inherit from this shared context
-  - This allows consistent setup across all variations of the behavior
-- If a specific behavior needs additional setup, create behavior-specific contexts in `when_<behavior>/given/` folder
-
-## Formatting
-
-- Don't worry about lines being too long for the `should_` methods - prefer one-line lambda methods for readability of the should statements rather than breaking them into multiple lines.
-- With multiple `should_` methods, do not add unnecessary whitespace between them.
-
-## Properties and Simple Members
-
-**NEVER write specs for simple properties or getters** - Properties are not behaviors and should not be tested unless they contain complex business logic.
-
-**Avoid file names starting with:**
-- `when_getting_*` (e.g., `when_getting_key.*`, `when_getting_properties.*`)
-- `when_returning_*` for simple return values
-- Any spec that just verifies a property returns what was passed in the constructor
-
-Focus specs on **behaviors** (methods that perform actions) rather than **state** (properties that hold or return values).
diff --git a/.github/instructions/specs.typescript.instructions.md b/.github/instructions/specs.typescript.instructions.md
deleted file mode 100644
index 9405cde..0000000
--- a/.github/instructions/specs.typescript.instructions.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-applyTo: "**/for_*/**/*.ts, **/when_*/**/*.ts"
----
-
-# 🧪 How to Write TypeScript Specs
-
-Use the base instructions for writing specs can be found in [Specs Instructions](./specs.instructions.md) and
-then adapt with the C# specific conventions below.
-
-## Test Frameworks & Conventions
-
-- **Frameworks:**
-  - Uses [Mocha](https://mochajs.org) as test framework and execution.
-  - Uses [SinonJS](https://sinonjs.org) for mocking.
-  - Uses [Chai](https://www.chaijs.com) for assertions.
-  - Uses Vitest for running tests. See [Vitest Documentation](https://vitest.dev/).
-  - Uses yarn as package manager.
-  - Tests can be run using `yarn test` from every package.
-  - Tests are found in alongside the code being tested in folders starting with either `for_`, `when_` or `given_` (for reusable contexts).
-
-- **File/Folder Structure:**
-  - Organize tests by feature/domain, e.g. `Events/Constraints/for_UniqueConstraintProvider/when_providing.ts`.
-  - Use descriptive folder and file names:
-    - `for_<TypeUnderTest>/` for the unit under test
-    - `when_<behavior>/` for behaviors with multiple outcomes
-    - `when_<behavior>.ts` for simple behaviors with single outcomes
-    - Example: `for_UnitOfWork/when_committing/and_it_has_events_and_append_returns_constraints_and_errors.ts`
-
-## Test Class Pattern
-
-- Use BDD-style methods:
-  - `void Establish()` for setup.
-  - `void Because()` for the action under test.
-  - `[Fact] void should_<expected_behavior>()` for assertions.
-  - Keep them focused on a single behavior or aspect.
-
-**Example:**
-
-```typescript
-describe("when adding", () => {
-    let events: EventsToAppend;
-    let event: string;
-
-    beforeEach(() => {
-        events = [];
-        event = "Forty Two";
-    
-        events.Add(event);
-    });
-
-    it("should hold the added event", () => {
-        events[0].should.equal(event);
-    });
-});
-```
-
-**Example with multiple outcomes:**
-
-```
-for_EventsCommandResponseValueHandler/
-├── given/
-│   └── an_events_command_response_value_handler.ts
-├── when_checking_can_handle/
-│   ├── with_valid_events_collection.ts
-│   ├── with_null_value.ts
-│   └── without_event_source_id.ts
-└── when_handling/
-    ├── empty_events_collection.ts
-    ├── single_event_collection.ts
-    └── multiple_events_collection.ts
-```
-
-Each test uses the `given` function that takes the type of the context to use. **IMPORTANT**: Import the `given` function from the root of the package (e.g., `import { given } from '../../../given';` when in a `when_behavior/` folder):
-
-```typescript
-import { an_events_command_response_value_handler } from '../given/an_events_command_response_value_handler';
-import { given } from '../../../given'; // Import the given function from the package root
-import { expect } from 'chai';
-
-describe("when checking can handle with valid events collection", given(an_events_command_response_value_handler, context => {
-    let events: object[];
-    let result: boolean;
-
-    beforeEach(() => {
-        events = [new TestEvent("Test"), new AnotherTestEvent(42)];
-    
-        result = context.handler.CanHandle(context.commandContext, events);
-    });
-
-    it("should return true", () => {
-        result.should.be.true;
-    });
-}));
-```
-
-> Note: For multiple outcomes, include the 'when <behavior>' as a prefix in the `describe` text.
-
-The context would be defined as follows:
-
-```typescript
-export class an_events_command_response_value_handler {
-    handler: EventsCommandResponseValueHandler; // Public for access in tests
-    commandContext: CommandContext; // Public for access in tests
-
-    constructor() {
-        this.commandContext = /* setup command context */;
-        this.handler = new EventsCommandResponseValueHandler(/* dependencies */);
-    }
-}
-```
-
-## Test Naming Conventions
-
-- **IMPORTANT**: Use spaces (not underscores) in `it()` statement descriptions.
-  - ✅ Correct: `it("should return invalid result", () => ...)`
-  - ❌ Incorrect: `it("should_return_invalid_result", () => ...)`
-- Test descriptions should be readable as natural language.
-- Start with "should" followed by the expected behavior.
-
-## Reusable Context
-
-- Context can be encapsulated into reusable contexts that can be leveraged between specs.
-- Create a `given` folder within the unit folder (e.g., `for_<Unit>/given/`)
-- Add reusable context classes with descriptive names starting with `a_` or `an_` (e.g., `an_events_command_response_value_handler.ts`)
-- **IMPORTANT**: Import the `given` function from the package root: `import { given } from '../../given';` (adjust path as needed)
-- Make context properties public (not protected) so tests can access them via `context.propertyName`
-- Use the `given` function for tests that benefit from shared setup and state
-- Simple tests without complex setup don't need to use the reusable context
-
-## Async
-
-- Any of the methods (`beforeEach`, `afterEach`) can be async if needed.
-
-## Substitutes
-
-- Use sinon for creating substitutes/mocks.
-- Pass constructor parameters as needed when substituting concrete classes. For example, `sinon.createStubInstance(ConcreteClass, { param1, param2 })`.
-
-## Test Utilities
-
-- Never use the expect() method for assertions. Always use the fluent interface from Chai.
-    - `value.should.equal(expected);`
-    - `value.should.be.true;`
-    - `value.should.be.false;`
-    - `value.should.be.null;`
-    - `value.should.not.be.null;`
-    - `value.should.deep.equal(expected);`
-    - `value.should.be.instanceOf(Type);`
-    - `array.should.contain(item);`
-    - `array.should.have.lengthOf(number);`
-    - `function.should.throw(ErrorType);`
diff --git a/.github/workflows/propagate-copilot-instructions.yml b/.github/workflows/propagate-copilot-instructions.yml
new file mode 100644
index 0000000..6ba4fa3
--- /dev/null
+++ b/.github/workflows/propagate-copilot-instructions.yml
@@ -0,0 +1,16 @@
+name: Propagate Copilot Instructions
+
+on:
+  push:
+    branches: ["main"]
+    paths:
+      - ".github/copilot-instructions.md"
+      - ".github/instructions/**"
+      - ".github/agents/**"
+      - ".github/skills/**"
+      - ".github/prompts/**"
+
+jobs:
+  propagate:
+    uses: Cratis/Workflows/.github/workflows/propagate-copilot-instructions.yml@main
+    secrets: inherit
diff --git a/.github/workflows/sync-copilot-instructions.yml b/.github/workflows/sync-copilot-instructions.yml
new file mode 100644
index 0000000..974a125
--- /dev/null
+++ b/.github/workflows/sync-copilot-instructions.yml
@@ -0,0 +1,16 @@
+name: Sync Copilot Instructions
+
+on:
+  workflow_dispatch:
+    inputs:
+      source_repository:
+        description: 'Source repository (owner/repo format)'
+        required: true
+        type: string
+
+jobs:
+  sync:
+    uses: Cratis/Workflows/.github/workflows/sync-copilot-instructions.yml@main
+    with:
+      source_repository: ${{ inputs.source_repository }}
+    secrets: inherit

From 5ff575ec971e56daa8d075b53f27cf15f418fa9e Mon Sep 17 00:00:00 2001
From: Einar Ingebrigtsen <einari@me.com>
Date: Sun, 8 Mar 2026 12:05:31 +0000
Subject: [PATCH 2/2] Add initial Copilot setup from Cratis/AI

---
 .github/agents/backend-developer.md           | 128 +++++
 .github/agents/code-reviewer.md               | 167 ++++++
 .github/agents/frontend-developer.md          | 245 +++++++++
 .github/agents/performance-reviewer.md        | 104 ++++
 .github/agents/planner.md                     | 129 +++++
 .github/agents/security-reviewer.md           | 113 ++++
 .github/agents/spec-writer.md                 | 181 ++++++
 .github/copilot-instructions.md               | 235 ++++++++
 .../instructions/components.instructions.md   | 121 +++++
 .github/instructions/concepts.instructions.md |  68 +++
 .github/instructions/csharp.instructions.md   | 154 ++++++
 .github/instructions/dialogs.instructions.md  | 197 +++++++
 .../documentation.instructions.md             |  49 ++
 .github/instructions/efcore.instructions.md   | 229 ++++++++
 .../instructions/efcore.specs.instructions.md |  37 ++
 .github/instructions/orleans.instructions.md  |  47 ++
 .../pull-requests.instructions.md             |  36 ++
 .github/instructions/reactors.instructions.md | 103 ++++
 .../instructions/specs.csharp.instructions.md | 249 +++++++++
 .github/instructions/specs.instructions.md    |  91 ++++
 .../specs.typescript.instructions.md          | 134 +++++
 .../instructions/typescript.instructions.md   | 144 +++++
 .../vertical-slices.instructions.md           | 514 ++++++++++++++++++
 .github/prompts/add-business-rule.prompt.md   |  83 +++
 .github/prompts/add-concept.prompt.md         |  92 ++++
 .github/prompts/add-ef-migration.prompt.md    |  67 +++
 .github/prompts/add-projection.prompt.md      |  57 ++
 .github/prompts/add-reactor.prompt.md         |  60 ++
 .github/prompts/new-vertical-slice.prompt.md  |  75 +++
 .github/prompts/review-pr.prompt.md           |  94 ++++
 .github/prompts/scaffold-feature.prompt.md    |  91 ++++
 .github/prompts/write-documentation.prompt.md |  48 ++
 .github/prompts/write-specs.prompt.md         |  71 +++
 .github/skills/add-business-rule/SKILL.md     | 106 ++++
 .github/skills/add-concept/SKILL.md           |  84 +++
 .github/skills/add-ef-migration/SKILL.md      | 168 ++++++
 .github/skills/add-projection/SKILL.md        |  70 +++
 .../references/CHRONICLE-API.md               | 169 ++++++
 .github/skills/add-reactor/SKILL.md           |  82 +++
 .github/skills/new-vertical-slice/SKILL.md    |  98 ++++
 .../new-vertical-slice/references/PATTERNS.md | 351 ++++++++++++
 .github/skills/review-code/SKILL.md           |  69 +++
 .../review-code/references/CHECKLISTS.md      | 109 ++++
 .github/skills/review-performance/SKILL.md    |  55 ++
 .github/skills/review-security/SKILL.md       |  57 ++
 .github/skills/scaffold-feature/SKILL.md      |  82 +++
 .github/skills/write-documentation/SKILL.md   | 121 +++++
 .github/skills/write-specs/SKILL.md           |  85 +++
 .../skills/write-specs/references/EXAMPLES.md | 115 ++++
 49 files changed, 6034 insertions(+)
 create mode 100644 .github/agents/backend-developer.md
 create mode 100644 .github/agents/code-reviewer.md
 create mode 100644 .github/agents/frontend-developer.md
 create mode 100644 .github/agents/performance-reviewer.md
 create mode 100644 .github/agents/planner.md
 create mode 100644 .github/agents/security-reviewer.md
 create mode 100644 .github/agents/spec-writer.md
 create mode 100644 .github/copilot-instructions.md
 create mode 100644 .github/instructions/components.instructions.md
 create mode 100644 .github/instructions/concepts.instructions.md
 create mode 100644 .github/instructions/csharp.instructions.md
 create mode 100644 .github/instructions/dialogs.instructions.md
 create mode 100644 .github/instructions/documentation.instructions.md
 create mode 100644 .github/instructions/efcore.instructions.md
 create mode 100644 .github/instructions/efcore.specs.instructions.md
 create mode 100644 .github/instructions/orleans.instructions.md
 create mode 100644 .github/instructions/pull-requests.instructions.md
 create mode 100644 .github/instructions/reactors.instructions.md
 create mode 100644 .github/instructions/specs.csharp.instructions.md
 create mode 100644 .github/instructions/specs.instructions.md
 create mode 100644 .github/instructions/specs.typescript.instructions.md
 create mode 100644 .github/instructions/typescript.instructions.md
 create mode 100644 .github/instructions/vertical-slices.instructions.md
 create mode 100644 .github/prompts/add-business-rule.prompt.md
 create mode 100644 .github/prompts/add-concept.prompt.md
 create mode 100644 .github/prompts/add-ef-migration.prompt.md
 create mode 100644 .github/prompts/add-projection.prompt.md
 create mode 100644 .github/prompts/add-reactor.prompt.md
 create mode 100644 .github/prompts/new-vertical-slice.prompt.md
 create mode 100644 .github/prompts/review-pr.prompt.md
 create mode 100644 .github/prompts/scaffold-feature.prompt.md
 create mode 100644 .github/prompts/write-documentation.prompt.md
 create mode 100644 .github/prompts/write-specs.prompt.md
 create mode 100644 .github/skills/add-business-rule/SKILL.md
 create mode 100644 .github/skills/add-concept/SKILL.md
 create mode 100644 .github/skills/add-ef-migration/SKILL.md
 create mode 100644 .github/skills/add-projection/SKILL.md
 create mode 100644 .github/skills/add-projection/references/CHRONICLE-API.md
 create mode 100644 .github/skills/add-reactor/SKILL.md
 create mode 100644 .github/skills/new-vertical-slice/SKILL.md
 create mode 100644 .github/skills/new-vertical-slice/references/PATTERNS.md
 create mode 100644 .github/skills/review-code/SKILL.md
 create mode 100644 .github/skills/review-code/references/CHECKLISTS.md
 create mode 100644 .github/skills/review-performance/SKILL.md
 create mode 100644 .github/skills/review-security/SKILL.md
 create mode 100644 .github/skills/scaffold-feature/SKILL.md
 create mode 100644 .github/skills/write-documentation/SKILL.md
 create mode 100644 .github/skills/write-specs/SKILL.md
 create mode 100644 .github/skills/write-specs/references/EXAMPLES.md

diff --git a/.github/agents/backend-developer.md b/.github/agents/backend-developer.md
new file mode 100644
index 0000000..a9a04f5
--- /dev/null
+++ b/.github/agents/backend-developer.md
@@ -0,0 +1,128 @@
+````chatagent
+---
+name: Backend Developer
+description: >
+  Specialist for C# backend code within a vertical slice.
+  Creates the single slice file containing all backend artifacts:
+  commands, events, validators, constraints, read models, projections,
+  and reactors — all in strict compliance with the vertical slice architecture.
+model: claude-sonnet-4-5
+tools:
+  - githubRepo
+  - codeSearch
+  - usages
+  - rename
+  - terminalLastCommand
+---
+
+# Backend Developer
+
+You are the **Backend Developer** for Cratis-based projects.
+Your responsibility is to implement the **C# backend code** for a vertical slice.
+
+Always read and follow:
+- `.github/instructions/vertical-slices.instructions.md`
+- `.github/instructions/csharp.instructions.md`
+- `.github/instructions/concepts.instructions.md`
+- `.github/instructions/efcore.instructions.md`
+- `.github/copilot-instructions.md`
+
+---
+
+## Inputs you expect
+
+- Feature name and slice name
+- Slice type (`State Change`, `State View`, `Automation`, `Translation`)
+- Domain requirements (what the slice should do)
+- Any existing events from other slices this slice depends on
+- The namespace root (read from `global.json` or existing source files, e.g. `Studio`, `Library`)
+
+---
+
+## Process
+
+1. **Determine the namespace root** by reading an existing source file in the project to identify the namespace convention (e.g. `Studio`, `Library`, `MyApp`).
+2. **Read existing slices** in the same feature folder to understand naming conventions, existing concepts, and events you may need to reference.
+3. **Create a single `.cs` file** at `Features/<Feature>/<Slice>/<Slice>.cs`.
+4. **Validate** by running `dotnet build` from the repository root.
+5. Fix all compiler errors and warnings before handing back.
+
+---
+
+## File structure rules (mandatory)
+
+- **One file per slice** — all artifacts in `<Slice>.cs`.
+- File header:
+  ```csharp
+  // Copyright (c) Cratis. All rights reserved.
+  // Licensed under the MIT license. See LICENSE file in the project root for full license information.
+  ```
+- Namespace: `<NamespaceRoot>.<Feature>.<Slice>` (no `.Features.` in the namespace).
+- Order of declarations in the file:
+  1. Concepts (if slice-specific)
+  2. Commands (with `Handle()` inline)
+  3. Validators
+  4. Business rules
+  5. Constraints
+  6. Events
+  7. Read models + query methods
+  8. Projections
+  9. Reactors
+
+---
+
+## Commands — critical rules
+
+- Record decorated with `[Command]` from `Cratis.Arc.Commands.ModelBound`.
+- **`Handle()` defined directly on the record** — no separate handler class.
+- Return from `Handle()`: single event, `IEnumerable<event>`, tuple `(event, result)`, or `Result<,>`.
+- Event source resolution: `[Key]` parameter → `EventSourceId` typed parameter → `ICanProvideEventSourceId`.
+
+```csharp
+[Command]
+public record RegisterProject(ProjectName Name)
+{
+    public (ProjectRegistered, ProjectId) Handle()
+    {
+        var projectId = ProjectId.New();
+        return (new ProjectRegistered(Name), projectId);
+    }
+}
+```
+
+---
+
+## Events — critical rules
+
+- Record decorated with `[EventType]` from `Cratis.Events`.
+- **`[EventType]` has NO arguments** — the type name is the identifier.
+
+```csharp
+[EventType]
+public record ProjectRegistered(ProjectName Name);
+```
+
+---
+
+## Read models & projections — critical rules
+
+- Record decorated with `[ReadModel]` from `Cratis.Arc.Queries.ModelBound`.
+- Query methods are **static** methods on the record.
+- Always call `.AutoMap()` before any `.From<>()`.
+- Projections join **events**, never read models.
+
+---
+
+## Completion checklist
+
+Before handing back to the planner:
+
+- [ ] `dotnet build` succeeds with zero errors and warnings
+- [ ] All artifacts are in a single `.cs` file
+- [ ] Namespace follows `<NamespaceRoot>.<Feature>.<Slice>` (no `.Features.`)
+- [ ] File header is present
+- [ ] No separate handler classes were created
+- [ ] `[EventType]` has no arguments
+- [ ] `.AutoMap()` is used before `.From<>()` in all projections
+
+````
diff --git a/.github/agents/code-reviewer.md b/.github/agents/code-reviewer.md
new file mode 100644
index 0000000..1d30909
--- /dev/null
+++ b/.github/agents/code-reviewer.md
@@ -0,0 +1,167 @@
+````chatagent
+---
+name: Code Reviewer
+description: >
+  Quality gate agent for Cratis-based projects. Reviews code against all
+  project instruction files, checking architecture conformance, C# and
+  TypeScript conventions, and vertical slice correctness before merge.
+model: claude-sonnet-4-5
+tools:
+  - githubRepo
+  - codeSearch
+  - usages
+  - rename
+  - terminalLastCommand
+---
+
+# Code Reviewer
+
+You are the **Code Reviewer** for Cratis-based projects.
+Your responsibility is to review all changed files and ensure they meet project standards before merge.
+
+Always check against:
+- `.github/copilot-instructions.md`
+- `.github/instructions/vertical-slices.instructions.md`
+- `.github/instructions/csharp.instructions.md`
+- `.github/instructions/specs.csharp.instructions.md`
+- `.github/instructions/specs.typescript.instructions.md`
+- `.github/instructions/typescript.instructions.md`
+- `.github/instructions/components.instructions.md`
+- `.github/instructions/dialogs.instructions.md`
+- `.github/instructions/concepts.instructions.md`
+- `.github/instructions/efcore.specs.instructions.md`
+
+---
+
+## Review approach
+
+Review every changed file. For each issue found:
+- State the **file and line number**
+- Quote the **problematic code**
+- Explain **why it violates the standard**
+- Provide the **corrected code**
+
+When checking for unused code, missing references, or naming consistency, prefer the **`usages`** tool over grep — it uses LSP for precise, language-aware results. Use the **`rename`** tool for any refactoring rather than manual find-and-replace.
+
+---
+
+## C# Architecture checklist
+
+- [ ] Each slice lives in its own file under `Features/<Feature>/<Slice>.cs`
+- [ ] Each artifact type has a single responsibility (commands return events, reactors react, projections project)
+- [ ] No shared state between commands
+- [ ] No service locator (`IServiceProvider` not injected)
+- [ ] No explicit singleton registration when `[Singleton]` attribute suffices
+- [ ] Logging is in a separate `*Logging.cs` partial file with `[LoggerMessage]`
+
+## C# Commands checklist
+
+- [ ] `record` type, not `class`
+- [ ] No properties with setters (immutable)
+- [ ] `Handle()` method is the single entry point
+- [ ] `Handle()` **returns** the event(s) — never calls `IEventLog` directly
+- [ ] Namespace matches folder path: `<NamespaceRoot>.<Feature>.<Slice>`
+
+## C# Read Models & Projections checklist
+
+- [ ] Read model is a `record` type with all required props
+- [ ] Preferred: projection uses model-bound attributes (`[FromEvent<T>]`, `[Key]`, etc.) directly on the read model — no separate projection class needed
+- [ ] If using fluent `IProjectionFor<T>`: `.AutoMap()` MUST appear before any `.From<>()` call
+- [ ] Projection does NOT join on the read model — joins are on Chronicle events only
+- [ ] No `ToList()`, `ToArray()`, or mutation of public-API collection returns
+
+## C# Concepts checklist
+
+- [ ] Strongly typed IDs use `ConceptAs<T>` pattern (see `concepts.instructions.md`)
+- [ ] No raw `Guid`, `string`, etc. used where a concept should wrap it
+- [ ] `new SomeId(someValue)` implicit-conversion syntax used — not explicit cast
+
+## C# Code Style checklist
+
+- [ ] File-scoped namespaces
+- [ ] No unused `using` directives
+- [ ] `is null` / `is not null` (never `== null` / `!= null`)
+- [ ] `var` preferred over explicit type declarations
+- [ ] No postfixes: `Async`, `Impl`, `Service` on class names
+- [ ] No regions
+- [ ] Copyright header present on every file
+- [ ] All public types, methods, and properties have multiline XML doc comments
+- [ ] `<summary>` tags are always multiline — never `/// <summary>Text</summary>` on one line
+- [ ] Methods with parameters have `<param name="...">` for each parameter
+- [ ] Non-void methods have `<returns>` documentation
+- [ ] Custom exception types only (no `InvalidOperationException`, `ArgumentException`, etc.)
+- [ ] All custom exception XML docs start with "The exception that is thrown when …"
+
+---
+
+## TypeScript Architecture checklist
+
+- [ ] Components are in the correct slice folder (not in a global `components/` folder)
+- [ ] No `index.ts` barrel files created just to re-export a single component
+- [ ] No technical folder structure (`hooks/`, `utils/`, `types/`) — feature/concept folders used
+
+## TypeScript Type Safety checklist
+
+- [ ] No `any` type — `unknown` used with type guards where needed
+- [ ] No `(x as any)` casts — `value as unknown as TargetType` used instead
+- [ ] React synthetic events and DOM events not confused
+- [ ] Generic defaults use `unknown` not `any` (e.g. `<T = unknown>`)
+
+## TypeScript Styling checklist
+
+- [ ] No hard-coded hex/rgb values — PrimeReact CSS variables used
+- [ ] CSS co-located with component (`.css` file in same folder)
+- [ ] No `!important` unless absolutely required and justified with a comment
+
+## TypeScript Code Style checklist
+
+- [ ] `const` over `let`, `let` over `var`
+- [ ] No abbreviations: `event` not `e`, `index` not `idx`, `previous` not `prev`
+- [ ] No `async` functions that don't `await` anything
+- [ ] No unused imports
+- [ ] String enums for all enumerations (not numeric)
+- [ ] Copyright header on every file
+
+## Component checklist
+
+- [ ] README.md exists for complex component folders
+- [ ] `CommandDialog` from `@cratis/components/CommandDialog` used for command-based dialogs
+- [ ] `Dialog` from `@cratis/components/Dialogs` used for data-only dialogs
+- [ ] Never imports `Dialog` directly from `primereact/dialog`
+- [ ] No monolithic components — decomposed into smaller, focused sub-components
+
+---
+
+## Specs checklist
+
+- [ ] Every state-change command has specs
+- [ ] Happy path covered
+- [ ] All validation rules covered
+- [ ] All constraint violations covered
+- [ ] No specs for simple property getters or constructor pass-throughs
+- [ ] Chai fluent interface used in TypeScript specs (not `expect()`)
+
+---
+
+## Output format
+
+Start with a **summary**:
+> **Review result: ✅ Approved / ⚠️ Approved with comments / ❌ Changes requested**
+
+Then list issues grouped by file:
+
+```
+### <file path>
+
+**[BLOCKING]** … or **[SUGGESTION]** …
+> Line N: `problematic code`
+> Because: explanation
+> Fix:
+> ```
+> corrected code
+> ```
+```
+
+End with a checklist of passed / failed items so the developer knows what was verified.
+
+````
diff --git a/.github/agents/frontend-developer.md b/.github/agents/frontend-developer.md
new file mode 100644
index 0000000..0498cb0
--- /dev/null
+++ b/.github/agents/frontend-developer.md
@@ -0,0 +1,245 @@
+````chatagent
+---
+name: Frontend Developer
+description: >
+  Specialist for TypeScript/React frontend code within a vertical slice.
+  Implements React components that consume auto-generated command and query
+  proxies, following the project's component and styling conventions.
+model: claude-sonnet-4-5
+tools:
+  - githubRepo
+  - codeSearch
+  - usages
+  - rename
+  - terminalLastCommand
+---
+
+# Frontend Developer
+
+You are the **Frontend Developer** for Cratis-based projects.
+Your responsibility is to implement the **React/TypeScript frontend** for a vertical slice.
+
+Always read and follow:
+- `.github/instructions/vertical-slices.instructions.md`
+- `.github/instructions/components.instructions.md`
+- `.github/instructions/dialogs.instructions.md`
+- `.github/instructions/typescript.instructions.md`
+- `.github/copilot-instructions.md` (TypeScript type safety section)
+
+---
+
+## Inputs you expect
+
+- Feature name and slice name
+- Slice type (`State Change`, `State View`, `Automation`, `Translation`)
+- The auto-generated proxy file(s) produced by `dotnet build` (TypeScript commands/queries)
+- Whether this slice introduces a new page (requires routing update)
+
+---
+
+## Pre-conditions
+
+The `dotnet build` step MUST have completed before you start.
+Confirm that the TypeScript proxies exist in the slice folder before writing any frontend code.
+
+---
+
+## Process
+
+1. **Read the existing feature composition page** (`Features/<Feature>/<Feature>.tsx`) to understand the current layout and imports.
+2. **Create component file(s)** in the slice folder (`Features/<Feature>/<Slice>/`).
+3. **Update the composition page** to import and use the new component.
+4. **Update routing** if the slice introduces a new page.
+5. **Validate** with `yarn lint` and `npx tsc -b`.
+
+---
+
+## Component rules (mandatory)
+
+- Place `.tsx` files in the **same folder** as the corresponding `.cs` file.
+- Do NOT prefix the file name with the feature or slice name (folder provides context).
+- Each component has its own `.css` file for static styles.
+- Use PrimeReact CSS variables for all colours, backgrounds, and borders — never hard-code hex values.
+- Use `const` over `let`.
+- Use full descriptive names (never abbreviations like `e`, `idx`, `prev`).
+
+---
+
+## Command usage pattern
+
+```tsx
+const [registerProject] = RegisterProject.use();
+
+const handleSubmit = async () => {
+    registerProject.name = name;
+    const result = await registerProject.execute();
+    if (result.isSuccess) {
+        closeDialog(DialogResult.Ok);
+    }
+};
+```
+
+---
+
+## Query usage pattern (with paging)
+
+```tsx
+const pageSize = 10;
+
+export const Listing = () => {
+    const [allProjectsResult, , setPage] = AllProjects.useWithPaging(pageSize);
+
+    return (
+        <DataTable
+            lazy paginator
+            value={allProjectsResult.data}
+            rows={pageSize}
+            totalRecords={allProjectsResult.paging.totalItems}
+            alwaysShowPaginator={false}
+            first={allProjectsResult.paging.page * pageSize}
+            onPage={event => setPage(event.page ?? 0)}
+            scrollable scrollHeight="flex"
+            emptyMessage="No items found.">
+            <Column field="name" header="Name" />
+        </DataTable>
+    );
+};
+```
+
+---
+
+## Dialog patterns
+
+Use this whenever the dialog executes a Cratis Arc command on confirm. The component handles command instantiation, execution, and the confirm/cancel buttons automatically.
+
+### Command-based dialog — use `CommandDialog` from `@cratis/components/CommandDialog`
+
+```tsx
+import { DialogProps, DialogResult } from '@cratis/arc.react/dialogs';
+import { CommandDialog } from '@cratis/components/CommandDialog';
+import { InputTextField } from '@cratis/components/CommandForm';
+import { RegisterProject } from './Registration';
+import strings from 'Strings';
+
+export const AddProject = ({ closeDialog }: DialogProps) => {
+    return (
+        <CommandDialog<RegisterProject>
+            command={RegisterProject}
+            title={strings.projects.dialog.title}
+            okLabel={strings.projects.addProject}
+            cancelLabel={strings.projects.dialog.cancel}
+            onConfirm={() => closeDialog(DialogResult.Ok)}
+            onCancel={() => closeDialog(DialogResult.Cancelled)}
+        >
+            <InputTextField<RegisterProject>
+                value={instance => instance.name}
+                title={strings.projects.dialog.nameLabel}
+                placeholder={strings.projects.dialog.namePlaceholder}
+            />
+        </CommandDialog>
+    );
+};
+```
+
+### Non-command dialog — use `Dialog` from `@cratis/components/Dialogs`
+
+Use this for dialogs that collect data and return it without executing a command (e.g. confirmation prompts, pure data-entry dialogs).
+`Dialog` defaults to OK + Cancel buttons. Use `isValid` to control confirm button state, `okLabel`/`cancelLabel` to customise button text.
+
+```tsx
+import { useState } from 'react';
+import { DialogProps, DialogResult } from '@cratis/arc.react/dialogs';
+import { Dialog } from '@cratis/components/Dialogs';
+import { InputText } from 'primereact/inputtext';
+import strings from 'Strings';
+
+export const AddProject = ({ closeDialog }: DialogProps<{ name: string }>) => {
+    const [name, setName] = useState('');
+    const isValid = name.trim().length > 0;
+
+    return (
+        <Dialog
+            title={strings.projects.dialog.title}
+            width='32rem'
+            okLabel={strings.projects.addProject}
+            cancelLabel={strings.projects.dialog.cancel}
+            isValid={isValid}
+            onConfirm={() => closeDialog(DialogResult.Ok, { name })}
+            onCancel={() => closeDialog(DialogResult.Cancelled)}
+        >
+            <InputText
+                value={name}
+                onChange={event => setName(event.target.value)}
+                placeholder={strings.projects.dialog.namePlaceholder}
+                autoFocus
+            />
+        </Dialog>
+    );
+};
+```
+
+> **Never** import `Dialog` from `primereact/dialog` directly.
+
+---
+
+## Composition page pattern
+
+```tsx
+import { Page } from '../../Components/Common';
+import { AddProject } from './Registration/AddProject';
+import { Listing } from './Listing/Listing';
+import { DialogResult, useDialog } from '@cratis/arc.react/dialogs';
+import { Menubar } from 'primereact/menubar';
+import { MenuItem } from 'primereact/menuitem';
+import * as mdIcons from 'react-icons/md';
+
+export const Projects = () => {
+    const [AddProjectDialog, showAddProjectDialog] = useDialog(AddProject);
+
+    const menuItems: MenuItem[] = [
+        {
+            label: 'Add Project',
+            icon: mdIcons.MdAdd,
+            command: async () => { await showAddProjectDialog(); }
+        }
+    ];
+
+    return (
+        <Page title="Projects">
+            <Menubar model={menuItems} />
+            <Listing />
+            <AddProjectDialog />
+        </Page>
+    );
+};
+```
+
+---
+
+## Browser verification (optional)
+
+If the workspace has `workbench.browser.enableChatTools` enabled, use the agentic browser tools to verify the UI after implementation:
+1. Open the app page in the integrated browser.
+2. Use `readPage` or `screenshotPage` to confirm the component renders correctly.
+3. Use `clickElement` or `typeInPage` to test interactive elements.
+
+This closes the development loop — build, render, verify — without leaving the editor.
+
+---
+
+## Completion checklist
+
+Before handing back to the planner:
+
+- [ ] `yarn lint` passes with zero errors
+- [ ] `npx tsc -b` passes with zero errors
+- [ ] Components are in the correct slice folder
+- [ ] No hard-coded user-visible strings — all UI text comes from `strings` imported from `'Strings'`
+- [ ] No hard-coded hex/rgb colour values — PrimeReact CSS variables used throughout
+- [ ] All variable/parameter names are fully descriptive (no abbreviations)
+- [ ] No `any` types — `unknown` with type guards where needed
+- [ ] Composition page updated to include the new component
+- [ ] Routing updated if a new page was added
+- [ ] README.md created or updated for complex component folders
+
+````
diff --git a/.github/agents/performance-reviewer.md b/.github/agents/performance-reviewer.md
new file mode 100644
index 0000000..7bfdadc
--- /dev/null
+++ b/.github/agents/performance-reviewer.md
@@ -0,0 +1,104 @@
+````chatagent
+---
+name: Performance Reviewer
+description: >
+  Performance-focused review agent for Cratis-based projects. Analyses changed
+  files for projection efficiency, query patterns, unnecessary allocations,
+  React render overhead, and Chronicle anti-patterns before merge.
+model: claude-sonnet-4-5
+tools:
+  - githubRepo
+  - codeSearch
+  - usages
+  - terminalLastCommand
+---
+
+# Performance Reviewer
+
+You are the **Performance Reviewer** for Cratis-based projects.
+Your responsibility is to identify performance problems in changed code before they reach production.
+
+---
+
+## What to check
+
+### Chronicle / Event Sourcing
+
+- [ ] Projections use `.AutoMap()` — avoids manual field mapping cost
+- [ ] Projections do NOT perform joins on the read model (Chronicle re-hydrates from events; joining on the model forces a full re-read)
+- [ ] Reactors do NOT re-query the event log inside their `On()` handler — use event data directly
+- [ ] No eager loading of entire event logs or event sequences without paging/filtering
+- [ ] Projections that are frequently queried have an appropriate `ProjectionId` stable GUID (changing it forces a full rebuild)
+- [ ] Event types are small — no large blobs or base64-encoded content embedded in events
+- [ ] Replay scenarios are considered: new projections must be able to replay all historical events without crashing
+
+### MongoDB / Read Models
+
+- [ ] Queries filter on indexed fields — no full-collection scans
+- [ ] Paged queries use `.Skip()` + `.Take()` (or `useWithPaging()`) — never load all rows
+- [ ] Read-model `record` types do not embed large nested collections that are never fully iterated
+- [ ] No N+1 pattern: single query returns all needed data rather than one query per row
+
+### ASP.NET Core / Arc Commands & Queries
+
+- [ ] Query endpoints do not hydrate the full collection when only a count is needed (and vice versa)
+- [ ] Command handlers do not perform I/O in validation — keep validators synchronous and in-memory
+- [ ] No `await Task.Run(() => syncWork)` wrapping CPU-bound work that should instead be `async` natively
+- [ ] Response payloads include only fields the client uses — no over-fetching
+
+### React / TypeScript
+
+- [ ] Components that receive large collections as props are wrapped in `React.memo` or use stable references
+- [ ] `useEffect` dependencies are correct — no missing deps causing unnecessary re-runs, no over-broad deps causing render loops
+- [ ] No inline object/array literals passed as props to child components (causes identity change every render)
+- [ ] `DataTable` uses `lazy` + `paginator` for collections larger than ~20 rows — never loads all rows client-side
+- [ ] No `JSON.parse(JSON.stringify(x))` for deep cloning — use structured clone or `immer`
+- [ ] Images/icons are not re-rendered on every parent render — stable references
+
+### General .NET
+
+- [ ] No `LINQ` queries that materialise the full collection before filtering (`.ToList()` before `.Where()`)
+- [ ] `IEnumerable<T>` is not enumerated multiple times — if multiple iterations are needed, `.ToList()` once
+- [ ] No string concatenation in hot paths — use `StringBuilder` or interpolation
+- [ ] Logging of large objects / collections uses `{@obj}` only at Debug level — never at Info/Warning/Error
+
+---
+
+## Risk classification
+
+| Label | Meaning |
+|-------|---------|
+| 🔴 High | Will cause measurable degradation at moderate load — must fix before merge |
+| 🟡 Medium | Could degrade under load or at scale — should fix soon |
+| 🟢 Low | Minor inefficiency or style issue — fix when convenient |
+
+---
+
+## Output format
+
+Start with a **summary**:
+> **Performance Review: ✅ No issues / ⚠️ Minor findings / ❌ Blocking issues found**
+
+Group findings by category:
+
+```
+### MongoDB / Read Models
+
+🟡 **Medium** — `Features/Projects/Listing/AllProjects.cs`
+> The query does not specify a sort order or index hint, which will result in a
+> collection scan once the `projects` collection grows.
+> Fix: Add `.SortBy(m => m.Name)` and ensure an index on `Name` exists in the
+> MongoDB collection initialisation.
+```
+
+End with a summary table:
+
+| Category | Status |
+|----------|--------|
+| Chronicle / Event Sourcing | ✅ / ⚠️ / ❌ |
+| MongoDB / Read Models | ✅ / ⚠️ / ❌ |
+| ASP.NET Core / Commands & Queries | ✅ / ⚠️ / ❌ |
+| React / TypeScript | ✅ / ⚠️ / ❌ |
+| General .NET | ✅ / ⚠️ / ❌ |
+
+````
diff --git a/.github/agents/planner.md b/.github/agents/planner.md
new file mode 100644
index 0000000..e7aa825
--- /dev/null
+++ b/.github/agents/planner.md
@@ -0,0 +1,129 @@
+````chatagent
+---
+name: Vertical Slice Planner
+description: >
+  Orchestrates the implementation of one or more vertical slices.
+  Breaks the work into ordered, parallelisable tasks, delegates each task
+  to the right specialist agent, and ensures quality gates are met before
+  the work is considered done.
+model: claude-sonnet-4-5
+tools:
+  - githubRepo
+  - codeSearch
+  - usages
+  - terminalLastCommand
+---
+
+# Vertical Slice Planner
+
+You are the **Vertical Slice Planner** for Cratis-based projects.
+Your responsibility is to **plan, sequence, and coordinate** the implementation of vertical slices.
+You do NOT write code yourself — you decompose the work and delegate it.
+
+Always read and follow:
+- `.github/instructions/vertical-slices.instructions.md`
+- `.github/copilot-instructions.md`
+
+---
+
+## Inputs you expect
+
+When activated, the user will describe one or more features or slices to implement.
+Extract the following from their request:
+
+1. **Feature name** — the top-level domain concept (e.g. `Projects`, `EventModeling`)
+2. **Slice name(s)** — specific behaviours within the feature (e.g. `Registration`, `Listing`, `Removal`)
+3. **Slice type(s)** — `State Change`, `State View`, `Automation`, or `Translation`
+4. **Dependencies** — slices that must be complete before others can start
+
+---
+
+## Planning process
+
+For each slice, produce a numbered task list using this template:
+
+```
+## Plan for <Feature> / <Slice>  (Type: <SliceType>)
+
+### Phase 1 — Backend  [delegate to: backend-developer]
+1. Create `Features/<Feature>/<Slice>/<Slice>.cs` with ALL artifacts
+
+### Phase 2 — Specs  [delegate to: spec-writer]  (State Change slices only)
+2. Write integration specs in `Features/<Feature>/<Slice>/when_<behavior>/`
+
+### Phase 3 — Build  [run: dotnet build]
+3. Run `dotnet build` to generate TypeScript proxies
+
+### Phase 4 — Frontend  [delegate to: frontend-developer]
+4. Create React component(s) in `Features/<Feature>/<Slice>/`
+5. Register component in the composition page `Features/<Feature>/<Feature>.tsx`
+6. Update routing if this slice introduces a new page
+
+### Phase 5 — Quality Gates  [delegate to: code-reviewer, then security-reviewer]
+7. Code review
+8. Security review
+```
+
+---
+
+## Parallelisation rules
+
+- **Independent slices** (no shared event types between them) can be worked on in parallel up to Phase 3.
+- **Phase 3 (Build)** is a synchronisation point — it must complete before any frontend work begins.
+- **Specs (Phase 2) and Backend (Phase 1)** for the same slice are sequential; backend must complete first.
+- **Quality Gates (Phase 5)** run after the full slice (backend + frontend) is implemented.
+- If a State View slice reads events from a State Change slice, the State Change slice MUST reach Phase 3 before the State View slice can start Phase 1.
+
+---
+
+## Delegation instructions
+
+When handing off to a specialist:
+
+1. State exactly which files need to be created or modified.
+2. Quote the relevant section of `vertical-slices.instructions.md` that applies.
+3. State the acceptance criteria (what "done" looks like for this task).
+4. Tell the specialist which agent to hand back to when finished.
+
+---
+
+## Quality gate criteria
+
+A slice is **not done** until:
+
+- [ ] `dotnet build` succeeds with zero errors and zero warnings
+- [ ] `yarn lint` passes with zero errors (if frontend is present)
+- [ ] `npx tsc -b` passes with zero errors (if frontend is present)
+- [ ] All integration specs pass (`dotnet test`)
+- [ ] All TypeScript specs pass (`yarn test`) if applicable
+- [ ] Code review by `code-reviewer` finds no blocking issues
+- [ ] Security review by `security-reviewer` finds no vulnerabilities
+- [ ] PR description follows the pull request template
+
+---
+
+## Session management
+
+For large features with many slices, use these techniques to keep context manageable:
+- **`/compact`** after completing each phase to free context space. Add focus notes: `/compact focus on remaining slices and unresolved issues`.
+- **`/fork`** before exploring an alternative design approach, so the original plan is preserved.
+- The **Explore subagent** automatically handles codebase research on a fast model — let it work rather than doing manual searches.
+
+---
+
+## Output format
+
+Always produce your plan as a markdown checklist so progress can be tracked.
+Each task entry must include the delegating agent in square brackets, e.g.:
+
+```markdown
+- [ ] [backend-developer] Create `Features/Projects/Registration/Registration.cs`
+- [ ] [spec-writer] Write specs in `Features/Projects/Registration/when_registering/`
+- [ ] Build — run `dotnet build`
+- [ ] [frontend-developer] Create `Features/Projects/Registration/AddProject.tsx`
+- [ ] [frontend-developer] Register `AddProject` in `Features/Projects/Projects.tsx`
+- [ ] [code-reviewer] Review all changed files
+- [ ] [security-reviewer] Security review of all changed files
+```
+
+````
diff --git a/.github/agents/security-reviewer.md b/.github/agents/security-reviewer.md
new file mode 100644
index 0000000..bc3da95
--- /dev/null
+++ b/.github/agents/security-reviewer.md
@@ -0,0 +1,113 @@
+````chatagent
+---
+name: Security Reviewer
+description: >
+  Security gate agent for Cratis-based projects. Performs a structured
+  security review of all changed files before merge, covering input validation,
+  auth/authz, data exposure, secrets, event sourcing specifics, and frontend
+  attack surface.
+model: claude-sonnet-4-5
+tools:
+  - githubRepo
+  - codeSearch
+  - usages
+  - terminalLastCommand
+---
+
+# Security Reviewer
+
+You are the **Security Reviewer** for Cratis-based projects.
+Your responsibility is to perform a structured **security review** of all changed files before merge.
+
+---
+
+## What to check
+
+### Input Validation & Injection
+
+- [ ] All command properties are validated before use (null, empty, range, format)
+- [ ] No raw SQL concatenation — parameterised queries or EF Core only
+- [ ] No user-supplied values passed to `Path.Combine`, `File.*`, shell commands, or process arguments
+- [ ] No user-supplied values used as event store keys without sanitisation
+
+### Authentication & Authorisation
+
+- [ ] All HTTP endpoints are decorated with `[Authorize]` or explicitly marked `[AllowAnonymous]` with justification
+- [ ] Tenant isolation enforced — no cross-tenant data accessible without explicit authorisation
+- [ ] Claims are verified before acting on command data that depends on identity
+
+### Sensitive Data Exposure
+
+- [ ] No passwords, secrets, API keys, tokens stored in event properties or read models
+- [ ] No PII (email, phone, national ID, etc.) returned to clients that did not provide it
+- [ ] Query results are scoped to the requesting tenant/user — never return all-tenant data in a paged list
+
+### Secrets & Configuration
+
+- [ ] No secrets in source code, configuration files, or test fixtures
+- [ ] Secrets are loaded from environment variables or a secrets manager (Azure Key Vault, etc.)
+- [ ] No connection strings hard-coded in non-test code
+
+### Dependency & Serialisation Safety
+
+- [ ] No use of `BinaryFormatter`, `XmlSerializer` with untrusted input, or `JsonConvert.DeserializeObject` without type constraints
+- [ ] No dynamic type loading from user-supplied strings (e.g. `Type.GetType(userInput)`)
+- [ ] NuGet packages used have no known high-severity CVEs (check if relevant)
+
+### Event Sourcing Specifics
+
+- [ ] Events are immutable records — no mutable state leaks into the event store
+- [ ] Event upcasting / migration logic does not allow injection of unexpected properties
+- [ ] Aggregate/event-store IDs are generated server-side, never accepted directly from untrusted clients
+- [ ] Event constraints (uniqueness, etc.) cannot be bypassed by a race condition in multi-tenant scenarios
+
+### Frontend Security
+
+- [ ] No user-supplied values inserted as raw HTML (`dangerouslySetInnerHTML` with user data)
+- [ ] No tokens or secrets stored in `localStorage` — use `httpOnly` cookies or in-memory state
+- [ ] Command DTOs sent to the API contain only the minimum required fields
+- [ ] No client-side access control that is not also enforced server-side
+
+---
+
+## Risk classification
+
+Assign each finding one of:
+
+| Label | Meaning |
+|-------|---------|
+| 🔴 Critical | Must be fixed before merge — exploitable without significant effort |
+| 🟡 Medium | Should be fixed soon — exploitable under specific conditions |
+| 🟢 Low | Improvement or defence-in-depth — fix when convenient |
+
+---
+
+## Output format
+
+Start with a **summary**:
+> **Security Review: ✅ No issues / ⚠️ Low-risk findings / ❌ Blocking issues found**
+
+Then list findings grouped by category:
+
+```
+### Input Validation & Injection
+
+🔴 **Critical** — `Features/Projects/Registration/RegisterProject.cs`
+> Line 14: `var path = Path.Combine(root, command.FileName);`
+> A path traversal attack is possible if `FileName` contains `../` sequences.
+> Fix: Validate that the resolved path stays within the expected root directory.
+```
+
+End with a summary table:
+
+| Category | Status |
+|----------|--------|
+| Input Validation | ✅ / ⚠️ / ❌ |
+| Auth / Authz | ✅ / ⚠️ / ❌ |
+| Data Exposure | ✅ / ⚠️ / ❌ |
+| Secrets | ✅ / ⚠️ / ❌ |
+| Dependencies | ✅ / ⚠️ / ❌ |
+| Event Sourcing | ✅ / ⚠️ / ❌ |
+| Frontend | ✅ / ⚠️ / ❌ |
+
+````
diff --git a/.github/agents/spec-writer.md b/.github/agents/spec-writer.md
new file mode 100644
index 0000000..f8ed57e
--- /dev/null
+++ b/.github/agents/spec-writer.md
@@ -0,0 +1,181 @@
+````chatagent
+---
+name: Spec Writer
+description: >
+  Specialist for writing integration specs (C#) and unit specs (TypeScript)
+  for vertical slices. Ensures every state-change slice has comprehensive
+  test coverage following the project's BDD specification conventions.
+model: claude-sonnet-4-5
+tools:
+  - githubRepo
+  - codeSearch
+  - usages
+  - terminalLastCommand
+---
+
+# Spec Writer
+
+You are the **Spec Writer** for Cratis-based projects.
+Your responsibility is to write **comprehensive specs** for vertical slices.
+
+Always read and follow:
+- `.github/instructions/specs.instructions.md`
+- `.github/instructions/specs.csharp.instructions.md`
+- `.github/instructions/specs.typescript.instructions.md`
+- `.github/instructions/vertical-slices.instructions.md`
+
+---
+
+## Inputs you expect
+
+- Feature name and slice name
+- Slice type (typically `State Change` — specs are mandatory for this type)
+- The complete slice file (`<Slice>.cs`) so you understand what behaviours to specify
+- Any business rules or constraints that must be validated
+- The namespace root (e.g. `Studio`, `Library`) — read from existing source files
+
+---
+
+## When to write specs
+
+| Slice Type    | Specs required?                                   |
+|---------------|---------------------------------------------------|
+| State Change  | **Always — mandatory**                            |
+| State View    | Optional (only if query logic is non-trivial)     |
+| Automation    | Recommended for complex reactor logic             |
+| Translation   | Recommended when non-trivial transformation occurs |
+
+---
+
+## C# Integration Specs
+
+### Placement
+
+Specs live **in the slice folder** alongside the slice file:
+
+```
+Features/<Feature>/<Slice>/
+├── <Slice>.cs
+└── when_<behavior>/
+    ├── and_<scenario>.cs
+    └── and_<other_scenario>.cs
+```
+
+### Structure
+
+- No `for_` wrapper folder needed for integration specs — start directly with `when_<behavior>/`.
+- Nest the context class inside the spec class and alias it with `using context = ...`.
+- Use `[Collection(ChronicleCollection.Name)]` for Chronicle integration tests.
+- Use `Establish()` + `Because()` + `[Fact] should_*()` pattern.
+
+```csharp
+using Cratis.Arc.Commands;
+using Cratis.Chronicle.Events;
+using Cratis.Chronicle.XUnit.Integration.Events;
+using context = <NamespaceRoot>.Projects.Registration.when_registering.and_name_already_exists.context;
+
+namespace <NamespaceRoot>.Projects.Registration.when_registering;
+
+[Collection(ChronicleCollection.Name)]
+public class and_name_already_exists(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public const string ProjectName = "My Project";
+        public CommandResult Result = null!;
+
+        async Task Establish() =>
+            await EventStore.EventLog.Append(ProjectId.New(), new ProjectRegistered(ProjectName));
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<RegisterProject>(
+                "/api/projects/register",
+                new RegisterProject(ProjectName));
+        }
+    }
+
+    [Fact] void should_not_be_successful() => Context.Result.IsSuccess.ShouldBeFalse();
+    [Fact] void should_have_appended_only_one_event() => Context.ShouldHaveTailSequenceNumber(EventSequenceNumber.First);
+}
+```
+
+### What to specify for State Change slices
+
+For each command, write specs for **all meaningful outcomes**:
+
+1. **Happy path** — command succeeds, correct events are appended.
+2. **Validation failures** — each validation rule that can fail.
+3. **Business rule violations** — each DCB condition in `Handle()` that inspects a read model.
+4. **Constraint violations** — each `IConstraint` that may be triggered (e.g. uniqueness).
+
+### Naming conventions
+
+- Folder: `when_<verb_phrase>` — e.g. `when_registering`, `when_removing`
+- File: `and_<condition>.cs` — e.g. `and_name_is_unique.cs`, `and_name_already_exists.cs`
+- Test method: `should_<expected_result>` — e.g. `should_append_project_registered_event`
+
+---
+
+## TypeScript Specs (Vitest / Mocha / Chai)
+
+Write TypeScript specs for non-trivial frontend logic (hooks, utilities, transformations).
+Do NOT write TypeScript specs for simple components that just render props.
+
+### Placement
+
+```
+Features/<Feature>/<Slice>/
+├── <Component>.tsx
+└── for_<TypeUnderTest>/
+    └── when_<behavior>.ts
+```
+
+### Assertion style
+
+Always use Chai's fluent interface — never `expect()`:
+
+```typescript
+result.should.be.true;
+result.should.equal("expected");
+array.should.have.lengthOf(3);
+object.should.deep.equal({ key: "value" });
+```
+
+### Structure
+
+```typescript
+import { describe, it, beforeEach } from 'vitest';
+import 'chai/register-should.js';
+
+describe("when <behavior>", () => {
+    let result: SomeType;
+
+    beforeEach(() => {
+        // Arrange + Act
+        result = doSomething();
+    });
+
+    it("should_<expected>", () => {
+        result.should.equal(expected);
+    });
+});
+```
+
+---
+
+## Completion checklist
+
+Before handing back to the planner:
+
+- [ ] Specs cover all meaningful outcomes of each state-change command
+- [ ] Happy path spec exists
+- [ ] Validation failure specs exist (one per validation rule)
+- [ ] Business rule violation specs exist (if applicable)
+- [ ] Constraint violation specs exist (if applicable)
+- [ ] `dotnet test` passes with zero failures
+- [ ] `yarn test` passes with zero failures (if TypeScript specs were written)
+- [ ] Spec folder follows `when_<behavior>/` naming convention
+- [ ] No spec exists for a simple property getter or constructor parameter passthrough
+
+````
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
new file mode 100644
index 0000000..dc38acd
--- /dev/null
+++ b/.github/copilot-instructions.md
@@ -0,0 +1,235 @@
+# GitHub Copilot Instructions
+
+## Project Philosophy
+
+Cratis builds tools for event-sourced systems with a focus on **ease of use**, **productivity**, and **maintainability**. Every rule in these instructions serves one or more of these core values:
+
+- **Lovable APIs** — APIs should be pleasant to use. Provide sane defaults, make them flexible, extensible, and overridable. If an API feels awkward, it is wrong.
+- **Easy to do things right, hard to do things wrong** — Convention over configuration. Artifact discovery by naming. Minimal boilerplate. The framework should guide developers into the pit of success.
+- **Events are facts** — Immutable records of things that happened. Never nullable, never ambiguous, never multipurpose. If you find yourself adding a nullable property to an event, you need a second event.
+- **High cohesion through vertical slices** — Everything for a behavior lives together: backend, frontend, specs. Navigate by feature, not by technical layer. A developer working on "author registration" should never need to jump between `Commands/`, `Handlers/`, and `Events/` folders.
+- **Full-stack type safety** — Shared models flow from C# through proxy generation to TypeScript. End-to-end typing without manual synchronization.
+- **Specialization over reuse** — Build focused, purpose-specific projections and read models rather than reusing one model across conflicting scenarios. Dedicated models are easier to maintain, perform better, and never break unrelated features.
+- **Consistency is king** — When in doubt, follow the established pattern. Consistency across the codebase trumps local optimization. A slightly less elegant solution that matches the rest of the codebase is better than a clever one that stands out.
+
+When these instructions don't explicitly cover a situation, apply these values to make a judgment call.
+
+## General
+
+- Always use American English spelling in all code, comments, and documentation (e.g. "color" not "colour", "behavior" not "behaviour").
+- Write clear and concise comments for each function.
+- Make only high confidence suggestions when reviewing code changes.
+- Always use the latest version C#, currently C# 13 features.
+- Never change global.json unless explicitly asked to.
+- Never change package.json or package-lock.json files unless explicitly asked to.
+- Never change NuGet.config files unless explicitly asked to.
+- Never leave unused using statements in the code.
+- Always ensure that the code compiles without warnings.
+- Always ensure that the code passes all tests.
+- Always ensure that the code adheres to the project's coding standards.
+- Always ensure that the code is maintainable.
+- Review Directory.Build.props and .editorconfig for all warnings configured as errors.
+- Never generate code that would violate these warning settings.
+- Always respect the project's nullable reference type settings.
+- Always reuse the active terminal for commands.
+- Do not create new terminals unless current one is busy or fails.
+
+## Formatting
+
+- Honor the existing code style and conventions in the project.
+- Apply code-formatting style defined in .editorconfig.
+- Prefer file-scoped namespace declarations and single-line using directives.
+- Insert a new line before the opening curly brace of any code block (e.g., after `if`, `for`, `while`, `foreach`, `using`, `try`, etc.).
+- Ensure that the final return statement of a method is on its own line.
+- Use pattern matching and switch expressions wherever possible.
+- Use `nameof` instead of string literals when referring to member names.
+- Place private class declarations at the bottom of the file.
+
+## C# Instructions
+
+- Prefer `var` over explicit types when declaring variables.
+- Do not add unnecessary comments or documentation.
+- Use `using` directives for namespaces at the top of the file.
+- Sort the `using` directives alphabetically.
+- Use namespaces that match the folder structure.
+- Remove unused `using` directives.
+- Use file-scoped namespace declarations.
+- Use single-line using directives.
+- For types that do not have an implementation, don't add a body (e.g., `public interface IMyInterface;`).
+- Prefer using `record` types for immutable data structures (events, commands, read models, concepts).
+- Use expression-bodied members for simple methods and properties.
+- Use `async` and `await` for asynchronous programming.
+- Use `Task` and `Task<T>` for asynchronous methods.
+- Use `IEnumerable<T>` for collections that are not modified.
+- Never return mutable collections from public APIs.
+- Don't use regions in the code.
+- Never add postfixes like Async, Impl, etc. to class or method names.
+- Favor collection initializers and object initializers.
+- Use string interpolation instead of string.Format or concatenation.
+- Favor primary constructors for all types.
+
+## Chronicle & Arc Key Conventions
+
+These conventions exist because the frameworks rely on convention-based discovery. Breaking them doesn't just violate style — it breaks runtime behavior.
+
+- `[EventType]` takes **no arguments** — the type name is used automatically. Adding a GUID or string argument is a common mistake from other frameworks; Chronicle does not use it.
+- `[Command]` records define `Handle()` directly on the record — never create separate handler classes. The framework discovers `Handle()` by convention; a separate class breaks that discovery.
+- `[ReadModel]` records define static query methods directly on the record. The proxy generator creates TypeScript hooks from these methods automatically.
+- Prefer `ConceptAs<T>` over raw primitives in all domain models, commands, events, and queries. This prevents accidental mix-ups (passing a `UserId` where an `AuthorId` was expected) and makes APIs self-documenting.
+- Use model-bound projection attributes (`[FromEvent<T>]`, `[SetFrom<T>]`, etc.) when possible; fall back to `IProjectionFor<T>` for complex cases.
+- For fluent projections, AutoMap is on by default — just call `.From<>()` directly.
+- Projections join **events**, never read models. This is fundamental to event sourcing: projections rebuild state from the event stream, not from other projections.
+- `IReactor` is a marker interface — method dispatch is by first-parameter event type, method name is descriptive.
+- All backend artifacts for a vertical slice go in a **single `.cs` file**. This keeps cohesion high and makes the scope of a slice immediately visible.
+
+## Proxy Generation — Build Dependency
+
+Commands and Queries generate TypeScript proxies at build time via `dotnet build`. This creates `.ts` files that the frontend imports (hooks, execute methods, change tracking). Until the backend compiles, **no proxy files exist** and frontend code cannot reference them.
+
+**This is a hard sequencing constraint:**
+1. Backend C# code must be written and compile successfully first.
+2. `dotnet build` must complete — this generates the TypeScript proxy files.
+3. Only then can frontend React components import and use the generated proxies.
+
+**When running parallel agents or sub-agents:** backend and frontend work for the same slice **cannot** run in parallel. The backend agent must finish and `dotnet build` must succeed before the frontend agent starts. Independent slices (no shared events) can have their backends worked on in parallel, but each slice's frontend still depends on its own backend build completing first.
+
+## TypeScript / Frontend Instructions
+
+- Prefer `const` over `let` over `var` when declaring variables.
+- Never use shortened or abbreviated names for variables, parameters, or properties.
+  - Use full descriptive names: `deltaX` not `dx`, `index` not `idx`, `event` not `e`, `previous` not `prev`, `direction` not `dir`, `position` not `pos`, `contextMenu` not `ctx`/`ctxMenu`.
+  - The only acceptable short names are well-established domain terms (e.g. `id`, `url`, `min`, `max`).
+- Never leave unused import statements in the code.
+- Always ensure that the code compiles without warnings.
+  - Use `yarn compile` to verify (if successful it doesn't output anything).
+- Do not prefix a file, component, type, or symbol with the name of its containing folder or the concept it belongs to. Instead, use folder structure to provide that context.
+- Favor functional folder structure over technical folder structure.
+  - Group files by the feature or concept they belong to, not by their technical role.
+  - Avoid folders like `components/`, `hooks/`, `utils/`, `types/` at the feature level.
+
+## Development Workflow
+
+- After creating each new file, run `dotnet build` (C#) or `yarn compile` (TypeScript) immediately before proceeding to the next file. Fix all errors as they appear — never accumulate technical debt.
+- Before adding parameters to interfaces or function signatures, review all usages to ensure the new parameter is needed at every call site.
+- When modifying imports, audit all occurrences — verify additions are used and removals don't break other files.
+- Never use placeholder or temporary types — use proper types from the start.
+- Review each file for lint compliance before moving on.
+- The user may keep Storybook running — do not try to stop it, suggest stopping it, or start your own instance.
+
+## XML Documentation
+
+- All **public** types, methods, properties, and operators **must** have XML doc comments.
+- Always use **multiline** `<summary>` tags — opening and closing tags on their own lines. Never single-line.
+- Every method or operator with parameters must include `<param name="...">` for each parameter.
+- Every non-void method or operator must include `<returns>`.
+- Every method that throws must document the exception with `<exception cref="...">` tags.
+- Use `<see cref="..."/>` and `<paramref name="..."/>` to cross-reference types and parameters.
+
+## Exceptions
+
+- Use exceptions for exceptional situations only.
+- Don't use exceptions for control flow.
+- Always provide a meaningful message when throwing an exception.
+- Always create a custom exception type that derives from Exception.
+- Never use any built-in exception types like InvalidOperationException, ArgumentException, etc.
+- Add XML documentation for exceptions being thrown.
+- XML documentation for exception should start with "The exception that is thrown when ...".
+- Never suffix exception class names with "Exception".
+
+## Nullable Reference Types
+
+- Always use is null or is not null instead of == null or != null.
+- Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
+- Add `!` operator where nullability warnings occur.
+- Use `is not null` checks before dereferencing potentially null values.
+
+## Naming Conventions
+
+- Follow PascalCase for component names, method names, and public members.
+- Use camelCase for private fields and local variables.
+- Prefix private fields with an underscore (e.g., `_privateField`).
+- Prefix interface names with "I" (e.g., IUserService).
+
+## Logging
+
+- Use structured logging with named parameters.
+- Use appropriate log levels (Information, Warning, Error, Debug).
+- Always use a generic ILogger<T> where T is the class name.
+- Keep logging in separate partial methods for better readability. Call the file `<SystemName>Logging.cs`. Make this class partial and static and internal and all methods should be internal.
+- Use the `[LoggerMessage]` attribute to define log messages.
+- Don't include `eventId` in the `[LoggerMessage]` attribute.
+
+## Dependency Injection
+
+- Systems that have a convention of IFoo to Foo does not need to be registered explicitly.
+- Prefer constructor injection over method injection.
+- Avoid service locator pattern (i.e., avoid using IServiceProvider directly).
+- For implementations that should be singletons, use the `[Singleton]` attribute on the class.
+
+## TypeScript Type Safety
+
+- Never use `any` type - always use proper type annotations:
+  - Use `unknown` for values of unknown type that need runtime checking.
+  - Use `Record<string, unknown>` for objects with unknown properties.
+  - Use proper generic constraints like `<TCommand extends object = object>` instead of `= any`.
+  - Use `React.ComponentType<Props>` for React component types.
+- When type assertions are necessary, use `unknown` as an intermediate type:
+  - Prefer `value as unknown as TargetType` over `value as any`.
+  - For objects with dynamic properties: `(obj as unknown as { prop: Type }).prop`.
+- For generic React components:
+  - Use `unknown` as default generic parameter instead of `any`.
+  - Example: `<TCommand = unknown>` not `<TCommand = any>`.
+- For Storybook files:
+  - Use `React.ComponentType<Record<string, never>>` for components with no props.
+  - Always use `as unknown as` when converting component imports to avoid type mismatch errors.
+  - Properly type story args instead of using `any`.
+- For event handlers:
+  - Be careful with React.MouseEvent vs DOM MouseEvent - they are different types.
+  - React synthetic events: `React.MouseEvent<Element, MouseEvent>`.
+  - DOM native events: `MouseEvent`.
+  - Convert between them using: `nativeEvent as unknown as React.MouseEvent`.
+  - Use `e.preventDefault?.()` instead of `(e as any).preventDefault?.()`.
+- For library objects (PIXI, etc.):
+  - Use proper library types when available.
+  - Use specific property types: `{ canvas?: HTMLCanvasElement }` instead of `any`.
+- When working with external libraries that have strict generic constraints:
+  - Import necessary types (e.g., `Command` from `@cratis/arc/commands`).
+  - Use type assertions through `unknown` to satisfy constraints: `props.command as unknown as Constructor<Command<...>>`.
+  - Extract tuple results explicitly rather than destructuring when type assertions are needed.
+- For function parameter types that may be unknown:
+  - Add type guards: `if (typeof accessor !== 'function') return ''`.
+  - Type parameters with fallbacks: `function<T = unknown>(accessor: ((obj: T) => unknown) | unknown)`.
+- For arrays and collections accessed from `unknown` types:
+  - Cast to proper array type: `((obj as Record<string, unknown>).items || []) as string[]`.
+  - Type array elements when iterating: `array.forEach((item: string) => ...)`.
+- For generic type parameters:
+  - Ensure proper type conversions: `String(value)` when string operations are needed.
+  - Use explicit Date parameter types: `new Date(value as string | number | Date)`.
+
+## Detailed Guides
+
+These guides contain the full rules, examples, and rationale for each topic. The sections above are the global defaults; the guides go deeper into each area:
+   - [C# Conventions](./instructions/csharp.instructions.md)
+   - [How to Write Specs](./instructions/specs.instructions.md)
+   - [How to Write C# Specs](./instructions/specs.csharp.instructions.md)
+   - [How to Write TypeScript Specs](./instructions/specs.typescript.instructions.md)
+   - [Entity Framework Core](./instructions/efcore.instructions.md)
+   - [Entity Framework Core Specs](./instructions/efcore.specs.instructions.md)
+   - [Concepts (ConceptAs)](./instructions/concepts.instructions.md)
+   - [Documentation](./instructions/documentation.instructions.md)
+   - [Pull Requests](./instructions/pull-requests.instructions.md)
+   - [Vertical Slices](./instructions/vertical-slices.instructions.md)
+   - [TypeScript Conventions](./instructions/typescript.instructions.md)
+   - [React Components](./instructions/components.instructions.md)
+   - [Dialogs](./instructions/dialogs.instructions.md)
+   - [Reactors](./instructions/reactors.instructions.md)
+   - [Orleans](./instructions/orleans.instructions.md)
+
+## Header
+
+All files should start with the following header:
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+```
diff --git a/.github/instructions/components.instructions.md b/.github/instructions/components.instructions.md
new file mode 100644
index 0000000..d1ad855
--- /dev/null
+++ b/.github/instructions/components.instructions.md
@@ -0,0 +1,121 @@
+---
+applyTo: "**/*.tsx"
+---
+
+# Building React Components
+
+## Composition over Monoliths
+
+A well-built component tree is like a well-organized kitchen — every tool has a place, and you can find what you need without opening every drawer. Large components that do everything are hard to understand, hard to test, and hard to change without breaking something unrelated.
+
+- Split components into small, focused pieces and compose them together. Each component should have a single, clear responsibility.
+- Parent components own state and event handlers; children receive props. This makes data flow predictable and debuggable.
+- If you find yourself writing a block comment like `// Author list section` inside a component, that section should be its own component. The comment is a code smell — the component name should provide that context instead.
+
+## Folder Structure
+
+- Single-file component → place directly in the parent feature folder.
+- Multi-file component (sub-components, hooks, CSS) → create a folder named after the component:
+
+```
+PrototypeWindow/
+  PrototypeWindow.tsx      ← composition root
+  PrototypeWindow.css      ← styles for the composition
+  TitleBar.tsx             ← sub-component
+  CanvasArea.tsx           ← sub-component
+  ResizeHandle.tsx         ← sub-component
+  index.ts                 ← re-exports public API
+```
+
+Add an `index.ts` that re-exports the public surface so import paths stay stable.
+
+## Styling
+
+Consistent styling comes from discipline: static styles in CSS files, dynamic values inline, and colors always from PrimeReact's design tokens. This ensures theming works automatically and no component breaks the visual language.
+
+- Use **CSS classes in co-located `.css` files** for static styles.
+- Each component must have its own CSS file — never add sub-component styles to the parent's CSS. This keeps styles co-located with the component they belong to.
+- The composition root's CSS only contains layout/grid rules for positioning children — it should not style the children themselves.
+- Use inline `style` props **only** for runtime-dynamic values (pixel positions, computed sizes).
+- Use **PrimeReact CSS variables** for all colors, backgrounds, borders. This ensures the application respects theming and dark/light mode switches:
+  - `var(--surface-0)` through `var(--surface-900)`, `var(--surface-card)`, `var(--surface-border)`, `var(--surface-ground)`
+  - `var(--text-color)`, `var(--text-color-secondary)`, `var(--primary-color)`, `var(--primary-color-text)`, `var(--highlight-bg)`
+  - Never hard-code hex or `rgb()` for UI chrome — it will break when themes change. Only hard-code colors that are intentionally theme-independent (e.g. brand-specific accent dots, traffic-light indicators).
+- Name CSS classes with a BEM-like prefix matching the component name.
+
+## Props
+
+Props are a component's public API. They should be clear, minimal, and well-documented.
+
+- Each sub-component declares its own `*Props` interface with JSDoc on every prop.
+- Pass only needed props — avoid threading large prop bags through component trees.
+- Event handlers follow `on*` naming: `onPointerDown`, `onSelect`.
+
+## Dialogs
+
+See [dialogs.instructions.md](./dialogs.instructions.md) for the full dialog guide.
+
+**Summary:** Never import `Dialog` from `primereact/dialog`. Use `CommandDialog` from `@cratis/components/CommandDialog` for command-executing dialogs and `Dialog` from `@cratis/components/Dialogs` for data-collection dialogs. Do not render manual `<Button>` components for dialog actions — the dialog components handle footers.
+
+## Icons
+
+Follow these rules when working with SVG icons:
+
+- **Distinguish icons from status/interactive components.** A pure SVG icon is a simple presentational element. A component that wraps an icon with interactive behavior (e.g. a dropdown, tooltip, or complex state) is a _component_, not an icon — name it accordingly (e.g. `SliceStatus`, not `SliceStatusIcon`).
+- **Store each SVG as a separate `.svg` file** inside the icon's folder. Do not embed SVG markup directly in `.tsx` files.
+  - Import SVG files with the `?raw` suffix to get the raw SVG string: `import iconSvg from './Icon.svg?raw';`
+  - Render inline using `dangerouslySetInnerHTML={{ __html: iconSvg }}` so that CSS `currentColor` is honored.
+- **Use subfolders for grouping related icons or complex components.**
+  - A folder named `SliceStatus/` groups the four status SVG files together with the interactive `SliceStatus` component that uses them.
+  - Simple, standalone icons may live directly in the `icons/` root if they have no related siblings.
+- **Every icon folder must have an `index.ts`** that re-exports the public API, keeping import paths for consumers stable.
+- **Barrel-export all icons through `icons/index.ts`** so consumers import from the `icons` path alias, not from deep paths.
+
+**Example structure:**
+```
+icons/
+  SliceStatus/
+    NotStarted.svg         ← raw SVG file
+    InProgress.svg         ← raw SVG file
+    ReadyForReview.svg     ← raw SVG file
+    Done.svg               ← raw SVG file
+    SliceStatus.tsx        ← interactive component using the SVG files
+    SliceStatus.css
+    index.ts
+  CogWheelIcon/
+    CogWheel.svg           ← raw SVG file
+    CogWheelIcon.tsx       ← thin wrapper component
+    CogWheelIcon.css
+    index.ts
+  WireframeIcon.tsx        ← simple component with no SVG (stays at root)
+  WireframeIcon.css
+  index.ts                 ← re-exports everything
+```
+
+## Storybook
+
+- Storybook runs at **http://localhost:6006** — never restart it.
+- Use the `click` tool to interact with Storybook for visual verification.
+
+## Verification
+
+After every task, run both:
+1. `yarn lint`
+2. `npx tsc -b`
+
+## README.md for Complex Components
+
+Complex components accumulate knowledge that lives nowhere else — why a particular state structure was chosen, how sub-components divide responsibilities, what conventions the CSS follows. Without a README, the next developer (or AI) has to reverse-engineer all of this from the code.
+
+Every component folder with sub-components, hooks, or non-trivial architecture **must** have a `README.md`.
+
+**Before starting work:** Check for an existing README and read it first. It may contain context that changes your approach.
+
+**A README must cover:**
+- Component hierarchy — tree of components and what each owns
+- Architecture decisions — what was chosen and why
+- State management — where state lives, what each piece controls
+- CSS conventions — patterns used across children
+- How to extend — steps for common modifications
+
+**Keep READMEs current** — update in the same commit when changing architecture, layout, or state structure.
diff --git a/.github/instructions/concepts.instructions.md b/.github/instructions/concepts.instructions.md
new file mode 100644
index 0000000..119ff16
--- /dev/null
+++ b/.github/instructions/concepts.instructions.md
@@ -0,0 +1,68 @@
+---
+applyTo: "**/*.cs"
+---
+
+# Concepts — Strongly-Typed Domain Values
+
+## Why
+
+A `Guid` is a `Guid` is a `Guid` — the compiler can't tell you if you accidentally passed a `UserId` where an `AuthorId` was expected. Both are `Guid`, both compile, and the bug hides until production.
+
+`ConceptAs<T>` wraps every domain value in a named type. The compiler now enforces that an `AuthorId` is not a `UserId`, method signatures become self-documenting, and code review becomes about logic rather than "is this the right ID?"
+
+Never use raw primitives (`string`, `int`, `Guid`) in domain models, commands, events, or queries.
+
+## Rules
+
+- Inherit from `ConceptAs<T>` as a positional `record` — this gives you value equality and immutability for free.
+- `ConceptAs<T>` already provides an implicit conversion **from** `T` **to** the concept.
+- Always add an implicit conversion operator **from** the concept **to** `T` for easy extraction.
+- Add a `static readonly` sentinel value instead of using `null` — sentinels make "no value" explicit and avoid nullable reference type noise:
+  - `Guid` → `NotSet` backed by `Guid.Empty`
+  - `string` → `NotSet` backed by `string.Empty`
+  - `int` / `long` → `NotSet` backed by `0` / `0L`
+- For `Guid`-backed identity concepts, add a `static New()` factory method — it reads better than `new AuthorId(Guid.NewGuid())`.
+- If the concept is used as a Chronicle event source key, add an implicit conversion to `EventSourceId` — this lets Chronicle resolve the key automatically.
+- Place concepts in the **feature folder they belong to** — never create a standalone `Concepts/` folder. Concepts shared between slices go in the feature root; shared between features go in `Features/` root.
+- One concept per file, named after the concept (e.g. `AuthorId.cs`, `AuthorName.cs`).
+
+## Examples
+
+**Guid identity concept (full canonical pattern):**
+
+```csharp
+public record AuthorId(Guid Value) : ConceptAs<Guid>(Value)
+{
+    public static readonly AuthorId NotSet = new(Guid.Empty);
+
+    public static implicit operator Guid(AuthorId id) => id.Value;
+    public static implicit operator AuthorId(Guid value) => new(value);
+    public static implicit operator EventSourceId(AuthorId id) => new(id.Value.ToString());
+
+    public static AuthorId New() => new(Guid.NewGuid());
+}
+```
+
+**String value concept:**
+
+```csharp
+public record AuthorName(string Value) : ConceptAs<string>(Value)
+{
+    public static readonly AuthorName NotSet = new(string.Empty);
+
+    public static implicit operator string(AuthorName name) => name.Value;
+    public static implicit operator AuthorName(string value) => new(value);
+}
+```
+
+**Int value concept:**
+
+```csharp
+public record Age(int Value) : ConceptAs<int>(Value)
+{
+    public static readonly Age NotSet = new(0);
+
+    public static implicit operator int(Age age) => age.Value;
+    public static implicit operator Age(int value) => new(value);
+}
+```
diff --git a/.github/instructions/csharp.instructions.md b/.github/instructions/csharp.instructions.md
new file mode 100644
index 0000000..4e49bfe
--- /dev/null
+++ b/.github/instructions/csharp.instructions.md
@@ -0,0 +1,154 @@
+---
+applyTo: "**/*.cs"
+---
+
+# C# Conventions
+
+The goal is minimal ceremony, maximum clarity. Modern C# (13+) gives us records, primary constructors, pattern matching, and file-scoped namespaces — use them everywhere. The less boilerplate in a file, the faster a reader can understand what it *does*.
+
+## Building
+
+- Use `dotnet build` from the command line.
+- Use `dotnet format` to format code.
+- Use `dotnet test` to run tests.
+
+## Formatting
+
+These rules exist so that every file in the codebase reads the same way. When formatting is consistent, code review focuses on logic, not style.
+
+- Apply code-formatting style defined in `.editorconfig`.
+- Use file-scoped namespace declarations — one less level of indentation for the entire file.
+- Use single-line `using` directives, sorted alphabetically.
+- Insert a blank line before the opening `{` of every code block (`if`, `for`, `foreach`, `try`, `using`, etc.).
+- Ensure the final `return` statement of a method is on its own line.
+- Use pattern matching and switch expressions wherever possible — they are more readable and the compiler verifies exhaustiveness.
+- Use `nameof` instead of string literals — it survives refactoring.
+- Place private class declarations at the bottom of the file — public API first, implementation details last.
+
+## Naming
+
+- PascalCase for type names, method names, and public members.
+- camelCase for private fields and local variables.
+- Prefix private fields with `_` (e.g. `_myField`).
+- Prefix interface names with `I` (e.g. `IMyService`).
+
+## Code Style
+
+Every rule here reduces noise. `var` avoids redundant type repetition. Expression bodies eliminate braces for trivial members. Primary constructors remove the constructor-plus-field ceremony.
+
+- Prefer `var` over explicit types — the right side of the assignment already tells you the type.
+- Use expression-bodied members for simple methods and properties.
+- Favor primary constructors for all types — they eliminate field declarations for injected dependencies.
+- Use string interpolation instead of `string.Format()` or concatenation.
+- Favor collection initializers and object initializers.
+- Use `IEnumerable<T>` for collections that are not modified; never return mutable collections from public APIs.
+- Don't use regions — they hide code instead of organizing it. If a file needs regions, it needs refactoring.
+- Never add postfixes like `Async`, `Impl`, `Service` to class names — they add noise without information.
+- For types with no implementation body, omit the braces (e.g. `public interface IMyInterface;`).
+- Prefer `record` types for immutable data structures (events, commands, read models, concepts) — they give you value equality, immutability, and concise syntax for free.
+
+## Nullable Reference Types
+
+Embrace the type system — it is the first line of defense against null-related bugs. When it says something cannot be null, trust it.
+
+- Use `is null` / `is not null` — never `== null` / `!= null`.
+- Trust the C# null annotations; don't add defensive null checks when the type system guarantees a value.
+- Add `!` operator where nullability warnings occur and you are certain the value is non-null.
+- Use `is not null` checks before dereferencing potentially null values.
+
+## XML Documentation
+
+XML doc comments are the public API's first impression. They must be multiline — never cram `<summary>` onto a single line. Every public type, method, property, and operator must have XML docs.
+
+- Always use **multiline** `<summary>` tags — opening and closing tags on their own lines:
+  ```csharp
+  /// <summary>
+  /// Represents the unique identifier of a project.
+  /// </summary>
+  ```
+- **Never** use single-line summaries:
+  ```csharp
+  // ❌ Wrong
+  /// <summary>Represents the unique identifier of a project.</summary>
+  ```
+- Every method or operator with parameters **must** include `<param name="...">` for each parameter.
+- Every method or operator that returns a value (non-void) **must** include `<returns>`.
+- Every method that throws must document the exception with `<exception cref="...">` tags.
+- Use `<see cref="..."/>` and `<paramref name="..."/>` to cross-reference types and parameters.
+- Keep summaries concise and purposeful — only document when it adds understanding beyond the name itself.
+
+Example:
+
+```csharp
+/// <summary>
+/// Represents an instance of <see cref="ICommandFilters"/>.
+/// </summary>
+/// <param name="filters">The collection of <see cref="ICommandFilter"/> to use for filtering commands.</param>
+[Singleton]
+public class CommandFilters(IInstancesOf<ICommandFilter> filters) : ICommandFilters
+{
+    /// <summary>
+    /// Filters the command execution through all registered command filters.
+    /// </summary>
+    /// <param name="context">The <see cref="CommandContext"/> to filter.</param>
+    /// <returns>A <see cref="CommandResult"/> representing the aggregated filter outcome.</returns>
+    public async Task<CommandResult> OnExecution(CommandContext context)
+    {
+        // ...
+    }
+}
+```
+
+## Exceptions
+
+Every exception type in the codebase should communicate *what went wrong* in domain terms. Built-in types like `InvalidOperationException` tell you nothing about the problem — a custom `AuthorAlreadyRegistered` tells you everything.
+
+- Use exceptions for exceptional situations only — never for control flow.
+- Always create a custom exception type that derives from `Exception`.
+- Never use built-in exception types (`InvalidOperationException`, `ArgumentException`, etc.).
+- Never suffix exception class names with `Exception` — `AuthorNotFound` reads better than `AuthorNotFoundException`.
+- Always provide a meaningful message when throwing.
+- Add XML doc on the exception type starting with "The exception that is thrown when ...".
+
+## Dependency Injection
+
+The framework discovers and wires dependencies by convention. Explicit registration is the exception, not the rule.
+
+- Prefer constructor injection; avoid `IServiceProvider` directly (service locator anti-pattern).
+- For singletons, use the `[Singleton]` attribute — no explicit registration needed.
+- Systems with a convention of `IFoo → Foo` do not need to be registered explicitly.
+- Command/query `Handle()` method parameters are automatically resolved from DI by type.
+
+## Logging
+
+- Use structured logging with named parameters.
+- Use `ILogger<T>` where `T` is the class name.
+- Keep log messages in a separate `<ClassName>Logging.cs` partial static internal class.
+- Use `[LoggerMessage]` attribute (without `eventId`).
+
+## Async
+
+- Use `async`/`await` for asynchronous programming.
+- Use `Task` and `Task<T>` for asynchronous methods.
+
+## Chronicle & Arc — Key API Types
+
+These are the building blocks. Each type has a specific role in the vertical slice architecture — using the right type in the right place means the framework handles discovery, wiring, and proxy generation automatically.
+
+| Type | Purpose |
+|---|---|
+| `ConceptAs<T>` | Strongly-typed domain value wrapper (see concepts instructions) |
+| `[EventType]` | Marks a record as a Chronicle event — **never** pass arguments to the attribute |
+| `[Command]` | Marks a record as a model-bound command — define `Handle()` directly on the record |
+| `[ReadModel]` | Marks a record as a model-bound query — define static query methods on the record |
+| `CommandValidator<T>` | FluentValidation validator for commands |
+| `IProjectionFor<T>` | Fluent projection definition — AutoMap is on by default |
+| `IReducerFor<T>` | Imperative reducer — receives current state, returns new state |
+| `IReactor` | Marker interface for side-effect observers — method dispatch by event type parameter |
+| `IConstraint` | Constraint definition — enforced server-side by Chronicle at append time |
+| `AggregateRoot` | Chronicle aggregate root with `Apply()` and `Commit()` |
+| `ICommandPipeline` | Programmatic command execution from reactors or other code |
+| `EventSourceId` | Primary identity binding — all events for an entity share the same event source ID |
+| `EventContext` | Event metadata: `Occurred`, `SequenceNumber`, `CorrelationId`, `EventSourceId`, etc. |
+| `ISubject<T>` | Observable query return type — enables real-time WebSocket push |
+| `IMongoCollection<T>` | MongoDB collection — use `.Observe()` for reactive queries |
diff --git a/.github/instructions/dialogs.instructions.md b/.github/instructions/dialogs.instructions.md
new file mode 100644
index 0000000..25a63d8
--- /dev/null
+++ b/.github/instructions/dialogs.instructions.md
@@ -0,0 +1,197 @@
+````instructions
+---
+applyTo: "**/*.tsx"
+---
+
+# Using Dialogs
+
+The Cratis dialog wrappers handle command execution, validation timing, loading states, and footer buttons consistently. Using PrimeReact's raw `Dialog` bypasses all of this and leads to inconsistent UX.
+
+## Choose the Correct Dialog Type
+
+- If confirm executes a command, use `CommandDialog` from `@cratis/components/CommandDialog`.
+- If no command is executed on confirm, use `Dialog` from `@cratis/components/Dialogs`.
+- **Never** import `Dialog` from `primereact/dialog` directly.
+
+## When Using `CommandDialog`
+
+- Pass the command constructor to `command={}`. `CommandDialog` handles instantiation, execution, and confirm/cancel buttons.
+- Use command form fields (`InputTextField`, `TextAreaField`, etc. from `@cratis/components/CommandForm`) for user-input values.
+- `CommandDialog` automatically disables confirm while the command executes.
+- Use `onBeforeExecute` only for values that cannot come from form fields (for example generated IDs).
+
+```tsx
+import { DialogProps, DialogResult } from '@cratis/arc.react/dialogs';
+import { CommandDialog } from '@cratis/components/CommandDialog';
+import { InputTextField } from '@cratis/components/CommandForm';
+import { RegisterProject } from './Registration';
+import { Guid } from '@cratis/fundamentals';
+
+export const AddProject = ({ closeDialog }: DialogProps) => {
+    return (
+        <CommandDialog<RegisterProject>
+            command={RegisterProject}
+            title="Add Project"
+            okLabel="Add"
+            cancelLabel="Cancel"
+            onBeforeExecute={(values) => {
+                values.projectId = Guid.create();  // generated, not user input
+                return values;
+            }}>
+            <InputTextField<RegisterProject>
+                value={instance => instance.name}
+                title="Project name"
+                placeholder="My Project"
+            />
+        </CommandDialog>
+    );
+};
+```
+
+To await the result from the parent:
+
+```tsx
+const [AddProjectDialog, showAddProjectDialog] = useDialog(AddProject);
+
+const [result] = await showAddProjectDialog();
+if (result === DialogResult.Ok) {
+    // Dialog confirmed and command executed successfully
+}
+```
+
+## When Using `Dialog`
+
+Use this for dialogs that collect data and return it without executing a command (e.g. confirmation prompts, pure data-entry dialogs). `Dialog` defaults to OK + Cancel buttons. Use `isValid` to control confirm button state, `okLabel`/`cancelLabel` to customise button text.
+
+```tsx
+import { useState } from 'react';
+import { DialogProps, DialogResult } from '@cratis/arc.react/dialogs';
+import { Dialog } from '@cratis/components/Dialogs';
+import { InputText } from 'primereact/inputtext';
+
+export const AddProject = ({ closeDialog }: DialogProps<{ name: string }>) => {
+    const [name, setName] = useState('');
+    const isValid = name.trim().length > 0;
+
+    return (
+        <Dialog
+            title="Add Project"
+            width='32rem'
+            isValid={isValid}
+            onConfirm={() => closeDialog(DialogResult.Ok, { name })}
+            onCancel={() => closeDialog(DialogResult.Cancelled)}
+        >
+            <InputText
+                value={name}
+                onChange={event => setName(event.target.value)}
+                autoFocus
+            />
+        </Dialog>
+    );
+};
+```
+
+## Prefer `DialogButtons` over Custom Button JSX
+
+Use the built-in `DialogButtons` enum instead of rendering manual `<Button>` elements in the `buttons` prop:
+
+```tsx
+import { DialogButtons, DialogResult, useDialogContext } from '@cratis/arc.react/dialogs';
+```
+
+### Available Button Sets
+
+| `buttons` value | Shows |
+|---|---|
+| `DialogButtons.OkCancel` | Ok + Cancel |
+| `DialogButtons.YesNo` | Yes + No |
+| `DialogButtons.YesNoCancel` | Yes + No + Cancel |
+| `DialogButtons.Ok` | Ok only |
+| `null` | No buttons (content-only dialog) |
+
+## Customising Built-in Buttons
+
+Use `okLabel`/`cancelLabel` to rename the buttons, and `isValid` to disable the confirm button:
+
+```tsx
+<Dialog
+    title="Import Orders"
+    visible={true}
+    buttons={DialogButtons.OkCancel}
+    okLabel="Upload"
+    isValid={!!file && !isUploading}
+    onConfirm={handleUpload}
+    onCancel={() => closeDialog(DialogResult.Cancelled)}
+>
+```
+
+## Validation Guard — Keep Dialog Open on Failure
+
+When `onConfirm` needs to keep the dialog open (e.g. a command fails), annotate the handler as `Promise<boolean>` and return `false` to block the close. Return `true` to let the Dialog close itself:
+
+```tsx
+const handleConfirm = async (): Promise<boolean> => {
+    const result = await myCommand.execute();
+    if (!result.isSuccess) return false; // dialog stays open
+    return true; // dialog closes
+};
+```
+
+> **TypeScript note:** Always annotate the function as `Promise<boolean>`. Without it TypeScript infers `Promise<false | void>` which does not satisfy the `ConfirmCallback` type.
+
+## Passing Result Data on Confirm
+
+When the dialog must return data to its caller (e.g. a postal code lookup result), use `onClose` and call `closeDialog` manually, returning `false` to prevent the Dialog from calling it a second time:
+
+```tsx
+<Dialog
+    title="Confirm Location"
+    visible={true}
+    buttons={DialogButtons.OkCancel}
+    isValid={isValid}
+    onClose={(result) => {
+        if (result === DialogResult.Ok) {
+            closeDialog(DialogResult.Ok, { postalCode, city, latitude, longitude } as MyResult);
+            return false; // prevent Dialog from calling closeDialog(Ok) again
+        }
+        // Cancelled: return undefined so the Dialog calls closeDialog(Cancelled)
+    }}
+>
+```
+
+## Content-only Dialogs (No Action Buttons)
+
+Use `buttons={null}` for dialogs that contain their own internal actions (e.g. a menu + data table) and don't need a confirm/cancel footer:
+
+```tsx
+<Dialog
+    title="Hubs"
+    visible={true}
+    width="50vw"
+    buttons={null}
+    onCancel={() => closeDialog(DialogResult.Cancelled)}
+>
+    <Menubar model={menuItems} />
+    <Listing configurationId={configurationId} />
+</Dialog>
+```
+
+## Props Reference
+
+| Prop | Type | Notes |
+|---|---|---|
+| `title` | `string` | Header text (replaces PrimeReact `header`) |
+| `visible` | `boolean` | Controls visibility |
+| `buttons` | `DialogButtons \| ReactNode \| null` | Prefer `DialogButtons` enum; `null` for no footer |
+| `isValid` | `boolean` | Disables the confirm button when `false` |
+| `okLabel` | `string` | Override the Ok/Confirm button label |
+| `cancelLabel` | `string` | Override the Cancel button label |
+| `onConfirm` | `() => boolean \| void \| Promise<boolean> \| Promise<void>` | Called when Ok is clicked; return `false` to keep dialog open, `true` to close |
+| `onCancel` | `() => void \| Promise<void>` | Called when Cancel is clicked |
+| `onClose` | `(result: DialogResult) => boolean \| void \| Promise<...>` | Combined handler for both Ok and Cancel |
+| `width` | `string` | Dialog width (e.g. `'50vw'`) — replaces PrimeReact `style={{ width }}` |
+| `resizable` | `boolean` | Default `false` |
+
+PrimeReact-specific props (`style`, `contentStyle`, `modal`, `dismissableMask`, `draggable`, `footer`, `onHide`) are **not** available — do not use them.
+
+````
diff --git a/.github/instructions/documentation.instructions.md b/.github/instructions/documentation.instructions.md
new file mode 100644
index 0000000..9f97bcb
--- /dev/null
+++ b/.github/instructions/documentation.instructions.md
@@ -0,0 +1,49 @@
+---
+applyTo: "Documentation/**/*.md"
+---
+
+# How to Write Documentation
+
+Documentation exists for one audience: **developers who need to use the framework** — not the team that built it. Write from the reader's perspective. They want to know *what this does*, *why they should care*, and *how to use it* — in that order.
+
+Every page should answer: "If I were a developer encountering this concept for the first time, what would I need to understand to use it correctly?"
+
+## General
+
+- All documentation lives in the `Documentation/` folder.
+- Site is built using [DocFX](https://dotnet.github.io/docfx/).
+- Use [Markdown](https://www.markdownguide.org/) with [GitHub Flavored Markdown](https://github.github.com/gfm/).
+- Use [Mermaid](https://mermaid-js.github.io/mermaid/#/) for diagrams — architecture flows, state transitions, and sequence diagrams are far clearer as visuals than as prose.
+- Follow [DocFX Markdown](https://dotnet.github.io/docfx/markdown/) guidelines.
+
+## Structure
+
+- Every folder must have its own `toc.yml` for navigation.
+- Every folder must have an `index.md` as a landing page with links to subtopics.
+- When linking to a folder in `toc.yml`, link to the folder's `toc.yml`, not to `index.md`.
+- Use relative links for internal references.
+
+## Writing Style
+
+The project's voice is **direct, practical, and opinionated**. Write like an experienced colleague explaining something to a capable developer — confident but never condescending.
+
+- **Active voice, present tense.** "Chronicle appends the event" not "The event is appended by Chronicle."
+- **Emphasize *why* before *how*.** The reason behind a design choice is more valuable than the steps to implement it. A developer who understands the *why* can handle edge cases the docs don't cover.
+- **Don't document the obvious.** If the API is self-explanatory, a code example is enough. Save prose for concepts that are genuinely non-obvious or where the reasoning is important.
+- Use headings, lists, and code blocks to organize content — dense paragraphs lose readers.
+- Use consistent terminology throughout. If it's called an "event source" in one place, don't call it an "event stream" elsewhere.
+- Focus on public APIs and features — not internal implementation.
+- Do not document third-party libraries.
+
+## Code Examples
+
+- Prefer `record` types for data structures (events, commands, read models) — this matches the actual codebase.
+- When specifying `[EventType]`, never add an explicit name argument — just `[EventType]`.
+- Never include verbatim code from the repository — APIs may change. Write purpose-built examples.
+- Every code example must be complete and correct — no pseudo-code, no `// ...` elisions that leave the reader guessing.
+
+## File Rules
+
+- Always end generated markdown with a single trailing newline in the file content itself.
+- Never use shell commands to modify files after writing them.
+- Run `verify-markdown.sh` in the Documentation folder after writing to validate links and formatting.
diff --git a/.github/instructions/efcore.instructions.md b/.github/instructions/efcore.instructions.md
new file mode 100644
index 0000000..da0862e
--- /dev/null
+++ b/.github/instructions/efcore.instructions.md
@@ -0,0 +1,229 @@
+---
+applyTo: "**/*.cs"
+---
+
+# Entity Framework Core Instructions
+
+## Project Structure
+
+Responsibilities are split across three projects:
+
+| Project | Responsibility |
+|---------|----------------|
+| `Database` | Migrations only – no entities, no DbContexts |
+| `Core` | Entities and feature DbContexts (co-located with features) |
+| `Infrastructure` | DbContext registration, migration runner, cross-cutting EF setup |
+
+**Critical dependency rule**: `Database` must NEVER import from `Core`. Migrations reference only `WellKnownTables` constants (strings) and EF migration types. The dependency chain is:
+
+```
+Core → Infrastructure → Database
+```
+
+## DbContext Base Types
+
+Always use the Cratis Arc base types — never inherit directly from `DbContext`:
+
+- **`ReadOnlyDbContext`** — for all read model / projection contexts (the vast majority)
+- **`BaseDbContext`** — only for writable contexts that own state (e.g. device state, infrastructure state)
+
+```csharp
+// ✅ Read model context
+public class StartupPhaseDbContext(DbContextOptions<StartupPhaseDbContext> options)
+    : ReadOnlyDbContext(options)
+{
+    public DbSet<StartupPhase> StartupPhases => Set<StartupPhase>();
+    public DbSet<PersonnelAssignment> PersonnelAssignments => Set<PersonnelAssignment>();
+}
+
+// ✅ Writable (state-owning) context
+public class DeviceStateDbContext(DbContextOptions<DeviceStateDbContext> options)
+    : BaseDbContext(options)
+{
+    public DbSet<DeviceState> DeviceStates => Set<DeviceState>();
+}
+```
+
+Use the primary constructor pattern. Expose `DbSet<T>` as expression-bodied properties using `Set<T>()`.
+
+## Feature Contexts — Not God Contexts
+
+Create one focused DbContext per feature or tightly-related feature group. Never aggregate unrelated entities into a single context.
+
+```csharp
+// ❌ God context
+public class AppDbContext : DbContext
+{
+    public DbSet<Mission> Missions { get; set; }
+    public DbSet<User> Users { get; set; }
+    public DbSet<Station> Stations { get; set; }
+    // ... many more
+}
+
+// ✅ Focused feature context
+public class StartupPhaseDbContext(DbContextOptions<StartupPhaseDbContext> options)
+    : ReadOnlyDbContext(options)
+{
+    public DbSet<StartupPhase> StartupPhases => Set<StartupPhase>();
+    public DbSet<PersonnelAssignment> PersonnelAssignments => Set<PersonnelAssignment>();
+}
+```
+
+Co-locate the DbContext file with its feature:
+
+```
+Missions/Ongoing/StartupPhase/
+├── StartupPhase.cs
+├── StartupPhaseDbContext.cs
+└── ...
+```
+
+## State Mutation — The Golden Rule
+
+> **Never mutate state directly through a DbContext.**
+
+All state changes must flow through events and Chronicle projections. Direct writes bypass the audit trail and event log.
+
+```csharp
+// ❌ Direct mutation — forbidden
+dbContext.StartupPhases.Add(new StartupPhase(...));
+await dbContext.SaveChangesAsync();
+
+// ✅ Correct: emit an event, let the projection handle writes
+[Command]
+public record UpdateStartupPhase(MissionId MissionId, ...) { ... }
+```
+
+Only infrastructure projection code, the Chronicle event engine, and reference data sync may write through DbContexts.
+
+## Registration
+
+Use the Cratis Arc `Cratis.Arc.EntityFrameworkCore` extension methods:
+
+```csharp
+// Register a single writable DbContext
+services.AddDbContextWithConnectionString<DeviceStateDbContext>(connectionString, optionalConfigure);
+
+// Auto-discover and register ALL ReadOnlyDbContext subtypes from given assemblies
+services.AddReadModelDbContextsWithConnectionStringFromAssemblies(
+    connectionString,
+    configureOptions,
+    [Assembly.GetExecutingAssembly()]);
+```
+
+Configure the database provider using `UseDatabaseFromConnectionString`, which auto-detects PostgreSQL vs SQLite from the connection string:
+
+```csharp
+options.UseDatabaseFromConnectionString(connectionString);
+```
+
+Centralise all DbContext setup in a single `AddApplicationDbContexts` extension method per layer.
+
+## Multiple Database Support
+
+The application supports both PostgreSQL (ASP.NET mode) and SQLite (MAUI mode) from the same code. The provider is selected at runtime via the connection string — `UseDatabaseFromConnectionString` handles the detection.
+
+Never hardcode a provider (e.g. `UseSqlite` or `UseNpgsql`) in application code. Always use `UseDatabaseFromConnectionString`.
+
+## Migrations
+
+Migrations live exclusively in the **`Database`** project, never in `Core` or `Infrastructure`.
+
+### Organisation
+
+Each entity category has its own folder with versioned migration files:
+
+```
+Database/
+├── Missions/
+│   ├── v1_0_0.cs
+│   └── v1_1_0.cs
+├── Users/
+│   └── v1_0_0.cs
+└── WellKnownTables.cs
+```
+
+### Naming
+
+Version files using the pattern `v{major}_{minor}_{patch}.cs` and place them inside a namespace matching their folder:
+
+```csharp
+namespace Database.Missions;
+
+public class v1_0_0 : Migration
+{
+    protected override void Up(MigrationBuilder migrationBuilder) { ... }
+    protected override void Down(MigrationBuilder migrationBuilder) { ... }
+}
+```
+
+The migration ID is composed as `{folder}_{ClassName}` (e.g. `Missions_v1_0_0`).
+
+### Cross-Database Column Helpers
+
+Always use the Cratis Arc `MigrationBuilder` extension helpers to define columns. These abstract over PostgreSQL and SQLite type differences:
+
+| Helper | Use for |
+|--------|---------|
+| `table.StringColumn(migrationBuilder)` | Text / varchar columns |
+| `table.GuidColumn(migrationBuilder)` | UUID / GUID columns |
+| `table.NumberColumn<T>(migrationBuilder)` | Integer, long, or numeric columns |
+| `table.DateTimeOffsetColumn(migrationBuilder)` | Timestamps with timezone |
+
+Never use raw EF `table.Column<string>()` etc. — the helpers ensure cross-database compatibility.
+
+```csharp
+// ✅ Cross-database migration
+migrationBuilder.CreateTable(
+    name: WellKnownTables.Missions,
+    columns: table => new
+    {
+        Id = table.StringColumn(migrationBuilder, nullable: false),
+        Title = table.StringColumn(migrationBuilder, maxLength: 200, nullable: false),
+        ResourceId = table.NumberColumn<int>(migrationBuilder, nullable: true),
+        DispatchTime = table.DateTimeOffsetColumn(migrationBuilder),
+        UrgencyId = table.GuidColumn(migrationBuilder)
+    },
+    constraints: table =>
+    {
+        table.PrimaryKey("PK_Missions", x => x.Id);
+        table.ForeignKey("FK_Missions_Urgency", x => x.UrgencyId,
+            WellKnownTables.MissionUrgencies, "Id", onDelete: ReferentialAction.SetNull);
+    });
+```
+
+### Table Names — WellKnownTables
+
+Always reference table names from `WellKnownTables` constants. Never use magic strings directly in migrations.
+
+```csharp
+// ❌ Magic string
+migrationBuilder.CreateTable(name: "Missions", ...);
+
+// ✅ Constant
+migrationBuilder.CreateTable(name: WellKnownTables.Missions, ...);
+```
+
+Add new table names to `Database/WellKnownTables.cs` before writing the migration.
+
+### Applying Migrations
+
+Migrations are applied via a custom runner from the `Database` project (not `dotnet ef database update`):
+
+```csharp
+// ASP.NET mode
+await app.ApplyAllMigrations(connectionString);
+
+// MAUI / IServiceProvider mode
+await services.ApplyAllMigrations(connectionString);
+```
+
+The runner discovers all `Migration` subclasses from the `Database` assembly, checks the EF history table, and applies pending migrations in version order within a transaction. Both PostgreSQL and SQLite are supported through the same runner.
+
+## Auto-Discovery
+
+The Cratis Arc `IImplementationsOf<T>` mechanism discovers types at runtime:
+
+- `IImplementationsOf<BaseDbContext>` — all DbContext subtypes across all loaded assemblies
+- `.NotReadonly()` extension — filters out `ReadOnlyDbContext` subtypes to isolate writable contexts
+- `IReadModelDbContexts.GetAll()` — returns all registered `ReadOnlyDbContext` instances
diff --git a/.github/instructions/efcore.specs.instructions.md b/.github/instructions/efcore.specs.instructions.md
new file mode 100644
index 0000000..d6387dd
--- /dev/null
+++ b/.github/instructions/efcore.specs.instructions.md
@@ -0,0 +1,37 @@
+---
+applyTo: "**/for_*/**/*.cs, **/when_*/**/*.cs"
+---
+
+# Entity Framework Core Specs
+
+EF Core specs verify database interaction logic — migrations, queries, and error handling. They use SQLite in-memory databases, which are fast, isolated, and disposable. This keeps specs independent of any real database server.
+
+These specs are for code that interacts directly with `DbContext`. For event-sourcing integration specs (testing commands against Chronicle), use the Chronicle integration spec pattern in [specs.csharp.instructions.md](./specs.csharp.instructions.md) instead.
+
+## Database Setup
+
+- Use SQLite in-memory database for all `DbContext` specs — it's fast and each spec gets a clean database.
+- Configure and dispose the in-memory database properly to avoid state leakage between tests. Each spec run should start with a fresh schema.
+
+## Mocking DbContext
+
+- `SaveChanges()` and `SaveChangesAsync()` are virtual — mock with NSubstitute.
+- `DbSet<T>` methods are virtual — mock as needed.
+- Pass options when substituting: `Substitute.For<YourDbContext>(options)`.
+
+```csharp
+var options = new DbContextOptionsBuilder<YourDbContext>()
+    .UseSqlite("DataSource=:memory:")
+    .Options;
+
+var context = Substitute.For<YourDbContext>(options);
+```
+
+## Simulating Failures
+
+Mock `SaveChanges` / `SaveChangesAsync` to throw exceptions for testing error handling and recovery:
+
+```csharp
+context.SaveChangesAsync(Arg.Any<CancellationToken>())
+    .Throws(new DbUpdateException("Simulated failure"));
+```
diff --git a/.github/instructions/orleans.instructions.md b/.github/instructions/orleans.instructions.md
new file mode 100644
index 0000000..2b06be4
--- /dev/null
+++ b/.github/instructions/orleans.instructions.md
@@ -0,0 +1,47 @@
+````instructions
+---
+applyTo: "**/*.cs"
+---
+
+# Orleans Conventions
+
+These conventions apply to projects that use Microsoft Orleans for distributed grain-based actors.
+
+## General
+
+- Do **not** split Orleans grain interfaces into a separate project. Keep all grain types in the same project as their implementations.
+- Use localhost clustering for local development (`UseLocalhostClustering()`).
+- Do **not** add `[Alias]` attributes to grain interfaces or methods — rely on the default alias generated by Orleans.
+
+## Storage Providers
+
+- Centralise all storage provider names in a single `WellKnownStorageProviders` static class at the root of the project.
+- Reference provider names via the constants in `WellKnownStorageProviders` — never use magic strings.
+- Use `WellKnownStorageProviders.Default` as the name for the primary MongoDB-backed storage provider.
+
+```csharp
+public static class WellKnownStorageProviders
+{
+    public const string Default = "MongoDbGrainStorage";
+}
+```
+
+- Annotate grains with `[StorageProvider(ProviderName = WellKnownStorageProviders.Default)]` when they need persistent state.
+
+## MongoDB Grain Storage
+
+- The `MongoDbGrainStorage<TState>` implementation accepts `IMongoCollection<TState>` as its only dependency — no additional plumbing is required.
+- Register it as a keyed singleton in the Orleans silo builder:
+
+```csharp
+builder.Host.UseOrleans(siloBuilder =>
+{
+    siloBuilder.UseLocalhostClustering();
+    siloBuilder.Services.AddKeyedSingleton<IGrainStorage>(
+        WellKnownStorageProviders.Default,
+        (sp, _) => new MongoDbGrainStorage<MyState>(
+            sp.GetRequiredService<IMongoCollection<MyState>>()));
+});
+```
+
+````
diff --git a/.github/instructions/pull-requests.instructions.md b/.github/instructions/pull-requests.instructions.md
new file mode 100644
index 0000000..121b159
--- /dev/null
+++ b/.github/instructions/pull-requests.instructions.md
@@ -0,0 +1,36 @@
+---
+applyTo: "**/*"
+---
+
+# How to Do Pull Requests
+
+PR descriptions serve two purposes: they help reviewers understand the change *now*, and they become the release notes that users read *later*. Write them with both audiences in mind.
+
+## Description
+
+- Follow the [pull request template](../pull_request_template.md).
+- Focus on the **Added**, **Changed**, **Fixed**, **Removed**, **Security**, and **Deprecated** sections. Remove sections that are empty — don't leave blank headings.
+- Each bullet should be a complete, self-contained statement that makes sense without context. A reader scanning release notes should understand what changed from the bullet alone.
+- Add a link to the issue on every bullet point (e.g. `(#123)`) at the end, if applicable.
+- Include a summary only if there is a cohesive theme across the changes. If you find yourself restating individual bullets in slightly different words, the summary adds no value — remove it.
+
+## Commits
+
+- Write clear, concise commit messages in imperative mood: "Add author registration" not "Added author registration" or "Adding author registration".
+- Each commit should represent a logical unit of work. Avoid "WIP" or "fix" commits in the final PR — squash or rebase if needed.
+
+## Labels
+
+- Label the PR according to semantic versioning impact:
+  - **major** — breaking changes to public APIs
+  - **minor** — new features, new slices, non-breaking additions
+  - **patch** — bug fixes, docs, refactoring with identical behavior
+
+## Quality Gates
+
+Before marking a PR ready for review:
+- `dotnet build` — zero errors, zero warnings
+- `dotnet test` — all specs pass
+- `yarn lint` — zero errors
+- `npx tsc -b` — zero TypeScript errors
+- Code follows all project coding standards and conventions
diff --git a/.github/instructions/reactors.instructions.md b/.github/instructions/reactors.instructions.md
new file mode 100644
index 0000000..36a523f
--- /dev/null
+++ b/.github/instructions/reactors.instructions.md
@@ -0,0 +1,103 @@
+---
+applyTo: "**/*.cs"
+---
+
+# Reactor Instructions
+
+Reactors are the "if this then that" of event sourcing — they observe events and produce side effects. Unlike projections (which build state), reactors *do things*: send emails, trigger commands in other slices, call external APIs.
+
+## IReactor — Marker Interface
+
+`IReactor` is a **marker interface** with no methods to implement. Method dispatch is entirely by convention: the first parameter type of each public method determines which event it handles.
+
+```csharp
+public class ProjectRegisteredNotifier(INotificationService notifications) : IReactor
+{
+    /// <summary>
+    /// Reacts to <see cref="ProjectRegistered"/> events by sending a notification.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task ProjectRegistered(ProjectRegistered @event, EventContext context) =>
+        await notifications.Notify($"Project '{@event.Name}' was registered.");
+}
+```
+
+## Method Signature
+
+```csharp
+public Task MethodName(TEvent @event, EventContext context)
+```
+
+- **First parameter** — the event type. This determines which events the method subscribes to.
+- **Second parameter** — `EventContext` (optional). Omit if event metadata is not needed.
+- **Return type** — `Task` (always async).
+- **Method name** — can be anything descriptive. The name is for readability, not dispatch.
+
+## Critical Rules
+
+1. **Idempotent** — Reactors may be called more than once for the same event (e.g. during replay or recovery). Design accordingly.
+2. **Use event data directly** — Never query the read model back inside a reactor. The event contains all the information you need.
+3. **Trigger commands for further writes** — If the reactor needs to produce new events, inject `ICommandPipeline` and execute a command. Never use `IEventLog` directly from a reactor.
+4. **Single responsibility** — Each reactor class should have a focused purpose. Multiple handler methods in one reactor are fine if they serve the same automation concern.
+5. **Failure behavior** — If a reactor throws, the failing event source partition pauses until the issue is resolved. Design for resilience.
+6. **No state** — Reactors should be stateless. Inject dependencies via primary constructor, but do not store mutable state on the class.
+
+## Slice Types That Use Reactors
+
+| Slice type | Pattern |
+|------------|---------|
+| **Automation** | Reacts to events, makes decisions, triggers side effects |
+| **Translation** | Adapts events from one slice/system by triggering commands in another |
+
+### Automation Example
+
+```csharp
+public class ProjectRegisteredNotifier(INotificationService notifications) : IReactor
+{
+    /// <summary>
+    /// Sends a notification when a project is registered.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task ProjectRegistered(ProjectRegistered @event, EventContext context) =>
+        await notifications.Notify($"Project '{@event.Name}' was registered.");
+}
+```
+
+### Translation Example
+
+```csharp
+public class StockKeeping(IStockKeeper stockKeeper, ICommandPipeline commandPipeline) : IReactor
+{
+    /// <summary>
+    /// Reacts to a book reservation by decreasing stock.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task BookReserved(BookReserved @event, EventContext context) =>
+        await commandPipeline.Execute(new DecreaseStock(@event.Isbn, await stockKeeper.GetStock(@event.Isbn)));
+}
+```
+
+## Testing Reactors
+
+Reactor specs follow the same BDD-style pattern as other specs. Use `IReactorInvoker` and `ReactorHandler` from the test infrastructure:
+
+```csharp
+// given/all_dependencies.cs
+public class all_dependencies : Specification
+{
+    protected IEventStore _eventStore;
+    protected IReactorInvoker _reactorInvoker;
+}
+
+// given/a_reactor_handler.cs
+public class a_reactor_handler : all_dependencies
+{
+    protected ReactorHandler _handler;
+    void Establish() => _handler = new(_eventStore, _reactorInvoker);
+}
+```
+
+See `specs.csharp.instructions.md` for full spec patterns.
diff --git a/.github/instructions/specs.csharp.instructions.md b/.github/instructions/specs.csharp.instructions.md
new file mode 100644
index 0000000..3449757
--- /dev/null
+++ b/.github/instructions/specs.csharp.instructions.md
@@ -0,0 +1,249 @@
+---
+applyTo: "**/for_*/**/*.cs, **/when_*/**/*.cs"
+---
+
+# How to Write C# Specs
+
+Extends the base [Specs Instructions](./specs.instructions.md) with C#-specific conventions.
+
+The `Cratis.Specifications` library was built to maintain the approach, structure, and syntax of Machine.Specifications (MSpec) — a BDD framework that makes specs read like a human-language specification. The `Establish → Because → should_` flow maps directly to "Given → When → Then" and keeps specs focused on *one action, one setup, one set of assertions*.
+
+## Frameworks
+
+- [xUnit](https://xunit.net/) for test execution.
+- [NSubstitute](https://nsubstitute.github.io/) for mocking — chosen for its clean API that reads naturally.
+- [Cratis.Specifications](https://github.com/Cratis/Specifications) for BDD-style specification by example.
+- Spec projects are named `<Source>.Specs` (e.g. `Infrastructure.Specs`).
+
+## Base Class
+
+`Specification` from `Cratis.Specifications` must be at the root of every spec's inheritance chain.
+It discovers `Establish`, `Because`, and `Destroy` methods by convention — no attributes needed.
+
+## BDD Pattern
+
+The three-phase pattern makes every spec self-explanatory: `Establish` sets up the world, `Because` performs the single action under test, and `should_*` facts verify individual outcomes. No test framework attributes are needed on `Establish` or `Because` — `Cratis.Specifications` discovers them by convention.
+
+```csharp
+public class when_combining_parts : Specification
+{
+    object[] _parts;
+    string _result;
+
+    void Establish() => _parts = ["First", "Second", "Third"];
+
+    void Because() => _result = KeyHelper.Combine(_parts);
+
+    [Fact] void should_combine_all_parts() => _result.ShouldEqual("First+Second+Third");
+}
+```
+
+| Method | Purpose | Notes |
+|---|---|---|
+| `void Establish()` | Setup — called before `Because()` | Each class in the chain gets its own, called base-first |
+| `void Because()` | The single action under test | Only in concrete spec files, never in reusable contexts |
+| `[Fact] void should_*()` | One assertion per fact | Use `ShouldXxx()` extension methods |
+| `void Destroy()` | Teardown after each test | |
+
+All methods can be `async Task` when needed.
+
+## Reusable Context Pattern
+
+Layered contexts build on each other like building blocks. The base layer mocks all dependencies, the next layer creates the system under test, and each spec only adds what's unique to its scenario. This eliminates setup duplication while keeping every spec self-contained.
+
+```csharp
+// for_Changeset/given/a_changeset.cs
+namespace MyApp.Changes.for_Changeset.given;
+
+public class a_changeset : Specification
+{
+    protected IObjectComparer _comparer;
+    protected Changeset<object, ExpandoObject> _changeset;
+
+    void Establish()
+    {
+        _comparer = Substitute.For<IObjectComparer>();
+        _changeset = new(_comparer, new object(), new ExpandoObject());
+    }
+}
+```
+
+```csharp
+// for_Changeset/when_adding_changes/and_there_are_differences.cs
+namespace MyApp.Changes.for_Changeset.when_adding_changes;
+
+public class and_there_are_differences : given.a_changeset
+{
+    bool _result;
+
+    void Establish() =>
+        _comparer.Compare(Arg.Any<object>(), Arg.Any<ExpandoObject>(), out Arg.Any<IEnumerable<PropertyDifference>>())
+            .Returns(true);
+
+    void Because() => _result = _changeset.HasChanges;
+
+    [Fact] void should_have_changes() => _result.ShouldBeTrue();
+}
+```
+
+**Layered givens (chaining contexts):**
+
+```csharp
+// given/all_dependencies.cs — mocks all deps
+public class all_dependencies : Specification
+{
+    protected IEventStore _eventStore;
+    protected IReactorInvoker _reactorInvoker;
+    void Establish() { _eventStore = Substitute.For<IEventStore>(); /* ... */ }
+}
+
+// given/a_reactor_handler.cs — builds the system under test
+public class a_reactor_handler : all_dependencies
+{
+    protected ReactorHandler _handler;
+    void Establish() => _handler = new(_eventStore, _reactorInvoker);
+}
+```
+
+## NSubstitute Patterns
+
+```csharp
+// Create substitutes
+_service = Substitute.For<IMyService>();
+
+// Setup returns
+_service.GetValue(Arg.Any<string>()).Returns("result");
+_service.ProcessAsync(Arg.Any<int>()).Returns(Task.FromResult(42));
+
+// Argument matchers
+Arg.Is<Request>(r => r.Id == expectedId && r.Name == expectedName)
+
+// Verify received calls
+_service.Received(1).DoSomething(Arg.Any<string>());
+_service.DidNotReceive().DoSomethingElse(Arg.Any<int>());
+
+// Capture arguments
+_service.When(s => s.Add(Arg.Any<IDictionary<string, string>>()))
+    .Do(info => _captured = info.Arg<IDictionary<string, string>>());
+
+// Throw exceptions
+_handler.Handle(Arg.Any<CommandContext>()).Throws(new Exception("fail"));
+```
+
+## Assertion Extension Methods
+
+From `Cratis.Specifications`:
+
+| Method | Usage |
+|---|---|
+| `.ShouldEqual(expected)` | `_result.ShouldEqual(42)` |
+| `.ShouldBeTrue()` | `_flag.ShouldBeTrue()` |
+| `.ShouldBeFalse()` | `_flag.ShouldBeFalse()` |
+| `.ShouldBeNull()` | `_error.ShouldBeNull()` |
+| `.ShouldNotBeNull()` | `_value.ShouldNotBeNull()` |
+| `.ShouldBeEmpty()` | `_list.ShouldBeEmpty()` |
+| `.ShouldNotBeEmpty()` | `_list.ShouldNotBeEmpty()` |
+| `.ShouldContain(item)` | `_list.ShouldContain(expected)` |
+| `.ShouldNotContain(item)` | `_list.ShouldNotContain(excluded)` |
+| `.ShouldContainOnly(items)` | `_list.ShouldContainOnly(expectedItems)` |
+| `.ShouldBeOfExactType<T>()` | `_obj.ShouldBeOfExactType<PropertiesChanged<ExpandoObject>>()` |
+| `.ShouldBeGreaterThan(n)` | `_count.ShouldBeGreaterThan(0)` |
+| `.ShouldBeLessThan(n)` | `_count.ShouldBeLessThan(100)` |
+
+**Catching exceptions:**
+
+```csharp
+async Task Because() => _error = await Catch.Exception(_sut.DoSomething);
+
+[Fact] void should_not_fail() => _error.ShouldBeNull();
+```
+
+## Using Statements
+
+- Common usings are provided globally in `GlobalUsings.Specs.cs` (`Xunit`, `NSubstitute`, `Cratis.Specifications`, etc.) — don't duplicate them.
+- Don't add a using statement for the namespace of the system under test.
+
+## Properties — What NOT to Spec
+
+Simple properties are compiler-verified — the type system already guarantees they work. Writing specs for them adds maintenance cost without catching real bugs. Save spec effort for code where errors actually hide: business logic, coordination between dependencies, and complex transformations.
+
+```csharp
+// ❌ Do NOT write specs for these
+public string TableName => tableName;                         // Returns constructor parameter
+public Key Key => key;                                        // Returns field
+public IEnumerable<Property> Properties => mapper.Properties; // Simple delegation
+
+// ✅ Only write specs for complex business logic in properties
+public decimal TotalCost => Items.Sum(i => i.Cost * i.Quantity * (1 + i.TaxRate));
+```
+
+---
+
+## Chronicle Integration Specs
+
+Integration specs are the highest-value specs in the project. They test a complete vertical slice — from HTTP request through command handling, event appending, constraint checking, and projection — against a real Chronicle event store. If one of these passes, the entire stack works.
+
+They live under `when_<behavior>/` folders directly inside the slice folder — **no `for_` folder**, because there's no isolated unit under test. The "unit" is the entire slice.
+
+### Structure
+
+```csharp
+using context = MyApp.Authors.Registration.when_registering.and_name_already_exists.context;
+
+namespace MyApp.Authors.Registration.when_registering;
+
+[Collection(ChronicleCollection.Name)]
+public class and_name_already_exists(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public const string AuthorName = "John Doe";
+        public CommandResult<object>? Result;
+
+        async Task Establish() =>
+            await EventStore.EventLog.Append(AuthorId.New(), new AuthorRegistered(AuthorName));
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<RegisterAuthor>(
+                "/api/authors/register",
+                new RegisterAuthor(AuthorName));
+        }
+    }
+
+    [Fact] void should_not_be_successful() => Context.Result.IsSuccess.ShouldBeFalse();
+    [Fact] void should_have_appended_only_one_event() => Context.ShouldHaveTailSequenceNumber(EventSequenceNumber.First);
+}
+```
+
+### Key Rules
+
+- `context` is an inner public class inheriting from `given.an_http_client(fixture)`.
+- Use `async Task Establish()` to seed the event store with preconditions.
+- Use `async Task Because()` to execute the command under test.
+- `ExecuteCommand<TCommand>(url, cmd)` returns `CommandResult<object>?` (single type parameter).
+- `ExecuteCommand<TCommand, TResult>(url, cmd)` returns `CommandResult<TResult>?` (two type parameters for typed response).
+- Declare `Result` initialized with `null!` to satisfy nullable analysis.
+- Add a `using context = ...` alias at the top of each spec file.
+
+### Integration Assertion Helpers
+
+| Assertion | Purpose |
+|---|---|
+| `Context.Result.IsSuccess.ShouldBeTrue()` | Command succeeded |
+| `Context.Result.IsSuccess.ShouldBeFalse()` | Command failed (validation, constraint, etc.) |
+| `Context.ShouldHaveTailSequenceNumber(n)` | Verify event log tail (First = sequence 0) |
+| `Context.ShouldHaveAppendedEvent<TEvent>(seq, eventSourceId, validator)` | Verify specific event was appended |
+
+## Formatting
+
+- Don't break long `should_` method lines — prefer one-line lambda assertions.
+- Don't add blank lines between multiple `should_` methods.
+
+## Entity Framework Core Specs
+
+- Use SQLite in-memory database for specs involving `DbContext`.
+- `SaveChanges` / `SaveChangesAsync` are virtual and can be mocked with NSubstitute.
+- `DbSet` methods are virtual — mock as needed.
+- Pass options when substituting: `Substitute.For<YourDbContext>(options)`.
+- Simulate failures by mocking `SaveChanges` to throw exceptions.
diff --git a/.github/instructions/specs.instructions.md b/.github/instructions/specs.instructions.md
new file mode 100644
index 0000000..c34b971
--- /dev/null
+++ b/.github/instructions/specs.instructions.md
@@ -0,0 +1,91 @@
+---
+applyTo: "**/for_*/**/*.*, **/when_*/**/*.*"
+---
+
+# How to Write Specs
+
+We call automated tests **specs** (specifications), not tests. This is deliberate — specs are executable documentation that describe what the system *does*, written in the language of the domain. A new developer should be able to read the spec folder structure like a table of contents and understand the system's behavior without opening a single source file.
+
+This philosophy comes from Specification by Example and BDD (Behavior Driven Development). The goal is human-readable, navigable specifications that double as a living contract.
+
+## Core Philosophy
+
+- **Specify behaviors, not implementations.** A spec should verify what a method *promises from its signature* — its contract with callers. If the implementation changes but the contract holds, specs should still pass. When they don't, the spec was testing the wrong thing.
+- **One behavior, one spec.** Every public method that performs an action gets its own `when_` folder or file. Never bundle multiple behaviors into one spec — it obscures what broke and why.
+- **Specs are documentation first.** The folder tree, class names, and `should_` assertions form a specification anyone can read. Optimize for readability over DRY. A little repetition in setup is fine if it makes the spec self-contained and clear.
+- **Do not test logging** — it is too fragile and provides no value. Don't test simple delegation or trivial getters either. The cost of maintaining these specs exceeds the value they provide.
+
+## Folder & File Structure
+
+Specs mirror the source structure and read like a sentence when you trace the path: `for_Changeset / when_adding_changes / and_there_are_differences`. This is not accidental — the folder hierarchy *is* the specification. Every level adds context:
+
+```
+for_<TypeUnderTest>/
+├── given/
+│   ├── all_dependencies           ← common DI/mock setup
+│   └── a_<descriptive_name>       ← reusable context
+├── when_<behavior>/               ← folder for behaviors with multiple outcomes
+│   ├── given/                     ← behavior-specific context (optional)
+│   │   └── a_<specific_setup>
+│   ├── and_<condition>            ← individual spec file
+│   ├── with_<data_state>
+│   └── without_<requirement>
+└── when_<simple_behavior>         ← single file for single-outcome behaviors
+```
+
+**Naming conventions — read them as English sentences:**
+| Element | Pattern | Reads as... |
+|---|---|---|
+| Unit folder | `for_<ClassName>` | "For the Changeset..." |
+| Behavior folder | `when_<action>` | "...when adding changes..." |
+| Spec file | Descriptive preposition | "...and there are differences" |
+| Assertion | `should <expected result>` | "...it should return true" |
+
+**Allowed prepositions for spec file/class names:**
+- `and_*` — additional conditions or compound scenarios
+- `with_*` / `without_*` — specific data or state present/absent
+- `having_*` — possession or state-based conditions
+- `given_*` — precondition scenarios
+
+## What to Specify
+
+The goal is to cover *decisions and transformations* — code where bugs hide. Simple plumbing that the compiler already validates is noise.
+
+**Write specs for:**
+- Public methods that perform actions (behaviors)
+- Methods with branching logic or business rules
+- Methods that coordinate between dependencies
+
+**Do NOT write specs for:**
+- Simple auto-properties (`public string Name { get; set; }`)
+- Properties returning constructor parameters (`public Key Key => key;`)
+- Simple delegation (`public IEnumerable<Property> Properties => mapper.Properties;`)
+- Trivial null checks or basic validation without complex logic
+- Getters returning injected dependencies
+
+**Avoid file names starting with:** `when_getting_*`, `when_returning_*` — if a spec name starts with "getting" or "returning", it's probably testing a simple getter, which is not worth specifying.
+
+## Multiple Outcomes
+
+Each distinct outcome deserves its own spec file. This keeps specs small, focused, and independently verifiable. When a spec fails, you immediately know *which* outcome broke — no debugging through a multi-assertion file.
+
+- When a behavior has multiple outcomes, create a `when_<behavior>/` folder with separate files for each outcome.
+- For simple behaviors with a single outcome, use a single file: `when_<behavior>`.
+- Never write a single file that tests an entire class.
+
+## Reusable Context
+
+Contexts capture the "given" part of a specification — the world as it exists before the action under test. They prevent duplicating setup across specs while keeping each spec readable.
+
+- Place in `given/` folder within the unit folder.
+- Name with `a_` or `an_` prefix (e.g. `an_observer`, `a_command_pipeline`). This reads naturally: "given an observer, when handling..."
+- More specific contexts can use descriptive names (e.g. `two_queries`, `existing_query`).
+- Context properties must be accessible to the specs that use them — see language-specific instructions for the exact access modifiers and naming conventions.
+- Use the setup phase for context initialization — **never** put the action under test in a reusable context. The action under test belongs only in the concrete spec.
+- Contexts can build on each other in layers: `all_dependencies → a_reactor_handler → when_handling`.
+- Consider creating `all_dependencies` as a root context that mocks all common dependencies. This avoids duplicating mock creation across unrelated specs.
+
+## Formatting
+
+- Keep assertions concise — prefer single-line assertions where the logic is readable.
+- Don't add blank lines between related assertions for the same behavior.
diff --git a/.github/instructions/specs.typescript.instructions.md b/.github/instructions/specs.typescript.instructions.md
new file mode 100644
index 0000000..b62a1bd
--- /dev/null
+++ b/.github/instructions/specs.typescript.instructions.md
@@ -0,0 +1,134 @@
+---
+applyTo: "**/for_*/**/*.ts, **/when_*/**/*.ts"
+---
+
+# How to Write TypeScript Specs
+
+Extends the base [Specs Instructions](./specs.instructions.md) with TypeScript-specific conventions.
+
+TypeScript specs follow the same BDD philosophy as C# specs — they describe behaviors, not implementations. The `given()` helper and context classes mirror the Cratis.Specifications pattern on the C# side: setup is separated from the action, and each `it()` assertion verifies a single outcome.
+
+## Frameworks
+
+- [Vitest](https://vitest.dev/) for running tests.
+- [Mocha](https://mochajs.org) for test structure (`describe`, `it`, `beforeEach`).
+- [SinonJS](https://sinonjs.org) for mocking/stubbing.
+- [Chai](https://www.chaijs.com) for assertions — **always use the `.should` fluent interface**, never `expect()`. The fluent style reads as a natural sentence: `result.should.equal(expected)`.
+- Run tests with `yarn test` from each package.
+
+## File Structure
+
+Tests live alongside source code in `for_`, `when_`, or `given_` folders:
+
+```
+for_EventsCommandResponseValueHandler/
+├── given/
+│   └── an_events_command_response_value_handler.ts
+├── when_checking_can_handle/
+│   ├── with_valid_events_collection.ts
+│   ├── with_null_value.ts
+│   └── without_event_source_id.ts
+└── when_handling/
+    ├── empty_events_collection.ts
+    └── multiple_events_collection.ts
+```
+
+## BDD Pattern with `given()` Helper
+
+The `given()` function is the TypeScript equivalent of the C# `Specification` base class. It instantiates a context class (the "given"), passes it to the test suite, and ensures setup runs before assertions. This keeps the Establish/Because/should pattern consistent across both stacks.
+
+```typescript
+import { an_events_command_response_value_handler } from '../given/an_events_command_response_value_handler';
+import { given } from '../../../given';
+
+describe('when checking can handle with valid events collection', given(an_events_command_response_value_handler, context => {
+    let result: boolean;
+
+    beforeEach(() => {
+        result = context.handler.canHandle(context.commandContext, [new TestEvent('Test')]);
+    });
+
+    it('should return true', () => {
+        result.should.be.true;
+    });
+}));
+```
+
+For behaviors with multiple outcomes, include "when \<behavior\>" as a prefix in the `describe` text.
+
+## Reusable Context Classes
+
+Context classes play the same role as `given/` classes in C# — they capture preconditions that multiple specs share. Unlike C# (where fields are `protected`), TypeScript context properties are public because tests access them directly through the `context` parameter.
+
+```typescript
+export class an_events_command_response_value_handler {
+    handler: EventsCommandResponseValueHandler;
+    commandContext: CommandContext;
+
+    constructor() {
+        this.commandContext = /* setup */;
+        this.handler = new EventsCommandResponseValueHandler(/* deps */);
+    }
+}
+```
+
+- Properties are public (not protected) — tests access them via `context.propertyName`.
+- Import `given` from the package root: `import { given } from '../../given';`.
+- Simple tests without shared setup don't need a reusable context.
+
+## Simple Test Pattern (without context)
+
+```typescript
+describe('when replacing route parameters', () => {
+    let result: { route: string; unusedParameters: object };
+
+    beforeEach(() => {
+        result = UrlHelpers.replaceRouteParameters('/api/items/{id}', { id: '123' });
+    });
+
+    it('should replace the route parameter', () => {
+        result.route.should.equal('/api/items/123');
+    });
+});
+```
+
+## Naming Conventions
+
+TypeScript specs use spaces in `it()` descriptions (unlike C# which uses underscores) because they appear in test runner output as human-readable sentences.
+
+- Use **spaces** (not underscores) in `it()` descriptions:
+  - ✅ `it('should return invalid result', ...)`
+  - ❌ `it('should_return_invalid_result', ...)`
+- Start `it()` descriptions with "should".
+- `describe()` text describes the scenario in natural language.
+
+## Assertions — Chai Fluent Interface
+
+**Always use the `.should` fluent interface. Never use `expect()`.** The `.should` style reads as a natural English sentence — `value.should.equal(expected)` vs `expect(value).to.equal(expected)` — and matches the project's preference for code that reads like prose.
+
+```typescript
+value.should.equal(expected);
+value.should.be.true;
+value.should.be.false;
+value.should.be.null;
+value.should.not.be.null;
+value.should.deep.equal(expected);
+value.should.be.instanceOf(Type);
+array.should.contain(item);
+array.should.have.lengthOf(3);
+(() => throwingFn()).should.throw(ErrorType);
+```
+
+## Mocking with Sinon
+
+```typescript
+import sinon from 'sinon';
+
+const stub = sinon.createStubInstance(ConcreteClass);
+const fetchStub = sinon.stub(globalThis, 'fetch');
+fetchStub.resolves({ ok: true, json: async () => ({ /* data */ }) });
+```
+
+## Async
+
+`beforeEach`, `afterEach`, and `it` callbacks can all be `async` when needed.
diff --git a/.github/instructions/typescript.instructions.md b/.github/instructions/typescript.instructions.md
new file mode 100644
index 0000000..84eaec8
--- /dev/null
+++ b/.github/instructions/typescript.instructions.md
@@ -0,0 +1,144 @@
+---
+applyTo: "**/*.ts,**/*.tsx"
+---
+
+# TypeScript Conventions
+
+TypeScript's type system is the primary tool for catching bugs before they reach production. Every rule here pushes toward maximum compiler coverage and self-documenting code. If the types are right, the code almost writes itself.
+
+## Enums over Magic Strings
+
+String literal unions look concise but provide no refactoring support, no namespace, and no discoverability. Enums give you all three — plus `switch` exhaustiveness checking.
+
+```ts
+// ✅ Correct — refactorable, discoverable, exhaustive
+export enum SliceType {
+    StateChange = 'stateChange',
+    StateView   = 'stateView',
+    Automation  = 'automation',
+    Translator  = 'translator',
+}
+
+// ❌ Wrong — no refactoring support, invisible to tooling
+export type SliceType = 'stateChange' | 'stateView' | 'automation' | 'translator';
+```
+
+- Use enum members everywhere — `switch` cases, comparisons, defaults.
+- Do **not** import enums as `type`; they are values.
+- Export enums from `index.ts` without the `type` keyword.
+
+## One Type or Enum per File
+
+Each type gets its own file because it makes the codebase navigable — finding `SliceType` means opening `SliceType.ts`, not hunting through `types.ts`. It also keeps diffs clean and makes imports explicit.
+
+- Every interface, type alias, and enum lives in **its own file**, named after the type (e.g. `SliceType.ts`).
+- **Never create** `types.ts`, `models.ts`, `interfaces.ts` grab-bag files — they become dumping grounds that grow without limit.
+- Exception: component props interfaces (`*Props`) may live alongside their component `.tsx` file since they are tightly coupled to that component.
+- Aggregate exports through the folder's `index.ts`.
+
+## Type Safety
+
+`any` disables the compiler — the one tool that catches bugs for free. Every `any` is a hole in the safety net. Use `unknown` and narrow with type guards instead.
+
+- Never use `any` — use `unknown`, `Record<string, unknown>`, or proper generic constraints.
+- Prefer `value as unknown as TargetType` over `value as any`.
+- Use `unknown` as default generic parameter instead of `any`.
+- React synthetic events (`React.MouseEvent<Element, MouseEvent>`) and DOM events (`MouseEvent`) are different types — don't mix them.
+
+## Localised Strings
+
+All user-visible text **must** come from translation files — never hard-code UI strings directly in component code. This is not optional even for English-only deployments — it centralizes copy, enables future localization, and makes it possible to audit all user-facing text in one place.
+
+### Structure
+
+```
+Source/Core/
+  Strings.ts                    ← re-exports the default (English) JSON
+  Locales/
+    en/
+      translation.json          ← all English strings, organized by feature/component
+```
+
+`translation.json` is a nested JSON object whose top-level keys group strings by feature or component (e.g. `projects`, `eventModeling`, `chat`). Add new keys under the appropriate existing group, or add a new top-level group if the feature is new.
+
+### Importing
+
+Import the strings object using the `Strings` path alias (configured in `tsconfig.json`):
+
+```ts
+import strings from 'Strings';
+```
+
+Do **not** use relative paths such as `'../../Strings'` or `'../Strings'`.
+
+### Usage
+
+Access strings directly through the nested object — TypeScript infers the full type from the JSON file:
+
+```tsx
+import strings from 'Strings';
+
+export const MyComponent = () => (
+    <Button label={strings.projects.addProject} />
+);
+```
+
+For attribute strings (e.g. `title`, `placeholder`, `aria-label`):
+
+```tsx
+<div title={strings.eventModeling.grid.detailPanel.event}>
+    ...
+</div>
+```
+
+### Adding New Strings
+
+1. Add the key to `Source/Core/Locales/en/translation.json` under the appropriate group.
+2. TypeScript picks up the new key automatically from `Strings.ts` (no regeneration step).
+3. Use the key via `strings.<group>.<key>` in the component.
+
+### Rules
+
+- **Never** use plain string literals for user-visible text in JSX or attribute props. This includes `label`, `header`, `placeholder`, `title`, `aria-label`, `emptyMessage`, and any visible text nodes.
+- Only constant, non-localised values are allowed as raw strings (CSS class names, `key` props, internal identifiers).
+
+## Arc Frontend Patterns
+
+Arc's proxy generator bridges C# and TypeScript automatically — every `[Command]` and `[ReadModel]` becomes a TypeScript class with `.use()` hooks, `.execute()` methods, and change tracking. This is the foundation of full-stack type safety: change a C# record and the TypeScript proxy updates on the next `dotnet build`.
+
+### Commands
+
+Auto-generated from C# `[Command]` records. The `.use()` hook returns a tuple: the command instance (with change tracking) and a setter for property values.
+
+```tsx
+const [command, setValues] = OpenAccount.use({ name: '', owner: '' });
+await command.execute();       // Sends command to backend, returns CommandResult
+await command.validate();      // Pre-flight validation only, no side effects
+command.hasChanges;            // True when any property differs from initial values
+command.revertChanges();       // Reset all properties to initial values
+```
+
+### Queries
+
+Auto-generated from C# `[ReadModel]` static query methods. Observable queries (returning `ISubject<T>` on the backend) auto-subscribe via WebSocket — the component re-renders when data changes on the server.
+
+```tsx
+const [result, perform] = AllProjects.use();
+// result.data — the query result
+// result.isPerforming — true while loading
+// result.hasData — true when data has arrived
+// result.isSuccess — true when query completed without errors
+```
+
+Paginated queries:
+```tsx
+const [result, , setPage] = AllProjects.useWithPaging(10);
+```
+
+### CommandScope
+
+Wraps multiple command-using components, aggregating their `hasChanges` state and enabling bulk `execute()` and `revertChanges()`. Useful for forms that span multiple components.
+
+### CommandForm
+
+Declarative form component with built-in field types, validation timing (`validateOn: blur|change|both`), and automatic server-side validation feedback.
diff --git a/.github/instructions/vertical-slices.instructions.md b/.github/instructions/vertical-slices.instructions.md
new file mode 100644
index 0000000..e54526f
--- /dev/null
+++ b/.github/instructions/vertical-slices.instructions.md
@@ -0,0 +1,514 @@
+---
+applyTo: "**/Features/**/*.*"
+---
+
+# Vertical Slice Architecture
+
+A vertical slice contains *everything* for a single behavior: the command or query, the events it produces, the projections that build read models, the React component that renders the UI, and the specs that verify it all works. Everything lives together in one folder because everything changes together.
+
+This is the opposite of layered architecture. In a layered project, adding "author registration" means touching `Commands/`, `Handlers/`, `Events/`, `Projections/`, `Models/`, and `Components/` — six folders across two tech stacks. In a vertical slice, it's one folder with one `.cs` file and one `.tsx` file. A developer working on a feature sees its entire scope without navigating elsewhere.
+
+## Technical Stack
+
+- .NET with C# 13 (ASP.NET Core)
+- React + TypeScript (Vite)
+- PrimeReact UI component library
+- Cratis Arc for CQRS application model
+- Cratis Chronicle for event sourcing
+- MongoDB for read models
+- Vitest + Mocha/Chai/Sinon for TypeScript specs
+- xUnit + Cratis.Specifications + NSubstitute for C# specs
+
+## Core Rules
+
+These are non-negotiable because the frameworks rely on them for convention-based discovery and proxy generation:
+
+- **Each vertical slice has its own folder with a single `.cs` file containing ALL backend artifacts.** This keeps cohesion high — you never wonder which file has the event or the validator. It's all in one place.
+- **Commands define `Handle()` directly on the record — never create separate handler classes.** Arc discovers `Handle()` by convention; a separate handler class breaks that discovery.
+- **`[EventType]` must have NO arguments — the type name is used automatically.** Adding a GUID or string argument is a mistake from other frameworks.
+- Complete one slice end-to-end before starting the next. Half-finished slices create confusion and merge conflicts.
+- Drop the `.Features` segment from namespaces (e.g. `MyApp.Projects.Registration` not `MyApp.Features.Projects.Registration`).
+
+---
+
+## Slice Types
+
+| Type | Purpose | What It Contains |
+|---|---|---|
+| **State Change** | Mutates system state | Command + events + validators/constraints |
+| **State View** | Projects events into queryable read models | Read model + projection + queries |
+| **Automation** | Reacts to read models, makes decisions | Reactor + local read models |
+| **Translation** | Adapts events across slices/systems | Reactor → triggers commands in own slice |
+
+---
+
+## Folder Structure
+
+```
+Features/
+├── <Feature>/
+│   ├── <Feature>.tsx              ← composition page (layout + menu)
+│   ├── <Concept>.cs               ← shared concepts for this feature
+│   ├── <SliceName>/
+│   │   ├── <SliceName>.cs         ← ALL backend artifacts in ONE file
+│   │   ├── <Component>.tsx        ← React component(s) for this slice
+│   │   └── when_<behavior>/       ← integration specs (state-change slices)
+│   │       ├── and_<scenario>.cs
+│   │       └── ...
+│   └── ...
+```
+
+**✅ CORRECT:**
+```
+Features/Authors/
+├── Authors.tsx
+├── AuthorId.cs
+├── AuthorName.cs
+├── Registration/
+│   ├── Registration.cs            ← command + event + constraint
+│   ├── AddAuthor.tsx
+│   └── when_registering/
+│       ├── and_there_are_no_authors.cs
+│       └── and_name_already_exists.cs
+└── Listing/
+    ├── Listing.cs                 ← read model + projection + query
+    └── Listing.tsx
+```
+
+**❌ WRONG — Never split by artifact type:**
+```
+Features/Authors/
+├── Commands/RegisterAuthor.cs
+├── Handlers/RegisterAuthorHandler.cs
+├── Events/AuthorRegistered.cs
+```
+
+---
+
+## What Goes in a Single Slice File
+
+A single `<SliceName>.cs` file contains ALL of:
+
+- `[Command]` records with `Handle()` method
+- `CommandValidator<T>` (if needed)
+- `IConstraint` implementations (if needed)
+- `[EventType]` records
+- `[ReadModel]` records with static query methods (State View slices)
+- `IProjectionFor<T>` or model-bound projection attributes (State View slices)
+- `IReducerFor<T>` implementations (if needed)
+- `IReactor` implementations (Translation/Automation slices)
+- Slice-specific `ConceptAs<T>` types
+
+---
+
+## Events
+
+Events are **facts** — immutable records of things that have already happened. They are the write-side of the system and form a perfect audit trail. Once appended, an event is never modified or deleted; if something needs to be "undone," append a compensating event.
+
+Immutable records decorated with `[EventType]` from `Cratis.Chronicle.Events`.
+
+```csharp
+[EventType]
+public record AuthorRegistered(AuthorName Name);
+```
+
+**Rules:**
+- `[EventType]` takes **no arguments** — the type name is the event identifier.
+- Use past tense: `ItemAddedToCart`, `UserRegistered`, `AddressChangedForPerson`. Past tense reinforces that events describe what *happened*, not what *should happen*.
+- Events are facts — never nullable properties. Nullable properties mean the event's meaning is ambiguous, forcing every observer to add logic to interpret it. If a property is genuinely optional, you need a second event.
+- One purpose per event — never multipurpose events. A `UserUpdated` event with 10 nullable fields is a design smell; use `EmailChanged`, `NameChanged`, `AddressChanged` instead.
+
+**❌ WRONG:**
+```csharp
+[EventType("ce956ea9-...")]              // ❌ No GUID argument
+[EventType("AuthorRegistered")]          // ❌ No string argument
+```
+
+---
+
+## Commands
+
+Records decorated with `[Command]` from `Cratis.Arc.Commands.ModelBound`.
+
+```csharp
+[Command]
+public record RegisterAuthor(AuthorName Name)
+{
+    public (AuthorId, AuthorRegistered) Handle()
+    {
+        var authorId = AuthorId.New();
+        return (authorId, new(Name));
+    }
+}
+```
+
+**`Handle()` return types:**
+- Single event: `public AuthorRegistered Handle() => new(Name);`
+- Tuple (event + result): `public (AuthorId, AuthorRegistered) Handle() => ...`
+- `Result<TSuccess, TError>`: `public Result<BookReserved, ValidationResult> Handle(Book book) => ...`
+- `void` / `Task` for commands without events
+
+**Event source resolution (in priority order):**
+1. Parameter marked with `[Key]` from `Cratis.Chronicle.Keys`
+2. Parameter whose type has implicit conversion to `EventSourceId`
+3. Implement `ICanProvideEventSourceId`
+
+**DI in Handle():** Extra parameters (beyond the command and read model arguments) are resolved from DI automatically.
+
+---
+
+## Business Rules via DCB (Dynamic Consistency Boundary)
+
+Express business rules by accepting a **read model parameter** in `Handle()`. The framework injects the current projected state before invoking the method.
+
+```csharp
+[Command]
+public record ReserveBook(ISBN Isbn, MemberId MemberId)
+{
+    public Result<BookReserved, ValidationResult> Handle(Book book)
+    {
+        if (book.Available <= 0)
+            return ValidationResult.Error($"No available copies for {Isbn}");
+
+        return new BookReserved(Isbn, MemberId);
+    }
+}
+```
+
+Throw a **custom exception** (never built-in) to signal a violation — the framework converts it to a failed `CommandResult`.
+
+---
+
+## Command Validation
+
+Use `CommandValidator<T>` from `Cratis.Arc.Commands` (extends FluentValidation):
+
+```csharp
+public class RegisterAuthorValidator : CommandValidator<RegisterAuthor>
+{
+    public RegisterAuthorValidator()
+    {
+        RuleFor(c => c.Name).NotEmpty().WithMessage("Author name is required");
+    }
+}
+```
+
+Validators with DI dependencies:
+```csharp
+public class MyValidator : CommandValidator<MyCommand>
+{
+    public MyValidator(IMyService service)
+    {
+        RuleFor(x => x).MustAsync(async (cmd, ct) => await service.IsValid(cmd));
+    }
+}
+```
+
+---
+
+## Constraints
+
+Server-side rules enforced by Chronicle at event-append time.
+
+**Unique property across events:**
+```csharp
+public class UniqueAuthorName : IConstraint
+{
+    public void Define(IConstraintBuilder builder) => builder
+        .Unique(_ => _
+            .On<AuthorRegistered>(e => e.Name)
+            .On<AuthorNameChanged>(e => e.Name)
+            .RemovedWith<AuthorRemoved>()
+            .WithMessage("Author name must be unique"));
+}
+```
+
+**Unique event type per event source:**
+```csharp
+public class UniqueUser : IConstraint
+{
+    public void Define(IConstraintBuilder builder) =>
+        builder.Unique<UserRegistered>();
+}
+```
+
+---
+
+## Read Models & Projections
+
+Read models are the *read side* of the system — purpose-built views optimized for specific queries. A single events stream can feed many projections, each building a different view of the same data. This is by design: specialized projections are easier to maintain, perform better, and never break unrelated features when one query's needs change.
+
+### Model-Bound (Preferred — Attributes)
+
+```csharp
+[ReadModel]
+[FromEvent<Registration.AuthorRegistered>]
+public record Author(
+    [Key] AuthorId Id,
+    AuthorName Name)
+{
+    public static ISubject<IEnumerable<Author>> AllAuthors(IMongoCollection<Author> collection) =>
+        collection.Observe();
+}
+```
+
+**Key attributes:**
+| Attribute | Purpose |
+|---|---|
+| `[Key]` | Read model primary key |
+| `[FromEvent<T>]` | Convention-based auto-mapping from event |
+| `[FromEvent<T>(key: nameof(...))]` | Custom key from event property |
+| `[SetFrom<T>]` | Explicit property mapping from event |
+| `[AddFrom<T>]` / `[SubtractFrom<T>]` | Arithmetic operations |
+| `[Increment<T>]` / `[Decrement<T>]` | ±1 counters |
+| `[Count<T>]` | Absolute count |
+| `[ChildrenFrom<T>]` | Child collection from event |
+| `[Join<T>]` | Join data from another event stream |
+| `[RemovedWith<T>]` | Remove entry when event occurs |
+| `[Passive]` | On-demand projection, not actively observed |
+| `[NotRewindable]` | Forward-only, cannot be replayed |
+
+### Fluent Projection (Alternative — for complex cases)
+
+```csharp
+public class AuthorProjection : IProjectionFor<Author>
+{
+    public void Define(IProjectionBuilderFor<Author> builder) => builder
+        .From<AuthorRegistered>();
+}
+```
+
+AutoMap is **on by default** — you only need `.AutoMap()` if you previously called `.NoAutoMap()`. Most projections just call `.From<>()` directly.
+
+**Complex projection with joins:**
+```csharp
+public class BorrowedBooksProjection : IProjectionFor<BorrowedBook>
+{
+    public void Define(IProjectionBuilderFor<BorrowedBook> builder) => builder
+        .From<BookBorrowed>(from => from
+            .Set(m => m.UserId).To(e => e.UserId)
+            .Set(m => m.Borrowed).ToEventContextProperty(c => c.Occurred))
+        .Join<BookAddedToInventory>(j => j
+            .On(m => m.Id)
+            .Set(m => m.Title).To(e => e.Title))
+        .RemovedWith<BookReturned>();
+}
+```
+
+**Projections join EVENTS, never read models.** This is fundamental to event sourcing — projections rebuild state from the event stream, not from other projections. A projection that reads from another read model creates a hidden dependency and breaks replay.
+
+### Passive Projections
+
+For read models used only in DCB business rules (not for queries):
+```csharp
+public class BookProjection : IProjectionFor<Book>
+{
+    public void Define(IProjectionBuilderFor<Book> builder) => builder
+        .Passive()
+        .From<BookAddedToInventory>(e => e.Increment(book => book.Available))
+        .From<BookReserved>(e => e.Decrement(book => book.Available));
+}
+```
+
+---
+
+## Queries
+
+Static methods on `[ReadModel]` records. Favor reactive queries (`ISubject<T>`) for real-time updates.
+
+```csharp
+public static ISubject<IEnumerable<Author>> AllAuthors(IMongoCollection<Author> collection) =>
+    collection.Observe();
+
+public static Author? ById(IMongoCollection<Author> collection, AuthorId id) =>
+    collection.Find(a => a.Id == id).FirstOrDefault();
+```
+
+Method parameters are DI-resolved. `IMongoCollection<T>` is automatically available for `[ReadModel]` types.
+
+---
+
+## Reducers
+
+Reducers are the imperative counterpart to projections. Where projections are declarative mappings, reducers give you full control: receive the current state and an event, return the new state. Use them when mapping alone can't express the logic — aggregations, conditional updates, or complex transformations.
+
+```csharp
+public class AccountBalanceReducer : IReducerFor<AccountBalance>
+{
+    public AccountBalance OnDepositMade(DepositMade @event, AccountBalance? current, EventContext context)
+    {
+        var balance = current?.Balance ?? 0m;
+        return new AccountBalance(balance + @event.Amount, context.Occurred);
+    }
+}
+```
+
+- `current` is `null` for the first event — always handle initialization gracefully.
+- Keep reducers pure — no side effects, no database calls, no I/O. They must be safe to replay.
+- Use immutable state with `with` expressions on records.
+
+---
+
+## Reactors
+
+Reactors are the "if this then that" of event sourcing — they observe events and produce side effects. Unlike projections (which build state) and reducers (which transform state), reactors *do things*: send emails, trigger commands in other slices, call external APIs.
+
+Side-effect observers for Translation and Automation slices.
+
+```csharp
+public class StockKeeping(ICommandPipeline commandPipeline) : IReactor
+{
+    public async Task HandleBookReserved(BookReserved @event) =>
+        await commandPipeline.Execute(new DecreaseStock(@event.Isbn));
+}
+```
+
+- `IReactor` is a marker interface — method dispatch is by first-parameter type.
+- Method name can be anything descriptive.
+- `EventContext` parameter is optional.
+- `[OnceOnly]` — method executes only on first processing, skipped during replay.
+- If a reactor throws, the failing event source partition pauses until resolved.
+
+---
+
+## Event Seeding
+
+Provide predefined events at startup. Chronicle deduplicates automatically.
+
+```csharp
+public class EmployeeSeeding : ICanSeedEvents
+{
+    public void Seed(IEventSeedingBuilder builder)
+    {
+        builder.ForEventSource("employee-1", [
+            new PersonHired("John", "Doe", "Engineer"),
+            new EmployeeAddressSet("123 Main St", "Springfield", "62701", "US")
+        ]);
+    }
+}
+```
+
+Use `#if DEBUG` to prevent seeding in production.
+
+---
+
+## Concepts
+
+- Prefer `ConceptAs<T>` over raw primitives everywhere.
+- Concepts shared between slices → feature folder.
+- Concepts shared between features → `Features/` root.
+- One file per concept.
+
+See [Concepts Instructions](./concepts.instructions.md) for full details.
+
+---
+
+## Development Workflow
+
+Work **slice-by-slice** in this exact order. The sequence matters — TypeScript proxies are generated from C# during `dotnet build`, so frontend work cannot begin until the backend compiles.
+
+1. **Backend** — Implement the C# slice file (command/query/projection + events, validators, constraints)
+2. **Specs** — Write integration specs for state-change slices
+3. **Build** — Run `dotnet build` to generate TypeScript proxies (this step creates the `.ts` files the frontend imports)
+4. **Frontend** — Implement React component(s) using the auto-generated proxies
+5. **Composition** — Register in the feature's composition page
+6. **Routes** — Add/update routing if needed
+
+### Sub-agent coordination
+
+When parallel agents or sub-agents are used, steps 1–3 are a **hard prerequisite** for step 4. Backend and frontend for the same slice cannot run in parallel — the frontend agent must wait for `dotnet build` to complete. Independent slices (no shared event types) can have their backend phases worked on in parallel, but each slice's frontend still depends on its own build completing first.
+
+---
+
+## Integration Specs
+
+Specs live under `when_<behavior>/` folders directly inside the slice folder — no `for_` prefix.
+
+```csharp
+using context = MyApp.Authors.Registration.when_registering.and_there_are_no_authors.context;
+
+namespace MyApp.Authors.Registration.when_registering;
+
+[Collection(ChronicleCollection.Name)]
+public class and_there_are_no_authors(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public CommandResult<Guid>? Result;
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<RegisterAuthor, Guid>(
+                "/api/authors/register",
+                new RegisterAuthor("John Doe"));
+        }
+    }
+
+    [Fact] void should_be_successful() => Context.Result.IsSuccess.ShouldBeTrue();
+    [Fact] void should_have_appended_only_one_event() => Context.ShouldHaveTailSequenceNumber(EventSequenceNumber.First);
+    [Fact] void should_append_author_registered_event() => Context.ShouldHaveAppendedEvent<AuthorRegistered>(
+        EventSequenceNumber.First, Context.Result.Response,
+        evt => evt.Name.Value.ShouldEqual("John Doe"));
+}
+```
+
+---
+
+## Frontend
+
+### Listing View
+
+```tsx
+import { DataTable } from 'primereact/datatable';
+import { Column } from 'primereact/column';
+import { AllAuthors } from './AllAuthors';
+
+export const Listing = () => {
+    const [result] = AllAuthors.use();
+
+    return (
+        <DataTable value={result.data} scrollable scrollHeight="flex" emptyMessage="No authors found.">
+            <Column field="name" header="Name" />
+        </DataTable>
+    );
+};
+```
+
+### Composition Page
+
+```tsx
+import { Page } from '../../Components/Common';
+import { AddAuthor } from './Registration/AddAuthor';
+import { Listing } from './Listing/Listing';
+import { useDialog } from '@cratis/arc.react/dialogs';
+import { Menubar } from 'primereact/menubar';
+import { MenuItem } from 'primereact/menuitem';
+import * as mdIcons from 'react-icons/md';
+
+export const Authors = () => {
+    const [AddAuthorDialog, showAddAuthorDialog] = useDialog(AddAuthor);
+
+    const menuItems: MenuItem[] = [
+        {
+            label: 'Add Author',
+            icon: mdIcons.MdAdd,
+            command: async () => { await showAddAuthorDialog(); }
+        }
+    ];
+
+    return (
+        <Page title="Authors">
+            <Menubar model={menuItems} />
+            <Listing />
+            <AddAuthorDialog />
+        </Page>
+    );
+};
+```
+
+### Dialogs
+
+- **Never** import `Dialog` from `primereact/dialog` — use Cratis wrappers.
+- `CommandDialog` from `@cratis/components/CommandDialog` — for dialogs that execute commands.
+- `Dialog` from `@cratis/components/Dialogs` — for data collection without commands.
+- Do not render manual `<Button>` for dialog actions.
diff --git a/.github/prompts/add-business-rule.prompt.md b/.github/prompts/add-business-rule.prompt.md
new file mode 100644
index 0000000..ffd0a20
--- /dev/null
+++ b/.github/prompts/add-business-rule.prompt.md
@@ -0,0 +1,83 @@
+---
+agent: agent
+description: Add a business rule (DCB ReadModel argument) or event-store constraint (IConstraint) to an existing command.
+---
+
+# Add a Business Rule or Constraint
+
+I need to enforce a new rule on an existing command in a Cratis-based project.
+
+## Inputs
+
+- **Command** — name of the existing command, e.g. `RegisterProject`
+- **Rule type** — one of:
+  - **Business rule (DCB)** — add a read model parameter to `Handle()`; the framework fetches and injects the current state before the method runs
+  - **Event-store constraint** (`IConstraint`) — enforced by Chronicle at the event-log level; typically uniqueness
+- **Rule description** — what must be true for the command to succeed, e.g. "project name must be unique across tenant"
+
+## Business Rules via DCB (ReadModel as argument)
+
+Business rules that depend on Chronicle event-sourced state are expressed by adding a **read model parameter** to the `Handle()` method.
+The framework resolves the read model instance (using the same event-source key as the command) and injects it before `Handle()` runs.
+
+```csharp
+[Command]
+public record AddItemToCart(CartId CartId, ItemId ItemId)
+{
+    /// <summary>
+    /// Adds the item; throws if the cart already holds 3 items.
+    /// </summary>
+    /// <param name="cart">The current cart summary.</param>
+    /// <returns>The <see cref="ItemAddedToCart"/> event.</returns>
+    /// <exception cref="CartIsFull">Thrown when the cart already contains the maximum number of items.</exception>
+    public ItemAddedToCart Handle(CartSummary cart)
+    {
+        if (cart.ItemCount >= 3)
+            throw new CartIsFullException(CartId);
+
+        return new ItemAddedToCart(ItemId);
+    }
+}
+```
+
+**Rules:**
+- The read model parameter type must be a `[ReadModel]`-decorated type in the same feature.
+- Throw a **custom exception** (never a built-in one) to signal a violation — the framework converts it to a failed `CommandResult`.
+- Multiple read model parameters are allowed if the decision requires more than one projection.
+
+## Event-Store Constraints (`IConstraint`)
+
+Constraints are enforced by Chronicle when the event is appended.
+Use when the uniqueness or validity guarantee must survive concurrent writes across multiple instances.
+
+```csharp
+public class UniqueProjectName : IConstraint
+{
+    public void Define(IConstraintBuilder builder) =>
+        builder.Unique(unique =>
+            unique
+                .On<ProjectRegistered>(e => e.Name)
+                .RemovedWith<ProjectRemoved>());
+}
+```
+
+Constraints are discovered and enforced automatically — no registration required.
+
+### When to use constraints vs business rules
+
+| Scenario | Use |
+|----------|-----|
+| Uniqueness that must survive concurrent writes | `IConstraint` |
+| Rule requiring Chronicle event-sourced state | ReadModel parameter in `Handle()` (DCB) |
+| Simple synchronous invariant (format, range) | `CommandValidator<T>` |
+
+## Checklist
+
+- [ ] Rule is placed in the same slice file as the command
+- [ ] ReadModel parameter type is a `[ReadModel]`-decorated type in the same feature
+- [ ] Custom exception type (never built-in) is thrown to signal a violation
+- [ ] Error messages are user-readable and include relevant context
+- [ ] Constraints are auto-discovered — no registration needed
+- [ ] Spec added for the failure case — see `write-specs.prompt.md`
+- [ ] `dotnet build` passes with zero errors
+- [ ] `dotnet test` passes with zero failures
diff --git a/.github/prompts/add-concept.prompt.md b/.github/prompts/add-concept.prompt.md
new file mode 100644
index 0000000..d0bc487
--- /dev/null
+++ b/.github/prompts/add-concept.prompt.md
@@ -0,0 +1,92 @@
+---
+agent: agent
+description: Create a strongly-typed Concept (ConceptAs<T>) for a primitive domain value.
+---
+
+# Add a Concept
+
+I need to create a **strongly-typed Concept** to wrap a primitive domain value.
+
+## Inputs
+
+- **Concept name** — e.g. `ProjectId`, `AuthorName`, `InvoiceNumber`
+- **Underlying primitive type** — `Guid`, `string`, `int`, `long`, `decimal`, etc.
+- **Is this an event-source ID?** — If yes, an `EventSourceId` implicit conversion is needed
+- **Does it need a `New()` factory?** — Typically yes for ID types backed by `Guid`
+- **Folder** — where in `Features/` or `Engine/` to place it (matches domain context, NOT a dedicated `Concepts/` folder)
+
+## Instructions
+
+Follow `.github/instructions/concepts.instructions.md` exactly.
+
+### Template
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+using Cratis.Concepts;
+
+namespace <NamespaceRoot>.<Feature>;
+
+/// <summary>
+/// Represents the identity of a <description>.
+/// </summary>
+/// <param name="Value">The underlying <type> value.</param>
+public record <ConceptName>(<UnderlyingType> Value) : ConceptAs<<UnderlyingType>>(Value)
+{
+    /// <summary>
+    /// Represents an unset or empty <ConceptName>.
+    /// </summary>
+    public static readonly <ConceptName> NotSet = new(<EmptyValue>);
+
+    /// <summary>
+    /// Implicitly converts a <UnderlyingType> to a <ConceptName>.
+    /// </summary>
+    public static implicit operator <ConceptName>(<UnderlyingType> value) => new(value);
+}
+```
+
+### When the concept is an event-source ID (add after the implicit from primitive)
+
+```csharp
+    /// <summary>
+    /// Implicitly converts a <ConceptName> to an <see cref="EventSourceId"/>.
+    /// </summary>
+    public static implicit operator EventSourceId(<ConceptName> id) => new(id.Value.ToString());
+```
+
+### When a `New()` factory is needed (Guid-backed IDs)
+
+```csharp
+    /// <summary>
+    /// Creates a new <ConceptName> with a unique value.
+    /// </summary>
+    public static <ConceptName> New() => new(Guid.NewGuid());
+```
+
+### Empty values by type
+
+| Underlying type | Recommended empty value |
+|-----------------|------------------------|
+| `Guid`          | `Guid.Empty`           |
+| `string`        | `string.Empty`         |
+| `int`           | `0`                    |
+| `long`          | `0L`                   |
+
+## Placement rules
+
+- Do NOT create a `Concepts/` folder.
+- Place the file in the folder that owns the concept semantically.
+  - `ProjectId` lives in `Features/Projects/` or the highest-level folder that uses it.
+  - Shared cross-feature concepts live in the project root source folder.
+
+## Checklist
+
+- [ ] Inherits `ConceptAs<T>` (not a plain `record` with a value)
+- [ ] Has a `static readonly NotSet` (or `Empty`) sentinel
+- [ ] Has an implicit conversion **from** the primitive type
+- [ ] Has an implicit conversion **to** `EventSourceId` if used as event-source key
+- [ ] Has a `New()` factory if `Guid`-backed
+- [ ] Copyright header present
+- [ ] `dotnet build` passes with zero errors or warnings
diff --git a/.github/prompts/add-ef-migration.prompt.md b/.github/prompts/add-ef-migration.prompt.md
new file mode 100644
index 0000000..7547c36
--- /dev/null
+++ b/.github/prompts/add-ef-migration.prompt.md
@@ -0,0 +1,67 @@
+---
+agent: agent
+description: Add or update an Entity Framework Core DbContext, table column, or hand-written migration in the project.
+---
+
+# Add an EF Core Migration
+
+I need to make a **database schema change** via Entity Framework Core.
+
+> **Before starting:** Read `.github/instructions/efcore.instructions.md` and `.github/instructions/efcore.specs.instructions.md`.
+
+## Inputs
+
+- **Change type** — one of:
+  - New table / entity
+  - New column on existing table
+  - Remove column
+  - Rename column / table
+  - New relationship (FK, navigation property)
+  - Other (describe)
+- **Entity name** — the C# record being changed
+- **Feature DbContext** — which `ReadOnlyDbContext` or `BaseDbContext` owns this entity
+
+## Step-by-step process
+
+### 1 — Update the entity and feature DbContext
+
+- Add/remove/rename properties on the entity `record` in the **Core** project, co-located with its feature folder.
+- Update or create the feature DbContext:
+  - Inherit from `ReadOnlyDbContext` (read models) or `BaseDbContext` (writable state) — never raw `DbContext`
+  - Expose `DbSet<T>` as expression-bodied properties: `public DbSet<Entity> Entities => Set<Entity>();`
+  - One focused context per feature — never a "god context"
+
+### 2 — Add the table name to WellKnownTables
+
+If this is a new table, add a `const string` to `Database/WellKnownTables.cs` before writing the migration.
+
+### 3 — Write the migration by hand
+
+Migrations are **hand-written** in the **Database** project — never use `dotnet ef migrations add`.
+
+- Place the file in a subfolder matching the entity category: `Database/Missions/v1_1_0.cs`
+- Use `v{major}_{minor}_{patch}.cs` naming — never PascalCase names like `AddColumn`
+- Namespace must match the folder: `namespace Database.Missions;`
+- Always use Cratis Arc cross-database column helpers (`table.StringColumn()`, `table.GuidColumn()`, `table.NumberColumn<T>()`, `table.DateTimeOffsetColumn()`) — never raw `table.Column<T>()`
+- Always reference table names from `WellKnownTables` constants — never magic strings
+
+### 4 — Register the DbContext (if new)
+
+- Read-only contexts are auto-discovered via `AddReadModelDbContextsWithConnectionStringFromAssemblies`
+- Writable contexts need explicit `AddDbContextWithConnectionString<T>` in Infrastructure
+
+### 5 — Update specs
+
+- Integration specs using in-memory SQLite pick up schema changes via `context.Database.EnsureCreated()`.
+- Follow `.github/instructions/efcore.specs.instructions.md` for testing patterns.
+
+### 6 — Validate
+
+Run `dotnet build` and `dotnet test`. Fix all failures before completing.
+
+## Key rules
+
+- **Never** use `dotnet ef migrations add` or `dotnet ef database update`
+- **Never** hardcode a provider (`UseSqlite`, `UseNpgsql`) — use `UseDatabaseFromConnectionString`
+- **Never** mutate state directly through a DbContext — writes flow through Chronicle events
+- **Always** use `WellKnownTables` constants and cross-database column helpers
diff --git a/.github/prompts/add-projection.prompt.md b/.github/prompts/add-projection.prompt.md
new file mode 100644
index 0000000..69d712a
--- /dev/null
+++ b/.github/prompts/add-projection.prompt.md
@@ -0,0 +1,57 @@
+---
+agent: agent
+description: Add a Chronicle projection to an existing read model slice.
+---
+
+# Add a Projection
+
+I need to add a **Chronicle projection** that populates a read model from events.
+
+> For **reactors** (automation / translation), use the `add-reactor` prompt instead.
+
+## Inputs
+
+- **Events to project from** — list the event types (e.g. `ProjectRegistered`, `ProjectRemoved`)
+- **Read model** — paste the `record` type or describe the shape you want
+
+## Projection rules (mandatory)
+
+Follow `.github/instructions/vertical-slices.instructions.md` — projection section.
+
+**Preferred — model-bound:** Place attributes directly on the read model record, no separate class needed.
+
+```csharp
+[ReadModel]
+[FromEvent<ProjectRegistered>]
+public record Project(
+    [Key] ProjectId Id,
+    ProjectName Name)
+{
+    public static ISubject<IEnumerable<Project>> AllProjects(IMongoCollection<Project> collection) =>
+        collection.Observe();
+}
+```
+
+**Alternative — fluent `IProjectionFor<T>:`** Use for complex joins, children, or conditionals.
+
+```csharp
+public class ProjectProjection : IProjectionFor<ReadModel>
+{
+    public void Define(IProjectionBuilderFor<ReadModel> builder) =>
+        builder
+            .From<ProjectRegistered>(b =>
+                b.UsingKey(e => e.ProjectId)
+                 .Set(m => m.Name).To(e => e.Name))
+            .RemovedWith<ProjectRemoved>();
+}
+```
+
+**Critical rules:**
+- AutoMap is on by default — just call `.From<>()` directly
+- Joins are on Chronicle **events**, never on the read model
+- Use `.RemovedWith<TEvent>()` for soft-delete events
+- **There is NO `ProjectionId Identifier` property — do not add one**
+
+## After creating the file
+
+Run `dotnet build` and fix all errors before completing.
diff --git a/.github/prompts/add-reactor.prompt.md b/.github/prompts/add-reactor.prompt.md
new file mode 100644
index 0000000..5b4beb7
--- /dev/null
+++ b/.github/prompts/add-reactor.prompt.md
@@ -0,0 +1,60 @@
+---
+agent: agent
+description: Add a Chronicle reactor (automation or translation) that reacts to events and triggers side effects.
+---
+
+# Add a Reactor
+
+I need to add a **Chronicle reactor** that observes events and produces side effects (automation, notifications, translations between slices).
+
+> **Before starting:** Read `.github/instructions/reactors.instructions.md`.
+
+## Inputs
+
+- **Events to react to** — list the event types (e.g. `ProjectRegistered`, `BookReserved`)
+- **Purpose** — describe the side-effect or automation to perform
+- **Pattern** — `Automation` (reacts to events, triggers side effects) or `Translation` (adapts events across slices by triggering commands)
+
+## Reactor rules (mandatory)
+
+```csharp
+public class AutomationName(IDependency dependency) : IReactor
+{
+    /// <summary>
+    /// Handles <see cref="SomeEvent"/> events.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public Task HandleSomeEvent(SomeEvent @event, EventContext context) =>
+        dependency.DoSomethingWith(@event);
+}
+```
+
+**Critical rules:**
+- `IReactor` is a **marker interface** — no methods to implement
+- Event dispatch is by first-parameter type; method name can be anything descriptive
+- `EventContext` is optional — omit if event metadata is not needed
+- Reactors MUST be idempotent — they may be called more than once for the same event
+- Do not query the read model inside the reactor — use the event data directly
+- To produce new events, inject `ICommandPipeline` and execute a command — never use `IEventLog` directly
+
+## Translation pattern
+
+If the reactor adapts events by triggering commands in another slice:
+
+```csharp
+public class StockKeeping(IStockKeeper stockKeeper, ICommandPipeline commandPipeline) : IReactor
+{
+    /// <summary>
+    /// Decreases stock when a book is reserved.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task BookReserved(BookReserved @event, EventContext context) =>
+        await commandPipeline.Execute(new DecreaseStock(@event.Isbn, await stockKeeper.GetStock(@event.Isbn)));
+}
+```
+
+## After creating the file
+
+Run `dotnet build` and fix all errors before completing.
diff --git a/.github/prompts/new-vertical-slice.prompt.md b/.github/prompts/new-vertical-slice.prompt.md
new file mode 100644
index 0000000..fc1b21c
--- /dev/null
+++ b/.github/prompts/new-vertical-slice.prompt.md
@@ -0,0 +1,75 @@
+---
+agent: agent
+description: Scaffold a complete vertical slice (backend + specs + frontend) for a Cratis-based project.
+---
+
+# New Vertical Slice
+
+I need you to implement a complete **vertical slice** for a Cratis-based project.
+
+## Inputs
+
+Please provide (or I'll ask):
+- **Feature name** — e.g. `Projects`
+- **Slice name** — e.g. `Registration`, `Listing`, `Removal`
+- **Slice type** — one of:
+  - `State Change` — command that appends events and changes read models
+  - `State View` — query that reads from a read model
+  - `Automation` — background reactor triggered by events
+  - `Translation` — transforms/enriches events into other events
+- **Domain description** — what the slice does in plain language
+- **Properties** — fields on the command/query and their types
+
+## What I want produced
+
+Follow `.github/instructions/vertical-slices.instructions.md` exactly.
+
+### Phase 1 — Backend (delegate to `backend-developer` agent)
+
+For a **State Change** slice, produce (in this order):
+1. Concept types (if new strongly-typed IDs are needed)
+2. Command `record` with `Handle()` method, validation, and business rules
+3. Event `record` with `[EventType]` attribute (no arguments)
+4. Read model `record` with `[ReadModel]` and model-bound projection attributes (`[FromEvent<T>]`, `[Key]`, etc.)
+   - Use fluent `IProjectionFor<T>` only when model-bound attributes don't fit
+
+For a **State View** slice, produce:
+1. Read model `record` with `[ReadModel]`, model-bound projection attributes (`[FromEvent<T>]`, `[Key]`, etc.), and a static query method
+   - Use fluent `IProjectionFor<T>` only when model-bound attributes don't fit
+
+Run `dotnet build` after creating the `.cs` file. Fix all errors before proceeding.
+
+### Phase 2 — Specs (delegate to `spec-writer` agent, State Change slices only)
+
+For each command, write specs covering:
+- Happy path (command succeeds, correct event appended)
+- Each validation failure
+- Each business rule violation
+- Each constraint violation
+
+Run `dotnet test` and fix all failures before proceeding.
+
+### Phase 3 — Frontend (delegate to `frontend-developer` agent)
+
+1. Create React component(s) in `Features/<Feature>/<Slice>/`
+2. Use auto-generated proxy types from `dotnet build`
+3. Use `CommandDialog` for command-based dialogs
+4. Update the feature composition page
+5. Update routing if a new page is introduced
+
+Run `yarn lint` and `npx tsc -b`. Fix all errors before proceeding.
+
+### Phase 4 — Quality Gates
+
+- `dotnet build` — zero errors/warnings
+- `dotnet test` — zero failures
+- `yarn lint` — zero errors
+- `npx tsc -b` — zero errors
+
+## Constraints
+
+- Namespace: `<NamespaceRoot>.<Feature>.<Slice>` — detect `<NamespaceRoot>` from existing source files
+- No abbreviations in TypeScript
+- No hard-coded colours — PrimeReact CSS variables only
+- Copyright header on every file
+- README.md for complex component folders
diff --git a/.github/prompts/review-pr.prompt.md b/.github/prompts/review-pr.prompt.md
new file mode 100644
index 0000000..36d7c58
--- /dev/null
+++ b/.github/prompts/review-pr.prompt.md
@@ -0,0 +1,94 @@
+---
+agent: agent
+description: Review a pull request against all Cratis project standards and produce a structured review report.
+---
+
+# Review Pull Request
+
+I need a structured **code review** of a pull request against all Cratis project standards.
+
+## Inputs
+
+- **PR number or branch name** — so I can examine the changed files
+- **Scope** — which repos / projects are affected
+
+## Review process
+
+### Step 1 — Gather context
+
+- List all changed files in the PR
+- Read each changed file in full
+- Identify the slice type(s) affected (State Change / State View / Automation / Translation)
+
+### Step 2 — Architecture review
+
+Delegate to the `code-reviewer` agent with all changed files.
+
+Check against:
+- `.github/instructions/vertical-slices.instructions.md`
+- `.github/instructions/csharp.instructions.md`
+- `.github/instructions/typescript.instructions.md`
+- `.github/instructions/components.instructions.md`
+- `.github/instructions/concepts.instructions.md`
+- `.github/copilot-instructions.md`
+
+### Step 3 — Security review
+
+Delegate to the `security-reviewer` agent with all changed files.
+
+Check all security categories:
+- Input validation & injection
+- Auth / authz
+- Sensitive data exposure
+- Secrets & configuration
+- Dependency & serialisation safety
+- Event sourcing specifics
+- Frontend attack surface
+
+### Step 4 — Spec coverage
+
+- Confirm every State Change command has specs covering happy path + failure cases
+- Confirm `dotnet test` output shows no regressions (if available)
+
+### Step 5 — Documentation
+
+- If a new public API, feature, or component was added, confirm documentation was updated
+- If a breaking change was introduced, confirm it is called out in the PR description
+
+---
+
+## Output format
+
+```
+## Pull Request Review — #<number>
+
+### Summary
+<2–3 sentence overview of what the PR does>
+
+### Architecture — ✅ / ⚠️ / ❌
+<findings from code-reviewer>
+
+### Security — ✅ / ⚠️ / ❌
+<findings from security-reviewer>
+
+### Spec Coverage — ✅ / ⚠️ / ❌
+<list of commands checked and whether specs exist>
+
+### Documentation — ✅ / ⚠️ / ❌
+<notes on docs updates>
+
+### Overall verdict
+**✅ Approved** / **⚠️ Approved with comments** / **❌ Changes requested**
+
+**Blocking issues** (must fix before merge):
+1. …
+
+**Suggestions** (non-blocking):
+1. …
+```
+
+## Conventions reminder
+
+- Blocking issues = anything that violates a `MUST` rule in the instructions
+- Suggestions = style improvements, optional enhancements, or `SHOULD` rules
+- Be specific: always include file, line number, and corrected code for blocking issues
diff --git a/.github/prompts/scaffold-feature.prompt.md b/.github/prompts/scaffold-feature.prompt.md
new file mode 100644
index 0000000..fcd83bc
--- /dev/null
+++ b/.github/prompts/scaffold-feature.prompt.md
@@ -0,0 +1,91 @@
+---
+agent: agent
+description: Scaffold a new feature — folder structure, composition page, routing, and first slice skeleton.
+---
+
+# Scaffold a Feature
+
+I need to scaffold a **complete new feature** in a Cratis-based project.
+This creates the folder structure, composition page, and routing — ready for slices to be added.
+
+## Inputs
+
+- **Feature name** — PascalCase, e.g. `Projects`, `Invoices`, `UserManagement`
+- **Route path** — URL path for the feature page, e.g. `/projects`
+- **Navigation label** — Text shown in the sidebar/navigation, e.g. `Projects`
+- **Navigation icon** — Name from `react-icons/md`, e.g. `MdFolderOpen`
+- **First slice** — Optional: describe one initial slice to implement after scaffolding (can also be done later with `new-vertical-slice.prompt.md`)
+
+## What to produce
+
+### 1 — Feature folder
+
+```
+Features/<Feature>/
+├── <Feature>.tsx          ← composition page
+├── <Feature>.css          ← feature-level styles (may be empty)
+└── index.ts               ← re-exports the composition page
+```
+
+### 2 — Composition page (`<Feature>.tsx`)
+
+```tsx
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { Page } from '../../Core/Page';
+
+export const <Feature> = () => {
+    return (
+        <Page title="<NavigationLabel>">
+            {/* Slices rendered here */}
+        </Page>
+    );
+};
+```
+
+### 3 — Update routing
+
+Add the feature to the application router. Locate the router configuration (typically `App.tsx` or a `routes.ts` file) and add:
+
+```tsx
+import { <Feature> } from './Features/<Feature>';
+
+// Inside the route definitions:
+{ path: '<route-path>', element: <<Feature> /> }
+```
+
+### 4 — Update navigation
+
+Locate the navigation/sidebar configuration and add:
+
+```tsx
+import * as mdIcons from 'react-icons/md';
+
+{
+    label: '<NavigationLabel>',
+    icon: mdIcons.<NavigationIcon>,
+    url: '<route-path>'
+}
+```
+
+### 5 — `index.ts`
+
+```typescript
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+export { <Feature> } from './<Feature>';
+```
+
+## Validation
+
+After scaffolding, run:
+- `yarn lint` — zero errors
+- `npx tsc -b` — zero errors
+- Confirm the new route renders an empty page without runtime errors
+
+## Next step
+
+Once scaffolding is complete, use `new-vertical-slice.prompt.md` to add slices to the feature.
+Each slice's component will be imported and composed into `<Feature>.tsx`.
diff --git a/.github/prompts/write-documentation.prompt.md b/.github/prompts/write-documentation.prompt.md
new file mode 100644
index 0000000..675f0a9
--- /dev/null
+++ b/.github/prompts/write-documentation.prompt.md
@@ -0,0 +1,48 @@
+---
+agent: agent
+description: "Write DocFX documentation following the Diataxis framework."
+---
+
+# Write Documentation
+
+I need you to write **DocFX documentation** for a feature, component, or concept using the **Diataxis framework**.
+
+## Inputs
+
+- **Subject** — what to document (e.g. "the Projects feature", "the CommandDialog component", "the ConceptAs type")
+- **Document type** — one of:
+  - **Tutorial** — step-by-step lesson for newcomers
+  - **How-to Guide** — recipe for accomplishing a specific task
+  - **Reference** — exhaustive technical description (APIs, attributes, configuration)
+  - **Explanation** — discussion of concepts, trade-offs, and architecture
+- **Target audience** — e.g. new developer, experienced contributor, framework consumer
+- **Existing source files** — paste or reference the code to document
+
+## Instructions
+
+Follow `.github/instructions/documentation.instructions.md` and the `write-documentation` skill exactly.
+
+### Workflow
+
+1. **Clarify** — Confirm the document type, audience, goal, and scope. Ask if anything is ambiguous.
+2. **Propose structure** — Present an outline (headings + one-line descriptions). Wait for approval.
+3. **Write** — Produce full DocFX-compatible Markdown with correct `toc.yml` entries.
+
+### File structure
+
+For a new topic under an existing section, create a folder with an `index.md` and `toc.yml`. Update the parent `toc.yml` to include the new topic.
+
+### Writing style
+
+- Active voice, present tense, second person
+- Lead with the most important information
+- Every code example must be complete and correct
+- Link to related topics using relative paths
+- Use Mermaid diagrams for architecture, sequence flows, and state transitions
+- Do not document internal implementation details in user-facing docs
+
+### Validation
+
+- Verify `toc.yml` is valid YAML
+- Verify all `href` values point to files that exist
+- Verify all Mermaid blocks are valid
diff --git a/.github/prompts/write-specs.prompt.md b/.github/prompts/write-specs.prompt.md
new file mode 100644
index 0000000..188e045
--- /dev/null
+++ b/.github/prompts/write-specs.prompt.md
@@ -0,0 +1,71 @@
+---
+agent: agent
+description: Write comprehensive BDD specs for an existing vertical slice command or query.
+---
+
+# Write Specs
+
+I need you to write **comprehensive specs** for an existing vertical slice.
+
+## What to provide
+
+Paste or reference the slice file (`.cs`) you want covered.
+
+## Instructions
+
+Follow `.github/instructions/specs.csharp.instructions.md` and `.github/instructions/specs.instructions.md`.
+
+### For a State Change slice (command)
+
+Write a spec class for **each meaningful outcome**:
+
+1. **Happy path** — command succeeds, expected event is appended, sequence number advanced.
+2. **Each validation failure** — one spec per validation rule.
+3. **Each business rule violation** — one spec per condition in `Handle()` that inspects a ReadModel argument (DCB pattern).
+4. **Each constraint violation** — one spec per `IConstraint` (e.g. uniqueness).
+
+### Structure
+
+```
+Features/<Feature>/<Slice>/
+└── when_<verb_phrase>/
+    ├── and_<happy_scenario>.cs
+    ├── and_<failure_scenario>.cs
+    └── and_<other_scenario>.cs
+```
+
+### C# spec shape
+
+```csharp
+using context = <NamespaceRoot>.<Feature>.<Slice>.when_<behavior>.and_<scenario>.context;
+
+namespace <NamespaceRoot>.<Feature>.<Slice>.when_<behavior>;
+
+[Collection(ChronicleCollection.Name)]
+public class and_<scenario>(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public CommandResult<object>? Result;
+
+        async Task Establish() { /* optional: seed events */ }
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<<Command>>(
+                "/api/<feature>/<action>",
+                new <Command>(...));
+        }
+    }
+
+    [Fact] void should_<expected_result>() => ...;
+}
+```
+
+### Assertions
+
+Use `ShouldBeFalse()`, `ShouldBeTrue()`, `ShouldEqual()`, `ShouldHaveTailSequenceNumber()` — never raw `Assert.*`.
+
+## Validation
+
+Run `dotnet test` after writing specs. Fix any failures before completing.
diff --git a/.github/skills/add-business-rule/SKILL.md b/.github/skills/add-business-rule/SKILL.md
new file mode 100644
index 0000000..b2c8454
--- /dev/null
+++ b/.github/skills/add-business-rule/SKILL.md
@@ -0,0 +1,106 @@
+---
+name: add-business-rule
+description: Use this skill when asked to add a validation rule, business rule, or uniqueness constraint to an existing command in a Cratis-based project.
+---
+
+Add a business rule or event-store constraint to an existing command.
+
+## Choose the right mechanism
+
+| Scenario                                           | Use                                           |
+|----------------------------------------------------|-----------------------------------------------|
+| Uniqueness that must survive concurrent writes     | `IConstraint`                                 |
+| Rule requiring Chronicle event-sourced state       | ReadModel as `Handle()` parameter (DCB)       |
+| Simple sync invariant (format, range, required)    | `CommandValidator<T>`                         |
+
+## Business Rules via DCB (ReadModel as argument)
+
+Use when the rule depends on **Chronicle event-sourced state** (e.g. current count, accumulated value).
+This is the DCB (Dynamic Consistency Boundary) pattern: add a **read model parameter** to the `Handle()` method.
+The framework fetches and injects the current read model snapshot before `Handle()` runs.
+
+The read model must already exist in the slice (decorated with `[ReadModel]` and a model-bound projection).
+If it doesn't, add it first — see the `new-vertical-slice` skill.
+
+```csharp
+[Command]
+public record <Command>(<KeyProperty> <Key>, ...)
+{
+    /// <summary>
+    /// Handles the command.
+    /// </summary>
+    /// <param name="readModelParam">The current state.</param>
+    /// <returns>The resulting event.</returns>
+    public <Event> Handle(<ReadModel> <readModelParam>)
+    {
+        if (<readModelParam>.<StateProperty> <violatesRule>)
+            throw new <ViolationException>(<meaningful message>);
+
+        return new <Event>(...);
+    }
+}
+```
+
+**Example — limit items in cart to 3:**
+
+```csharp
+[Command]
+public record AddItemToCart(CartId CartId, ItemId ItemId)
+{
+    /// <summary>
+    /// Adds the item; throws if the cart already holds 3 items.
+    /// </summary>
+    /// <param name="cart">The current cart summary.</param>
+    /// <returns>The <see cref="ItemAddedToCart"/> event.</returns>
+    /// <exception cref="CartIsFull">Thrown when the cart already contains the maximum number of items.</exception>
+    public ItemAddedToCart Handle(CartSummary cart)
+    {
+        if (cart.ItemCount >= 3)
+            throw new CartIsFullException(CartId);
+
+        return new ItemAddedToCart(ItemId);
+    }
+}
+```
+
+**Key rules:**
+- The read model parameter type must match a `[ReadModel]`-decorated type in the same feature.
+- The framework resolves the instance using the same event-source key as the command.
+- Throw a **custom exception** (never a built-in one) to signal violation — the framework converts it to an error result.
+- One parameter per logical read model; if you need multiple reads, use multiple parameters.
+
+## Event-Store Constraints (`IConstraint`)
+
+Enforced by Chronicle at append time. Use for uniqueness that must hold across concurrent writes.
+
+```csharp
+public class Unique<PropertyName> : IConstraint
+{
+    public void Define(IConstraintBuilder builder) =>
+        builder.Unique(unique =>
+            unique
+                .On<<EventType>>(e => e.<UniqueProperty>)
+                .RemovedWith<<RemovedEventType>>());  // omit if there is no remove event
+}
+```
+
+**Example — unique project name:**
+
+```csharp
+public class UniqueProjectName : IConstraint
+{
+    public void Define(IConstraintBuilder builder) =>
+        builder.Unique(unique =>
+            unique
+                .On<ProjectRegistered>(e => e.Name)
+                .RemovedWith<ProjectRemoved>());
+}
+```
+
+Constraints are discovered and enforced automatically — no registration or attribute on the command needed.
+
+## After adding
+
+1. Add a spec for the failure case — see `write-specs` skill
+2. Run `dotnet build` and `dotnet test`
+3. Fix all failures before completing
diff --git a/.github/skills/add-concept/SKILL.md b/.github/skills/add-concept/SKILL.md
new file mode 100644
index 0000000..18c57f3
--- /dev/null
+++ b/.github/skills/add-concept/SKILL.md
@@ -0,0 +1,84 @@
+---
+name: add-concept
+description: Use this skill when asked to create a strongly-typed domain identifier or value (such as ProjectId, AuthorName, InvoiceNumber) in a Cratis-based project. Produces a ConceptAs<T> record with the correct conversions and sentinel values.
+---
+
+Create a strongly-typed Concept that wraps a primitive domain value.
+
+## Never use raw primitives in domain models
+
+Replace `Guid`, `string`, `int`, etc. with a `ConceptAs<T>` record whenever the value has domain meaning.
+
+## Template
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+using Cratis.Concepts;
+
+namespace <NamespaceRoot>.<Feature>;
+
+/// <summary>
+/// Represents the identity of a <description>.
+/// </summary>
+/// <param name="Value">The underlying <type> value.</param>
+public record <ConceptName>(<UnderlyingType> Value) : ConceptAs<<UnderlyingType>>(Value)
+{
+    /// <summary>
+    /// Represents an unset <ConceptName>.
+    /// </summary>
+    public static readonly <ConceptName> NotSet = new(<emptyValue>);
+
+    /// <summary>
+    /// Implicitly converts a <UnderlyingType> to a <ConceptName>.
+    /// </summary>
+    public static implicit operator <ConceptName>(<UnderlyingType> value) => new(value);
+}
+```
+
+## Add when backed by Guid
+
+```csharp
+    /// <summary>
+    /// Creates a new <ConceptName> with a unique value.
+    /// </summary>
+    /// <returns>A new <ConceptName>.</returns>
+    public static <ConceptName> New() => new(Guid.NewGuid());
+```
+
+## Add when used as an event-source ID
+
+```csharp
+    /// <summary>
+    /// Implicitly converts a <ConceptName> to an <see cref="EventSourceId"/>.
+    /// </summary>
+    /// <param name="id">The <ConceptName> to convert.</param>
+    public static implicit operator EventSourceId(<ConceptName> id) => new(id.Value.ToString());
+```
+
+## Empty/sentinel values
+
+| Underlying type | Use             |
+|-----------------|-----------------|
+| `Guid`          | `Guid.Empty`    |
+| `string`        | `string.Empty`  |
+| `int`           | `0`             |
+| `long`          | `0L`            |
+
+## Placement rules
+
+- Do NOT create a `Concepts/` folder
+- Place the file in the folder that **semantically owns** the concept
+  - `ProjectId` → `Features/Projects/`
+  - Shared cross-feature concepts → project source root
+
+## Checklist
+
+- [ ] Inherits `ConceptAs<T>`
+- [ ] Has a `static readonly NotSet` (or `Empty`) sentinel
+- [ ] Has implicit conversion **from** the primitive
+- [ ] Has implicit conversion **to** `EventSourceId` if used as event-source key
+- [ ] Has `New()` factory if `Guid`-backed
+- [ ] Copyright header present
+- [ ] `dotnet build` passes
diff --git a/.github/skills/add-ef-migration/SKILL.md b/.github/skills/add-ef-migration/SKILL.md
new file mode 100644
index 0000000..1ba16fe
--- /dev/null
+++ b/.github/skills/add-ef-migration/SKILL.md
@@ -0,0 +1,168 @@
+---
+name: add-ef-migration
+description: Use this skill when asked to add a database table, column, relationship, or other schema change via Entity Framework Core in a Cratis-based project.
+---
+
+Add or update an Entity Framework Core schema change with a hand-written migration.
+
+> **Always read `.github/instructions/efcore.instructions.md` first.** It is the source of truth for project structure, base types, column helpers, and migration conventions.
+
+## Pre-flight — Understand the project split
+
+Before writing anything, locate these three projects:
+
+| Project | What lives there |
+|---------|-----------------|
+| **Database** | Migrations only — `WellKnownTables.cs` + versioned migration files |
+| **Core** | Entities and feature DbContexts (co-located with features) |
+| **Infrastructure** | DbContext registration, migration runner, cross-cutting EF setup |
+
+**Critical:** `Database` must NEVER import from `Core`. Migrations reference only `WellKnownTables` constants and EF migration types.
+
+## Step 1 — Update or create the entity
+
+Add, rename, or remove properties on the entity `record` in the **Core** project, co-located with its feature:
+
+```
+Features/Missions/StartupPhase/
+├── StartupPhase.cs            ← entity record
+├── StartupPhaseDbContext.cs   ← feature DbContext
+└── ...
+```
+
+## Step 2 — Update or create the feature DbContext
+
+Use the Cratis Arc base types — never inherit directly from `DbContext`:
+
+- **`ReadOnlyDbContext`** — for all read model / projection contexts (the vast majority)
+- **`BaseDbContext`** — only for writable contexts that own state
+
+```csharp
+public class StartupPhaseDbContext(DbContextOptions<StartupPhaseDbContext> options)
+    : ReadOnlyDbContext(options)
+{
+    public DbSet<StartupPhase> StartupPhases => Set<StartupPhase>();
+}
+```
+
+Create one focused DbContext per feature — never a "god context" with unrelated entities.
+
+## Step 3 — Add the table name to WellKnownTables
+
+If this is a new table, add the constant to `Database/WellKnownTables.cs` **before** writing the migration:
+
+```csharp
+public static class WellKnownTables
+{
+    public const string StartupPhases = "StartupPhases";
+}
+```
+
+## Step 4 — Write the migration by hand
+
+Migrations are **hand-written**, not generated by `dotnet ef migrations add`. Place the file in the **Database** project using versioned naming:
+
+```
+Database/
+├── Missions/
+│   ├── v1_0_0.cs
+│   └── v1_1_0.cs
+└── WellKnownTables.cs
+```
+
+Use the `v{major}_{minor}_{patch}.cs` naming pattern. The namespace must match the folder:
+
+```csharp
+namespace Database.Missions;
+
+public class v1_1_0 : Migration
+{
+    /// <summary>
+    /// Apply the schema change.
+    /// </summary>
+    /// <param name="migrationBuilder">The migration builder.</param>
+    protected override void Up(MigrationBuilder migrationBuilder)
+    {
+        migrationBuilder.AddColumn<string>(
+            name: "Description",
+            table: WellKnownTables.Missions,
+            type: migrationBuilder.StringColumnType(maxLength: 1000),
+            nullable: true);
+    }
+
+    /// <summary>
+    /// Reverse the schema change.
+    /// </summary>
+    /// <param name="migrationBuilder">The migration builder.</param>
+    protected override void Down(MigrationBuilder migrationBuilder)
+    {
+        migrationBuilder.DropColumn(
+            name: "Description",
+            table: WellKnownTables.Missions);
+    }
+}
+```
+
+### Cross-database column helpers (mandatory)
+
+Always use the Cratis Arc `MigrationBuilder` extension helpers — never raw `table.Column<T>()`:
+
+| Helper | Use for |
+|--------|---------|
+| `table.StringColumn(migrationBuilder)` | Text / varchar columns |
+| `table.GuidColumn(migrationBuilder)` | UUID / GUID columns |
+| `table.NumberColumn<T>(migrationBuilder)` | Integer, long, or numeric columns |
+| `table.DateTimeOffsetColumn(migrationBuilder)` | Timestamps with timezone |
+
+Example `CreateTable`:
+
+```csharp
+migrationBuilder.CreateTable(
+    name: WellKnownTables.StartupPhases,
+    columns: table => new
+    {
+        Id = table.StringColumn(migrationBuilder, nullable: false),
+        Title = table.StringColumn(migrationBuilder, maxLength: 200, nullable: false),
+        ResourceId = table.NumberColumn<int>(migrationBuilder, nullable: true),
+        DispatchTime = table.DateTimeOffsetColumn(migrationBuilder),
+        UrgencyId = table.GuidColumn(migrationBuilder)
+    },
+    constraints: table =>
+    {
+        table.PrimaryKey("PK_StartupPhases", x => x.Id);
+    });
+```
+
+## Step 5 — Register the DbContext (if new)
+
+In the **Infrastructure** project, ensure the context is registered. Read-only contexts are auto-discovered:
+
+```csharp
+services.AddReadModelDbContextsWithConnectionStringFromAssemblies(
+    connectionString,
+    configureOptions,
+    [Assembly.GetExecutingAssembly()]);
+```
+
+Writable contexts need explicit registration:
+
+```csharp
+services.AddDbContextWithConnectionString<DeviceStateDbContext>(connectionString);
+```
+
+## Step 6 — Update specs
+
+Integration specs using in-memory SQLite pick up schema changes automatically via `context.Database.EnsureCreated()`. If specs break, check that the fixture uses the correct connection string and that the new migration is in the `Database` assembly.
+
+## Step 7 — Validate
+
+Run `dotnet build` and `dotnet test`. Fix all failures before completing.
+
+## Key rules
+
+- **Never** use `dotnet ef migrations add` — all migrations are hand-written
+- **Never** use `dotnet ef database update` — use the custom runner: `await app.ApplyAllMigrations(connectionString)`
+- **Never** hardcode a provider (`UseSqlite`, `UseNpgsql`) — use `UseDatabaseFromConnectionString`
+- **Never** mutate state directly through a DbContext — all writes flow through Chronicle events and projections
+- **Always** use `WellKnownTables` constants — never magic strings for table names
+- **Always** use cross-database column helpers — never raw `table.Column<T>()`
diff --git a/.github/skills/add-projection/SKILL.md b/.github/skills/add-projection/SKILL.md
new file mode 100644
index 0000000..0520077
--- /dev/null
+++ b/.github/skills/add-projection/SKILL.md
@@ -0,0 +1,70 @@
+---
+name: add-projection
+description: Use this skill when asked to add a Chronicle projection to a Cratis-based project. Enforces the AutoMap-first rule and Chronicle-specific join semantics.
+---
+
+Add a Chronicle **projection** that populates a read model from events.
+
+> For **reactors** (automation / translation), see the `add-reactor` skill instead.
+
+## Projection — Model-Bound (preferred)
+
+Put projection metadata directly on the read model using attributes. No separate class needed.
+
+```csharp
+[ReadModel]
+[FromEvent<SomeEventHappened>]              // auto-maps all matching property names
+public record <ReadModelName>(
+    [Key] <IdType> Id,                      // marks the primary key
+    <PropType> <PropName>)                  // auto-mapped from SomeEventHappened
+{
+    public static ISubject<IEnumerable<<ReadModelName>>> All(IMongoCollection<<ReadModelName>> collection) =>
+        collection.Observe();
+}
+```
+
+**Attribute reference:**
+| Attribute | Purpose |
+|-----------|---------|
+| `[FromEvent<T>]` | Auto-maps all matching property names (equivalent to `.AutoMap().From<T>()`) |
+| `[FromEvent<T>(key: nameof(T.Prop))]` | Same, but uses `Prop` as the read model key instead of EventSourceId |
+| `[Key]` | Marks the primary key property |
+| `[SetFrom<T>(nameof(T.Prop))]` | Explicitly maps one property from event T |
+| `[AddFrom<T>(nameof(T.Prop))]` | Adds event property value to the read model property |
+| `[SubtractFrom<T>(nameof(T.Prop))]` | Subtracts event property value |
+| `[ChildrenFrom<T>(key: nameof(T.Prop))]` | Projects into a nested child collection |
+| `[Join<T>(on: nameof(Prop), eventPropertyName: nameof(T.EProp))]` | Joins data from a related event |
+| `[RemovedWith<T>]` | Marks the instance as removed when event T is appended |
+
+**Critical rules:**
+- Joins must be on Chronicle **events** — NEVER join on a read model type
+- If property names between event and read model match, `[FromEvent<T>]` alone is sufficient
+- Child types also support all attributes recursively
+
+## Projection — Fluent (use for complex cases)
+
+Use `IProjectionFor<T>` when projection logic is too complex for attributes.
+
+```csharp
+public class <Name>Projection : IProjectionFor<<ReadModel>>
+{
+    public void Define(IProjectionBuilderFor<<ReadModel>> builder) =>
+        builder
+            .From<SomeEventHappened>(b =>
+                b.UsingKey(e => e.SomeId))
+            .RemovedWith<SomeThingRemoved>();
+}
+```
+
+**Critical rules:**
+- AutoMap is on by default — just call `.From<>()` directly. Only call `.AutoMap()` if you previously used `.NoAutoMap()`.
+- Joins are on Chronicle **events** only — NEVER join on the read model
+- There is NO `Identifier` / `ProjectionId` property — do not add one
+
+## After creating
+
+Run `dotnet build`. Fix all errors before completing.
+
+---
+
+For the full model-bound projection attribute reference and fluent builder API, see [references/CHRONICLE-API.md](references/CHRONICLE-API.md).
diff --git a/.github/skills/add-projection/references/CHRONICLE-API.md b/.github/skills/add-projection/references/CHRONICLE-API.md
new file mode 100644
index 0000000..2768ef3
--- /dev/null
+++ b/.github/skills/add-projection/references/CHRONICLE-API.md
@@ -0,0 +1,169 @@
+# Chronicle Projection API
+
+---
+
+## Model-Bound Projections (preferred)
+
+Apply attributes directly to read model types. No separate projection class needed.
+
+### Class-level attributes
+
+#### `[FromEvent<T>]`
+Auto-maps all properties with matching names from event `T` to the read model.
+Equivalent to `.AutoMap().From<T>()` in the fluent API.
+
+```csharp
+[ReadModel]
+[FromEvent<AccountOpened>]
+public record Account(
+    [Key] Guid Id,
+    string Name,          // auto-mapped from AccountOpened.Name
+    decimal Balance);     // auto-mapped from AccountOpened.Balance
+```
+
+#### `[FromEvent<T>(key: nameof(T.PropertyName))]`
+Same as above, but uses the specified event property as the read model key instead of EventSourceId.
+
+```csharp
+[ReadModel]
+[FromEvent<OrderPlaced>(key: nameof(OrderPlaced.OrderId))]
+public record Order([Key] Guid Id, decimal Total);
+```
+
+Multiple `[FromEvent<T>]` attributes are supported for different events:
+
+```csharp
+[FromEvent<AccountOpened>]
+[FromEvent<AccountRenamed>]
+public record Account([Key] Guid Id, string Name, decimal Balance);
+```
+
+---
+
+### Property-level attributes
+
+#### `[Key]`
+Marks the primary key property.
+
+#### `[SetFrom<T>]` / `[SetFrom<T>(nameof(T.Prop))]`
+Maps a specific property from event `T`. Omit the property name if the names match.
+
+#### `[SetFrom<T>]` with multiple events
+Apply multiple attributes to update the same property from different events.
+
+```csharp
+[SetFrom<AccountOpened>(nameof(AccountOpened.AccountName))]
+[SetFrom<AccountRenamed>(nameof(AccountRenamed.NewName))]
+string Name
+```
+
+#### `[AddFrom<T>(nameof(T.Prop))]`
+Adds the event property value to the read model property (accumulates).
+
+#### `[SubtractFrom<T>(nameof(T.Prop))]`
+Subtracts the event property value.
+
+#### `[ChildrenFrom<T>(key: nameof(T.ChildId))]`
+Projects into a nested child collection. The child type also supports all attributes recursively.
+
+```csharp
+public record Order(
+    [Key] Guid Id,
+    [ChildrenFrom<LineItemAdded>(key: nameof(LineItemAdded.ItemId))]
+    IEnumerable<LineItem> Items);
+
+public record LineItem(
+    [Key] Guid Id,
+    string ProductName,   // auto-mapped
+    int Quantity,         // auto-mapped
+    decimal Price);       // auto-mapped
+```
+
+#### `[Join<T>(on: nameof(Prop), eventPropertyName: nameof(T.EProp))]`
+Joins data from a related event (keyed by a different entity).
+
+```csharp
+[Join<CustomerRegistered>(
+    on: nameof(CustomerId),
+    eventPropertyName: nameof(CustomerRegistered.Name))]
+string CustomerName
+```
+
+#### `[RemovedWith<T>]`
+Marks the instance removed when event `T` is appended.
+
+---
+
+## Fluent Projections (alternative for complex cases)
+
+Use `IProjectionFor<T>` when model-bound attributes don't fit the complexity of the projection.
+
+### Basic structure
+
+```csharp
+public class MyProjection : IProjectionFor<MyReadModel>
+{
+    public void Define(IProjectionBuilderFor<MyReadModel> builder) =>
+        builder
+            .From<SomeEvent>(...);  // AutoMap is on by default
+}
+```
+
+> **There is NO `Identifier`/`ProjectionId` property** — do not add one.
+
+---
+
+### `.AutoMap()`
+
+Maps all event properties to read model properties with matching names automatically.
+**AutoMap is on by default — you only need to call it explicitly if you previously used `.NoAutoMap()`.**
+
+---
+
+### `.From<TEvent>(Action<IFromBuilder<TReadModel, TEvent>>)`
+
+Handles an event type. Builder methods:
+
+- `.UsingKey(e => e.PropertyOnEvent)` — sets the key from an event property
+- `.UsingParentKey(e => e.PropertyOnEvent)` — sets key from parent (child projections)
+- `.Set(m => m.Target).To(e => e.Source)` — explicit property mapping
+- `.Set(m => m.Prop).ToValue(literal)` — set to constant value
+- `.Add(m => m.Counter).With(1)` — increment by fixed value
+- `.Subtract(m => m.Counter).With(1)` — decrement by fixed value
+- `.Count(m => m.TotalCount)` — increment count by 1
+
+---
+
+### `.Children<TChild>(m => m.ChildCollection, childBuilder => ...)`
+
+Projects into a nested collection.
+
+```csharp
+builder
+    .Children<LineItem>(m => m.LineItems, child =>  // AutoMap is on by default
+        child
+            .From<LineItemAdded>(b =>
+                b.UsingKey(e => e.LineItemId)
+                 .Set(li => li.Description).To(e => e.Description))
+            .RemovedWith<LineItemRemoved>());
+```
+
+---
+
+### `.RemovedWith<TEvent>()`
+
+Marks the read model as removed when the specified event is appended.
+
+---
+
+### `.Join<TEvent>(Action<IJoinBuilder<TReadModel, TEvent>>)`
+
+Joins data from a different event. The join is always on the **event**, never on the read model.
+
+```csharp
+builder
+    .From<ProjectRegistered>()                      // AutoMap is on by default
+    .Join<OwnerAssigned>(b =>
+        b.On(e => e.ProjectId)
+         .Set(m => m.OwnerName).To(e => e.OwnerName));
+```
diff --git a/.github/skills/add-reactor/SKILL.md b/.github/skills/add-reactor/SKILL.md
new file mode 100644
index 0000000..018235c
--- /dev/null
+++ b/.github/skills/add-reactor/SKILL.md
@@ -0,0 +1,82 @@
+---
+name: add-reactor
+description: Use this skill when asked to add a Chronicle reactor (automation or translation) to a Cratis-based project. Reactors observe events and produce side effects.
+---
+
+Add a Chronicle **reactor** that triggers automation or translation logic in response to events.
+
+> **Always read `.github/instructions/reactors.instructions.md` first.** It is the source of truth for reactor conventions, rules, and patterns.
+
+## Step 1 — Identify the event(s)
+
+Determine which event type(s) the reactor needs to observe. These events must already exist or be created as part of the slice.
+
+## Step 2 — Create the reactor class
+
+Place the reactor in the appropriate feature folder, co-located with the slice it belongs to.
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+namespace MyApp.Projects.Notifications;
+
+/// <summary>
+/// Sends a notification when a project is registered.
+/// </summary>
+/// <param name="notifications">The notification service.</param>
+public class ProjectRegisteredNotifier(INotificationService notifications) : IReactor
+{
+    /// <summary>
+    /// Reacts to <see cref="Registration.ProjectRegistered"/> events.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task ProjectRegistered(Registration.ProjectRegistered @event, EventContext context) =>
+        await notifications.Notify($"Project '{@event.Name}' was registered.");
+}
+```
+
+## Step 3 — Follow the critical rules
+
+- **`IReactor` is a marker interface** — no methods to implement. Method dispatch is by first-parameter event type.
+- **Method name** — can be anything descriptive. The name is for readability, not dispatch.
+- **`EventContext`** — optional second parameter. Omit if event metadata is not needed.
+- **Idempotent** — reactors may be called more than once for the same event. Design accordingly.
+- **Use event data directly** — never query the read model back inside the reactor.
+- **Trigger commands for further writes** — inject `ICommandPipeline` and execute a command. Never use `IEventLog` directly.
+
+## Step 4 — Translation pattern (if applicable)
+
+If the reactor adapts events from one slice by triggering commands in another, it is a **Translation** reactor:
+
+```csharp
+/// <summary>
+/// Reacts to reservation events and decreases stock accordingly.
+/// </summary>
+/// <param name="stockKeeper">The stock keeper service.</param>
+/// <param name="commandPipeline">The command pipeline.</param>
+public class StockKeeping(IStockKeeper stockKeeper, ICommandPipeline commandPipeline) : IReactor
+{
+    /// <summary>
+    /// Handles a <see cref="BookReserved"/> event.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task BookReserved(BookReserved @event, EventContext context) =>
+        await commandPipeline.Execute(new DecreaseStock(@event.Isbn, await stockKeeper.GetStock(@event.Isbn)));
+}
+```
+
+## Step 5 — Validate
+
+Run `dotnet build`. Fix all errors before completing.
+
+## When to use a Reactor vs a Projection
+
+| Need | Use |
+|------|-----|
+| Populate a queryable read model from events | **Projection** (see `add-projection` skill) |
+| Trigger side effects, send notifications, call external APIs | **Reactor** |
+| Adapt events across slices by triggering commands | **Reactor** (Translation pattern) |
+| Both populate a read model AND trigger side effects | **Both** — one projection + one reactor |
diff --git a/.github/skills/new-vertical-slice/SKILL.md b/.github/skills/new-vertical-slice/SKILL.md
new file mode 100644
index 0000000..647dda5
--- /dev/null
+++ b/.github/skills/new-vertical-slice/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: new-vertical-slice
+description: Use this skill when asked to implement a new feature, command, query, slice, or screen in a Cratis-based project. Guides the full end-to-end workflow: C# backend → specs → dotnet build → React frontend → quality gates.
+---
+
+Implement a complete vertical slice following this EXACT order. Never skip steps or work on multiple slices in parallel.
+
+## Step 1 — Identify the slice type
+
+Choose **one** of:
+- **State Change** — a command that mutates state and records events (most common)
+- **State View** — a query that reads from a read model
+- **Automation** — a background reactor triggered by events
+- **Translation** — transforms events into other events
+
+## Step 2 — Determine the namespace root
+
+Read `global.json` and existing `.cs` files in `Features/` to find the namespace root (e.g. `Studio`, `Library`). Never hard-code it.
+
+## Step 3 — Create the C# slice file
+
+Place ALL backend artifacts in a single file: `Features/<Feature>/<Slice>.cs`
+
+File creation order within the slice:
+1. Concept types (if new strongly-typed IDs are needed — see `add-concept` skill)
+2. Command `record` with `Handle()` method and optional validation attributes
+   - If a business rule depends on Chronicle event-sourced state, add the relevant read model as a parameter to `Handle()` — see `add-business-rule` skill (DCB pattern)
+3. Constraint class `<Name>Constraint` (if needed)
+5. Event `record` with `[EventType]` (no arguments, no mutable properties)
+6. Read model `record` with `[ReadModel]` and model-bound projection attributes (`[FromEvent<T>]`, `[Key]`, etc.)
+   - Use fluent `IProjectionFor<T>` only when model-bound attributes don't fit
+
+**Critical rules:**
+- Commands are `record` types with a `Handle()` method directly on them — DO NOT create separate handler classes
+- Events use `[EventType]` with NO arguments — never pass a GUID or string
+- Projection: prefer model-bound attributes on the read model; if using `IProjectionFor<T>`, AutoMap is on by default — just call `.From<>()` directly
+- Namespace must be `<NamespaceRoot>.<Feature>.<Slice>` (drop `.Features.` segment)
+- Copyright header on every file: `// Copyright (c) Cratis. All rights reserved. // Licensed under the MIT license. See LICENSE file in the project root for full license information.`
+
+## Step 4 — Build
+
+Run `dotnet build`. Fix ALL errors and warnings before proceeding. This generates TypeScript proxies.
+
+## Step 5 — Write specs (State Change slices only)
+
+For each command, write specs covering:
+- Happy path — command succeeds, correct event appended
+- Each validation failure (one spec per rule)
+- Each business rule violation (one spec per DCB condition in `Handle()` that inspects a read model)
+- Each constraint violation
+
+See `write-specs` skill for the complete spec structure.
+
+Run `dotnet test`. Fix all failures before proceeding.
+
+## Step 6 — Implement React component(s)
+
+Place `.tsx` files in `Features/<Feature>/<Slice>/`.
+
+- Import the auto-generated command/query proxy from the same folder
+- Use `CommandDialog` from `@cratis/components/CommandDialog` for command dialogs
+- Use `Dialog` from `@cratis/components/Dialogs` for data-only dialogs — NEVER import from `primereact/dialog`
+- Use PrimeReact CSS variables for all colours — never hard-code hex values
+- Use full descriptive variable names — never abbreviations (`event` not `e`, `index` not `idx`)
+- No `any` types — use `unknown` with type guards
+
+**Command usage:**
+```tsx
+const [myCommand] = MyCommand.use();
+const handleSubmit = async () => {
+    myCommand.propertyName = value;
+    const result = await myCommand.execute();
+    if (result.isSuccess) closeDialog(DialogResult.Ok);
+};
+```
+
+**Query with paging:**
+```tsx
+const pageSize = 10;
+const [result, , setPage] = MyQuery.useWithPaging(pageSize);
+// Use result.data, result.paging.totalItems, result.paging.page
+```
+
+## Step 7 — Update the composition page
+
+Open `Features/<Feature>/<Feature>.tsx` and add the new component. If a new page is introduced, also update the router and navigation.
+
+## Step 8 — Quality gates
+
+All must pass before the slice is considered done:
+- `dotnet build` — zero errors/warnings
+- `dotnet test` — zero failures
+- `yarn lint` — zero errors
+- `npx tsc -b` — zero errors
+
+---
+
+For complete code patterns for all 4 slice types and frontend examples, see [references/PATTERNS.md](references/PATTERNS.md).
diff --git a/.github/skills/new-vertical-slice/references/PATTERNS.md b/.github/skills/new-vertical-slice/references/PATTERNS.md
new file mode 100644
index 0000000..639fa8c
--- /dev/null
+++ b/.github/skills/new-vertical-slice/references/PATTERNS.md
@@ -0,0 +1,351 @@
+# Vertical Slice Patterns
+
+## State Change — full example
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+namespace MyApp.Projects.Registration;
+
+// ─── Concepts ───────────────────────────────────────────────────────────────
+
+/// <summary>
+/// Represents the unique identifier of a project.
+/// </summary>
+public record ProjectId(Guid Value) : ConceptAs<Guid>(Value)
+{
+    /// <summary>
+    /// Gets a sentinel value for an unset identifier.
+    /// </summary>
+    public static readonly ProjectId NotSet = new(Guid.Empty);
+
+    /// <summary>
+    /// Implicitly converts a <see cref="Guid"/> to a <see cref="ProjectId"/>.
+    /// </summary>
+    /// <param name="value">The <see cref="Guid"/> to convert.</param>
+    public static implicit operator ProjectId(Guid value) => new(value);
+
+    /// <summary>
+    /// Implicitly converts a <see cref="ProjectId"/> to an <see cref="EventSourceId"/>.
+    /// </summary>
+    /// <param name="id">The <see cref="ProjectId"/> to convert.</param>
+    public static implicit operator EventSourceId(ProjectId id) => new(id.Value.ToString());
+
+    /// <summary>
+    /// Creates a new <see cref="ProjectId"/> with a unique value.
+    /// </summary>
+    /// <returns>A new <see cref="ProjectId"/>.</returns>
+    public static ProjectId New() => new(Guid.NewGuid());
+}
+
+/// <summary>
+/// Represents the name of a project.
+/// </summary>
+public record ProjectName(string Value) : ConceptAs<string>(Value)
+{
+    /// <summary>
+    /// Gets a sentinel value for an unset name.
+    /// </summary>
+    public static readonly ProjectName NotSet = new(string.Empty);
+
+    /// <summary>
+    /// Implicitly converts a <see cref="string"/> to a <see cref="ProjectName"/>.
+    /// </summary>
+    /// <param name="value">The string to convert.</param>
+    public static implicit operator ProjectName(string value) => new(value);
+
+    /// <summary>
+    /// Implicitly extracts the underlying <see cref="string"/> value.
+    /// </summary>
+    /// <param name="name">The <see cref="ProjectName"/> to convert.</param>
+    public static implicit operator string(ProjectName name) => name.Value;
+}
+
+// ─── Command ────────────────────────────────────────────────────────────────
+
+/// <summary>
+/// Command to register a new project.
+/// </summary>
+[Command]
+public record RegisterProject(ProjectId ProjectId, ProjectName Name)
+{
+    /// <summary>
+    /// Produces a <see cref="ProjectRegistered"/> event.
+    /// </summary>
+    /// <returns>The <see cref="ProjectRegistered"/> event.</returns>
+    public ProjectRegistered Handle() => new(Name);
+}
+
+// ─── Constraint ─────────────────────────────────────────────────────────────
+
+/// <summary>
+/// Prevents two projects from being registered with the same name.
+/// </summary>
+public class UniqueProjectNameConstraint : IConstraint
+{
+    /// <inheritdoc/>
+    public void Define(IConstraintBuilder builder) => builder
+        .Unique(unique => unique.On<ProjectRegistered>(e => e.Name));
+}
+
+// ─── Event ──────────────────────────────────────────────────────────────────
+
+/// <summary>
+/// Raised when a new project has been successfully registered.
+/// </summary>
+[EventType]
+public record ProjectRegistered(ProjectName Name);
+```
+
+**Key rules for State Change slices:**
+- `[Command]` attribute marks the command record — there is no `ICommand` interface
+- `Handle()` RETURNS the event — it never calls `IEventLog` or `eventLog.Append()`
+- `[EventType]` has **no arguments** — the event type name is resolved automatically
+- The event source ID is resolved in order: `ICanProvideEventSourceId` > `EventSourceId` property > `[Key]` attribute
+- Constraints (`IConstraint`) live in the same slice file as the command
+- The read model and projection live in the **State View** slice, not here
+
+---
+
+## State View — full example
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+namespace MyApp.Projects.Listing;
+
+// ─── Read Model (model-bound projection — no separate class needed) ──────────
+
+/// <summary>
+/// Represents a project in the listing read model.
+/// </summary>
+[ReadModel]
+[FromEvent<Registration.ProjectRegistered>]
+public record Project(
+    [Key] ProjectId Id,
+    ProjectName Name)
+{
+    /// <summary>
+    /// Observes all projects in the collection.
+    /// </summary>
+    /// <param name="collection">The <see cref="IMongoCollection{Project}"/> to observe.</param>
+    /// <returns>An observable subject of all projects.</returns>
+    public static ISubject<IEnumerable<Project>> AllProjects(IMongoCollection<Project> collection) =>
+        collection.Observe();
+}
+```
+
+**Key rules for State View slices:**
+- The read model is decorated with `[ReadModel]` — needed for the static observable query API
+- **Model-bound projection (preferred):** Add `[FromEvent<TEvent>]` at class level for auto-mapping — no separate `IProjectionFor<T>` class needed
+- Mark the primary key property with `[Key]` from `Cratis.Chronicle.Keys`
+- Use `[SetFrom<TEvent>]` / `[AddFrom<TEvent>]` / `[SubtractFrom<TEvent>]` for explicit property-level mapping
+- Use `[ChildrenFrom<TEvent>]` for nested child collections, `[Join<TEvent>]` for cross-event enrichment
+- Query methods are **static methods** on the read model record itself
+- `Observe()` returns an `ISubject<IEnumerable<T>>` for live updates; use `ObserveWithPaging(...)` for paged results
+
+**When to use fluent `IProjectionFor<T>` instead:**
+- Projection logic is too complex for attributes (e.g. conditional branching)
+- You prefer to separate projection definition from the read model type
+
+```csharp
+// Fluent alternative — still correct, use for complex cases
+public class ProjectProjection : IProjectionFor<Project>
+{
+    public void Define(IProjectionBuilderFor<Project> builder) => builder
+        .From<Registration.ProjectRegistered>();     // AutoMap is on by default
+}
+```
+
+---
+
+## Automation (Reactor) — full example
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+namespace MyApp.Projects.Notifications;
+
+/// <summary>
+/// Sends a notification when a project is registered.
+/// </summary>
+/// <param name="notifications">The notification service.</param>
+public class ProjectRegisteredNotifier(INotificationService notifications) : IReactor
+{
+    /// <summary>
+    /// Reacts to <see cref="Registration.ProjectRegistered"/> events.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task ProjectRegistered(Registration.ProjectRegistered @event, EventContext context) =>
+        await notifications.Notify($"Project '{@event.Name}' was registered.");
+}
+```
+
+**Key rules:**
+- Reactors implement `IReactor` — a marker interface with **no methods**
+- The method name MUST match the event type name exactly (by convention)
+- Reactors MUST be idempotent — they can be called more than once per event
+- Use the event data directly — do not query the read model inside the handler
+- To trigger further commands, inject and call `ICommandPipeline` — never use `IEventLog` directly
+
+---
+
+## Translation — full example
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+namespace MyApp.Projects.StockKeeping;
+
+/// <summary>
+/// Reacts to reservation events and decreases stock accordingly.
+/// </summary>
+/// <param name="stockKeeper">The stock keeper service.</param>
+/// <param name="commandPipeline">The command pipeline for executing commands.</param>
+public class StockKeeping(IStockKeeper stockKeeper, ICommandPipeline commandPipeline) : IReactor
+{
+    /// <summary>
+    /// Handles a <see cref="BookReserved"/> event.
+    /// </summary>
+    /// <param name="event">The event.</param>
+    /// <param name="context">The event context.</param>
+    public async Task BookReserved(BookReserved @event, EventContext context) =>
+        await commandPipeline.Execute(new DecreaseStock(@event.Isbn, await stockKeeper.GetStock(@event.Isbn)));
+}
+
+/// <summary>
+/// Command to decrease available stock of a book.
+/// </summary>
+[Command]
+public record DecreaseStock(ISBN Isbn, BookStock StockBeforeDecrease)
+{
+    /// <summary>
+    /// Produces a <see cref="StockDecreased"/> event.
+    /// </summary>
+    /// <returns>The <see cref="StockDecreased"/> event.</returns>
+    public StockDecreased Handle() => new(Isbn, StockBeforeDecrease);
+}
+
+/// <summary>
+/// Raised when the available stock of a book has decreased.
+/// </summary>
+[EventType]
+public record StockDecreased(ISBN Isbn, BookStock StockBeforeDecrease);
+```
+
+---
+
+## Frontend — complete component examples
+
+### Listing component with paging
+
+```tsx
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { Column } from 'primereact/column';
+import { DataTable } from 'primereact/datatable';
+import { AllProjects } from './AllProjects';
+
+const pageSize = 10;
+
+export const Listing = () => {
+    const [result, , setPage] = AllProjects.useWithPaging(pageSize);
+
+    return (
+        <DataTable
+            lazy paginator
+            value={result.data}
+            rows={pageSize}
+            totalRecords={result.paging.totalItems}
+            alwaysShowPaginator={false}
+            first={result.paging.page * pageSize}
+            onPage={event => setPage(event.page ?? 0)}
+            scrollable scrollHeight="flex"
+            emptyMessage="No projects found.">
+            <Column field="name" header="Name" />
+        </DataTable>
+    );
+};
+```
+
+### CommandDialog for state-change commands
+
+```tsx
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { useState } from 'react';
+import { DialogProps, DialogResult } from '@cratis/arc.react/dialogs';
+import { CommandDialog } from '@cratis/components/CommandDialog';
+import { InputText } from 'primereact/inputtext';
+import { RegisterProject } from './RegisterProject';
+
+export const AddProject = ({ closeDialog }: DialogProps) => {
+    const [name, setName] = useState('');
+
+    return (
+        <CommandDialog
+            command={RegisterProject}
+            visible
+            header="Add Project"
+            width="32rem"
+            confirmLabel="Add"
+            cancelLabel="Cancel"
+            onBeforeExecute={(values) => {
+                values.name = name;
+                return values;
+            }}
+            onConfirm={() => closeDialog(DialogResult.Ok)}
+            onCancel={() => closeDialog(DialogResult.Cancelled)}>
+            <CommandDialog.Fields>
+                <InputText
+                    value={name}
+                    onChange={event => setName(event.target.value)}
+                    autoFocus
+                />
+            </CommandDialog.Fields>
+        </CommandDialog>
+    );
+};
+```
+
+### Composition page
+
+```tsx
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { DialogResult, useDialog } from '@cratis/arc.react/dialogs';
+import { Menubar } from 'primereact/menubar';
+import { MenuItem } from 'primereact/menuitem';
+import * as mdIcons from 'react-icons/md';
+import { Page } from '../../Core/Page';
+import { AddProject } from './Registration/AddProject';
+import { Listing } from './Listing/Listing';
+
+export const Projects = () => {
+    const [AddProjectDialog, showAddProjectDialog] = useDialog(AddProject);
+
+    const menuItems: MenuItem[] = [
+        {
+            label: 'Add Project',
+            icon: mdIcons.MdAdd,
+            command: async () => { await showAddProjectDialog(); }
+        }
+    ];
+
+    return (
+        <Page title="Projects">
+            <Menubar model={menuItems} />
+            <Listing />
+            <AddProjectDialog />
+        </Page>
+    );
+};
+```
diff --git a/.github/skills/review-code/SKILL.md b/.github/skills/review-code/SKILL.md
new file mode 100644
index 0000000..4e75a23
--- /dev/null
+++ b/.github/skills/review-code/SKILL.md
@@ -0,0 +1,69 @@
+---
+name: review-code
+description: Use this skill when asked to review, check, or validate code in a Cratis-based project. Produces a structured review report with blocking issues and suggestions, checked against all project architecture and style standards.
+---
+
+Review changed code against all Cratis project standards and produce a structured report.
+
+## C# Architecture
+
+- [ ] Each slice: single file `Features/<Feature>/<Slice>.cs` with all backend artifacts
+- [ ] Commands: `record` type with `Handle()` directly on them — no separate handler classes
+- [ ] Events: `record` type, no mutable properties
+- [ ] Projections: AutoMap is on by default — `.AutoMap()` only needed after `.NoAutoMap()`
+- [ ] No service locator (`IServiceProvider` not injected)
+- [ ] Namespace matches folder: `<NamespaceRoot>.<Feature>.<Slice>`
+
+## C# Code Style
+
+- [ ] File-scoped namespaces; `using` directives alphabetically sorted
+- [ ] No unused `using` directives
+- [ ] `is null` / `is not null` — never `== null` / `!= null`
+- [ ] `var` preferred over explicit types
+- [ ] No postfixes: `Async`, `Impl`, `Service` on class names
+- [ ] No regions
+- [ ] All public types, methods, and properties have multiline XML doc comments
+- [ ] `<summary>` tags always multiline — never `/// <summary>Text</summary>` on one line
+- [ ] Methods with parameters include `<param name="...">` for each
+- [ ] Non-void methods include `<returns>`
+- [ ] Custom exception types only — never `InvalidOperationException`, `ArgumentException`, etc.
+- [ ] Exception XML docs start with "The exception that is thrown when …"
+- [ ] Copyright header on every file
+- [ ] Strongly-typed Concepts for all domain IDs/values (no raw `Guid`/`string` in domain models)
+
+## TypeScript Code Style
+
+- [ ] `const` over `let` over `var`
+- [ ] Full descriptive names — never `e`, `idx`, `prev`, `dir`, `pos`
+- [ ] No `any` type — `unknown` with type guards
+- [ ] No `(x as any)` — use `value as unknown as TargetType`
+- [ ] No unused imports
+- [ ] Copyright header on every file
+
+## Component Rules
+
+- [ ] `CommandDialog` from `@cratis/components/CommandDialog` for command dialogs
+- [ ] `Dialog` from `@cratis/components/Dialogs` for data-only dialogs
+- [ ] Never imports `Dialog` from `primereact/dialog` directly
+- [ ] No hard-coded hex/rgb colours — PrimeReact CSS variables only
+- [ ] README.md present for complex component folders with multiple sub-components
+
+## Output format
+
+Start with: **Review result: ✅ Approved / ⚠️ Approved with comments / ❌ Changes requested**
+
+Then list issues:
+```
+### <file path>
+
+**[BLOCKING]** Line N: `problematic code`
+Because: explanation
+Fix:
+```corrected code```
+```
+
+End with a concise summary of what passed and what must change.
+
+---
+
+For the full expanded checklists across all categories, see [references/CHECKLISTS.md](references/CHECKLISTS.md).
diff --git a/.github/skills/review-code/references/CHECKLISTS.md b/.github/skills/review-code/references/CHECKLISTS.md
new file mode 100644
index 0000000..57babb4
--- /dev/null
+++ b/.github/skills/review-code/references/CHECKLISTS.md
@@ -0,0 +1,109 @@
+# Code Review Checklists
+
+## C# Architecture
+
+- [ ] Each slice lives in a single file at `Features/<Feature>/<Slice>.cs`
+- [ ] ALL backend artifacts in one file: command, validator, business rules, event, read model, projection, slice class
+- [ ] No separate handler classes — `Handle()` is on the command `record` directly
+- [ ] No shared mutable state between commands
+- [ ] No service locator (`IServiceProvider` not injected as a dependency)
+- [ ] No explicit singleton registration when `[Singleton]` attribute suffices
+- [ ] Logging in a separate `*Logging.cs` partial file using `[LoggerMessage]`
+- [ ] Namespace: `<NamespaceRoot>.<Feature>.<Slice>` (no `.Features.` segment)
+
+## C# Commands
+
+- [ ] `record` type, not `class`
+- [ ] All properties use `init` (immutable)
+- [ ] `Handle()` is the single public entry point
+- [ ] No unnecessary constructors — primary constructor only
+- [ ] Validation attributes on properties (`[Required]`, `[MaxLength]`, etc.) for simple rules
+- [ ] Business rules that depend on Chronicle state use a read model parameter in `Handle()` (DCB pattern)
+
+## C# Events
+
+- [ ] `record` type with no mutable properties
+- [ ] Decorated with `[EventType("stable-guid-string")]`
+- [ ] No behaviour — data only
+- [ ] Properties are domain types (Concepts), not raw primitives like `Guid` or `string`
+
+## C# Read Models & Projections
+
+- [ ] Read model is a `record` type
+- [ ] Projection: AutoMap is on by default — `.AutoMap()` only needed after `.NoAutoMap()`
+- [ ] No joins on the read model — joins are on Chronicle events only
+- [ ] `ProjectionId` is a stable GUID string — never changes after first deployment
+- [ ] No `ToList()`, `ToArray()`, or mutable collection exposed from public API
+
+## C# Concepts
+
+- [ ] Domain IDs/values use `ConceptAs<T>` (see `add-concept` skill)
+- [ ] No raw `Guid`, `string`, `int` used where a concept should wrap it
+- [ ] Concept has `static readonly NotSet`/`Empty` sentinel
+- [ ] Concept has implicit conversion from primitive
+- [ ] Concept has `New()` factory if Guid-backed
+
+## C# Code Style
+
+- [ ] File-scoped namespace declaration (`namespace Foo.Bar;`)
+- [ ] `using` directives alphabetically sorted, no unused ones
+- [ ] `is null` / `is not null` — never `== null` / `!= null`
+- [ ] `var` preferred over explicit type declarations
+- [ ] No postfixes on class names: `Async`, `Impl`, `Service`, `Manager`, `Helper`
+- [ ] No regions (`#region`)
+- [ ] No built-in exception types: `InvalidOperationException`, `ArgumentException`, etc.
+- [ ] All public types, methods, and properties have multiline XML doc comments
+- [ ] `<summary>` tags always multiline — never `/// <summary>Text</summary>` on one line
+- [ ] Methods with parameters include `<param name="...">` for each parameter
+- [ ] Non-void methods include `<returns>` documentation
+- [ ] Methods that throw include `<exception cref="...">` documentation
+- [ ] Custom exceptions derive from `Exception`, XML doc starts with "The exception that is thrown when …"
+- [ ] Copyright header on every file
+- [ ] No trailing whitespace or missing newlines at end of file
+
+## TypeScript Architecture
+
+- [ ] Components placed in the slice folder (`Features/<Feature>/<Slice>/`)
+- [ ] No `index.ts` barrel just to re-export a single component
+- [ ] No technical folder groupings (`hooks/`, `utils/`, `types/`) at feature level
+- [ ] Feature folder structure is functional, not technical
+
+## TypeScript Type Safety
+
+- [ ] No `any` types — `unknown` with type guards
+- [ ] No `(x as any)` — use `value as unknown as TargetType`
+- [ ] React synthetic events and DOM events not confused (`React.MouseEvent` vs `MouseEvent`)
+- [ ] Generic defaults use `unknown`, not `any` (e.g. `<T = unknown>`)
+- [ ] No `@ts-ignore` or `@ts-expect-error` without a comment explaining why
+
+## TypeScript Styling
+
+- [ ] No hard-coded hex/rgb values — PrimeReact CSS variables (`var(--...)`) only
+- [ ] CSS co-located with component (`.css` file in same folder)
+- [ ] No `!important` unless justified with a comment
+
+## TypeScript Code Style
+
+- [ ] `const` over `let`, `let` over `var`
+- [ ] Full descriptive names — never `e`, `evt`, `idx`, `i`, `prev`, `dir`, `pos`, `ctx`
+- [ ] No async functions that don't `await` anything
+- [ ] No unused variables or imports
+- [ ] String enums for all enumerations (not numeric)
+- [ ] Copyright header on every file
+
+## Component Conventions
+
+- [ ] `CommandDialog` from `@cratis/components/CommandDialog` for command-based dialogs
+- [ ] `Dialog` from `@cratis/components/Dialogs` for data-only dialogs
+- [ ] Never imports `Dialog` from `primereact/dialog` directly
+- [ ] No monolithic components — decomposed into focused sub-components
+- [ ] `README.md` exists for component folders with ≥2 sub-components or non-trivial architecture
+
+## Spec Coverage
+
+- [ ] Every State Change command has specs
+- [ ] Happy path covered
+- [ ] Every validation rule has a failure spec
+- [ ] Every business rule violation has a spec
+- [ ] Every constraint violation has a spec
+- [ ] No spec for trivial property getters or constructor passthrough
diff --git a/.github/skills/review-performance/SKILL.md b/.github/skills/review-performance/SKILL.md
new file mode 100644
index 0000000..44d465f
--- /dev/null
+++ b/.github/skills/review-performance/SKILL.md
@@ -0,0 +1,55 @@
+---
+name: review-performance
+description: Use this skill when asked to check for performance issues, inefficiencies, or scalability problems in a Cratis-based project. Covers Chronicle projections, MongoDB query patterns, .NET allocations, and React render overhead.
+---
+
+Perform a focused performance review of changed code.
+
+## Chronicle / Event Sourcing
+
+- [ ] Projections use AutoMap (on by default) — avoids manual mapping cost
+- [ ] Projections do NOT join on the read model (forces full re-read)
+- [ ] Reactors do NOT re-query the event log inside `On()` — use event data directly
+- [ ] No eager loading of entire event sequences without paging/filtering
+- [ ] New projections can replay all historical events without crashing
+- [ ] Events are small — no large blobs or base64-encoded content embedded
+
+## MongoDB / Read Models
+
+- [ ] Queries filter on indexed fields — no unintentional full-collection scans
+- [ ] Paged queries use `.Skip()` + `.Take()` — never load all rows
+- [ ] No N+1 pattern — single query returns all needed data
+- [ ] Read-model records do not embed large nested collections that are never fully iterated
+
+## ASP.NET Core / Commands & Queries
+
+- [ ] Query endpoints do not hydrate the full collection when only a count is needed
+- [ ] Command validators are synchronous and in-memory — no I/O in validation
+- [ ] No `await Task.Run(() => syncWork)` wrapping for naturally async work
+- [ ] Response payloads include only fields the client uses — no over-fetching
+
+## React / TypeScript
+
+- [ ] `DataTable` uses `lazy` + `paginator` for collections larger than ~20 rows
+- [ ] No inline object/array literals passed as props (causes identity change every render)
+- [ ] `useEffect` dependencies are correct — no missing deps, no over-broad deps
+- [ ] Large-collection components wrapped in `React.memo` or use stable references
+- [ ] No `JSON.parse(JSON.stringify(x))` deep cloning
+
+## General .NET
+
+- [ ] No LINQ `.ToList()` before `.Where()` — filter before materialising
+- [ ] `IEnumerable<T>` not enumerated multiple times — materialise once if needed
+- [ ] Large object logging uses `{@obj}` only at `Debug` level
+
+## Risk classification
+
+- 🔴 High — measurable degradation at moderate load — must fix before merge
+- 🟡 Medium — could degrade under load or at scale
+- 🟢 Low — minor inefficiency or style issue
+
+## Output format
+
+Start with: **Performance Review: ✅ No issues / ⚠️ Minor findings / ❌ Blocking issues found**
+
+Group findings by category. End with a summary table showing ✅/⚠️/❌ per category.
diff --git a/.github/skills/review-security/SKILL.md b/.github/skills/review-security/SKILL.md
new file mode 100644
index 0000000..e06f17c
--- /dev/null
+++ b/.github/skills/review-security/SKILL.md
@@ -0,0 +1,57 @@
+---
+name: review-security
+description: Use this skill when asked to perform a security review or security audit of code in a Cratis-based project. Checks for injection, auth/authz, data exposure, secrets, and event-sourcing-specific vulnerabilities.
+---
+
+Perform a structured security review of changed code.
+
+## Input Validation & Injection
+
+- [ ] All command properties validated before use (null, empty, range, format)
+- [ ] No raw SQL concatenation — parameterised queries or EF Core only
+- [ ] No user-supplied values passed to `Path.Combine`, `File.*`, shell commands, or process args
+- [ ] No user-supplied values used as event-store keys without sanitisation
+
+## Authentication & Authorisation
+
+- [ ] All HTTP endpoints decorated with `[Authorize]` or explicitly `[AllowAnonymous]` with justification
+- [ ] Tenant isolation enforced — no cross-tenant data accessible without authorisation
+- [ ] Claims verified before acting on identity-dependent command data
+
+## Sensitive Data Exposure
+
+- [ ] No passwords, secrets, API keys, or tokens stored in event properties or read models
+- [ ] No PII returned to clients that did not provide it
+- [ ] Query results scoped to requesting tenant/user — never return all-tenant data
+
+## Secrets & Configuration
+
+- [ ] No secrets in source code, config files, or test fixtures
+- [ ] Secrets loaded from environment variables or a secrets manager
+- [ ] No hard-coded connection strings in non-test code
+
+## Event Sourcing Specifics
+
+- [ ] Events are immutable records — no mutable state in the event store
+- [ ] Aggregate/event-store IDs generated server-side, never accepted from untrusted clients
+- [ ] Event upcasting logic does not allow injection of unexpected properties
+- [ ] Uniqueness constraints cannot be bypassed by concurrent multi-tenant writes
+
+## Frontend
+
+- [ ] No user-supplied values in `dangerouslySetInnerHTML`
+- [ ] No tokens or secrets in `localStorage` — use `httpOnly` cookies or in-memory state
+- [ ] Command DTOs contain only the minimum required fields
+- [ ] No client-side access control not also enforced server-side
+
+## Risk classification
+
+- 🔴 Critical — must fix before merge
+- 🟡 Medium — should fix soon
+- 🟢 Low — fix when convenient
+
+## Output format
+
+Start with: **Security Review: ✅ No issues / ⚠️ Low-risk findings / ❌ Blocking issues found**
+
+Group findings by category. End with a summary table showing ✅/⚠️/❌ per category.
diff --git a/.github/skills/scaffold-feature/SKILL.md b/.github/skills/scaffold-feature/SKILL.md
new file mode 100644
index 0000000..bd83ee6
--- /dev/null
+++ b/.github/skills/scaffold-feature/SKILL.md
@@ -0,0 +1,82 @@
+---
+name: scaffold-feature
+description: Use this skill when asked to create a new feature, section, or page that does not yet exist in a Cratis-based project. Sets up the folder, composition page, routing, and navigation entry before any slices are added.
+---
+
+Scaffold a brand-new feature folder with routing and navigation — ready for slices.
+
+## What to produce
+
+### 1 — Feature folder
+
+```
+Features/<Feature>/
+├── <Feature>.tsx    ← composition page
+├── <Feature>.css    ← feature-level styles (can be empty initially)
+└── index.ts         ← re-exports the composition page
+```
+
+### 2 — Composition page (`<Feature>.tsx`)
+
+```tsx
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { Page } from '../../Core/Page';
+
+export const <Feature> = () => {
+    return (
+        <Page title="<NavigationLabel>">
+            {/* Slices will be composed here */}
+        </Page>
+    );
+};
+```
+
+### 3 — `index.ts`
+
+```typescript
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+export { <Feature> } from './<Feature>';
+```
+
+### 4 — Update routing
+
+Locate the app router (typically `App.tsx` or a `routes.ts` file) and add:
+
+```tsx
+import { <Feature> } from './Features/<Feature>';
+
+{ path: '<route-path>', element: <<Feature> /> }
+```
+
+### 5 — Update navigation
+
+Locate the sidebar/navigation configuration and add:
+
+```tsx
+import * as mdIcons from 'react-icons/md';
+
+{
+    label: '<NavigationLabel>',
+    icon: mdIcons.<NavigationIcon>,
+    url: '<route-path>'
+}
+```
+
+## Rules
+
+- Feature name: PascalCase (e.g. `Projects`, `Invoices`)
+- Route path: kebab-case (e.g. `/projects`, `/user-management`)
+- Navigation icon: from `react-icons/md` — e.g. `MdFolderOpen`, `MdPeople`
+- Copyright header on every file
+
+## Validation
+
+Run `yarn lint` and `npx tsc -b`. Fix all errors. Confirm the blank page renders without runtime errors.
+
+## Next step
+
+Add slices using the `new-vertical-slice` skill.
diff --git a/.github/skills/write-documentation/SKILL.md b/.github/skills/write-documentation/SKILL.md
new file mode 100644
index 0000000..b1cc792
--- /dev/null
+++ b/.github/skills/write-documentation/SKILL.md
@@ -0,0 +1,121 @@
+---
+name: write-documentation
+description: "Diátaxis Documentation Expert for Cratis projects. Writes high-quality DocFX documentation guided by the Diátaxis framework — classifying every page as a Tutorial, How-to Guide, Reference, or Explanation."
+---
+
+# Diátaxis Documentation Expert
+
+You are an expert technical writer producing DocFX-compatible documentation for Cratis projects. Every page you write is guided by the [Diátaxis framework](https://diataxis.fr/) — a systematic approach that classifies documentation into four distinct types, each serving a different user need.
+
+## Guiding Principles
+
+1. **Clarity** — Write in simple, clear, unambiguous language.
+2. **Accuracy** — Every code example must be complete, correct, and runnable. No pseudo-code.
+3. **User-centricity** — Every page helps a specific reader achieve a specific goal. Lead with *why*, then *how*.
+4. **Consistency** — Match the project's existing tone, terminology, and style. If it's "event source" in one place, it's "event source" everywhere.
+
+## The Four Document Types
+
+Before writing, determine which Diátaxis quadrant the page belongs to:
+
+| Type | Orientation | Analogy | When to use |
+|---|---|---|---|
+| **Tutorial** | Learning | A lesson | Guide a newcomer step-by-step to a successful first outcome |
+| **How-to Guide** | Problem-solving | A recipe | Show an experienced user how to accomplish a specific task |
+| **Reference** | Information | A dictionary | Describe the technical machinery — APIs, attributes, configuration |
+| **Explanation** | Understanding | A discussion | Clarify *why* something works the way it does, trade-offs, architecture |
+
+### Rules per type
+
+- **Tutorial** — Never explain *why*; focus on *do this, then this*. Each step must produce a visible, verifiable result. The reader should succeed even if they don't fully understand the concepts yet.
+- **How-to Guide** — Assume competence. State the goal, list prerequisites, give the steps, done. No teaching.
+- **Reference** — Be exhaustive and terse. Tables, type signatures, attribute lists. No narrative.
+- **Explanation** — No steps. Discuss concepts, trade-offs, and architecture decisions. Use Mermaid diagrams freely.
+
+## Workflow
+
+Follow this process for every documentation request:
+
+1. **Clarify** — Determine before writing:
+   - **Document type** — Tutorial, How-to, Reference, or Explanation
+   - **Target audience** — e.g. new developer, experienced contributor, framework consumer
+   - **Reader's goal** — What they want to achieve by reading this page
+   - **Scope** — What to include *and* what to exclude
+   If the request is ambiguous, ask before proceeding.
+
+2. **Propose structure** — Present an outline (headings + one-line descriptions). Wait for approval before writing full content.
+
+3. **Write** — Produce the full documentation in well-formatted Markdown. Adhere to all rules below.
+
+## File Structure
+
+All documentation lives in the `Documentation/` folder at the repository root. The site is built with [DocFX](https://dotnet.github.io/docfx/).
+
+For a new topic:
+
+    Documentation/<Section>/<Topic>/
+    ├── index.md      ← main content page
+    └── toc.yml       ← local table of contents
+
+Update the **parent** `toc.yml` to link to the new folder's `toc.yml`.
+
+### Structure rules
+
+- Every folder must have a `toc.yml` for navigation.
+- Every folder must have an `index.md` as its landing page.
+- In `toc.yml`, link to a subfolder's `toc.yml`, not its `index.md`.
+- Use relative links for all internal references.
+
+## toc.yml format
+
+Simple topic:
+
+    - name: <Topic Title>
+      href: index.md
+
+With sub-topics:
+
+    - name: <Topic Title>
+      href: index.md
+      items:
+        - name: Sub-topic
+          href: subtopic/toc.yml
+
+## Writing Style
+
+The project's voice is **direct, practical, and opinionated**. Write like an experienced colleague explaining something to a capable developer — confident but never condescending.
+
+- **Active voice, present tense.** "Chronicle appends the event" not "The event is appended by Chronicle."
+- **Second person.** "You configure…" not "One configures…" or "It is possible to configure…"
+- **Lead with the most important information.** Don't bury the key point after three paragraphs of context.
+- Use headings, lists, and code blocks to organize content — dense paragraphs lose readers.
+- Focus on public APIs and features — never internal implementation.
+- Do not document third-party libraries.
+
+## Code Examples
+
+- Prefer `record` types for data structures (events, commands, read models).
+- `[EventType]` takes no arguments — never add a GUID or string.
+- Never include verbatim code from the repository — APIs change. Write purpose-built examples.
+- Every example must be complete and correct — no `// ...` elisions.
+
+## Diagrams
+
+Use [Mermaid](https://mermaid-js.github.io/mermaid/#/) for:
+- Architecture diagrams (`graph TD` or `graph LR`)
+- Sequence flows (`sequenceDiagram`)
+- State transitions (`stateDiagram-v2`)
+
+## Contextual Awareness
+
+- When existing documentation files are available, read them first to match tone, style, and terminology.
+- Do not copy content from them unless explicitly asked.
+- Do not fabricate external URLs — only link to resources you can verify exist.
+
+## Validation
+
+After writing, verify:
+- `toc.yml` is valid YAML
+- All `href` values point to files that exist (or will exist when created)
+- All Mermaid blocks are syntactically valid (balanced brackets, correct syntax)
+- File ends with a single trailing newline
diff --git a/.github/skills/write-specs/SKILL.md b/.github/skills/write-specs/SKILL.md
new file mode 100644
index 0000000..b64dbfd
--- /dev/null
+++ b/.github/skills/write-specs/SKILL.md
@@ -0,0 +1,85 @@
+---
+name: write-specs
+description: Use this skill when asked to write tests, specs, or test coverage for a command, query, or slice in a Cratis-based project. Produces BDD-style integration specs using xUnit and Cratis.Specifications.
+---
+
+Write comprehensive BDD integration specs for a vertical slice command or query.
+
+## Spec placement
+
+Specs live **in the same slice folder** as the `.cs` file:
+
+```
+Features/<Feature>/<Slice>/
+├── <Slice>.cs
+└── when_<verb_phrase>/
+    ├── and_<happy_scenario>.cs
+    └── and_<failure_scenario>.cs
+```
+
+## What to cover for every State Change command
+
+Write one spec class for **each** of:
+
+1. **Happy path** — command succeeds, expected event is appended, sequence number advanced
+2. **Each validation failure** — one `and_` class per `[Required]`, `[MaxLength]`, etc. rule
+3. **Each business rule violation** — one `and_` class per DCB condition in `Handle()` that inspects a read model
+4. **Each constraint violation** — one `and_` class per `IConstraint`
+
+## C# spec structure
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+using Cratis.Arc.Commands;
+using context = <NamespaceRoot>.<Feature>.<Slice>.when_<behavior>.and_<scenario>.context;
+
+namespace <NamespaceRoot>.<Feature>.<Slice>.when_<behavior>;
+
+[Collection(ChronicleCollection.Name)]
+public class and_<scenario>(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public CommandResult<object>? Result;
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<<Command>>(
+                "/api/<feature>/<action>",
+                new <Command>(...));
+        }
+    }
+
+    [Fact] void should_<expected_result>() => Context.Result.IsSuccess.ShouldBeTrue();
+}
+```
+
+For scenarios that require pre-existing state, add an `async Task Establish()` before `Because()`:
+
+```csharp
+async Task Establish() =>
+    await EventStore.EventLog.Append(SomeId.New(), new SomeEvent(...));
+```
+
+## Naming conventions
+
+- Folder: `when_<verb_phrase>` — e.g. `when_registering`, `when_removing_a_project`
+- File: `and_<condition>.cs` — e.g. `and_name_is_unique.cs`, `and_name_already_exists.cs`
+- Test method: `should_<expected_result>` — e.g. `should_append_the_registered_event`
+
+## Assertion helpers
+
+Use Cratis.Specifications helpers — never raw `Assert.*`:
+- `Context.Result.IsSuccess.ShouldBeTrue()`
+- `Context.Result.IsSuccess.ShouldBeFalse()`
+- `Context.ShouldHaveTailSequenceNumber(EventSequenceNumber.First)` — checks the event log tail
+
+## After writing
+
+Run `dotnet test`. Fix all failures before completing.
+
+---
+
+For full worked examples of each spec type (happy path, validation, business rule, constraint), see [references/EXAMPLES.md](references/EXAMPLES.md).
diff --git a/.github/skills/write-specs/references/EXAMPLES.md b/.github/skills/write-specs/references/EXAMPLES.md
new file mode 100644
index 0000000..263122f
--- /dev/null
+++ b/.github/skills/write-specs/references/EXAMPLES.md
@@ -0,0 +1,115 @@
+# Spec Examples
+
+## Happy path spec
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+using context = MyApp.Projects.Registration.when_registering.and_name_is_unique.context;
+
+namespace MyApp.Projects.Registration.when_registering;
+
+[Collection(ChronicleCollection.Name)]
+public class and_name_is_unique(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public CommandResult<object>? Result;
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<RegisterProject>(
+                "/api/projects/registration",
+                new RegisterProject(ProjectId.New(), "My Project"));
+        }
+    }
+
+    [Fact] void should_succeed() => Context.Result.IsSuccess.ShouldBeTrue();
+    [Fact] void should_have_appended_the_registered_event() =>
+        Context.ShouldHaveTailSequenceNumber(EventSequenceNumber.First);
+}
+```
+
+---
+
+## Constraint violation spec (pre-existing state)
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+using context = MyApp.Projects.Registration.when_registering.and_name_already_exists.context;
+
+namespace MyApp.Projects.Registration.when_registering;
+
+[Collection(ChronicleCollection.Name)]
+public class and_name_already_exists(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public const string ProjectName = "My Project";
+        public CommandResult<object>? Result;
+
+        async Task Establish() =>
+            await EventStore.EventLog.Append(ProjectId.New(), new ProjectRegistered(ProjectName));
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<RegisterProject>(
+                "/api/projects/registration",
+                new RegisterProject(ProjectId.New(), ProjectName));
+        }
+    }
+
+    [Fact] void should_not_succeed() => Context.Result.IsSuccess.ShouldBeFalse();
+    [Fact] void should_not_have_appended_any_additional_events() =>
+        Context.ShouldHaveTailSequenceNumber(EventSequenceNumber.First);
+}
+```
+
+---
+
+## Validation failure spec (model validation)
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+using context = MyApp.Projects.Registration.when_registering.and_name_is_empty.context;
+
+namespace MyApp.Projects.Registration.when_registering;
+
+[Collection(ChronicleCollection.Name)]
+public class and_name_is_empty(context context) : Given<context>(context)
+{
+    public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
+    {
+        public CommandResult<object>? Result;
+
+        async Task Because()
+        {
+            Result = await Client.ExecuteCommand<RegisterProject>(
+                "/api/projects/registration",
+                new RegisterProject(ProjectId.New(), string.Empty));
+        }
+    }
+
+    [Fact] void should_not_succeed() => Context.Result.IsSuccess.ShouldBeFalse();
+    [Fact] void should_report_validation_error_on_name() =>
+        Context.Result.ValidationResults.ShouldNotBeEmpty();
+}
+```
+
+---
+
+## Assertion helpers reference
+
+| Helper | When to use |
+|--------|-------------|
+| `.ShouldBeTrue()` / `.ShouldBeFalse()` | Boolean assertions |
+| `.ShouldEqual(x)` | Value equality |
+| `Context.ShouldHaveTailSequenceNumber(n)` | Confirm the tail event sequence number (use `EventSequenceNumber.First` for exactly one event in the log) |
+| `Context.Result.ValidationResults.ShouldNotBeEmpty()` | Confirm model validation rejected the command |
+| `Context.Result.IsSuccess.ShouldBeFalse()` | Confirm the command did not succeed (constraint or validation) |
+| `EventSequenceNumber.First` | Sequence number 0 — the very first event |