@eventmodelers/cli 1.0.73 → 1.0.74

package/README.md

@@ -18,7 +18,6 @@ Running without `--stack` shows an arrow-key picker. Or go straight to a stack:
 npx @eventmodelers/cli init --stack node            # Node.js / TypeScript
 npx @eventmodelers/cli init --stack supabase         # Supabase
 npx @eventmodelers/cli init --stack axon             # Axon Framework (Java/Kotlin)
-npx @eventmodelers/cli init --stack cratis-csharp    # Cratis (.NET/C#)
 npx @eventmodelers/cli init --stack opencqrs         # OpenCQRS (Java, EventSourcingDB)
 npx @eventmodelers/cli init --stack umadb            # UmaDB (Java)
 npx @eventmodelers/cli init --stack kurrent          # Kurrent (Java, KurrentDB)
@@ -89,7 +88,7 @@ your-project/
 └── CLAUDE.md                      ← agent instructions
 ```
 
-The seven backend stacks (`node`, `supabase`, `axon`, `cratis-csharp`, `opencqrs`, `umadb`, `kurrent`) also scaffold a real project skeleton into your project root (`templates/root/`) — source layout, build files, migrations, etc.
+The six backend stacks (`node`, `supabase`, `axon`, `opencqrs`, `umadb`, `kurrent`) also scaffold a real project skeleton into your project root (`templates/root/`) — source layout, build files, migrations, etc.
 
 `react` and `supabase-react` are two more registered stacks (installable the same way). `supabase-react` is real, filled-in content — a Vite + React 19 + TypeScript scaffold that authenticates and issues command POSTs via a Supabase session (`src/lib/api.ts`/`src/lib/supabase.ts`), plus `init-style-guide`/`learn-styleguide` skills so generated UI stays on-brand. It's UI-only: `.build-kit/CLAUDE.md` only routes `STATE_CHANGE`/`STATE_VIEW` slices to `build-state-change`/`build-state-view` — an `AUTOMATION` slice has no UI counterpart and gets flagged via `request-feedback` instead, since it belongs to whichever backend stack is installed alongside this one. It needs no overrides at all and uses `shared/build-kit`'s realtime agent as-is.
 
@@ -162,11 +161,19 @@ npx @eventmodelers/cli init --build-kit              # blank build-kit scaffold
 **Building a new kit for an unsupported stack:**
 
 ```bash
-npx @eventmodelers/cli init --build-kit
+npx @eventmodelers/cli init --build-kit --demo
 ```
 
 This scaffolds `.build-kit/CLAUDE.md`, `lib/prompt.md`, `lib/backend-prompt.md`, and the `build-*` skills with TODO placeholders instead of real content. Fill in the TODOs against the actual stack you're integrating (build/test commands, file layout, framework idioms) while building something real with it, then follow "Adding a stack" below to promote it to a first-class stack once it works.
 
+`--demo` is what gives you something to build *against* while you do that: it seeds the kit's `.slices/` with the ready-made 16-slice **Understanding Eventsourcing** model (see "Trying it out before you have a board of your own" above), so you don't need a board, credentials, or a connected project to exercise the kit you're writing. With it in place the whole loop is:
+
+```bash
+npx @eventmodelers/cli run --local
+```
+
+and the agent starts building — `--local` skips platform config and credential lookup entirely, so it works straight out of `init` with nothing connected. Every TODO you fill in gets exercised on the next iteration against real slice data covering all four slice types (state change, state view, automation, translation), which is exactly the coverage a new stack's `build-*` skills need before it's worth promoting.
+
 Installing both a build stack and `init-modeling` into the same project reuses this one `.eventmodelers/config.json` — run whichever `init` command second and it finds the existing config already satisfies the required fields and skips straight past the credential prompt.
 
 ### The modeling agent — `run --modeling` and `--standalone`

package/cli.js

@@ -63,13 +63,6 @@ const STACKS = {
     useShared: true,
     needsBoardId: true,
   },
-  'cratis-csharp': {
-    label: 'Cratis (.NET/C#)',
-    kitSubdir: 'build-kit',
-    kitDirName: '.build-kit',
-    useShared: true,
-    needsBoardId: true,
-  },
   opencqrs: {
     label: 'OpenCQRS (Java, EventSourcingDB)',
     kitSubdir: 'build-kit',

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.73",
-  "description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, Cratis, OpenCQRS, UmaDB, Kurrent, or modeling-only)",
+  "version": "1.0.74",
+  "description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, OpenCQRS, UmaDB, Kurrent, or modeling-only)",
   "type": "module",
   "bin": {
     "eventmodelers": "cli.js"

package/stacks/blank/templates/.claude/skills/build-automation/SKILL.md

@@ -6,7 +6,7 @@ description: TODO — one-line description of how a reactive slice (a processor/
 # Build Automation Slice
 
 > **TODO — placeholder installed by `init --build-kit`.** Study an existing stack's
-> build-automation/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/cratis-csharp,
+> build-automation/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/umadb,
 > under `templates/.claude/skills/`) for the level of detail expected, then rewrite
 > every section below for your stack's real conventions — file layout, naming, and
 > the actual framework/language idioms. Delete this callout once done.

package/stacks/blank/templates/.claude/skills/build-state-change/SKILL.md

@@ -6,7 +6,7 @@ description: TODO — one-line description of how a write-side slice (command va
 # Build State Change Slice
 
 > **TODO — placeholder installed by `init --build-kit`.** Study an existing stack's
-> build-state-change/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/cratis-csharp,
+> build-state-change/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/umadb,
 > under `templates/.claude/skills/`) for the level of detail expected, then rewrite
 > every section below for your stack's real conventions — file layout, naming, and
 > the actual framework/language idioms. Delete this callout once done.

package/stacks/blank/templates/.claude/skills/build-state-view/SKILL.md

@@ -6,7 +6,7 @@ description: TODO — one-line description of how a read-side slice (a projectio
 # Build State View Slice
 
 > **TODO — placeholder installed by `init --build-kit`.** Study an existing stack's
-> build-state-view/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/cratis-csharp,
+> build-state-view/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/umadb,
 > under `templates/.claude/skills/`) for the level of detail expected, then rewrite
 > every section below for your stack's real conventions — file layout, naming, and
 > the actual framework/language idioms. Delete this callout once done.

package/stacks/blank/templates/root/README.md

@@ -7,7 +7,7 @@ layout, a slices directory the skills in `.claude/skills/` generate into, and wh
 local infra (docker-compose, migrations, etc.) it needs to run.
 
 See an existing stack's `templates/root/` in the eventmodelers-cli source —
-`stacks/node`, `stacks/supabase`, `stacks/axon`, `stacks/cratis-csharp` — for the shape
+`stacks/node`, `stacks/supabase`, `stacks/axon`, `stacks/umadb` — for the shape
 a real one takes.
 
 Once this is filled in and working, consider contributing it back as a first-class

package/stacks/modeling-kit/templates/kit/README.md

@@ -7,7 +7,7 @@ Config directory for modeling-only projects — skills + agent loop, no backend
 There's exactly one runtime mode for a modeling-kit install: a single warm Claude
 process, kept alive across turns, that a prompt is written straight into as soon as
 it's fetched off the board's queue. There is no cold-spawn loop and no `tasks.json`
-file — that's what build-kit stacks (`node`, `supabase`, `axon`, `cratis-csharp`) use
+file — that's what build-kit stacks (`node`, `supabase`, `axon`, `umadb`) use
 instead, for their independent, self-contained slice-implementation tasks.
 
 The loop itself lives in `@eventmodelers/cli`, not in this directory — start it from

package/stacks/react/templates/.claude/skills/build-automation/SKILL.md

@@ -6,7 +6,7 @@ description: TODO — one-line description of how a reactive slice (a processor/
 # Build Automation Slice
 
 > **TODO — placeholder installed by `init --build-kit`.** Study an existing stack's
-> build-automation/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/cratis-csharp,
+> build-automation/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/umadb,
 > under `templates/.claude/skills/`) for the level of detail expected, then rewrite
 > every section below for your stack's real conventions — file layout, naming, and
 > the actual framework/language idioms. Delete this callout once done.

package/stacks/react/templates/.claude/skills/build-state-change/SKILL.md

@@ -6,7 +6,7 @@ description: TODO — one-line description of how a write-side slice (command va
 # Build State Change Slice
 
 > **TODO — placeholder installed by `init --build-kit`.** Study an existing stack's
-> build-state-change/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/cratis-csharp,
+> build-state-change/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/umadb,
 > under `templates/.claude/skills/`) for the level of detail expected, then rewrite
 > every section below for your stack's real conventions — file layout, naming, and
 > the actual framework/language idioms. Delete this callout once done.

package/stacks/react/templates/.claude/skills/build-state-view/SKILL.md

@@ -6,7 +6,7 @@ description: TODO — one-line description of how a read-side slice (a projectio
 # Build State View Slice
 
 > **TODO — placeholder installed by `init --build-kit`.** Study an existing stack's
-> build-state-view/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/cratis-csharp,
+> build-state-view/SKILL.md (stacks/node, stacks/supabase, stacks/axon, or stacks/umadb,
 > under `templates/.claude/skills/`) for the level of detail expected, then rewrite
 > every section below for your stack's real conventions — file layout, naming, and
 > the actual framework/language idioms. Delete this callout once done.

package/stacks/cratis-csharp/templates/.claude/skills/_shared/cratis-conventions.md

@@ -1,251 +0,0 @@
-# Cratis Conventions — Distilled
-
-> Self-contained distillation of the Cratis way of building software, taken from the shared
-> Cratis AI configuration (cratis.io). The build skills (`build-state-change`, `build-state-view`,
-> `build-automation`) all rely on these conventions. When in doubt, follow the established pattern in
-> the target project over anything written here — **consistency is king**.
-
-## Stack
-
-- .NET / C# 13, ASP.NET Core. **Cratis Arc** for CQRS, **Cratis Chronicle** for event sourcing,
-  **MongoDB** for read models.
-- React + TypeScript (Vite), PrimeReact UI — generated from C# via **proxy generation** on `dotnet build`.
-- Specs: xUnit + **Cratis.Specifications** + NSubstitute, BDD `for_*/when_*/and_*` layout.
-
-## The eight values (apply these when a rule doesn't cover a case)
-
-1. **Lovable APIs** — sane defaults, flexible, overridable.
-2. **Easy to do right, hard to do wrong** — convention over configuration; discovery by naming.
-3. **Events are facts** — immutable, never nullable, never ambiguous, never multipurpose. A nullable
-   property on an event means you need a *second* event.
-4. **High cohesion through vertical slices** — everything for a behavior lives together.
-5. **Full-stack type safety** — C# → proxy generation → TypeScript, no manual sync.
-6. **Specialization over reuse** — dedicated read models per use case, never one shared model.
-7. **Consistency is king** — match the established pattern over local cleverness.
-8. American English spelling everywhere (behavior, color, initialize, modeling, dialog, …).
-
-## Non-negotiable structural rules
-
-- **ONE `.cs` file per slice** holds ALL backend artifacts: `[Command]` records with `Handle()`,
-  validators, constraints, `[EventType]` records, `[ReadModel]` records with static query methods,
-  projections/reducers, reactors, and slice-specific concepts.
-- **Never split by artifact type** — no `Commands/`, `Handlers/`, `Events/` folders.
-- **Commands define `Handle()` directly on the record** — never a separate handler class.
-- **`[EventType]` takes NO arguments** — the type name is the identifier.
-- **Drop the `.Features.` segment from namespaces** — `MyApp.Authors.Registration`, not
-  `MyApp.Features.Authors.Registration`.
-- Complete one slice end-to-end before starting the next.
-- **File header:** match the project. The shipped starter's example slices use **no** header — follow
-  that. (Cratis's own framework repos use a copyright header; only add one if the project's existing
-  `.cs` files already carry it.)
-
-## Folder convention
-
-Slices live in a **module → feature → slice** hierarchy. **Discover the actual top-level folder from an
-existing slice in the project** (the shipped starter uses `SomeModule/SomeFeature/...`; some projects
-use a `Features/` root) — match what's already there. Namespace mirrors the folders and drops any
-`.Features.` segment: `<Root>.<Module>.<Feature>.<Slice>` (the starter's `<Root>` is `CratisApp`).
-
-```
-<Module>/<Feature>/
-├── <Feature>.tsx              ← composition page (layout, buttons, dialogs, tables)
-├── index.ts                   ← barrel: export * from './<Feature>'
-├── <Concept>.cs               ← shared concepts for this feature (ConceptAs<T>)
-└── <Slice>/
-    ├── <Slice>.cs             ← ALL backend artifacts in ONE file
-    ├── <Proxy>.ts             ← GENERATED by dotnet build — never hand-edit (marked // @generated)
-    ├── <Component>.tsx        ← React component(s) using the co-located generated proxy
-    ├── index.ts               ← barrel export
-    └── when_<behavior>/       ← integration specs (state-change slices)
-        ├── and_<scenario>.cs
-        └── ...
-```
-
-**Proxies are generated next to the source.** The starter `.csproj` sets
-`CratisProxiesUseSourceFileAsOutputFile=true`, so `dotnet build` writes each TypeScript proxy beside its
-`.cs` file (`Register.ts` next to `Registration.cs`). Frontend imports the proxy from the **same folder**
-(`import { Register } from './Register'`). Never edit a `// @generated` file. (Some projects instead
-generate into a separate `api/` folder — follow whatever the existing slices do.)
-
-## Concepts — `ConceptAs<T>` (never raw primitives in domain models)
-
-```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());
-}
-```
-
-- Positional `record` inheriting `ConceptAs<T>` (value equality + immutability for free).
-- Add implicit conversion **to** `T`. Add a `static readonly NotSet` sentinel instead of `null`.
-- `Guid` identity concepts: add `static New()` and an implicit conversion to `EventSourceId`.
-- One concept per file, in the feature folder it belongs to (shared between features → `Features/` root).
-
-## Events — `[EventType]`
-
-```csharp
-[EventType]
-public record AuthorRegistered(AuthorName Name);
-```
-
-- **No attribute arguments** — never `[EventType("some-guid")]`.
-- Past-tense names: `AuthorRegistered`, `BookReserved`, `AddressChanged`.
-- Never nullable properties; one purpose per event.
-
-## Commands — `[Command]` with `Handle()` on the record
-
-```csharp
-[Command]
-public record RegisterAuthor(AuthorName Name)
-{
-    public AuthorRegistered Handle() => new(Name);
-}
-```
-
-- `[Command]` from `Cratis.Arc.Commands.ModelBound`; required for discovery.
-- `Handle()` returns: single event, `(eventSourceId, event)` tuple (Arc returns the id as
-  `CommandResult<T>.response`), `IEnumerable<object>` for multiple events, `Result<TSuccess,TError>`,
-  or `void`.
-- Imperative name — `RegisterAuthor`, not `RegisterAuthorCommand`.
-- Event source resolved from a `[Key]` parameter, an `EventSourceId`-convertible concept, or
-  `ICanProvideEventSourceId`.
-- Inject services / constraints / read models as `Handle()` parameters — DI provides them. A read-model
-  parameter gives you current Chronicle-derived state for **DCB** business rules.
-
-### Validation
-```csharp
-public class RegisterAuthorValidator : CommandValidator<RegisterAuthor>
-{
-    public RegisterAuthorValidator() =>
-        RuleFor(c => c.Name).NotEmpty().WithMessage("Name is required").MaximumLength(100);
-}
-```
-- Extend `CommandValidator<T>` (not `AbstractValidator<T>`) — auto-discovered, runs client-side and
-  via the auto-generated `/validate` endpoint.
-
-## Read Models — `[ReadModel]` + static query methods
-
-```csharp
-[ReadModel]
-public record AuthorListItem(AuthorId Id, AuthorName Name, int BookCount)
-{
-    public static async Task<IEnumerable<AuthorListItem>> AllAuthors(
-        IMongoCollection<AuthorListItem> collection)
-        => await collection.Find(_ => true).ToListAsync();
-
-    public static ISubject<IEnumerable<AuthorListItem>> ObserveAllAuthors(
-        IMongoCollection<AuthorListItem> collection)
-        => collection.Observe();
-}
-```
-
-- `[ReadModel]` required. Query methods are **`public static`** on the record — the method name becomes
-  the TypeScript query proxy class name. No controller, no `IReadModels` injection.
-- Observable (real-time) queries return `ISubject<T>` directly — never `Task<ISubject<T>>`.
-- Prefer model-bound projection attributes; AutoMap is **on by default** (`.From<EventType>()` directly).
-- **Projections join events, never read models.** One read model per use case.
-
-### Projection (declarative mapping)
-```csharp
-public class AuthorListItemProjection : IProjectionFor<AuthorListItem>
-{
-    public void Define(IProjectionBuilderFor<AuthorListItem> builder) => builder
-        .From<AuthorRegistered>(from => from.Set(m => m.Name).To(e => e.Name))
-        .From<BookAdded>(from => from.Add(m => m.BookCount).With(_ => 1));
-}
-```
-
-### Model-bound shorthand
-```csharp
-[ReadModel]
-public record AuthorInfo(
-    [Key] Guid Id,
-    [FromEvent<AuthorRegistered>] string Name);
-```
-
-### Reducer (running aggregates — balances, counts, sums)
-```csharp
-public class BalanceReducer : IReducerFor<Balance>
-{
-    public Balance Deposited(FundsDeposited @event, Balance? current, EventContext context)
-        => (current ?? new(0m)) with { Amount = (current?.Amount ?? 0m) + @event.Amount };
-}
-```
-Return the complete new state; never mutate `current` (`null` on first event). Projections/reducers
-are discovered automatically — no registration.
-
-## Reactors — `IReactor` (automation + translation slices)
-
-```csharp
-public class StockKeeping(IStockKeeper stock, ICommandPipeline commands) : IReactor
-{
-    public async Task BookReserved(BookReserved @event, EventContext context) =>
-        await commands.Execute(new DecreaseStock(@event.Isbn, await stock.GetStock(@event.Isbn)));
-}
-```
-
-- `IReactor` is a **marker interface** — dispatch is by the **first parameter type** of each public
-  method. Method name is for readability only. Signature: `Task Method(TEvent @event, EventContext context)`.
-- Reactors *do things* (side effects); they never build read-model state.
-- To write new events, inject `ICommandPipeline` and `Execute` a command — **never** use `IEventLog`
-  directly from a reactor.
-- **Design for idempotency** — a reactor may run more than once (replay/recovery). Use event data
-  directly; never read the read model back inside a reactor. Keep reactors stateless.
-- **Translation** = a reactor that adapts an event by triggering a command in its own slice.
-
-## Specs — BDD with Cratis.Specifications
-
-```csharp
-public class when_registering : Specification
-{
-    RegisterAuthor _command;
-    AuthorRegistered _event;
-
-    void Establish() => _command = new(new AuthorName("John"));
-    void Because() => _event = _command.Handle();
-
-    [Fact] void should_carry_the_name() => _event.Name.Value.ShouldEqual("John");
-}
-```
-
-- Inherit `Specification`. `Establish()` = setup, `Because()` = the **one** action, `[Fact] should_*()`
-  = one assertion each (no blank lines between facts). Fields `private`/`protected`, `_camelCase`.
-- Shared setup → `given/` contexts (`all_dependencies` → `a_<sut>`). Mock with NSubstitute.
-- Folder/file names read as English: `for_<Type>/when_<behavior>/and_<condition>.cs`.
-- Chronicle integration specs live in the slice's `when_<behavior>/` folder and run against a real
-  event store using `Given<context>` + `ChronicleOutOfProcessFixture`; assert with
-  `Context.ShouldHaveAppendedEvent<T>(...)`.
-
-## React (frontend) — only relevant once `dotnet build` has generated proxies
-
-- Import the generated command/query proxy from the slice's `../api/...` path.
-- Commands: `const [command] = MyCommand.use();` → set props → `await command.execute()` →
-  check `result.isSuccess` / `result.response`.
-- Queries: `MyQuery.use()` (snapshot) or `MyQuery.useWithPaging(pageSize)`.
-- Dialogs: `CommandDialog` from `@cratis/components/CommandDialog`, `Dialog` from
-  `@cratis/components/Dialogs`. **Never** import `Dialog` from `primereact/dialog`.
-- PrimeReact CSS variables for colors (no hard-coded hex). No `any` — use `unknown` + type guards.
-  Full descriptive names (`event`, not `e`; `index`, not `idx`).
-
-## Build / test / sequencing
-
-- **`dotnet build`** compiles the backend AND regenerates the TypeScript proxies. The frontend cannot
-  reference a slice's proxy until the backend compiles — so the order is strict:
-  **Backend → `dotnet build` → Frontend.** Backend and frontend of the same slice never run in parallel.
-- Zero warnings, zero errors — warnings are treated as errors.
-- `dotnet test` (filter to the slice while iterating:
-  `dotnet test --filter "FullyQualifiedName~<SliceName>"`).
-- Slice-by-slice order: Backend → Specs → `dotnet build` → Frontend → Composition page → Routes.
-
-## Final verification against `slice.json` (the JSON is the source of truth)
-
-- Every `commands[]` field → a Command record property. No invented fields, none missing.
-- Every event in `events[]` → an `[EventType]` record; names match exactly; no invented fields.
-- Every read model field → a `[ReadModel]` property fed by a projection/reducer mapping.
-- Every specification / GWT scenario in the slice → an executable spec.
-- No business rule appears in `Handle()` that is not in the slice `description`/`comments`.
-- If a field is not in `slice.json`, it is not in the code.

package/stacks/cratis-csharp/templates/.claude/skills/build-automation/SKILL.md

@@ -1,122 +0,0 @@
----
-name: build-automation
-description: >
-  Implement automation and translation slices the Cratis way — an IReactor that observes events and
-  produces side effects, triggering further writes via ICommandPipeline. Use when: (1) implementing a
-  new automation / reactor in a Cratis project, (2) a slice.json has a non-empty processors[] section
-  or sliceType === "TRANSLATION", (3) the user provides an Event Modeling artifact or description of an
-  event-driven reaction and asks to implement it, (4) the user says "implement", "create", "add" an
-  automation, reactor, translation, or event-to-command flow in a Cratis Arc / Chronicle project.
----
-
-# Cratis — Automation / Translation Slice
-
-An automation *reacts* to events and *does things* (side effects). A translation adapts an event by
-triggering a command in its own slice. Both are implemented with an **`IReactor`**.
-
-```
-event  →  IReactor method (dispatch by first param type)  →  side effect / ICommandPipeline.Execute(command)
-```
-
-> **Read first:** [../_shared/cratis-conventions.md](../_shared/cratis-conventions.md). Everything
-> below assumes those rules.
-
-## Step 0 — Discover conventions
-
-Read `.build-kit/CLAUDE.md` and one existing reactor. Confirm the namespace root, how reactors are placed within a
-slice, which services are available for side effects, and how existing translations call
-`ICommandPipeline`. Resolve slice `comments` when done (see the state-change skill's Step 0).
-
-## Step 1 — Understand the input (`slice.json` is the source of truth)
-
-| Element | What to extract |
-|---|---|
-| **Trigger event(s)** | Which event(s) the reactor observes (the method's first parameter type) |
-| **Reaction** | The side effect — notify, call a service, or trigger a command |
-| **Target command** | For translation: which command to `Execute`, and how its fields map from the event |
-| **Idempotency** | The reaction must be safe to run more than once (replay/recovery) |
-| **Specifications** | Each scenario → an executable spec |
-| **Storylines** (optional) | `storylines[]` — ordered walkthrough "beats"; an event-triggering-this-reactor transition is a supplementary spec source, see Step 4a |
-
-If a command field has no source in the trigger event or an injected service, do not invent it.
-
-## Step 2 — Write the reactor in the slice `.cs` file
-
-`<Module>/<Feature>/<Slice>/<Slice>.cs` — namespace `<Root>.<Module>.<Feature>.<Slice>` (mirror the folders; drop any `.Features.`).
-
-### Automation — side effect
-```csharp
-public class ProjectRegisteredNotifier(INotificationService notifications) : IReactor
-{
-    public async Task ProjectRegistered(ProjectRegistered @event, EventContext context) =>
-        await notifications.Notify($"Project '{@event.Name}' was registered.");
-}
-```
-
-### Translation — event → command via ICommandPipeline
-```csharp
-public class StockKeeping(IStockKeeper stock, ICommandPipeline commands) : IReactor
-{
-    public async Task BookReserved(BookReserved @event, EventContext context) =>
-        await commands.Execute(new DecreaseStock(@event.Isbn, await stock.GetStock(@event.Isbn)));
-}
-```
-
-**Critical rules:**
-- `IReactor` is a **marker interface** — dispatch is by the **first parameter type**. Method name is
-  for readability only. Signature: `Task Method(TEvent @event, EventContext context)` (`EventContext`
-  optional).
-- To write new events, inject `ICommandPipeline` and `Execute` a command — **never** use `IEventLog`
-  directly from a reactor.
-- **Design for idempotency** — a reactor may run more than once. Use event data directly; never query
-  the read model back inside a reactor. Keep the reactor stateless (constructor-injected deps only).
-- One focused concern per reactor class; multiple handler methods are fine if they serve that concern.
-
-If the translation's target command doesn't exist yet, implement it first with the
-**build-state-change** skill, then reference it here.
-
-## Step 3 — Build
-
-`dotnet build` from the project root — zero warnings / errors.
-
-## Step 4 — Specs
-
-Write specs proving the reactor reacts correctly — for translations, assert the expected command was
-executed (mock `ICommandPipeline` with NSubstitute and verify `Execute` was called with the mapped
-command); for automations, assert the side-effect service was invoked. Cover idempotency where the
-slice calls for it. One spec per scenario. Run `dotnet test --filter "FullyQualifiedName~<SliceName>"`.
-See [references/patterns.md](references/patterns.md).
-
-## Step 4a — Storyline-derived specs (optional)
-
-If `storylines[]` is non-empty — a storyline embedded in this slice's slice.json already belongs
-entirely to this slice, no need to match beats against `events[]`/`commands[]` by id/title — look
-for an `EVENT → (COMMAND | EVENT)` transition: a trigger event beat, followed by the command it
-triggers (translation) or a further event/side-effect signal (automation).
-
-- **Establish** — append the trigger event (and any preceding events in the storyline needed to
-  reach it).
-- **Because** — invoke/replay the reactor.
-- **should_\*** — for a translation, assert `ICommandPipeline.Execute` was called with the mapped
-  command from the beat's `fields`; for a plain automation, assert the mocked side-effect service
-  was invoked.
-
-If the storyline continues past the triggered command into that command's own event, or into a
-read model, those halves belong to **build-state-change** / **build-state-view** respectively — a
-reactor spec only covers the event-in → reaction-out step.
-
-Skip silently when the beat sequence can't be isolated (e.g. no traceable trigger event).
-
-## Final verification — does the implementation match `slice.json`?
-
-- [ ] The reactor observes exactly the trigger event(s) named in the slice.
-- [ ] For translation: the executed command and its field mapping match the slice; the command exists.
-- [ ] No new events written via `IEventLog` — only via `ICommandPipeline`.
-- [ ] The reaction is idempotent; the reactor is stateless.
-- [ ] Every scenario → an executable spec; `dotnet build` clean; specs pass.
-- [ ] A `storylines[]` transition triggering this reactor has a spec, or was deliberately skipped
-      (not silently ignored).
-
-## References
-- [references/patterns.md](references/patterns.md) — full reactor/translation code and reactor specs.
-- [../_shared/cratis-conventions.md](../_shared/cratis-conventions.md) — the Cratis conventions.

package/stacks/cratis-csharp/templates/.claude/skills/build-automation/references/patterns.md

@@ -1,115 +0,0 @@
-# Automation / Translation Patterns — Cratis Arc + Chronicle
-
-Complete code for automation and translation slices. The reactor lives in the slice's single
-`<Module>/<Feature>/<Slice>/<Slice>.cs` (the shipped starter uses `SomeModule/SomeFeature/...` — match
-whatever the existing slices use). The example slices use no file header (match the project); namespace
-mirrors the folders and drops any `.Features.`. Examples below use short illustrative names; mirror your
-project's actual module/feature layout instead.
-
----
-
-## 1. Automation — react with a side effect
-
-```csharp
-// Features/Projects/RegistrationNotifications/RegistrationNotifications.cs
-namespace MyApp.Projects.RegistrationNotifications;
-
-using Cratis.Chronicle.Events;
-using Cratis.Chronicle.Reactors;
-
-public class ProjectRegisteredNotifier(INotificationService notifications) : IReactor
-{
-    /// <summary>Sends a notification when a project is registered.</summary>
-    public async Task ProjectRegistered(ProjectRegistered @event, EventContext context) =>
-        await notifications.Notify($"Project '{@event.Name}' was registered.");
-}
-```
-
----
-
-## 2. Translation — event → command via ICommandPipeline
-
-```csharp
-// Features/Inventory/StockKeeping/StockKeeping.cs
-namespace MyApp.Inventory.StockKeeping;
-
-using Cratis.Arc.Commands;
-using Cratis.Chronicle.Events;
-using Cratis.Chronicle.Reactors;
-
-public class StockKeeping(IStockKeeper stock, ICommandPipeline commands) : IReactor
-{
-    /// <summary>Decreases stock when a book is reserved.</summary>
-    public async Task BookReserved(BookReserved @event, EventContext context) =>
-        await commands.Execute(new DecreaseStock(@event.Isbn, await stock.GetStock(@event.Isbn)));
-}
-```
-
-The `DecreaseStock` command lives in its own slice (build it with the build-state-change skill first if
-it doesn't exist). The reactor only triggers it.
-
----
-
-## 3. Multiple handlers in one reactor (same concern)
-
-```csharp
-public class OrderFulfillment(ICommandPipeline commands) : IReactor
-{
-    public Task OrderPlaced(OrderPlaced @event, EventContext context) =>
-        commands.Execute(new ReserveInventory(@event.OrderId, @event.Items));
-
-    public Task PaymentCaptured(PaymentCaptured @event, EventContext context) =>
-        commands.Execute(new ShipOrder(@event.OrderId));
-}
-```
-
----
-
-## 4. Idempotency
-
-A reactor may be invoked more than once for the same event (replay, recovery, redelivery). Use only the
-event's own data, keep the reactor stateless, and make the triggered command/side effect safe to repeat
-(e.g. the target command is itself idempotent, or carries a key that de-duplicates). Never read the read
-model back inside the reactor to "check if already done".
-
----
-
-## 5. Reactor spec (translation — assert the command was executed)
-
-```csharp
-namespace MyApp.Inventory.StockKeeping.for_StockKeeping.when_a_book_is_reserved;
-
-public class and_stock_is_available : Specification
-{
-    IStockKeeper _stock;
-    ICommandPipeline _commands;
-    StockKeeping _reactor;
-
-    void Establish()
-    {
-        _stock = Substitute.For<IStockKeeper>();
-        _stock.GetStock("123").Returns(Task.FromResult(5));
-        _commands = Substitute.For<ICommandPipeline>();
-        _reactor = new StockKeeping(_stock, _commands);
-    }
-
-    async Task Because() => await _reactor.BookReserved(new BookReserved("123"), EventContext.Empty);
-
-    [Fact] void should_decrease_stock() =>
-        _commands.Received(1).Execute(Arg.Is<DecreaseStock>(c => c.Isbn == "123" && c.Quantity == 5));
-}
-```
-
-For automations, mock the side-effect service (e.g. `INotificationService`) and assert it was called.
-Match the project's existing reactor-spec harness (`IReactorInvoker` / `ReactorHandler`) for full
-event-store-driven specs — discover it from an existing reactor's specs.
-
----
-
-## Checklist
-
-- One `.cs` file, namespace without `.Features.` (no file header unless the project uses one).
-- `IReactor` marker; dispatch by **first parameter type**; `Task Method(TEvent, EventContext)`.
-- New writes only via `ICommandPipeline.Execute(...)` — never `IEventLog` from a reactor.
-- Stateless and idempotent; constructor-injected dependencies only.
-- One spec per scenario; `dotnet build` clean; specs pass.