@cratis/pi 0.0.1

package/skills/cratis-fundamentals-concept/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: cratis-fundamentals-concept
+description: Create strongly typed Cratis domain values with ConceptAs<T> and Chronicle event-source identities with EventSourceId<T>. Use when a C# domain value has meaning beyond its primitive or when an identity is actually used as a Chronicle event-source/stream ID. Do not use for enums, DTO-only transport values, arbitrary non-stream entity IDs, or event schema migration.
+license: MIT
+---
+
+# Cratis domain concepts and event-source identities
+
+Replace a primitive only when the domain gives it distinct meaning. Keep value
+concepts and Chronicle stream identities separate.
+
+## Verified product sources
+
+This skill is verified against these exact public releases:
+
+| Package | Version | Purpose |
+| --- | --- | --- |
+| `Cratis.Fundamentals` | `7.18.1` | `Cratis.Concepts.ConceptAs<T>` |
+| `Cratis.Chronicle` | `16.38.1` | `Cratis.Chronicle.Events.EventSourceId` and `EventSourceId<T>` |
+
+Reverify product sources before claiming support for another version.
+
+## Choose the type
+
+- Derive a name, amount, code, number, or non-stream entity ID from
+  `ConceptAs<T>`.
+- Derive an identity from `EventSourceId<T>` only when that value is actually
+  passed to Chronicle as the event-source/stream ID.
+- Do not use `ConceptAs<Guid>` for a Chronicle stream identity.
+- Do not use `EventSourceId<T>` merely because a value is called an ID.
+- Do not wrap an enum. An enum already expresses a closed domain concept.
+- Keep DTO-only transport values primitive unless the domain type belongs in the
+  public contract.
+
+Both generic bases require an underlying type that implements `IComparable`.
+
+## Create a value concept
+
+A value concept contains exactly one wrapped value. Do not add extra properties;
+Fundamentals converters assume the concept is a single-value type and additional
+state can be lost during serialization.
+
+```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 <description>.
+/// </summary>
+/// <param name="Value">The underlying value.</param>
+public record <ConceptName>(<ComparableUnderlyingType> Value) :
+    ConceptAs<<ComparableUnderlyingType>>(Value);
+```
+
+`ConceptAs<T>` supplies implicit conversion from the concept to `T`. Add the
+reverse conversion only when it improves the domain API:
+
+```csharp
+public static implicit operator <ConceptName>(<ComparableUnderlyingType> value) =>
+    new(value);
+```
+
+Primitive-to-concept conversion is optional; it is not a Fundamentals
+requirement.
+
+### Absence and sentinels
+
+`ConceptAs<T>` rejects a null wrapped value. Represent absence with a nullable
+concept reference such as `<ConceptName>?` when absence is valid.
+
+A `NotSet` or `Empty` value is optional domain policy. Add one only when the
+chosen primitive value is impossible or explicitly reserved in that domain.
+Do not assume `string.Empty`, `0`, or `Guid.Empty` is universally invalid.
+
+## Create a Guid-backed Chronicle stream identity
+
+Use this shape only for an identity actually supplied to Chronicle append/read
+operations as the event-source ID.
+
+```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.Chronicle.Events;
+
+namespace <NamespaceRoot>.<Feature>;
+
+/// <summary>
+/// Represents the event-source identity of a <description>.
+/// </summary>
+/// <param name="Value">The underlying Guid value.</param>
+public record <ConceptName>(Guid Value) : EventSourceId<Guid>(Value)
+{
+    /// <summary>
+    /// Creates a new <ConceptName>.
+    /// </summary>
+    /// <returns>A new <ConceptName>.</returns>
+    public static <ConceptName> New() => new(Guid.NewGuid());
+
+    /// <summary>
+    /// Converts a Guid to a <ConceptName>.
+    /// </summary>
+    public static implicit operator <ConceptName>(Guid value) => new(value);
+}
+```
+
+`New()` and the primitive-to-derived conversion are conveniences on this domain
+type. `EventSourceId<T>` does not construct an arbitrary derived identity for
+you.
+
+## Create a non-Guid Chronicle stream identity
+
+Use a factory only when the domain has an authoritative way to create the
+underlying value.
+
+```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.Chronicle.Events;
+
+namespace <NamespaceRoot>.<Feature>;
+
+/// <summary>
+/// Represents the event-source identity of a <description>.
+/// </summary>
+/// <param name="Value">The underlying value.</param>
+public record <ConceptName>(<ComparableUnderlyingType> Value) :
+    EventSourceId<<ComparableUnderlyingType>>(Value)
+{
+    /// <summary>
+    /// Converts the underlying value to a <ConceptName>.
+    /// </summary>
+    public static implicit operator <ConceptName>(<ComparableUnderlyingType> value) =>
+        new(value);
+}
+```
+
+The exact `EventSourceId<T>` base supports conversions among `T`, string,
+untyped `EventSourceId`, and `EventSourceId<T>`. Those operators do not create
+your derived `<ConceptName>` from `T`, string, or untyped `EventSourceId`.
+Declare only the derived-type conversions your domain API needs.
+
+String and Guid are the safest round-trip primitives. Chronicle also supports
+constructible `ConceptAs<string>` and `ConceptAs<Guid>` values. Other comparable
+values rely on `Convert.ChangeType`; verify round-trip behavior before using
+them as stream IDs.
+
+### Unspecified and sensitive identities
+
+`EventSourceId.Unspecified` belongs to the untyped string-backed ID.
+`Guid.Empty`, `0`, `0L`, and similar typed values become real, specified stream
+IDs after conversion; they are not Chronicle's unspecified value. Treat any
+sentinel on a typed identity as explicit domain policy, not framework behavior.
+
+Never use a sensitive natural identifier directly as an event-source ID.
+Chronicle cannot encrypt event-source IDs. Use a random surrogate stream ID and
+store the sensitive value separately under the approved compliance model.
+
+## Use the identity with Chronicle
+
+Pass the typed identity as the append/read event-source ID. Merely declaring an
+`EventSourceId<T>` property does not select the event stream.
+
+Do not add `[Key]` or `[Subject]` to an `EventSourceId<T>`-derived member;
+Chronicle analyzer `CHR0026` reports that misuse. Do not add `[PII]` to an
+event-source ID; analyzer `CHR0034` rejects it.
+
+## Placement is an application convention
+
+In a Cratis application, place the concept with the feature that owns its
+meaning rather than in a generic `Concepts/` folder. Put genuinely cross-feature
+concepts in `Common/`. Do not introduce a top-level `Features/` wrapper.
+
+This placement is a Cratis application convention, not a Fundamentals or
+Chronicle API requirement. Framework and client repositories follow their own
+repository structure.
+
+## Verify
+
+- `ConceptAs<T>` and `EventSourceId<T>` use an `IComparable` underlying type.
+- A concept contains exactly one wrapped value and no extra properties.
+- Enums remain enums.
+- Null absence uses a nullable concept reference rather than a null wrapped
+  value.
+- Primitive-to-derived conversions and sentinels exist only when justified by
+  the domain.
+- An `EventSourceId<T>` type represents a real Chronicle stream identity.
+- The typed identity is passed explicitly to Chronicle operations.
+- No `[Key]`, `[Subject]`, or `[PII]` attribute is placed on the stream identity.
+- Sensitive natural identifiers use a surrogate stream ID.
+- The file carries the repository license header.
+- The project builds and its relevant specifications pass against the verified
+  package versions.

package/skills/cratis-fundamentals-type-discovery/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-fundamentals-type-discovery/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: cratis-fundamentals-type-discovery
+description: Wire a type that must enumerate every implementation of an abstraction by injecting IInstancesOf<T> from Cratis.Types and deleting the hand-maintained service registrations. Use when a handler set, filter chain, strategy set, or dispatcher fans out to all implementations. Do not use for ordinary single-service dependency injection.
+license: MIT
+---
+
+# Cratis implementation discovery
+
+`services.AddSingleton<IFoo, Foo>()` looks free at the registration line. The
+cost arrives later: a new implementation in another folder does nothing until
+someone remembers the line, a removed one leaves a registration that fails at
+startup, and every specification setup has to mirror the composition root.
+
+`IInstancesOf<T>` moves that knowledge into the implementation. Adding or
+removing one becomes a single-file change.
+
+## Verified product sources
+
+| Package | Version | Purpose |
+| --- | --- | --- |
+| `Cratis.Fundamentals` | `7.18.2` | `IInstancesOf<T>`, `IImplementationsOf<T>`, `[Singleton]`, `[Scoped]`, `[IgnoreConvention]`, the convention bindings |
+
+Reverify against the Cratis Fundamentals repository before claiming support for
+another version.
+
+## Route near misses
+
+- The consumer needs **one** implementation chosen at composition time:
+  constructor-inject the interface and let the `IFoo → Foo` convention resolve
+  it. This skill does not apply.
+- The method **returns** a sequence of values to a caller: `IEnumerable<T>` (or
+  `IReadOnlyList<T>`) is still the right return type. The rule is about
+  *injecting* implementations of an abstraction, not about returning values.
+- You only need the **types**, never instances: inject `IImplementationsOf<T>`,
+  which enumerates `Type` rather than `T`.
+
+## When you need this
+
+The consumer of an abstraction has to iterate, filter, or fan out to **every**
+registered implementation:
+
+- Anything plural that delegates to a set — `*Handlers`, `*Filters`,
+  `*Validators`, `*Formatters`, `*Strategies`, `*Providers`, `*Resolvers`.
+- A dispatcher that asks each implementation `CanHandle(...)` and forwards to
+  the one that says yes.
+- A composite that fans one input out to all implementations and aggregates.
+
+## Step 1 — Confirm the implementations are discoverable
+
+`IInstancesOf<T>` finds types by convention across the loaded assemblies. The
+requirements are only:
+
+- Each implementation is a non-abstract `public class`.
+- It implements the interface directly, not through a layer that hides it.
+- `T` is an interface or abstract class — the interface is declared
+  `where T : class`.
+
+No assembly attribute and no registration call is needed.
+
+## Step 2 — Choose the lifetime with an attribute
+
+```csharp
+using Cratis.DependencyInjection;
+
+[Singleton]
+public class CsvReportFormatter(IClock clock) : IReportFormatter
+{
+    public bool CanHandle(ReportRequest request) => request.Format == "csv";
+    public string Format(Report report) => /* … */;
+}
+```
+
+⚠️ `[Singleton]` lives in **`Cratis.DependencyInjection`**, not `Cratis`. That
+is the using directive to add when it does not resolve.
+
+The convention reads exactly three attributes:
+
+| Attribute | Lifetime |
+| --- | --- |
+| `[Singleton]` | Singleton |
+| `[Scoped]` | Scoped |
+| neither | **Transient** |
+
+`[IgnoreConvention]` opts a type out of convention binding entirely.
+
+Skip `[Singleton]` only when the implementation genuinely holds per-call state.
+The `IFoo → Foo` convention still applies to transients — do not register them
+explicitly either.
+
+## Step 3 — Inject `IInstancesOf<T>` in the consumer
+
+```csharp
+using Cratis.DependencyInjection;
+using Cratis.Types;
+
+[Singleton]
+public class ReportFormatters(IInstancesOf<IReportFormatter> formatters) : IReportFormatters
+{
+    public bool CanHandle(ReportRequest request) =>
+        formatters.Any(formatter => formatter.CanHandle(request));
+
+    public string Format(ReportRequest request, Report report) =>
+        formatters.First(formatter => formatter.CanHandle(request)).Format(report);
+}
+```
+
+`IInstancesOf<T>` implements `IEnumerable<T>`, so LINQ works on it directly.
+
+**It resolves an instance from the service provider on every enumeration**, not
+once at construction. That is what makes a scoped or transient implementation
+behave correctly, and it is why materializing with `.ToArray()` is worth doing
+only when you genuinely need a stable snapshot within one operation.
+
+## Step 4 — Delete the dead registrations
+
+Find every line in a composition root or service-collection extension that
+registered the implementations or the consumer, and remove it:
+
+```csharp
+// Delete — IInstancesOf<T> discovers them, [Singleton] gives them their lifetime
+services.AddSingleton<IReportFormatter, CsvReportFormatter>();
+services.AddSingleton<IReportFormatter, JsonReportFormatter>();
+services.AddSingleton<IReportFormatters, ReportFormatters>();
+```
+
+Search for every remaining reference before deleting, so nothing else was
+relying on a registration for a different reason.
+
+## What breaks
+
+- **`[Singleton]` does not resolve.** The using directive is
+  `Cratis.DependencyInjection`, not `Cratis`.
+- **An implementation is silently absent from the set.** Its assembly is not
+  loaded at the point of enumeration, it is not `public`, it is abstract, or it
+  carries `[IgnoreConvention]`.
+- **An implementation is a new instance every time it is touched.** It has no
+  lifetime attribute, so the convention made it transient. That is correct
+  behavior for the convention and usually the wrong intent — add `[Singleton]`.
+- **A stale registration fails at startup.** A hand-written
+  `AddSingleton<TInterface, Impl>()` survived a type being removed. Step 4 is
+  what prevents it.
+- **Injecting `IEnumerable<T>` seems to work and returns nothing.** That
+  signature only sees hand-registered implementations. It is the failure mode
+  this skill exists to remove — it fails silently and empty, not loudly.
+
+## How it is proven
+
+`dotnet build` — zero warnings, zero errors — then run the specifications for
+the affected behavior. The non-vacuity check matters here: assert the **count**
+of discovered implementations, not just that iterating them threw nothing. A
+fan-out over an empty set passes every assertion that only says "nothing went
+wrong".

package/skills/cratis-governed-release-methodology/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-governed-release-methodology/SKILL.md

@@ -0,0 +1,297 @@
+---
+name: cratis-governed-release-methodology
+description: Choose the assurance tier a release needs, gather the evidence that tier requires, label release intent by semantic-version impact, and structure a canary-before-promotion path with an explicit recovery disposition. Use when planning a release or judging whether checksums, provenance, an SBOM, or a claim of support are warranted. Do not use for product code, publish-command syntax, or release credentials.
+license: MIT
+---
+
+# Governed release methodology
+
+Release engineering is the discipline of matching **ceremony to consequence**.
+Too little, and a consumer upgrades into a broken build with no way back. Too
+much, and every documentation fix drags a supply-chain ritual behind it until
+the ritual is performed without belief and stops meaning anything.
+
+This skill is product-, language-, and registry-independent. It applies to a
+Cratis repository publishing NuGet packages, one publishing npm packages, one
+pushing container images, and one whose whole delivery is a merge to `main`. It
+grants no release authority of its own: it tells you what a claim costs, not
+that you may make it.
+
+## Start with the artifact, not the process
+
+The single most expensive mistake is applying package-release ceremony to
+something that is not a package. Classify the artifact first.
+
+| Artifact | What the consumer receives | Ceremony it earns |
+| --- | --- | --- |
+| Compiled package (NuGet, npm, Maven, Hex), container image, installer | Opaque bytes built on infrastructure the consumer cannot inspect | Full supply-chain receipts |
+| Generated or bundled tree assembled by a pipeline | Bytes that do not exist in any reviewed source tree | Full supply-chain receipts |
+| Source files a host reads directly from a git ref (rules, skills, templates) | Exactly the reviewed content at a commit | Review and versioning only |
+
+The dividing question is **"can the consumer verify what they got against what
+was reviewed, without trusting our build?"** If the host clones a git ref and
+reads the files, git's own content addressing already answers that: the tree
+hash *is* the checksum, the commit *is* the provenance, and the reviewed diff
+*is* the artifact. Generating a checksum file for that content, publishing an
+SBOM of markdown, and demanding a signed attestation before a folder may be read
+adds process without adding a guarantee. Say so plainly rather than performing
+it.
+
+If the artifact is compiled or assembled, the opposite holds, and the
+supply-chain receipts below are not optional decoration.
+
+## Pick the assurance tier before you pick the checks
+
+Three tiers, each earning strictly more claim than the one below it. Default to
+the lowest tier that supports the claim you intend to make, and never let a
+lower tier's evidence be reinterpreted as a higher tier's.
+
+**Candidate review** — an internal, non-published build for review. Claim:
+"this builds deterministically from an immutable source and contains nothing it
+should not." Requires deterministic regeneration from an exact revision, static
+contract and schema validation, secret and path scanning, and an inventory
+digest. It may never be installed by a consumer or described as available.
+
+**Preview** — a real, published, low-commitment version (a `0.x.y`, a
+prerelease channel). Claim: "a consumer can install this, use it, and get back
+out." Requires everything above, plus an independent human review and a real
+**exact-artifact** lifecycle smoke: pack, install, discover, use, uninstall, and
+roll back to a prior exact version. A preview may be withdrawn, may break, and
+must never be described as supported.
+
+**Governed support** — the claim that a consumer may depend on this. Requires
+everything above, plus the full lifecycle phase set on a real host, external
+control attestations, a canary against a real consumer, a recorded recovery
+disposition, and a named human approval for that exact released artifact.
+
+Graduation between tiers does not change the artifact's format. It changes
+what has been observed about it. A preview that later graduates re-runs the
+evidence for the exact released version; earlier observations of an earlier
+build do not transfer.
+
+## Evidence is an observation, not an intention
+
+"Evidence" degrades into paperwork the moment it is allowed to mean "we
+implemented the thing that would produce it." Hold the line with a technical
+ladder where each rung names an observation someone actually made:
+
+1. **documented** — the behavior is written down.
+2. **generated** — an artifact is produced deterministically.
+3. **statically validated** — schemas, contracts, and scans pass on it.
+4. **install-tested** — it installs into a real host.
+5. **behavior-tested** — it is discovered, does the right thing on a positive
+   case, and correctly refuses a negative case.
+6. **lifecycle-tested** — install, update, rollback, uninstall, and preservation
+   of consumer-owned state all pass on that exact artifact.
+7. **release-tested** — the *released* artifact (not a local build of the same
+   commit) passed a canary.
+8. **supported** — a named human approved that exact released artifact.
+
+Two rules keep the ladder honest:
+
+- **Synthetic evidence caps out at statically validated.** A fixture, simulator,
+  or mocked host proves the pipeline, never the host. Classify every observation
+  as synthetic, local, hosted, or real-consumer, and never let a synthetic
+  observation satisfy an execution requirement.
+- **A missing or version-mismatched host is a blocked outcome, not a skip.** If
+  the canary needed host 2.1.245 and the runner had 2.1.235, the phase did not
+  pass; it did not run. A skipped phase that reports green is worse than a red
+  one, because it retires the question.
+
+## The lifecycle phases a real install cycle must cover
+
+When you claim a consumer can adopt and un-adopt your artifact, these are the
+phases that claim decomposes into. Run them against the exact artifact a
+consumer would receive.
+
+- **collision-negative** — with the artifact absent, nothing already present
+  answers to its name. This is the baseline that makes the positive result mean
+  something.
+- **install** — it installs from the published location, not a local path.
+- **discovery** — the host actually finds and lists it afterwards.
+- **behavior-positive** — it does the thing it exists to do.
+- **behavior-negative** — it declines the case it must decline. An artifact that
+  never says no has not been tested for judgment.
+- **update** — moving from the previous version to this one succeeds.
+- **rollback** — moving back to the previous exact version succeeds. This is the
+  phase teams skip and the one consumers need most.
+- **uninstall** — it removes cleanly.
+- **project-context-preservation** — consumer-owned files it never owned are
+  untouched by install, update, rollback, and uninstall. Destroying local
+  configuration during an upgrade is the most expensive failure in this list.
+- **cleanup** — no residue in caches, registries, or host state.
+
+Rollback and preservation are what convert "it works" into "it is safe to try."
+A release path without a proven way back is not a release path; it is a
+one-way door.
+
+## Supply-chain receipts and what each one proves
+
+For compiled or assembled artifacts only, and each for a distinct reason:
+
+- **Checksums** prove the bytes a consumer downloaded are the bytes that were
+  built. They defend against a corrupted or substituted download.
+- **Provenance** proves *which* build, from which source revision, on which
+  workflow, produced those bytes. It defends against a package that matches its
+  own checksum but was built from something nobody reviewed.
+- **SBOM** proves what is *inside* the artifact. It is what makes a downstream
+  vulnerability answerable at all: without it, "are we affected?" requires
+  re-deriving the dependency closure of a shipped binary.
+- **Canary receipt** proves the released artifact worked for a real consumer.
+- **Promotion receipt** proves the decision to widen the audience came after the
+  canary, and records what it was based on.
+- **Recovery disposition** records, before publication, exactly what can be
+  undone and what cannot.
+- **Support approval** is a named human accepting responsibility for that exact
+  released artifact.
+
+Each receipt is written **at the stage it describes and never backdated**. A
+publication receipt cannot be a prepublication prerequisite; a promotion receipt
+cannot be written before the canary it cites. If an earlier record has to be
+rewritten to make a later claim true, the later claim is false.
+
+Prefer registry-native provenance (trusted publishing / OIDC) over
+hand-assembled attestations. It removes the long-lived credential, and the
+consumer can verify it without trusting a file you wrote.
+
+## Automation is not a control
+
+The most common false claim in release engineering is that implemented
+automation proves a control is configured. It does not. A workflow that *would*
+publish through a protected environment says nothing about whether the
+environment exists, who can approve it, or who owns the package name.
+
+Before claiming a control, record an attestation binding: the exact subject
+(repository, branch, workflow, environment, package, or publisher account), who
+observed it and with what authority, when, how long the observation is good
+for, where revocation would be visible, and when revocation was last checked.
+An attestation without an expiry and a revocation check is a screenshot.
+
+Controls worth attesting for a real publishing pipeline: protected default
+branch with required status checks, a release-specific required status, a
+protected publication environment, repository-scoped credentials, exact package
+name ownership in the registry, and exact trusted-publisher registration.
+
+## Label release intent by outward-facing effect
+
+The version label on a pull request is not paperwork describing the change; in
+a label-driven pipeline it **is the decision to ship**. Exactly one of four
+labels belongs on every pull request:
+
+- **major** — a breaking change to public API or observable behavior.
+- **minor** — new capability, backward compatible.
+- **patch** — a fix, or a refactor with identical observable behavior.
+- **no-release** — nothing a consumer could observe by upgrading.
+
+The test is **outward-facing effect, not file location**. A change under a
+source directory that only touches tests is not shippable; a one-line change to
+a shipped package's behavior is, however small. Documentation, CI workflows,
+test-only changes, and local tooling carry `no-release`.
+
+`no-release` is a decision, not an omission — leaving the label off is
+indistinguishable from forgetting it, so an unlabeled pull request stays an
+error. Never default to `patch` when unsure: an unnecessary release burns a
+version number, ships release notes describing nothing, and buries the releases
+that matter.
+
+Two consequences worth internalizing:
+
+- **Group related small work into one pull request.** Several small merges
+  become several releases, and a stream of near-empty patch releases makes the
+  release history useless to the people it is written for. The pull request is
+  the release boundary; make it a coherent, describable change.
+- **Folding one pull request into another means relabeling it.** When branch X
+  is merged as part of Y, X auto-closes *as merged* and fires its own publish
+  run under its own label. Relabel X to `no-release`; do not close it by hand,
+  or its author loses the attribution.
+
+## Structure the release path so no step can vouch for itself
+
+The ordering below is what makes the evidence non-circular. Each step consumes
+only records that already existed when it started.
+
+1. **Prerequisites first.** Every approval, evidence record, and control
+   attestation the release will cite already exists on the protected base
+   branch. A release request may not introduce, weaken, or grant its own
+   prerequisites.
+2. **Freeze a preflight snapshot.** Bind the exact source revision, the exact
+   candidate artifact digest, and the exact prerequisite set — without including
+   the request that will cite it.
+3. **One append-only request.** One version, one artifact, referencing the
+   preflight digest. Requests are never rewritten or reused; a defect in a
+   released version is corrected by a new version, never by editing the record
+   of the old one.
+4. **Named review, then merge.** Merging is the human approval. Keep the merge
+   a true merge commit so the branch's real history survives, and bind the
+   approval to the parent commit so unrelated authority changes cannot be
+   batched in ahead of it.
+5. **Publish, then write the publication receipt** with package identity,
+   artifact digest, provenance, SBOM, and checksums.
+6. **Canary the released artifact against a real consumer** — a real downstream
+   repository or sample that actually depends on it, running its own build and
+   tests against the published version. A canary against a fixture proves the
+   pipeline; a canary against a real consumer proves the release. Publication
+   jobs must stop before promotion if it fails.
+7. **Promote only on canary evidence**, and record the promotion separately.
+8. **Support requires its own final named approval** for that exact released
+   artifact. Publication is not promotion, promotion is not support, and a
+   marketplace or registry listing is none of the three.
+
+## Write the recovery disposition before you publish
+
+Decide and record, per stage, what failure means — while you still have the
+choice.
+
+- **Before publication**, everything is reversible: delete the draft release,
+  close the index or subscriber pull request, remove the branch and tag.
+- **After publication, most registries are immutable.** A published npm, NuGet,
+  or Maven version cannot be un-published in any way a consumer can rely on.
+  The honest recovery is roll-*forward*: publish a corrected version and move
+  the moving pointer (`latest`, a floating tag) back to a known-good exact
+  version. Never describe an immutable version as rolled back.
+- **Automatic rollback is a capability, not an assumption.** Claim it only where
+  it is implemented and canaried; otherwise record it as disabled and name the
+  manual procedure.
+- **Keep failed intermediate state for inspection** rather than deleting the
+  evidence of the failure.
+
+State the disposition in terms a consumer can act on: which exact version to
+pin to, and what the pinned version does not have.
+
+## Never claim a tier you have not paid for
+
+The final discipline is linguistic. "Available", "published", "preview",
+"listed", and "supported" are different claims with different costs, and the
+gap between them is where trust is lost.
+
+- Publishing a package makes it **available**, not supported.
+- A marketplace submission is not a listing; a listing is not support.
+- Passing static validation makes an artifact **statically validated**, not
+  install-tested.
+- Automation that could produce a receipt has not produced one.
+
+When the evidence for a claim is missing, say which evidence is missing and what
+the artifact *is* — not a hedged version of the claim you wanted to make.
+
+## Verify
+
+- The artifact is classified as compiled/assembled or as source read from a git
+  ref, and the ceremony matches that classification.
+- The chosen tier is the lowest one that supports the intended claim.
+- Every phase result is pass, fail, or explicitly blocked — never a silent skip.
+- No synthetic or fixture observation is counted as install, behavior,
+  lifecycle, or canary evidence.
+- Rollback to a prior exact version and preservation of consumer-owned files
+  were both actually exercised.
+- Checksums, provenance, and SBOM exist for compiled or assembled artifacts and
+  are absent, deliberately and explainably, for git-ref source delivery.
+- Every claimed external control has an attestation with subject, issuer,
+  validity, and a revocation check.
+- The pull request carries exactly one of `major`, `minor`, `patch`, or
+  `no-release`, chosen by outward-facing effect.
+- No record was rewritten or backdated to satisfy a later stage.
+- A canary ran against a real consumer before promotion.
+- The recovery disposition is written down and does not claim an immutable
+  version can be rolled back.
+- Nothing is described as supported without a named approval of that exact
+  released artifact.

package/skills/cratis-lens-browser-extension/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.