@cratis/pi 7.125.0 → 7.125.2

package/package/corpus/agents/orchestrator.md

@@ -97,7 +97,8 @@ When you receive a goal:
 6. **Output a team plan** — always as a structured markdown checklist with agent assignments and phase labels.
 7. **Return or execute the plan** — default to a parent handoff; delegate only under the explicit large-scope contract.
 8. **Track overall progress** — after each phase, report what was completed and what remains.
-9. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
+9. **Open the PR yourself, once** — sub-agents deliver verified branches and never open or push to PRs. Verify locally first, then open one PR for the whole scope with `--assignee @me`; do not open it early or keep pushing to it (see `pull-requests.md`).
+10. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
 
 ---
 
@@ -107,6 +108,7 @@ When you receive a goal:
 - **Implementation before documentation** — documentation of new features must wait until the implementation is complete and reviewed.
 - **Build is a synchronisation point** — `dotnet build` must succeed before any frontend, spec, or documentation work that references generated proxies.
 - **Quality gates are always last** — code review and security review run after all implementation, specs, and documentation are complete.
+- **Cap local parallelism.** Delegated streams share this machine: limit each build and spec run (`dotnet -m:2`, `vitest --maxWorkers=2`), run one heavy phase at a time, and stagger parallel agents' builds so the machine stays responsive (see `verification-discipline.md`).
 - **Independent features** (no shared events) can be implemented in parallel via separate `planner` or `coordinator` invocations.
 
 ---

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

@@ -34,3 +34,4 @@ applyTo: "**/*"
 - Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`; it applies the exact `policy / verify` release-note rules and the Bash hook runs it on `gh pr create` and `gh pr edit`. If it fails, fix the description, not the code. Before every body edit, run `git diff --stat origin/main...HEAD` and delete bullets the diff no longer supports.
 - Run the affected-project gates before marking work ready (`dotnet build`/`dotnet test` with zero warnings, `yarn lint`, `npx tsc -b`), and the repository's required CI checks after an authorized push. `no-release` and documentation-only PRs still satisfy every required check; none is a blanket exemption from red CI.
 - Group small related changes into one branch and one PR; see the skill for consolidation and the release-action windows.
+- Open the PR once, when verified: each push starts CI. One PR per body of work, opened by the orchestrator (`cratis-engineering-release-trains`), with `--assignee @me`.

package/package/corpus/harnesses/copilot/instructions/verification-discipline.instructions.md

@@ -12,6 +12,7 @@ authored a file or preserve a chain of evidence about how it arrived.
 
 - Run the narrowest relevant build, type check, lint, and specifications while iterating; explain when a wider gate is required before completion or push/PR.
 - Run one phase per command with its real exit status. Budget targeted checks around 120 seconds and build/test phases around 300 seconds; explain any longer budget first, and obtain explicit approval before a phase exceeds 600 seconds. Stop on a failure; do not blindly retry or repeat passing tests on unchanged inputs without a flaky-test hypothesis or required matrix.
+- CI is not a feedback loop: run every gate locally before pushing. On a shared machine cap parallelism, one heavy phase at once (`cratis-engineering-ci-gates`).
 - Separate status/fetch from builds, Debug from Release, each test project, and frontend lint/compile/test/build. Do not combine these into an opaque command with a large outer timeout. Expose progress and cancellation; report the precise failed or timed-out phase and do not continue dependent phases after failure.
 - Never use `build/test | grep | sort/head/tail` as gate evidence. Capture the producer's exit status before summarising output; `pipefail` alone is insufficient with early-closing consumers such as `head`. Printed zero-error counts are not proof of success. Preserve needed full diagnostics in task-scoped `.ai-work/` logs rather than hiding them in `/tmp`.
 - Fast feedback is a product requirement: a spec takes milliseconds, the suite seconds; specs share setup and run in parallel; analyzers must not halt builds. CI builds the spec path without analyzers and enforces them, warnings as errors, in a parallel required job; the pre-push gate runs them. A slowdown is a defect.

package/package/corpus/harnesses/pi/agents/orchestrator.md

@@ -93,7 +93,8 @@ When you receive a goal:
 6. **Output a team plan** — always as a structured markdown checklist with agent assignments and phase labels.
 7. **Return or execute the plan** — default to a parent handoff; delegate only under the explicit large-scope contract.
 8. **Track overall progress** — after each phase, report what was completed and what remains.
-9. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
+9. **Open the PR yourself, once** — sub-agents deliver verified branches and never open or push to PRs. Verify locally first, then open one PR for the whole scope with `--assignee @me`; do not open it early or keep pushing to it (see `pull-requests.md`).
+10. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
 
 ---
 
@@ -103,6 +104,7 @@ When you receive a goal:
 - **Implementation before documentation** — documentation of new features must wait until the implementation is complete and reviewed.
 - **Build is a synchronisation point** — `dotnet build` must succeed before any frontend, spec, or documentation work that references generated proxies.
 - **Quality gates are always last** — code review and security review run after all implementation, specs, and documentation are complete.
+- **Cap local parallelism.** Delegated streams share this machine: limit each build and spec run (`dotnet -m:2`, `vitest --maxWorkers=2`), run one heavy phase at a time, and stagger parallel agents' builds so the machine stays responsive (see `verification-discipline.md`).
 - **Independent features** (no shared events) can be implemented in parallel via separate `planner` or `coordinator` invocations.
 
 ---

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

@@ -14,7 +14,7 @@ branch → commits → PR → merge → issue disposition → cleanup workflow.
 ## Inputs
 
 - **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>`
+- **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> --assignee @me`
 - **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,
@@ -41,6 +41,12 @@ another. The method is in the `cratis-engineering-release-trains` skill.
 
 ## Waiting on checks and merging
 
+Verify locally and open the PR once: CI is the final confirmation, not a feedback loop, so every
+gate runs on this machine first, with parallelism capped when other agents or builds share it
+(see `verification-discipline.md`). Do not open the PR early or keep pushing to it; each push
+starts checks on shared runners. Assign the PR to the user you run for with `--assignee @me`.
+When this prompt is run by an orchestrator or for sub-agent deliveries, the orchestrator opens the one PR.
+
 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

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

@@ -10,3 +10,5 @@ unassigned. Never guess an issue/repository, replace an assignee or reopen a
 closed issue. Report assignment failures and continue. The request to work on
 the issue authorizes this claim only, not comments, labels or closure; follow
 [pull-requests.md](./pull-requests.md) and the user's request for those.
+
+Assign each PR you open to the same user: `gh pr create --assignee @me`.

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

@@ -33,3 +33,4 @@ applyTo: "**/*"
 - Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`; it applies the exact `policy / verify` release-note rules and the Bash hook runs it on `gh pr create` and `gh pr edit`. If it fails, fix the description, not the code. Before every body edit, run `git diff --stat origin/main...HEAD` and delete bullets the diff no longer supports.
 - Run the affected-project gates before marking work ready (`dotnet build`/`dotnet test` with zero warnings, `yarn lint`, `npx tsc -b`), and the repository's required CI checks after an authorized push. `no-release` and documentation-only PRs still satisfy every required check; none is a blanket exemption from red CI.
 - Group small related changes into one branch and one PR; see the skill for consolidation and the release-action windows.
+- Open the PR once, when verified: each push starts CI. One PR per body of work, opened by the orchestrator (`cratis-engineering-release-trains`), with `--assignee @me`.

package/package/corpus/rules/verification-discipline.md

@@ -11,6 +11,7 @@ authored a file or preserve a chain of evidence about how it arrived.
 
 - Run the narrowest relevant build, type check, lint, and specifications while iterating; explain when a wider gate is required before completion or push/PR.
 - Run one phase per command with its real exit status. Budget targeted checks around 120 seconds and build/test phases around 300 seconds; explain any longer budget first, and obtain explicit approval before a phase exceeds 600 seconds. Stop on a failure; do not blindly retry or repeat passing tests on unchanged inputs without a flaky-test hypothesis or required matrix.
+- CI is not a feedback loop: run every gate locally before pushing. On a shared machine cap parallelism, one heavy phase at once (`cratis-engineering-ci-gates`).
 - Separate status/fetch from builds, Debug from Release, each test project, and frontend lint/compile/test/build. Do not combine these into an opaque command with a large outer timeout. Expose progress and cancellation; report the precise failed or timed-out phase and do not continue dependent phases after failure.
 - Never use `build/test | grep | sort/head/tail` as gate evidence. Capture the producer's exit status before summarising output; `pipefail` alone is insufficient with early-closing consumers such as `head`. Printed zero-error counts are not proof of success. Preserve needed full diagnostics in task-scoped `.ai-work/` logs rather than hiding them in `/tmp`.
 - Fast feedback is a product requirement: a spec takes milliseconds, the suite seconds; specs share setup and run in parallel; analyzers must not halt builds. CI builds the spec path without analyzers and enforces them, warnings as errors, in a parallel required job; the pre-push gate runs them. A slowdown is a defect.

package/package/corpus/skills/cratis-commits-and-pull-requests/references/pr-labels-and-release.md

@@ -17,7 +17,7 @@ See [commits.md](./commits.md) for logical grouping, message format and staging
 
 Confirm the current repository workflow contract before selecting release intent because release-intent labels can trigger publication. A direct request to ship with a named label authorizes applying that label and completing the repository's standard pull-request workflow, including the release it normally triggers. Do not ask for separate authorization at each step. If the user did not request shipping or publication, a proposed semantic label describes impact but does not grant authority.
 
-- Exactly one of `major`/`minor`/`patch`/`no-release`, set in the creating command (`gh pr create --label patch`), in every repository, including samples, docs and tooling repositories (`no-release` when nothing is shipped). To change intent, swap labels in one command: `gh pr edit <n> --remove-label minor --add-label patch`. Never add a second: with more than one of them, release-action releases nothing and reports `reason=error`. Re-running a `pull_request` workflow replays the original label payload, so fix a label mistake by editing the PR or pushing; a `workflow_dispatch` run needs an explicit `version` and the PR description as `release-notes`, and without notes it closes no issues.
+- Exactly one of `major`/`minor`/`patch`/`no-release`, set in the creating command (`gh pr create --label patch --assignee @me`), in every repository, including samples, docs and tooling repositories (`no-release` when nothing is shipped). To change intent, swap labels in one command: `gh pr edit <n> --remove-label minor --add-label patch`. Never add a second: with more than one of them, release-action releases nothing and reports `reason=error`. Re-running a `pull_request` workflow replays the original label payload, so fix a label mistake by editing the PR or pushing; a `workflow_dispatch` run needs an explicit `version` and the PR description as `release-notes`, and without notes it closes no issues.
 - Dependabot PRs carry only `no-release`. release-action never releases them, and the `major`/`minor`/`patch` Dependabot adds describe the dependency's version, not this product's.
 - Label the PR according to semantic versioning impact:
   - **major**: breaking changes to public APIs
@@ -43,11 +43,17 @@ Where the repository requires release intent, `no-release` is a decision, not an
 
 This covers, whenever the PR touches *only* these:
 
-- **Documentation**: anything under `Documentation/**`, READMEs, the `.cratis/ai/` corpus.
+- **Documentation**: anything under `Documentation/**`, READMEs, the `.cratis/ai/` copy installed in a consumer repository.
 - **CI and repository automation**: `.github/workflows/**`, `.github/scripts/**`, `.github/CODEOWNERS`, issue/PR templates.
 - **Tests and specs**: `*.Specs/**`, `when_*/**`, `for_*/**`, `Integration/**`, and test-only fixtures.
 - **Build and tooling configuration** that produces no shipped artifact difference: lint config, editor config, local scripts.
 
+**In Cratis/AI the corpus is the product.** Its skills, rules, prompts and hooks reach users through `@cratis/pi`, so a corpus change there is labelled by its effect on those users, like code:
+
+- `patch`: a fix to existing guidance, for example correcting a wrong command or a broken link in a skill.
+- `minor`: new or changed guidance, for example a new skill or a new required step in an existing one.
+- `no-release`: only when users cannot see the change, for example specs, evaluations or CI.
+
 The test is **outward-facing effect, not file location**. A change under `Source/**` that only touches specs is not shippable; a one-line change to a published package's behavior is, however small. If a consumer could not tell the difference by upgrading, there is nothing to version. When genuinely unsure, ask rather than defaulting to `patch`: an unnecessary release is not free. It burns a version number, ships release notes describing nothing, and buries the releases that matter.
 
 A non-release pull request must satisfy the relevant required checks like any other. Confirm label acceptance and publication suppression against the current workflow contract; do not assume external CI or API state.

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

@@ -72,6 +72,23 @@ 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.
 
+## Local first, and resource-aware
+
+CI is the final confirmation before merge and deploy, never a feedback loop.
+Run build, specifications, lint and frontend gates locally until green, then
+push. Do not push to see whether something compiles or passes, and do not use
+a red run to discover the next failure.
+
+Several agents, worktrees or builds often share one machine. Keep it responsive:
+
+- Cap parallelism, for example `dotnet build -m:2`, `dotnet test -m:2` with the
+  spec runner's thread limit, and `vitest run --maxWorkers=2`.
+- Run one heavy phase at a time (build, then specs, then frontend lint and
+  tests), never several at once.
+- Do not start a heavy phase while another agent's runs in the same machine's
+  checkout; wait or lower the cap, and do not retry a starved or timed-out phase
+  at full parallelism.
+
 ## Wait without polling
 
 After an authorized push, capture the full head SHA and discover the run for the

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

@@ -38,6 +38,9 @@ Before starting, read the issue, comments, assignees and any status block. Follo
 - Do this once, at the start before the first edit, not on every turn. If it
   fails (permissions or authentication), report it and continue with the work.
 
+Assign each PR you open the same way: `gh pr create --assignee @me`, or
+`gh pr edit <n> --add-assignee @me` afterwards.
+
 The request to work on the issue authorizes this assignment only, not comments,
 labels or closure. If another writer is active, coordinate rather than starting
 a parallel edit. Delegated workers do not claim or mutate the issue.

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

@@ -34,6 +34,16 @@ 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.
 
+## Open the PR once
+
+Each push to an open PR starts checks on shared runners. Push the branch for
+backup or hand-off if needed, but open the PR only once, when the work is
+verified locally and ready. Push to it again only for a correction that review
+or CI found. Do not open a draft PR to see what CI says. Related work goes into
+one PR (see below and `cratis-engineering-consolidation-guard`). An orchestrator
+opens the one PR; a sub-agent delivers a verified branch and does not open or
+push to a PR unless the request says so. Pass `--assignee @me` when creating it.
+
 ## Choose the candidate before creating a PR
 
 1. Inspect the repository's worktrees, finished branches, and open PRs:

package/package.json

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