@cratis/pi 7.105.1 → 7.106.0

package/package/corpus/harnesses/copilot/instructions/profiles.instructions.md

@@ -87,6 +87,7 @@ profile includes neither Screenplay nor Stage.
 | Profile ID | Description | Automatically Includes |
 |---|---|---|
 | `cratis/engineering` | Engineering conventions and workflows | `cratis/engineering/core`, `cratis/engineering/csharp`, `cratis/engineering/elixir`, `cratis/engineering/go`, `cratis/engineering/kotlin`, `cratis/engineering/react`, `cratis/engineering/typescript` |
+| `cratis/engineering/core` | Shared engineering method skills: `cratis-ci-pipeline-performance`, `cratis-documentation-writing`, `cratis-engineering-ci-gates`, `cratis-engineering-consolidation-guard`, `cratis-engineering-decision-record`, `cratis-engineering-docs-authoring`, `cratis-engineering-effect-boundaries`, `cratis-engineering-issue-hygiene`, `cratis-engineering-local-cross-repo-verification`, `cratis-engineering-regression-cluster`, `cratis-engineering-release-trains`, `cratis-engineering-review-rounds`, `cratis-release-notes`, `cratis-technical-examples` | (no child profiles) |
 | `cratis/engineering/csharp` | C# engineering conventions, .NET engineering skills, and framework Orleans jobs (`cratis-orleans-jobs`, alongside `orleans.md`) | `cratis/engineering/core`, `cratis/engineering/dotnet` |
 | `cratis/engineering/dotnet` | Upstream .NET engineering workflows | `cratis/engineering/dotnet/performance`, `cratis/engineering/dotnet/diagnostics`, `cratis/engineering/dotnet/msbuild`, `cratis/engineering/dotnet/orleans`, `cratis/engineering/dotnet/testing`, `cratis/engineering/dotnet/refactoring` |
 | `cratis/engineering/dotnet/performance` | Microbenchmarking, performance patterns, SIMD, and profiling | (no child profiles) |

package/package/corpus/harnesses/copilot/instructions/pull-requests.instructions.md

@@ -126,9 +126,10 @@ intents do not.
   name the exact breaking change(s), who is affected and how, and the
   resulting version number. A generic "ready to ship?" is not this checkpoint —
   say plainly that this release breaks compatibility and needs a yes.
-- Proceed to merge only on an explicit, affirmative answer to that question.
-  A prior general instruction to "ship" or "land this" does not answer it,
-  even when it named `major` as the intended label.
+- A human merges a `major` PR, after answering that question with an explicit
+  yes. An agent never merges it, even after the confirmation. A prior general
+  instruction to "ship" or "land this" does not answer it, even when it named
+  `major` as the intended label.
 - This checkpoint is per release, not per conversation — a human confirming
   one major release does not pre-authorize the next one.
 
@@ -156,7 +157,7 @@ A non-release pull request must satisfy the relevant required checks like any ot
 
 ### Group small related changes into one pull request
 
-Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change.
+Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change. Joining an open candidate, folding superseded PRs and the cut are in `cratis-engineering-release-trains`.
 
 **Before consolidating open PRs, review each PR’s release intent and workflow effects.** Integration may trigger completion/publication behavior on an absorbed PR. Use supported non-release intent where appropriate. A direct request to consolidate the named pull requests authorizes the necessary relabeling and merge; it does not authorize unrelated notifications.
 
@@ -177,4 +178,4 @@ Before marking code/automation work ready, select the affected-project gates tha
 - `yarn lint` — zero errors
 - `npx tsc -b` — zero TypeScript errors
 - Code follows all project coding standards and conventions
-- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).
+- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. Waiting, cancelling and tiered local gates are in `cratis-engineering-ci-gates`. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).

package/package/corpus/harnesses/copilot/instructions/review-reports.instructions.md

@@ -67,6 +67,12 @@ When a workflow requires a typed review envelope, preserve its schema and expres
 these sections, verdict meanings, and scope limits through its existing fields.
 Do not append a competing Markdown report or invent envelope fields.
 
+## Rounds
+
+A follow-up round reviews only the delta since the last reviewed commit and carries prior
+findings forward. Cap the rounds and prefer one structural fix over looping. See
+`cratis-engineering-review-rounds`.
+
 ## Reviewer independence
 
 - **[contract]** Run a reviewer on a different provider family than the author's model

package/package/corpus/prompts/ship-changes.prompt.md

@@ -15,7 +15,7 @@ branch → commits → PR → merge → issue disposition → cleanup workflow.
 
 - **What changed** — brief description of the work (used for branch name and PR title)
 - **Label** — exactly one of `no-release`, `patch`, `minor`, or `major`, selected from the repository's release contract and applied in `gh pr create --label <intent>`
-- **Related issue** — optional exact repository and issue number; if unknown, search read-only first. Comment on or close it only when the user's request includes that effect; otherwise prepare the disposition as a proposal. In repositories released by `cratis/release-action`, a delivered issue is closed by release-action through `(#n)` in the description, but release-action does not run for a `no-release` PR, so `(#n)` closes nothing there; elsewhere follow the repository's own release and issue-closing process.
+- **Related issue** — optional exact repository and issue number; if unknown, search read-only first. Comment on or close it only when the user's request includes that effect; otherwise prepare the disposition as a proposal. In repositories released by `cratis/release-action`, a delivered issue is closed by release-action through `(#n)` in the description, but release-action does not run for a `no-release` PR, so `(#n)` closes nothing there; elsewhere follow the repository's own release and issue-closing process. Keep the issue current and close it with a reason per `cratis-engineering-issue-hygiene`.
 
 Invoking this prompt is direct authority for the standard branch, commit, push, pull-request,
 requested-label, merge, and branch-cleanup effects. Do not pause to ask for separate approval at
@@ -24,8 +24,8 @@ and verify required checks before merging.
 
 **Exception: a `major` label does not carry merge authority.** Prepare the branch, commits, push,
 and PR labeled `major` as usual, then stop before merging. Ask a human to confirm the breaking
-change(s), who is affected, and the resulting version number, and merge only on an explicit
-affirmative answer to that specific question — see
+change(s), who is affected, and the resulting version number; the human merges it after an
+explicit yes to that specific question, and an agent never does — see
 [`pull-requests.md`](../rules/pull-requests.md#a-major-release-needs-a-humans-explicit-go-ahead).
 Every other label proceeds through merge under this prompt's ordinary authority.
 
@@ -33,6 +33,19 @@ This prompt is for an explicit request to ship or land. If the user asked only t
 push, or only to open a PR, stop after that step: the narrower request does not become authority
 for the rest of the chain because this prompt happens to be loaded.
 
+## Before you branch
+
+Check for an open release candidate or PR in the repository before opening a new branch.
+Group related work onto one branch and one PR, and join an open candidate instead of starting
+another. The method is in the `cratis-engineering-release-trains` skill.
+
+## Waiting on checks and merging
+
+Push only when the ship bar is met: root cause understood, specs added, local gate green,
+review passed, issue and PR re-read, and no overlap with main. Then watch the exact run once
+instead of polling it. Merge only after required checks pass. The method is in the
+`cratis-engineering-ci-gates` skill. For review rounds, see `cratis-engineering-review-rounds`.
+
 ## Pull request description
 
 The description is published verbatim as the release notes, so it follows the contract in

package/package/corpus/rules/issue-assignment.md

@@ -29,3 +29,4 @@ up, or it looks abandoned while it is being done.
 The user's request to work on the issue is the authority for this assignment; do not ask
 before doing it. It authorizes assigning the issue and nothing else: commenting, labeling
 or closing still follow [pull-requests.md](./pull-requests.md) and the user's request.
+- **After claiming,** keep the issue current per `cratis-engineering-issue-hygiene`.

package/package/corpus/rules/profiles.md

@@ -86,6 +86,7 @@ profile includes neither Screenplay nor Stage.
 | Profile ID | Description | Automatically Includes |
 |---|---|---|
 | `cratis/engineering` | Engineering conventions and workflows | `cratis/engineering/core`, `cratis/engineering/csharp`, `cratis/engineering/elixir`, `cratis/engineering/go`, `cratis/engineering/kotlin`, `cratis/engineering/react`, `cratis/engineering/typescript` |
+| `cratis/engineering/core` | Shared engineering method skills: `cratis-ci-pipeline-performance`, `cratis-documentation-writing`, `cratis-engineering-ci-gates`, `cratis-engineering-consolidation-guard`, `cratis-engineering-decision-record`, `cratis-engineering-docs-authoring`, `cratis-engineering-effect-boundaries`, `cratis-engineering-issue-hygiene`, `cratis-engineering-local-cross-repo-verification`, `cratis-engineering-regression-cluster`, `cratis-engineering-release-trains`, `cratis-engineering-review-rounds`, `cratis-release-notes`, `cratis-technical-examples` | (no child profiles) |
 | `cratis/engineering/csharp` | C# engineering conventions, .NET engineering skills, and framework Orleans jobs (`cratis-orleans-jobs`, alongside `orleans.md`) | `cratis/engineering/core`, `cratis/engineering/dotnet` |
 | `cratis/engineering/dotnet` | Upstream .NET engineering workflows | `cratis/engineering/dotnet/performance`, `cratis/engineering/dotnet/diagnostics`, `cratis/engineering/dotnet/msbuild`, `cratis/engineering/dotnet/orleans`, `cratis/engineering/dotnet/testing`, `cratis/engineering/dotnet/refactoring` |
 | `cratis/engineering/dotnet/performance` | Microbenchmarking, performance patterns, SIMD, and profiling | (no child profiles) |

package/package/corpus/rules/pull-requests.md

@@ -125,9 +125,10 @@ intents do not.
   name the exact breaking change(s), who is affected and how, and the
   resulting version number. A generic "ready to ship?" is not this checkpoint —
   say plainly that this release breaks compatibility and needs a yes.
-- Proceed to merge only on an explicit, affirmative answer to that question.
-  A prior general instruction to "ship" or "land this" does not answer it,
-  even when it named `major` as the intended label.
+- A human merges a `major` PR, after answering that question with an explicit
+  yes. An agent never merges it, even after the confirmation. A prior general
+  instruction to "ship" or "land this" does not answer it, even when it named
+  `major` as the intended label.
 - This checkpoint is per release, not per conversation — a human confirming
   one major release does not pre-authorize the next one.
 
@@ -155,7 +156,7 @@ A non-release pull request must satisfy the relevant required checks like any ot
 
 ### Group small related changes into one pull request
 
-Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change.
+Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change. Joining an open candidate, folding superseded PRs and the cut are in `cratis-engineering-release-trains`.
 
 **Before consolidating open PRs, review each PR’s release intent and workflow effects.** Integration may trigger completion/publication behavior on an absorbed PR. Use supported non-release intent where appropriate. A direct request to consolidate the named pull requests authorizes the necessary relabeling and merge; it does not authorize unrelated notifications.
 
@@ -176,4 +177,4 @@ Before marking code/automation work ready, select the affected-project gates tha
 - `yarn lint` — zero errors
 - `npx tsc -b` — zero TypeScript errors
 - Code follows all project coding standards and conventions
-- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).
+- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. Waiting, cancelling and tiered local gates are in `cratis-engineering-ci-gates`. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).

package/package/corpus/rules/review-reports.md

@@ -66,6 +66,12 @@ When a workflow requires a typed review envelope, preserve its schema and expres
 these sections, verdict meanings, and scope limits through its existing fields.
 Do not append a competing Markdown report or invent envelope fields.
 
+## Rounds
+
+A follow-up round reviews only the delta since the last reviewed commit and carries prior
+findings forward. Cap the rounds and prefer one structural fix over looping. See
+`cratis-engineering-review-rounds`.
+
 ## Reviewer independence
 
 - **[contract]** Run a reviewer on a different provider family than the author's model

package/package/corpus/skills/cratis-ci-pipeline-performance/SKILL.md

@@ -134,7 +134,7 @@ OS or framework matrix. Default: full matrix on `schedule` and
 rule states this). Pitfall: the full matrix needs an owner who reads its failures.
 
 **Flaky and hung jobs.** Fits failure-bound workflows. Default: a
-`timeout-minutes` on every job, `--blame-hang`, retry only a diagnosed flake, and
+`timeout-minutes` on every job, `--blame-hang` with a mini dump, retry only a diagnosed flake, and
 quarantine a test with an issue. Pitfall: a blanket rerun hides the defect and
 doubles minutes. Read `references/flaky-and-hung-jobs.md`.
 

package/package/corpus/skills/cratis-ci-pipeline-performance/references/flaky-and-hung-jobs.md

@@ -25,12 +25,14 @@ cost runner-minutes and developer trust; diagnose before retrying.
 
 ```bash
 dotnet test Repo.slnx --configuration Release --no-build \
-  --blame-hang --blame-hang-timeout 5m --blame-crash \
+  --blame-hang --blame-hang-timeout 5m --blame-hang-dump-type mini \
+  --blame-crash --blame-crash-dump-type mini \
   --results-directory TestResults
 ```
 
 - This is the VSTest form. Microsoft.Testing.Platform projects use their own
-  crash and hang dump extensions and options; do not mix the two sets of switches.
+  crash and hang dump extensions and options (`--hangdump-type Mini`, `--crashdump-type Mini`); do not mix the two sets of switches.
+- Read the stack (for example `dotnet-dump analyze <file>` then `clrstack -all`), keep the text output, and delete the `.dmp` file. Use a full dump only for a named investigation that needs heap contents.
 - Upload `TestResults` as an artifact with `if: ${{ !cancelled() }}`, so the dump
   survives the failure.
 

package/package/corpus/skills/cratis-code-review/SKILL.md

@@ -177,6 +177,9 @@ correction before merge. Style preferences and maintainability improvements
 without such a consequence belong in Suggestions. Apply the shared verdict
 vocabulary to those findings.
 
+For a follow-up round after blockers were fixed, review only the delta and carry prior
+findings forward; see `cratis-engineering-review-rounds`.
+
 ## What breaks
 
 - **The review restates the compiler.** The gates were not run first, so

package/package/corpus/skills/cratis-code-review/verification.json

@@ -5,6 +5,7 @@
   "assertions": [
     { "kind": "skill-contains", "value": ".cratis/ai/rules/review-reports.md" },
     { "kind": "skill-contains", "value": "Correctness regressions, broken contracts" },
-    { "kind": "skill-contains", "value": "Style preferences and maintainability improvements" }
+    { "kind": "skill-contains", "value": "Style preferences and maintainability improvements" },
+    { "kind": "skill-contains", "value": "cratis-engineering-review-rounds" }
   ]
 }

package/package/corpus/skills/cratis-engineering-ci-gates/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.

package/package/corpus/skills/cratis-engineering-ci-gates/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: cratis-engineering-ci-gates
+description: Run CI-matched local gates and watch exact workflow runs without polling or wasting checks. Use when choosing a local gate or tier, deciding how to wait for CI, starting a blocking watch, or deciding which superseded runs to cancel. Not for grouping deliveries (use cratis-engineering-release-trains), review iterations (use cratis-engineering-review-rounds), or editing workflows for speed (use cratis-ci-pipeline-performance).
+license: LICENSE
+compatibility: Requires git and the GitHub CLI (gh).
+---
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Run the gate once, then watch the exact run
+
+Operate checks; do not redesign workflows here. Read
+[verification-discipline.md](../../rules/verification-discipline.md) for phase
+budgets and exit-status handling, and
+[pull-requests.md](../../rules/pull-requests.md#quality-gates) for required checks.
+Read [capability-is-not-authority.md](../../rules/capability-is-not-authority.md)
+before an external effect. A request to verify does not authorize a push.
+
+## Derive the local gate
+
+1. Read `.github/workflows/` and the repository's tier policy. Follow reusable
+   workflows and invoked scripts. Extract commands, solution and test selection,
+   configuration, warning settings, analyzers, lint and formatting checks.
+2. Prefer the repository's existing gate script. If none exists, keep a small
+   local runner under `.ai-work/`, with each phase's real exit status preserved.
+   Do not substitute only the touched projects for the final gate.
+3. **Tier 1** is the whole-solution build with CI's configuration and warning
+   settings, lint/format, and every non-integration test project. For example,
+   use Release with warnings as errors when that is what CI uses.
+4. **Tier 2** adds integration tests. The repository's tier policy decides
+   whether they run locally. The default is CI-backed integration only if CI
+   runs that coverage, it passes before merge, and reviewer notes say it was
+   deferred to CI. If CI lacks that coverage, do not claim it is verified.
+5. Name anything CI runs that cannot run locally: services, platforms, secrets
+   or hosted checks. Say what ran instead and what remains unverified before
+   pushing. Missing coverage is not a local pass.
+
+Use affected-project checks while coding and writing specifications. Build once
+at the end: run the full local gate when the work is believed complete, not after
+every edit. Do not repeat a passing gate on unchanged inputs for reassurance.
+When several deliveries form one candidate, the assembler runs the final gate
+on the assembled state; deliveries bring targeted results. A changed state after
+a failure needs the required gate again.
+
+Keep build, lint and test phases separate, each with a deadline. Stop on failure;
+do not run dependent phases or hide a producer's exit status behind a filter.
+Report the exact command and result. Put verification and deferred coverage in
+reviewer comments, not the release-note description.
+
+## Wait without polling
+
+After an authorized push, capture the full head SHA and discover the run for the
+intended workflow. For example:
+
+```bash
+head_sha=$(git rev-parse HEAD)
+gh run list --repo OWNER/REPO --workflow ci.yml --commit "$head_sha" \
+  --json databaseId,headSha,event,status
+```
+
+Select the exact run ID, not the newest run by time or branch alone. Disambiguate
+multiple events or dispatches for the same SHA. Capture one ID per required
+workflow. If no matching run is visible, report that no run was captured; do not
+start a status-query loop or guess an ID.
+
+Start one blocking watch for that run, with a deadline sized to the repository:
+
+```bash
+gh run watch <id> --repo OWNER/REPO --exit-status
+```
+
+A background job, if the harness has one, can hold the same blocking watch.
+Never re-query status by hand. Use the watch's completion and exit status, not
+repeated `gh run list`, `gh run view` or PR-check requests while waiting.
+
+Say: "Waiting on CI run <id> for the current PR head." Do independent work while
+it runs. If none remains, end the turn. If the watch cannot finish in the session,
+leave a handoff under `.ai-work/` with the SHA, run ID and outstanding checks;
+report the wait as incomplete, not successful. A watch timeout does not cancel
+the remote run and is not a failed-test diagnosis.
+
+## Diagnose once, fix together
+
+After the run completes with a failure:
+
+1. Read the failed logs once, for example
+   `gh run view <id> --repo OWNER/REPO --log-failed`.
+2. Check other jobs in that completed run, for example
+   `gh run view <id> --repo OWNER/REPO --json jobs`. Account for every failure,
+   including independent failures beyond the first red job.
+3. Fix all in-scope causes together. Report unrelated or unavailable causes as
+   blockers rather than silently waiving them. Re-run the required local gate
+   on the fixed state, then push once when the request authorizes it.
+4. Rerun a job only for a diagnosed flake, including a demonstrated transient
+   infrastructure failure, and only after the run completes. For example,
+   `gh run rerun <id> --repo OWNER/REPO --failed` retries failed jobs. Watch the
+   resulting attempt once. A deterministic failure needs a fix, not a retry.
+
+Never put a CI skip token in a title or commit. Do not spend a push on each
+individual fix or use CI to discover whether speculative fixes compile.
+
+## Cancel only owned, superseded work
+
+Cancellation needs a reason and an exact target. Within an authorized shipping
+or folding request, cancel only runs started by the session's own superseded or
+folded pushes. Anyone else's run needs the owner's agreement. Merely sharing a
+branch or finding a duplicate run does not establish ownership.
+
+Before acting, inspect each candidate, for example:
+
+```bash
+gh run view <id> --repo OWNER/REPO \
+  --json workflowName,event,headBranch,headSha,status,createdAt
+```
+
+Confirm the initiating push, workflow and SHA against the superseding head or
+folded PR. Inspect the workflow's jobs if its effects are unclear. Never cancel
+a release, publish or deploy run, regardless of ownership or workflow name.
+Do not cancel a check whose result a queued or running publication needs, or a
+required check about to gate a merge. Another owner's watched merge run needs
+that owner's agreement. Even with agreement, release, publish and deploy runs
+and checks needed by publication remain protected.
+
+Re-read immediately before cancelling so drift cannot widen the target. Do not
+cancel by branch, name or age alone, or use a bulk cancellation command. Once
+confirmed, for example:
+
+```bash
+gh run cancel <id> --repo OWNER/REPO
+```
+
+Report one line naming the run ID and superseding or folding reason. If ownership
+or downstream use is uncertain, leave it running and report the uncertainty.
+
+## Integration and containers
+
+Run local integration only when the tier policy calls for it or a bounded
+cross-repository proof needs it. Give every container phase and Docker call a
+deadline, including startup, image builds, tests and teardown. A background job
+is not a timeout or a cleanup policy.
+
+Keep track of the containers and networks created by the phase. On success,
+failure, timeout or abandonment, stop and remove only those owned resources.
+Use exact IDs or a task-specific Compose project; confirm ownership before
+removal. Do not restart a shared daemon or stop another task's services.
+Never run `docker system prune -a` or `docker image prune -a`.
+
+When a test run hangs, ask for a mini hang dump (`--blame-hang-dump-type mini` on VSTest, `--hangdump-type Mini` on Microsoft.Testing.Platform). Read the stack (for example `dotnet-dump analyze <file>` then `clrstack -all`), keep the text output, and delete the `.dmp` file. Use a full dump only for a named investigation that needs heap contents.
+
+For a repository's Compose test setup, one scoped teardown example is
+`docker compose -p <task-project> down`, under its own deadline. Do not add
+volume deletion unless those volumes are disposable and owned by this task.
+Keep secrets out of logs and artifacts per
+[secrets.md](../../rules/secrets.md).
+
+## What breaks
+
+- An affected-project build presented as Tier 1 leaves other projects unchecked.
+- A green Tier 1 presented as integration proof hides coverage deferred to CI.
+- Watching a branch's newest run can report success for the wrong SHA.
+- Manual polling duplicates the watch and wastes time without improving proof.
+- Blind retries and one push per failure spend checks without fixing the run.
+- Broad container cleanup destroys resources the phase does not own.
+
+## How it is proven
+
+The derived local commands exit successfully on the final state. The blocking
+watch for each required run exits successfully for the exact head SHA, including
+integration coverage deferred to CI. A timeout, cancellation, missing check or
+unobserved result stays unverified. Report local results, CI results and omissions
+separately; no inventory or receipt substitutes for running the checks.

package/package/corpus/skills/cratis-engineering-issue-hygiene/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.

package/package/corpus/skills/cratis-engineering-issue-hygiene/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: cratis-engineering-issue-hygiene
+description: Keep GitHub issues current and reduce unfinished work with a single-writer status block and reasoned disposition. Use when maintaining an issue status block, deciding who may claim an issue, whether to close completed work, or whether to file a necessary follow-up. Not for grouping deliveries (use cratis-engineering-release-trains), review iterations (use cratis-engineering-review-rounds), workflow optimization (use cratis-ci-pipeline-performance), or CI operations (use cratis-engineering-ci-gates).
+license: LICENSE
+compatibility: Requires git and the GitHub CLI (gh).
+---
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Leave fewer issues, with a truthful description
+
+An issue must make sense to a reader outside the session. Keep its present state
+in the description and meaningful events in the timeline. Before any mutation,
+read [capability-is-not-authority.md](../../rules/capability-is-not-authority.md).
+The request authorizes its named effects, not arbitrary filing or closing.
+
+## One writer and a clear claim
+
+One person or session owns all body edits, comments and disposition for a named
+issue. Delegated workers report findings to that owner. An explicit handoff can
+transfer the named issue, but the previous writer must stop editing it. GitHub
+body edits are not conditional writes; a last-minute reread alone cannot prevent
+two writers from overwriting each other.
+
+Before starting, read the issue, comments, assignees and any status block. Follow
+[issue-assignment.md](../../rules/issue-assignment.md) to claim it. Do not replace
+an existing assignment. If another writer is already active, coordinate rather
+than starting a parallel edit. A failed assignment is not a blocker to the work.
+
+When the request covers maintaining the issue, set the status block to
+**In progress** before coding. Keep it true as work moves: **In review** for the
+open PR, **Blocked** with the dependency, **Paused** when no active work remains,
+and **Done** only when delivery is confirmed. Never leave In progress behind
+when the writer stops.
+
+## Put the status block in the description
+
+Preserve the original problem statement and all text outside the managed block.
+Append the block if absent. Stop for coordination if markers are malformed,
+duplicated or already managed by another active writer. A minimal template is:
+
+```markdown
+<!-- agent-status:start -->
+## Status
+**State:** In progress
+**Scope:** Deliver the agreed behavior and its regression specification.
+**Approach:** Fix the shared decision and exercise it through the public API.
+**PR:** Not opened.
+**Delivered:** Nothing yet.
+**Remaining:** Implement, verify, review and deliver.
+**Follow-ups:** None.
+<!-- agent-status:end -->
+```
+
+Replace the example with the real scope and remaining work. Use public PR or
+issue URLs when they exist. Summarize a local plan; never link its file path.
+Do not put local paths, harness commands, credentials or private context in
+public issue or PR text. Read [secrets.md](../../rules/secrets.md) before handling
+output, and [local-work-artifacts.md](../../rules/local-work-artifacts.md) before
+creating the private working copy.
+
+For example, read the body into an ignored local working file:
+
+```bash
+gh issue view <n> --repo OWNER/REPO --json body --jq .body > .ai-work/issue-body.md
+```
+
+Edit only the managed block in that file. Immediately before writing, re-read
+both the issue and any linked PR. Read the remote body again:
+
+```bash
+gh issue view <n> --repo OWNER/REPO --json body
+```
+
+Compare it with the body used to prepare the edit. If anything changed, preserve
+those changes and recompose from the fresh body. If concurrent edits continue,
+stop and coordinate with the other writer. Do not write a stale whole body.
+After a clean comparison, write the complete preserved body back, for example:
+
+```bash
+gh issue edit <n> --repo OWNER/REPO --body-file .ai-work/issue-body.md
+gh issue view <n> --repo OWNER/REPO --json body
+```
+
+Verify the block changed as intended and the surrounding content stayed intact.
+Do not paste the private working-file path into the issue.
+
+## Description versus comment
+
+Edit the status block for current scope, decisions, approach, checklist, linked
+PRs, dependencies and what remains. The description alone should explain the
+present state. Do not rewrite other people's text or replace the original report.
+
+Comment only for an event worth notifying readers about: a decision or scope
+change with its reason, a human blocker, a delivery milestone or a closing
+summary. Each comment stands alone: what happened, why it matters, what comes
+next. Use absolute public URLs. Do not repeat the block as a comment or post
+"working on it", tool output, test counts, receipts or model/session chatter.
+
+Re-read the issue and PR before every key step: starting, changing scope,
+updating public state, filing follow-ups, merging or disposing of the issue.
+For example, use `gh issue view <n> --repo OWNER/REPO --comments` and
+`gh pr view <pr> --repo OWNER/REPO`. Do not act on an old summary after drift.
+
+## Make the open-issue count go down
+
+1. **Fix before filing.** Fix a small, in-scope finding in the same files and
+   risk area as the active change. Do not widen scope to improve the count.
+   Review advisories are fixed cheaply inline or dropped, not filed as issues.
+2. **File only when needed and authorized.** A real defect that cannot be fixed
+   now, or a follow-up delivery truly requires, may need an issue. Search open
+   and closed issues first, for example
+   `gh issue list --repo OWNER/REPO --state all --search "<area> in:title,body"`.
+   Reuse an existing issue instead of duplicating it; comment only when that
+   effect is authorized and adds necessary context.
+3. Group related findings into one checklist issue per area. Include concrete,
+   testable `## Acceptance criteria`. No speculative hardening, ideas or
+   "investigate later" issues. If filing is outside the request, list necessary
+   follow-ups in the report instead of creating them.
+4. **Close what is done**, through the correct delivery mechanism below. Partial
+   delivery stays open with exactly what remains. Do not manufacture completion
+   or create extra issues merely to move unfinished scope elsewhere.
+5. Prefer bounded issues that can be finished completely over starting large
+   epics. Report completed dispositions, not how many new issues were produced.
+
+## Close with a reason, through the owning mechanism
+
+Read [pull-requests.md](../../rules/pull-requests.md#issue-references) before
+changing issue references or disposition. Confirm the actual PR state, release
+intent and repository workflow; a merged PR is not proof of a published release.
+
+- **Release-action delivery:** for a fully delivered issue, the delivering
+  release-note bullet ends with `(#n)`. Release-action closes it at release;
+  do not close it by hand. If release is pending, keep that dependency visible.
+- **Manual completion:** only for a `no-release` PR or a repository without
+  release-action, and only when the request includes closing. Confirm all scope
+  is delivered and no required PR is open, unmerged, reverted or failing. Set
+  Done and close with reason `completed` and a public delivery link.
+- **Duplicate or obsolete:** only with clear evidence and authority. Use reason
+  `not planned`, explain why, and link the canonical issue or superseding work.
+  If uncertain, leave it open and report the question.
+- **Partial or unauthorized disposition:** leave it open with truthful remaining
+  scope or report the proposed disposition. Do not invent follow-up authority.
+
+For an authorized manual completion, for example:
+
+```bash
+gh issue close <n> --repo OWNER/REPO --reason completed \
+  --comment "Delivered in <public PR URL>. The agreed behavior is available."
+```
+
+A duplicate uses `--reason "not planned"` and a specific canonical public URL.
+No closing keywords are needed in the PR description; follow the owning rule.
+
+## End-of-work audit
+
+List issues touched by this work and reconcile each against its PR and release.
+For example, `gh issue list --repo OWNER/REPO --assignee @me --state open` helps
+find assigned work, but does not replace the list of issues actually touched.
+Check merged PRs for completed work still open; distinguish pending release-action
+closure from an authorized manual disposition. Verify closure through the issue's
+actual state, not an assumption about merging.
+
+Leave no issue In progress without an active writer. For unfinished work, set
+Paused or Blocked with what remains and what it waits for. Reconcile follow-ups
+with existing issues. Perform only authorized mutations; otherwise report the
+proposed changes and the blocker. Summarize completed issues, pending release
+closures and unfinished scope without publishing local paths or harness details.
+
+## How it is proven
+
+Read the final body and state, for example with
+`gh issue view <n> --repo OWNER/REPO --json body,state`. The original report is
+intact, the status block matches the actual PR and release, and any authorized
+closure is observable. Until release-action runs, pending closure is not Done.
+
+## What breaks
+
+- Two body writers lose each other's updates even if both reread first.
+- A status comment buries current state and needlessly notifies subscribers.
+- Manual closure before release bypasses release-action's delivery contract.
+- Filing every advisory grows the backlog without a necessary delivery.
+- Stale In progress blocks the next person without anyone doing the work.

package/package/corpus/skills/cratis-engineering-local-cross-repo-verification/SKILL.md

@@ -27,7 +27,9 @@ Also use this loop for:
 Prefer a release/preview for trivial changes, external consumers unable to use
 the local feed, or CI-only behavior this loop cannot reproduce.
 
-**Local verification replaces waiting, not shipping.** After local proof, release
+**Local verification replaces waiting, not shipping.** Other waits a candidate
+can avoid are in [cratis-engineering-release-trains](../cratis-engineering-release-trains/SKILL.md).
+After local proof, release
 the producer through the normal authorized workflow and bump the consumer to the
 released version. Local feeds, pins and images never go into production or a PR.
 Single-repository work needs its own regression specs, not this overlay. Released

package/package/corpus/skills/cratis-engineering-release-trains/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.

package/package/corpus/skills/cratis-engineering-release-trains/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: cratis-engineering-release-trains
+description: Group related deliveries into one release candidate, fold superseded pull requests, and apply a ship bar before publishing the assembled change. Use when asked to group finished branches, join an open PR, fold superseded PRs, size a candidate, or decide whether the ship bar is met. Not for waiting on checks (use cratis-engineering-ci-gates), planning review rounds (use cratis-engineering-review-rounds), or optimizing workflow performance (use cratis-ci-pipeline-performance).
+license: LICENSE
+compatibility: Requires git and the GitHub CLI (gh).
+---
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# One assembled candidate, one release
+
+A **candidate** is the branch assembling deliveries intended to ship together.
+A repository includes its main checkout and all its worktrees. Consider their
+concurrent work together, not as separate releases merely because it has
+separate branches. One person or session assembles the candidate.
+
+## Authority and routing
+
+Read [capability-is-not-authority.md](../../rules/capability-is-not-authority.md)
+and the [ship-changes prompt](../../prompts/ship-changes.prompt.md) before any
+external effect. A user's ship request authorizes its ordinary shipping steps;
+loading this skill does not turn an implementation-only request into shipping.
+Without that request, prepare the grouping and report the proposed next action.
+
+Read [pull-requests.md](../../rules/pull-requests.md) for release intent, split
+criteria, release notes, issue dispositions, and the human checkpoint for a
+major release. A major release is never merged by an agent: a human confirms
+and merges it. Agent work stops at preparing the PR, even after confirmation.
+Read [git-commits.md](../../rules/git-commits.md) before assembling
+branches. Preserve commits: never squash, rebase, amend, or force-push.
+
+Use `cratis-engineering-consolidation-guard` when folding existing PRs to prove
+nothing was dropped. Use `cratis-engineering-ci-gates` for gate selection and
+run handling, and `cratis-engineering-review-rounds` for proportionate review.
+
+## Choose the candidate before creating a PR
+
+1. Inspect the repository's worktrees, finished branches, and open PRs:
+
+   ```bash
+   git worktree list
+   gh pr list --state open --json number,headRefName,title,author
+   ```
+
+2. Group related, ready deliveries under one candidate and one PR. Check with
+   the person assembling an existing candidate before changing it. Independent
+   work branches start from `origin/main`; work that depends on an unmerged
+   candidate may start from that candidate's latest commit (see Replace waits
+   with local work). Ongoing work keeps its branch.
+   Do not edit another session's checkout or include its uncommitted work.
+3. Prefer joining a related open PR that is still accepting deliveries, has no
+   checks running, and is not being merged by another session. Agree on its
+   writer, merge `origin/main` into its branch, then merge the deliveries and
+   extend its release note. Do not open a competing PR while it is being cut.
+4. If no candidate exists, create a branch from current `origin/main` and merge
+   ready delivery branches with merge commits. Keep each logical change in its
+   own commits. Return a conflicting or failing delivery for correction rather
+   than guessing its intent in the assembled branch.
+5. Keep one candidate per repository by default. Apply the split criteria in
+   `pull-requests.md` for unrelated work, different risk, or an urgent fix. Name
+   the exception in the reviewer comment; a major awaiting human confirmation
+   must not silently hold unrelated safe work indefinitely.
+
+Minimal assembly, after agreeing on the included deliveries:
+
+```bash
+git fetch origin
+git switch -c release-candidate origin/main
+git merge --no-ff delivery-a
+git merge --no-ff delivery-b
+```
+
+Use a new branch name if `release-candidate` already exists. This example does
+not authorize publication. Run the assembled gates before the shipping push.
+
+## Fold superseded PRs promptly
+
+Once a fold is decided within the authorized shipping scope, stop pushing to
+its old branch. Close the superseded PR with a one-line reason:
+`Folded into <candidate branch or PR>`; use `Will be folded into <candidate>`
+when assembly is still pending. Do not wait for the candidate's push to retire
+a PR that is already known to be superseded.
+
+Move its delivered release-note bullets into the candidate's release note,
+following `pull-requests.md`; retain only issues actually delivered by the diff.
+Before consolidation, check release intent and publication effects and apply
+`cratis-engineering-consolidation-guard`.
+
+Identify the exact queued or in-progress runs for the superseded head. Cancel
+only runs started by this session's own superseded pushes. Never cancel a
+release, publish, or deploy run, or another session's watched merge. Leave
+others running and report them. Follow `cratis-engineering-ci-gates` for the
+cancellation checks; folding a PR is not blanket cancellation authority.
+
+## Size by readiness, then freeze
+
+Before the final gate, list in-flight deliveries and their expected readiness.
+Hold the cut for work expected ready within about one gate duration, so the
+assembled gate runs once on the larger set. Cut without work further out or
+blocked on a design decision, consumer proof, or another repository.
+
+After the cut, nothing joins. Late deliveries go into the next candidate.
+Corrections needed to make the frozen candidate pass are not new deliveries;
+rerun the affected required gates for that changed code state.
+
+Record the cut and readiness estimates in one line in the reviewer comment,
+not the release note: `Cut with A and B; C waits for consumer proof.` Keep local
+coordination records under `.ai-work/`, never in public release text.
+
+## Replace waits with local work
+
+Most waits are removable. The build queue is the only legitimate one; while
+queued, do the next independent piece of work.
+
+- Base work on a committed local candidate instead of waiting for it to reach
+  main, and say which candidate commit it is based on when delivering.
+- Prove against locally built packages instead of waiting for a release; see
+  [cratis-engineering-local-cross-repo-verification](../cratis-engineering-local-cross-repo-verification/SKILL.md).
+  Only the final version pin waits for the release.
+- Drop an item that has been stuck for about two hours rather than holding the
+  candidate; it joins the next one.
+- Cut a candidate at least every few hours with whatever is green.
+
+## Apply the ship bar
+
+Check these six conditions. If one is missing, stop and report it instead of
+making a speculative shipping push. Recheck the merge conditions after CI.
+
+1. **Cause and design understood.** The change solves the named problem using
+   established conventions. Product questions are resolved, not guessed.
+2. **Behavior proved.** Changed behavior has specifications, or an explicit
+   reason why they do not apply. The assembled local gate is green. Required
+   integration coverage follows repository policy and must pass before merge;
+   name anything that cannot run locally rather than calling it a local pass.
+3. **Whole change reviewed.** The candidate has a completed review without
+   Blockers or missing required evidence. Targeted delivery reviews alone do
+   not satisfy this condition.
+4. **Release decision settled.** Release intent follows `pull-requests.md`.
+   For a major release, require explicit human confirmation and human merge.
+   An agent never merges it; preparing the PR does not answer that checkpoint.
+5. **Conversation reread.** Re-read the issues and PR, including comments and
+   requested changes, before pushing and again immediately before merging.
+   Resolve unanswered objections rather than treating green checks as consent.
+6. **Main overlap checked.** Fetch main before merging. Inspect changes since
+   the tested head on the candidate's changed paths, for example
+   `git log <ci-sha>..origin/main -- <changed-paths>`. If main overlaps, merge it
+   into the candidate and rerun the required gates and CI before merge.
+
+## Push deliberately and finish
+
+Batch local commits and review corrections into one meaningful shipping push.
+After feedback, fix the full set, rerun the required gates, and push once.
+Never push a lone merge of main as a save point or push just to discover whether
+untested code passes.
+
+Never put a CI skip token (`[skip ci]`, `[ci skip]`, `[no ci]`, `[skip actions]`)
+in a PR title or commit message. The merge commit inherits the PR title, so a
+skip token can prevent every check from running on main. Remove such tokens
+before creating or editing the PR; never rewrite an existing commit to do it.
+If a committed token cannot be corrected without rewriting history, stop and
+report the unsafe message rather than pushing it.
+
+Use the ship-changes prompt for PR creation, notes, merge, issue disposition,
+and cleanup. Non-major releases use a merge commit; never squash or rebase.
+A human confirms and merges every major release. In repositories
+using release-action, delivered `(#n)` references close at release, not by hand;
+follow `pull-requests.md` for other cases rather than inventing a closing step.
+
+Do not enable auto-merge. Wait using `cratis-engineering-ci-gates`. If checks
+outlast the session, leave a handoff under `.ai-work/` per
+[local-work-artifacts.md](../../rules/local-work-artifacts.md), with valid
+preconditions, candidate and tested SHAs, PR, exact pending checks, and the next
+steps. The next session must recheck the ship bar, not blindly merge on green.
+
+## What breaks
+
+- **One PR per delivery:** duplicate gates and fragmented releases replace an
+  assembled check of the actual shipped change.
+- **A growing frozen candidate:** late work invalidates the gate and cut.
+- **Green means permitted:** checks neither resolve objections nor approve a
+  major release. The user's request and owning rules still govern effects.
+
+## How it is proven
+
+Run the repository's exact assembled gate and inspect its successful exit.
+Run `gh pr checks <pr>` before merge: required checks must pass for the tested
+head. Confirm the whole-change review, fresh discussion, and main-overlap check.
+For release notes, execute the repository's `cratis-check-pr.mjs` command from
+`pull-requests.md`; a zero exit is the pass signal. No checklist replaces those
+behavioral and CI signals.

package/package/corpus/skills/cratis-engineering-release-trains/verification.json

@@ -0,0 +1,20 @@
+{
+  "skill": "cratis-engineering-release-trains",
+  "input": "Group related deliveries, freeze the candidate, and apply the ship bar without bypassing human merge or CI.",
+  "fixtures": [],
+  "assertions": [
+    { "kind": "skill-contains", "value": "One assembled candidate, one release" },
+    { "kind": "skill-contains", "value": "After the cut, nothing joins." },
+    { "kind": "skill-contains", "value": "The build queue is the only legitimate one" },
+    { "kind": "skill-contains", "value": "only runs started by this session's own superseded pushes" },
+    { "kind": "skill-contains", "value": "A major release is never merged by an agent: a human confirms" },
+    { "kind": "skill-contains", "value": "in a PR title or commit message" },
+    { "kind": "skill-contains", "value": "[skip ci]" },
+    { "kind": "skill-contains", "value": "[ci skip]" },
+    { "kind": "skill-contains", "value": "[no ci]" },
+    { "kind": "skill-contains", "value": "[skip actions]" },
+    { "kind": "skill-contains", "value": "never squash or rebase" },
+    { "kind": "skill-contains", "value": "../../rules/pull-requests.md" },
+    { "kind": "skill-contains", "value": "../../prompts/ship-changes.prompt.md" }
+  ]
+}

package/package/corpus/skills/cratis-engineering-review-rounds/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.

package/package/corpus/skills/cratis-engineering-review-rounds/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: cratis-engineering-review-rounds
+description: Plan proportionate review rounds, distinguish blocking from advisory findings, and carry prior evidence into a delta round with a firm stopping point. Use when choosing a review round, handling blocking or advisory feedback, requesting a delta since the last reviewed SHA, or stopping recurring blockers. Not for review criteria (use cratis-code-review), grouping a release candidate (use cratis-engineering-release-trains), waiting on checks (use cratis-engineering-ci-gates), or a repeated regression class (use cratis-engineering-regression-cluster).
+license: LICENSE
+compatibility: Requires git and the GitHub CLI (gh).
+---
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Review the change, then its corrections
+
+Read [review-reports.md](../../rules/review-reports.md) before choosing reviewers
+or reporting findings. Its report shape, verdicts, scope limits, and reviewer
+independence apply to every round. This skill schedules reviews; it does not
+replace the criteria in `cratis-code-review` or specialist review skills.
+
+**Blocking** means a must-fix finding in **Blockers**, yielding **Changes
+requested**. **Advisory** means a non-blocking finding in **Suggestions**. An
+advisory preference is not a merge gate. Missing required evidence yields
+**Incomplete**, not approval; retain that gap until it is resolved.
+
+## Budget the review
+
+- Run one quick round per delivery. A second is warranted only after a blocker,
+  not to seek reassurance or eliminate suggestions.
+- Run one whole-change review per PR on the assembled change. Quick delivery
+  rounds do not replace it. Start whole-change inspection in parallel with the
+  gate when possible, but keep it provisional: required gates must pass before
+  an approval report is finalized. Do not launch duplicate gates for review.
+- Use ordinary depth by default. Deep review needs one named risk class:
+  **security**, **algorithmic**, **concurrency**, or **cross-cutting**, plus a
+  one-line justification tied to the changed behavior. Data-loss exposure or
+  irreversible migrations may justify cross-cutting review; merely wanting
+  extra confidence does not.
+- Prove migrations and deployment-sensitive behavior by running the migration
+  on representative local data and exercising the relevant old/new behavior.
+  Deeper inspection is not execution evidence. Follow repository test policy.
+
+## First whole-change round
+
+1. Fix the target scope and committed base and head SHAs. Name changed surfaces,
+   expected behavior, required checks, and any specific risk before starting.
+   Use `git rev-parse <base>` and `git rev-parse HEAD` to resolve full SHAs.
+2. Apply reviewer independence from `review-reports.md`: use a different
+   provider family where selectable. Where it is not selectable, declare
+   `single-provider` in the report header and on the Not examined line. A
+   provider/tool error makes the review Incomplete; fall back once as that
+   rule directs, rather than manufacturing a verdict.
+3. Review the whole diff using the applicable criteria and real gate results.
+   Record round 1 with its base/head and retain the complete report unchanged.
+   Keep local review records under `.ai-work/`; public reviewer notes follow
+   [pull-requests.md](../../rules/pull-requests.md), never the release note.
+4. Fix confirmed Blockers together. Dismiss a candidate only with evidence and
+   a reason, not by silently deleting it. Correct required evidence gaps before
+   seeking approval. Cheap advisory fixes may join this correction pass.
+
+## Delta rounds
+
+A delta round follows a whole-change review and reviews from the last reviewed
+SHA, not from an arbitrary base. Carry the prior Blockers, unresolved evidence
+gaps, Suggestions, and Dismissed findings with their reasons. Supply the round
+number, prior report, original base, last reviewed SHA, and new head explicitly.
+
+For example, after correcting a blocker from round 1:
+
+```text
+Round: 2 (delta)
+Original base: <full base SHA>
+Since: <full head SHA reviewed in round 1>
+Head: <full corrected head SHA>
+Prior: <complete round 1 report, including dismissals and scope limits>
+Scope: inspect the correction diff and verify disposition of prior findings
+```
+
+Inspect the correction diff with `git diff <last-reviewed-sha>..<new-head-sha>`.
+Recheck earlier blockers against the correction and its specifications. Preserve
+unresolved findings and limits; a narrow delta cannot certify surfaces that
+were never examined. Reuse earlier approval only for the exact committed SHAs
+and examined scope, never for a dirty tree or a changed head.
+
+Do not start a follow-up round for advisory findings alone. Fix them only when
+cheap in an existing correction pass; otherwise leave them as Suggestions.
+Never file an issue merely to dispose of advisory feedback. A distinct defect
+needs its own evidence and the authority rules, not automatic issue creation.
+
+## Stop instead of looping
+
+Cap review at **3 rounds per work item**, normally fewer. Keep delivery and
+whole-change round counts explicit; renaming the target does not reset a work
+item's cap. If blockers recur, stop the fix/review loop. Make one structural
+change addressing the failure class or ask the user about the approach. Use
+`cratis-engineering-regression-cluster` when repeated instances share a surface.
+A structural change does not authorize an automatic fourth round or waive any
+required review; report the remaining blocker or required decision.
+
+## What breaks
+
+- **A whole-change restart after every correction:** repeats work while losing
+  the earlier blocker list and dismissals. Use a delta with the prior report.
+- **Advisory becomes blocking:** a preference causes needless edits, extra
+  rounds, or unwanted issues. Preserve the shared report vocabulary.
+- **Deep by habit:** extra review displaces running the behavior without a
+  named risk. State the risk or use ordinary depth.
+- **Green by absence:** a reviewer failure or missing required proof is
+  Incomplete, not a successful review with no findings.
+
+## How it is proven
+
+Run the repository's required gates and behavioral specifications for the
+correction; successful exits are required evidence, not review substitutes.
+Use the delta command above to confirm scope and verify that each earlier
+finding has a disposition with evidence. The report includes Blockers,
+Suggestions, Dismissed (with reason), Verdict, and Not examined, per the shared
+rule. No Blockers and complete required evidence permit approval; suggestions
+alone permit Approved with suggestions.
+
+For PR descriptions and release notes, run the deterministic
+`cratis-check-pr.mjs` command from `pull-requests.md` and require a zero exit.
+Do not spend a review round on checks that script owns.

package/package/corpus/skills/cratis-engineering-review-rounds/verification.json

@@ -0,0 +1,16 @@
+{
+  "skill": "cratis-engineering-review-rounds",
+  "input": "Plan a delta round after a blocker without restarting whole-change review or filing advisory findings.",
+  "fixtures": [],
+  "assertions": [
+    { "kind": "skill-contains", "value": "../../rules/review-reports.md" },
+    { "kind": "skill-contains", "value": "Run one quick round per delivery" },
+    { "kind": "skill-contains", "value": "Run one whole-change review per PR" },
+    { "kind": "skill-contains", "value": "SHA, not from an arbitrary base" },
+    { "kind": "skill-contains", "value": "Prior: <complete round 1 report, including dismissals and scope limits>" },
+    { "kind": "skill-contains", "value": "3 rounds per work item" },
+    { "kind": "skill-contains", "value": "Never file an issue merely to dispose of advisory feedback" },
+    { "kind": "skill-contains", "value": "single-provider" },
+    { "kind": "skill-contains", "value": "**cross-cutting**" }
+  ]
+}

package/package/corpus/skills/run-tests/NOTICE

@@ -15,5 +15,6 @@ SKILL.md:
 - Render unimported mtp-hot-reload routing reference as plain topic text.
 - Rewrite the description to the Cratis shape (what it does, Use when, Not for) and drop references to skills that are not part of this corpus.
 - Remove the reference to the mtp-hot-reload skill.
+- Ask for mini dumps in the crash and hang dump options and add the read-then-delete instruction.
 
 NOTICE: Add this attribution, change list, and any download/execution disclosure.

package/package/corpus/skills/run-tests/SKILL.md

@@ -242,8 +242,8 @@ speculative alternative grammars.
 | TRX | SDK-style: `--logger "trx;LogFileName=<name>.trx"` when an exact output file is requested, otherwise `--logger trx`; standalone `vstest.console.exe`: `/Logger:trx`; `MSTest.exe`: repository-documented results option | `--report-trx` |
 | Results directory | `--results-directory <dir>` | `--results-directory <dir>` |
 | Diagnostic log | `--diag <file>` | `--diagnostic --diagnostic-output-directory <dir>` |
-| Crash dump | `--blame-crash` | `--crashdump` |
-| Hang timeout | `--blame-hang --blame-hang-timeout 5min` | `--hangdump --hangdump-timeout 5min` |
+| Crash dump | `--blame-crash --blame-crash-dump-type mini` | `--crashdump --crashdump-type Mini` |
+| Hang timeout | `--blame-hang --blame-hang-timeout 5min --blame-hang-dump-type mini` | `--hangdump --hangdump-timeout 5min --hangdump-type Mini` |
 | Code coverage | `--collect "Code Coverage"` | `--coverage` |
 
 MTP report, dump, and coverage flags require their corresponding registered
@@ -251,6 +251,8 @@ extensions (`TrxReport`, `CrashDump`, `HangDump`, or `CodeCoverage`). Some
 framework SDKs bundle common extensions; if a flag is unrecognized, inspect
 package references before recommending a package change.
 
+Always ask for a mini dump. Read the stack (for example `dotnet-dump analyze <file>` then `clrstack -all`), keep the text output, and delete the `.dmp` file. Use a full dump only for a named investigation that needs heap contents.
+
 `--verbosity diagnostic` increases dotnet/MSBuild output verbosity; it does not
 write a VSTest diagnostic log file.
 
@@ -264,7 +266,7 @@ dotnet test Tests.csproj --logger "trx;LogFileName=TestResults.trx"
 dotnet test Tests.csproj -- --report-trx
 
 # Native MTP TRX and hang detection
-dotnet test --project Tests.csproj --report-trx --hangdump --hangdump-timeout 5min
+dotnet test --project Tests.csproj --report-trx --hangdump --hangdump-timeout 5min --hangdump-type Mini
 
 # Native MTP diagnostics
 dotnet test --project Tests.csproj --diagnostic --diagnostic-output-directory artifacts/diagnostics

package/package/profile-catalog.json

@@ -992,12 +992,16 @@
       "availableTargets": [
         "cratis-ci-pipeline-performance",
         "cratis-documentation-writing",
+        "cratis-engineering-ci-gates",
         "cratis-engineering-consolidation-guard",
         "cratis-engineering-decision-record",
         "cratis-engineering-docs-authoring",
         "cratis-engineering-effect-boundaries",
+        "cratis-engineering-issue-hygiene",
         "cratis-engineering-local-cross-repo-verification",
         "cratis-engineering-regression-cluster",
+        "cratis-engineering-release-trains",
+        "cratis-engineering-review-rounds",
         "cratis-release-notes",
         "cratis-technical-examples"
       ],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cratis/pi",
-  "version": "7.105.1",
+  "version": "7.106.0",
   "description": "Configuration-aware Cratis AI integration for Pi",
   "type": "module",
   "files": [