@cratis/pi 0.0.1

package/skills/cratis-chronicle-event-constraints/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: cratis-chronicle-event-constraints
+description: Enforce append-time uniqueness in Chronicle with the [Unique] attribute, [RemoveConstraint], and IConstraint, and specify the violation with EventScenario. Use when a rule must hold at the event store rather than in a command, so two concurrent appends cannot both win. Do not use for ordinary command input validation and do not use to create a projection.
+license: MIT
+---
+
+# Chronicle event constraints
+
+A constraint is an **append-time** invariant. Chronicle evaluates it inside the
+append, against the event store's own index — so it is the only mechanism that
+holds when two requests race. A command-side pre-check reads state that may
+already be stale by the time the append lands; a constraint cannot be.
+
+Constraints are discovered automatically. There is no registration call.
+
+## Verified product sources
+
+| Package | Version | Purpose |
+| --- | --- | --- |
+| `Cratis.Chronicle` (client) | `16.45.2` | `[Unique]`, `[RemoveConstraint]`, `IConstraint`, `IConstraintBuilder`, `IUniqueConstraintBuilder`, `ConstraintViolation`, `IAppendResult` |
+| `Cratis.Chronicle` code analysis | `16.45.2` | `CHR0017`, `CHR0018`, `CHR0020` |
+| `Cratis.Chronicle.Testing` | `16.45.2` | `EventScenario` and the `IAppendResult` `Should*` assertions |
+
+Reverify against the Chronicle repository before claiming support for another
+version. Never translate an attribute argument order or an assertion name from
+memory.
+
+## Route near misses
+
+- The rule rejects **command input** — a range, a format, a cross-field
+  condition: use `cratis-arc-command-validation`.
+- The rule is state-dependent and belongs in the handler under concurrency (the
+  DCB pattern): also `cratis-arc-command-validation`.
+- You are creating or changing a read model that the rule reads: use
+  `cratis-chronicle-read-model`.
+- You are writing the specification and want the `EventScenario` mechanics in
+  depth: use `cratis-chronicle-event-specifications`.
+
+## Step 1 — Pick the mechanism
+
+| Situation | Use |
+| --- | --- |
+| One event of this type per event source | class-level `[Unique]` on the event type |
+| A property value unique across event sources | property-level `[Unique]` on that property |
+| Release a claimed value when something is removed | `[RemoveConstraint("name")]` on the removal event |
+| The same value must be unique across **several** event types | `IConstraint` with one `[Unique(name: …)]` name, or a fluent `Unique(…)` |
+| Case-insensitive matching, composite keys, or a scoped constraint | `IConstraint` |
+
+**Per-event-source versus across-event-sources is the constraint *kind*, not a
+setting.** Class-level `[Unique]` (and the generic `Unique<TEvent>()` builder
+call) means "at most one such event per event source id". Property-level
+`[Unique]` (and `Unique(unique => unique.On<T>(…))`) means "this value is unique
+across event sources". Choosing the wrong one gives a constraint that never
+fires rather than a compile error.
+
+## Step 2 — `[Unique]` — the default
+
+```csharp
+// Event-type uniqueness — only one of this event per event source
+[EventType]
+[Unique(message: "A project with this name already exists.")]
+public record ProjectRegistered(ProjectName Name);
+
+// Property uniqueness — the value must be unique across event sources
+[EventType]
+public record UserRegistered([Unique(name: "UniqueEmail", message: "Email already registered.")] EmailAddress Email, DisplayName Name);
+
+// Release a claimed value on removal — the name must match the [Unique] name exactly
+[EventType]
+[RemoveConstraint("UniqueEmail")]
+public record UserRemoved;
+```
+
+- `UniqueAttribute`'s constructor is `(string? name = default, string? message = default)` —
+  **name first, message second**. Pass them by name, as above, so a future
+  reader cannot misread the order.
+- The attribute targets `Class | Property`, `AllowMultiple = false`.
+- **The name defaults to the member or type name** when omitted. Give it an
+  explicit name whenever a removal event or another event type has to refer to
+  it, because the string in `[RemoveConstraint]` must match exactly.
+- `RemoveConstraintAttribute` is class-only with `AllowMultiple = true`. Stack
+  several on one removal event to release several claimed values at once.
+- To enforce the same property across **multiple** event types, give each its
+  `[Unique(name: "UniqueEmail")]` with the **same name**.
+- Several removal events may declare the same name; **any one of them releases
+  the claim on its own**.
+
+## Step 3 — `IConstraint` — the advanced form
+
+Reach for `IConstraint` when uniqueness spans event types with different
+property names, needs `.IgnoreCasing()`, covers a composite of properties, or a
+`RemovedWith` event must release it.
+
+```csharp
+public class UniqueProjectName : IConstraint
+{
+    public void Define(IConstraintBuilder builder) =>
+        builder.Unique(unique =>
+            unique
+                .On<ProjectRegistered>(e => e.Name)
+                .IgnoreCasing()                    // case-insensitive — do NOT lowercase inside the lambda
+                .RemovedWith<ProjectRemoved>());   // omit if there is no remove event
+}
+```
+
+`IUniqueConstraintBuilder` also carries `WithName(name)`, `WithMessage(message)`,
+and an `On(EventType, string[])` overload. `On<TEvent>` is **variadic** —
+`On<T>(e => e.Tenant, e => e.Email)` constrains the composite of both
+properties, not two independent values.
+
+`IConstraintBuilder` additionally offers `PerEventSourceType()`,
+`PerEventStreamType()`, and `PerEventStreamId()` to narrow the scope a
+uniqueness claim is keyed by, and a `Unique<TEvent>(message, name)` overload for
+event-type uniqueness. **That overload takes the message first and the name
+second** — the reverse of the `[Unique]` attribute. Both parameters convert
+implicitly from `string`, so the wrong order compiles and silently swaps them.
+Always pass them by name.
+
+`ConstraintScope` is a record of three optional dimensions, not an enum, and you
+never construct it — the three `Per…` calls select which dimensions participate.
+
+## Step 4 — Keep `Define` declarative
+
+`Define` builds a rule; it never runs one. Three analyzers enforce that, all at
+error severity:
+
+| Id | Rejects |
+| --- | --- |
+| `CHR0017` | Injecting `IEventLog` or `ICommandPipeline` into a constraint |
+| `CHR0018` | An imperative statement in `Define` — `if`, loops, `switch`, `return`, `throw`, a local declaration, an assignment |
+| `CHR0020` | An expression lambda that is not a pure member-access chain |
+
+`CHR0020` is the one that bites: `e => e.Email.ToLower()` is a method call, so
+it is rejected. Use `.IgnoreCasing()` instead. Suppressing the analyzer does not
+make it work — the runtime path extracts an **empty** property path from a
+method call and then fails at startup with `PropertyDoesNotExistOnEventType`,
+which is a much harder failure to read.
+
+## Step 5 — Treat a violation as a result, never as an exception
+
+A violated constraint comes back on the append result, not as a throw. On
+`IAppendResult`: `IsSuccess`, `HasConstraintViolations`,
+`HasConcurrencyViolations`, `HasErrors`, `ConstraintViolations`, and `Errors`.
+Each `ConstraintViolation` carries `ConstraintName`, `ConstraintType`,
+`Message`, `Details`, the `EventTypeId` and the `SequenceNumber`. Arc surfaces
+it as a validation error on the command result.
+
+Note the asymmetry: `AppendResult` exposes a singular nullable
+`ConcurrencyViolation`, while `AppendManyResult` exposes a plural
+`ConcurrencyViolations`. Only the `HasConcurrencyViolations` flag is on the
+interface.
+
+⚠️ A `[PII]` property's value is encrypted before the constraint index sees it,
+so the claimed value and the violation details hold the encrypted form.
+Uniqueness still works; a human reading the index will not see the plaintext.
+
+## Step 6 — Specify the violation
+
+Specify the constraint with `EventScenario`: seed the conflicting state through
+`Given`, append again, and assert
+`ShouldHaveConstraintViolationFor(<Module>ConstraintNames.UniqueX)` — **the
+constraint name, never the message**. A message is presentation text and will
+change without the behavior changing.
+
+```csharp
+#if DEBUG
+public class and_the_name_already_exists : Specification
+{
+    EventScenario _scenario;
+    IAppendResult _result;
+
+    async Task Establish()
+    {
+        _scenario = new EventScenario();
+        await _scenario.Given
+            .ForEventSource(ProjectId.New())
+            .Events(new ProjectRegistered("Acme"));
+    }
+
+    async Task Because() =>
+        _result = await _scenario.EventLog.Append(ProjectId.New(), new ProjectRegistered("Acme"));
+
+    [Fact] void should_be_failed() => _result.ShouldBeFailed();
+    [Fact] void should_have_constraint_violation_for_unique_name() =>
+        _result.ShouldHaveConstraintViolationFor(ProjectConstraintNames.UniqueProjectName);
+}
+#endif
+```
+
+Use per-test unique values (`$"{Guid.NewGuid():N}"`) so specifications are not
+order-dependent. For a release, append the removal event and then assert the
+value can be claimed again.
+
+⚠️ **`EventScenario` disables concurrency checking.** It wires a no-op
+concurrency-scope strategy, so `ShouldHaveConcurrencyViolations()` can never
+become true through the in-process scenario. Constraint violations are fully
+exercisable there; concurrency violations need the real kernel.
+
+## What breaks
+
+- **The constraint never fires.** You used class-level `[Unique]` for a value
+  that has to be unique across event sources, or property-level `[Unique]` for
+  a "one per event source" rule. Re-read Step 1 — the kind is the switch.
+- **`[RemoveConstraint]` releases nothing.** The string does not match the
+  `[Unique]` name. When `[Unique]` had no explicit name the real name is the
+  member or type name, which is easy to get wrong; name it explicitly.
+- **`PropertyDoesNotExistOnEventType` at startup.** A non-member-access lambda
+  reached the builder — the `CHR0020` case with the analyzer suppressed.
+- **`MissingNameForUniqueConstraint` / `NoEventTypesAddedToUniqueConstraint`.**
+  The fluent builder was built without a name, or without any `On` call.
+- **`NoUniqueEventTypeConstraintToRemove`.** `IConstraintBuilder.RemovedWith<T>()`
+  was called with no preceding `Unique<TEvent>()`. That method attaches to the
+  last event-type constraint; the fluent one on `IUniqueConstraintBuilder` is a
+  different method.
+
+## Verify
+
+- Every constraint is discovered without a registration call.
+- `[Unique]` arguments are passed by name, and every name a removal event refers
+  to is explicit rather than defaulted.
+- `Define` contains no imperative statement, no injected effect dependency, and
+  no lambda that is not a pure member-access chain — `CHR0017`, `CHR0018` and
+  `CHR0020` are all clean.
+- Every constraint has an `EventScenario` specification that seeds the conflict
+  and asserts `ShouldHaveConstraintViolationFor(<name>)` on the name.
+- No specification asserts on a violation message string.
+- Build clean in Debug and Release, and the specifications pass.

package/skills/cratis-chronicle-event-modeling/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the project root for full license information.

package/skills/cratis-chronicle-event-modeling/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: cratis-chronicle-event-modeling
+description: Design a Chronicle event model before writing code - stream boundaries and event-source identities, commands, past-tense events, read models, automations and translations, compliance subjects, and the specification outline. Use when behavior, event vocabulary, stream boundaries, or a multi-slice flow is not yet settled. Do not use to draw or update an existing model diagram, and do not use for a mechanical change to a flow that is already decided.
+license: MIT
+---
+
+# Chronicle event modeling
+
+Use this **before writing code**, when behavior, event vocabulary, stream
+boundaries, or a multi-step flow is not already settled. The output is an
+implementation brief: which commands exist, which stream each event lands on,
+which read models consume those events, which automations and translations react,
+and which specifications prove the flow.
+
+Skip it for a mechanical change where the event types and the flow already exist
+and the request is wiring or a narrow fix.
+
+> **Lineage.** The four behavior types and the given/when/then-per-behavior
+> discipline follow **Event Modeling** (Adam Dymitruk; Martin Dilger,
+> *Understanding Eventsourcing*). This skill applies that method to Chronicle.
+
+## Verified product sources
+
+This skill is verified against these exact sources:
+
+| Package | Version | Purpose |
+| --- | --- | --- |
+| `Cratis.Chronicle` | `16.45.2` | event types, event-source identities, subjects, `[PII]` |
+| `Cratis.Chronicle.CodeAnalysis` | `16.45.2` | `CHR0012`, `CHR0026`, `CHR0034`, `CHR0035` |
+
+Reverify product sources before claiming support for another version.
+
+## The four behavior types
+
+Classify every behavior in the model as exactly one:
+
+| Type | What it does | Built from |
+| --- | --- | --- |
+| **State change** | accepts a command, appends events | command, validation, events |
+| **State view** | projects events into a queryable read model | read model plus a projection or a reducer |
+| **Automation** | reacts to events and causes an external side effect | a reactor |
+| **Translation** | reacts to events and appends follow-up events elsewhere | a reactor |
+
+Automation and translation differ in the *result*: an automation reaches out of
+the system, a translation stays inside it and produces new facts.
+
+## Decide before implementing
+
+- **Behavior name and type** for each step in the flow.
+- **Commands** — their inputs and the authorization that gates them. Commands
+  are imperative intents.
+- **Events** — past-tense, one-purpose facts. Names must be self-describing:
+  `<Entity><PastTenseVerb>`, never a bare `Created`.
+- **The event-source id for every event.** Events never carry their own
+  event-source id as a payload property; it lives in the event context. Deciding
+  the id *is* deciding the stream boundary.
+- **Event properties are non-nullable.** Analyzer `CHR0012` warns otherwise.
+  Model an optional fact as a separate event, not a nullable field.
+- **Read models** — their consumers and their source events, and whether the
+  model is projection-backed, reducer-backed, or `[Passive]` for a
+  strongly-consistent command-side decision.
+- **Automations and translations** — which events they react to, whether they
+  emit follow-up events or run commands, and which side effects must not repeat.
+- **Specifications** — the happy path, the validation failures, the constraints,
+  the projections and reducers, and the reactor side effects.
+
+Do not append an event for derived or aggregate state. Project it from the source
+events instead; an event that records a total is a fact that can disagree with
+its own inputs.
+
+## Information completeness — trace every field to an event
+
+This is the check that pays for itself, and it belongs at modeling time rather
+than after the projection misbehaves.
+
+- **Backward:** for each read model, walk every property back to the event that
+  carries it. A field with no source event is a **missing event or command** —
+  not a nullable column. Resolve it in the model.
+- **Forward:** every event you define should feed at least one read model,
+  automation, or translation. An event nothing consumes is a smell: either a
+  consumer is missing or the event should not exist.
+
+If a field can only be filled by reaching into another behavior's read model,
+you have found a missing event or a wrong stream boundary. Fix the model; do not
+cross-read at runtime.
+
+## Compliance modeling
+
+Decide this *before* choosing event and read-model shapes, because erasure
+operates on the subject and the subject follows the stream.
+
+- Prefer **one subject per event stream** for person-level personal data. The
+  subject then defaults correctly to the event-source id and needs no attribute.
+- Mark inherently personal values with `[PII]` — names, email addresses, phone
+  numbers, identity-provider subjects, personal notes. Leave business metadata
+  unmarked; every marked value becomes unreadable once the subject is erased.
+- Record the rationale with `[ComplianceDetails("...")]`. A string argument
+  passed to `[PII]` is **not** read by Chronicle.
+- Set `[Subject]` only when the person is not the event source. A stored
+  read-model document carries one subject — do not mix several people's personal
+  data into one document.
+- Never place `[PII]` on an event-source id: Chronicle cannot encrypt it, and
+  analyzer `CHR0034` rejects it. When the natural identifier is itself
+  sensitive, model a surrogate stream id and carry the sensitive value as a
+  `[PII]` property.
+- Do not place `[Key]` or `[Subject]` on an `EventSourceId<T>` value — it is
+  already both, and analyzer `CHR0026` says so.
+- Bearer tokens, magic links, and signed URLs are not durable facts. Model a
+  keyed hash or an opaque reference, never the secret. Chronicle has no attribute
+  that withholds a value from the log.
+
+If a subject boundary cannot be made person-level without changing product
+behavior, **stop and surface that trade-off** before implementing.
+
+## Output shape
+
+Write the brief in this order:
+
+1. stream boundaries and subjects
+2. commands and events
+3. read models and their consumers
+4. automations and translations
+5. compliance notes
+6. specifications
+
+## The lifecycle: draft, ready, working, done
+
+The behavior is the unit of work, and it moves through four states. The model —
+events, commands, read models, screens, specifications — lives inside it, and
+anyone may author or update it.
+
+- **Draft** — being modeled; events, commands, read models, and boundaries are
+  still in flux.
+- **Ready** — the handoff gate. The model is *information-complete*: the checks
+  above pass, and commands, authorization, compliance, and the specification
+  outline are all decided. A ready behavior can be implemented with **no further
+  modeling decisions**.
+- **Working** — an implementer has picked it up and is running the
+  implementation workflow end to end.
+- **Done** — every quality gate is green.
+
+**Marking a behavior ready is the signal to implement it.** Do not batch ready
+items behind one another. Branching, pull requests, merging, and publication
+remain separately authorized; a ready model authorizes none of them.
+
+## Verify the brief before handing it over
+
+- Every behavior has exactly one type.
+- Every event is past-tense, self-describing, single-purpose, and non-nullable.
+- Every event has a decided event-source id, and none carries that id as a
+  property.
+- Every read-model field traces back to an event.
+- Every event has at least one consumer.
+- No behavior depends on reading another behavior's read model at runtime.
+- Personal data has a decided subject, and the subject is person-level or the
+  trade-off is surfaced.
+- The specification outline names the failures, not only the happy path.

package/skills/cratis-chronicle-event-specifications/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the project root for full license information.

package/skills/cratis-chronicle-event-specifications/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: cratis-chronicle-event-specifications
+description: Specify event-append behavior with EventScenario from Cratis.Chronicle.Testing — seeding prior events through Given, appending through When or the event log, and asserting on the append result including constraint violations. Use when the behavior under specification is what reaches the event store. Do not use for command handling or for read-model projection behavior.
+license: MIT
+---
+
+# Chronicle event specifications
+
+`EventScenario` runs the append path in-process. No Chronicle server, no
+database, no network — an empty event log at sequence number zero, with the
+application's constraints discovered and active.
+
+## Verified product sources
+
+| Package | Version | Purpose |
+| --- | --- | --- |
+| `Cratis.Chronicle.Testing` | `16.45.2` | `EventScenario`, its `Given`/`When` builders, the `IAppendResult` `Should*` assertions |
+| `Cratis.Chronicle` | `16.45.2` | `IEventSequence.Append`/`AppendMany`, `IAppendResult`, `ConstraintViolation` |
+
+```bash
+dotnet add package Cratis.Chronicle.Testing
+```
+
+Reverify against the Chronicle repository before claiming support for another
+version. Never translate an assertion name from memory.
+
+## Route near misses
+
+- The behavior is a command running through validators, `Provide()` and
+  `Handle()`: use `cratis-application-slice-specifications`.
+- The behavior is a projection or reducer building a read model: use
+  `cratis-chronicle-read-model-specifications`.
+- You are deciding what the constraint should *be*: use
+  `cratis-chronicle-event-constraints`.
+- The specification style itself — folder shape, naming, what not to specify:
+  use `cratis-specification-by-example`.
+
+## When you need this
+
+- A constraint must reject a duplicate or conflicting append.
+- A batch append (`AppendMany`) must behave as one unit.
+- The event log's own behavior is the subject, not the command that reached it.
+
+## When you do not
+
+- **Concurrency violations cannot be provoked here.** `EventScenario` wires a
+  no-op concurrency-scope strategy, so `HasConcurrencyViolations` is never true
+  inside the scenario however the append is shaped. Specify concurrency against
+  the real kernel with an out-of-process integration specification, and do not
+  write a scenario specification that looks like it covers it — it would pass
+  vacuously, which is worse than not having one.
+
+## Step 1 — Create the scenario
+
+A new `EventScenario` per specification, never shared state.
+
+```csharp
+var scenario = new EventScenario();
+```
+
+The parameterless constructor uses the default event log, an in-memory event
+store, the `default` namespace, and **auto-discovers the constraints** declared
+in the loaded assemblies — which is what makes a constraint specification work
+without wiring. Pass an `ICanProvideConstraints` to the single-argument
+constructor when the specification needs a narrower set.
+
+## Step 2 — Seed prior state through `Given`
+
+```csharp
+await scenario.Given
+    .ForEventSource(authorId)
+    .Events(new AuthorRegistered("Jane Smith"), new BookAdded("Clean Code"));
+```
+
+Chain a second `ForEventSource` for a different event source:
+
+```csharp
+await scenario.Given.ForEventSource(author1Id).Events(new AuthorRegistered("Jane Smith"));
+await scenario.Given.ForEventSource(author2Id).Events(new AuthorRegistered("John Doe"));
+```
+
+- `Given` returns a bare `Task` — it carries no result, because seeding is not
+  the action under specification.
+- Seed **before** the act phase; seeded events take monotonically increasing
+  sequence numbers.
+- Never put the act under test inside `Given`. Only the world as it already is
+  belongs there.
+
+## Step 3 — Append, and hold the result
+
+Two equivalent surfaces. `When` reads as the act phase; the event log is the
+direct one.
+
+```csharp
+// The act-phase builder — returns Task<AppendResult>
+_result = await scenario.When
+    .ForEventSource(authorId)
+    .Events(new AuthorRegistered("Jane Smith"));
+
+// The event log directly
+_result = await scenario.EventLog.Append(authorId, new AuthorRegistered("Jane Smith"));
+```
+
+`When…Events(@event, params object[] additionalEvents)` takes the first event
+positionally and **stops at the first non-successful append**, so a specification
+that appends several events asserts on the first failure rather than the last.
+
+`AppendMany` on the event log appends a batch for one event source:
+
+```csharp
+_result = await scenario.EventLog.AppendMany(cartId, [
+    new ItemAddedToCart(itemId1),
+    new ItemAddedToCart(itemId2)
+]);
+```
+
+`Append` and `AppendMany` are members of the event sequence reached through
+`scenario.EventLog`, not of `EventScenario` itself.
+
+## Step 4 — Assert on the result
+
+Every assertion below is an extension on `IAppendResult` and throws
+`AppendResultAssertionException` on failure, with a message listing the
+violations and errors it found.
+
+| Method | Asserts |
+| --- | --- |
+| `ShouldBeSuccessful()` | No violation and no error |
+| `ShouldBeFailed()` | Any violation or error |
+| `ShouldHaveConstraintViolations()` | At least one constraint violation |
+| `ShouldNotHaveConstraintViolations()` | No constraint violation |
+| `ShouldHaveConstraintViolationFor(name)` | A violation for the named constraint |
+| `ShouldHaveConstraintViolation(name)` | The same assertion, singular spelling |
+| `ShouldHaveErrors()` | At least one error |
+| `ShouldNotHaveErrors()` | No error |
+
+`ShouldHaveConcurrencyViolations()` and `ShouldNotHaveConcurrencyViolations()`
+also exist, but see *When you do not* above — the first can never pass inside a
+scenario and the second passes vacuously.
+
+The constraint name parameter is a `ConstraintName`, which converts implicitly
+from `string`, so a literal compiles. Prefer a shared constant
+(`<Module>ConstraintNames.UniqueX`) so a rename moves both sides at once.
+**Assert the name, never the message.**
+
+## Step 5 — Write the specification
+
+Specification files live in the slice folder, wrapped in `#if DEBUG … #endif` so
+specification code ships only in Debug.
+
+```csharp
+#if DEBUG
+namespace MyApp.Library.Authors.when_registering;
+
+public class and_the_name_already_exists : Specification
+{
+    EventScenario _scenario;
+    IAppendResult _result;
+
+    async Task Establish()
+    {
+        _scenario = new EventScenario();
+        await _scenario.Given
+            .ForEventSource(AuthorId.New())
+            .Events(new AuthorRegistered("Jane Smith"));
+    }
+
+    async Task Because() =>
+        _result = await _scenario.EventLog.Append(AuthorId.New(), new AuthorRegistered("Jane Smith"));
+
+    [Fact] void should_be_failed() => _result.ShouldBeFailed();
+    [Fact] void should_have_constraint_violation_for_unique_name() =>
+        _result.ShouldHaveConstraintViolationFor(AuthorConstraintNames.UniqueAuthorName);
+}
+#endif
+```
+
+Use per-specification unique values (`$"{Guid.NewGuid():N}"`) so the suite does
+not depend on execution order. For a release, append the removal event and then
+assert the value can be claimed again.
+
+## What breaks
+
+- **The duplicate append succeeds.** The constraint was not discovered — the
+  scenario was given an explicit constraint provider that excludes it, or the
+  constraint type is not in a loaded assembly.
+- **`ShouldHaveConstraintViolationFor` fails with an empty violation list on a
+  batch append.** `When…Events` short-circuits, so the conflict may be on an
+  event the append never reached.
+- **A concurrency specification is always green.** It is vacuous — the scenario
+  disables the check. Delete it or move it out-of-process.
+- **The specification passes alone and fails in the suite.** A hard-coded unique
+  value collided with another specification's claim.
+
+## How it is proven
+
+`dotnet build` in Debug (which compiles the `#if DEBUG` specification code) and
+`dotnet test`, both clean. A constraint specification is only meaningful if it
+has been seen to fail: remove the seeding `Given` once and confirm the
+specification goes red before trusting it green.

package/skills/cratis-chronicle-event-type-migration/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the project root for full license information.