@cratis/pi 7.89.0 → 7.90.1

package/package/corpus/harnesses/copilot/instructions/ai-distribution.instructions.md

@@ -90,10 +90,9 @@ Cratis behavior. The `engineering-` prefix identifies the maintainer audience;
 it does not imply confidential package contents or a private registry.
 
 The consuming repository owns its project facts, confidential behavior, local
-skills, and minimal host bootstraps. Use repository-owned documentation as canonical
-project context when that migration is active, `.agents/skills/` for private or
-repository-specific local workflows, and repository-owned documentation only as the
-documented legacy context fallback. Never merge, overwrite, or remove these
+skills, and minimal host bootstraps. Project-specific context is the repository's own
+documentation plus `.cratis/ai/rules/project.md`; `.agents/skills/` holds private or
+repository-specific local workflows. Never merge, overwrite, or remove these
 local files as a side effect of installing, updating, rolling back, or
 uninstalling shared AI capabilities.
 

package/package/corpus/harnesses/copilot/instructions/authoring-skills.instructions.md

@@ -85,7 +85,9 @@ When changing a description, run trigger evaluations before and after when autho
 
 ## 11. Always-on content
 
-Keep `general.md` to facts needed in every session, at most 200 lines. Warn above 24,000 bytes and above 91,000 combined bytes for rules without `paths`; line length alone can hide context bloat. Review globally applied Copilot instructions above 4,000 characters. These budgets leave room for source and task context, rather than promising a token count.
+Keep `general.md` to facts needed in every session, at most 200 lines. Warn above 24,000 bytes and above 91,000 combined bytes for rules without `paths`; line length alone can hide context bloat. Review globally applied Copilot instructions above 4,000 characters. These budgets leave room for source and task context, rather than promising a token count. The corpus verification caps the rule bytes each harness loads at session start and fails above a cap: displace or demote text to an on-demand skill, or raise the cap in a reviewed change.
+
+Every proposed rule names its enforcement: analyzer-enforceable, CI-enforceable or judgment-shaped. The first two ship as the analyzer, lint or CI check, with at most a one-line pointer in prose; only judgment-shaped rules are written out, because prose does not enforce itself and costs context in every session that loads it.
 
 Use path-scoped rules for file-specific invariants and skills for particular operations. Hooks and CI enforce mechanical constraints; natural-language rules do not replace permission controls.
 

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

@@ -7,7 +7,7 @@ applyTo: "**/*"
 
 ## The description is the release note
 
-**The PR description is published verbatim as the GitHub release. In repositories released by `cratis/release-action`, it also closes every issue written as `(#n)`; elsewhere, follow the repository's own release and issue-closing process.** Write the note the person upgrading should read, not a development write-up. The same contract applies to release notes typed into a manual workflow run or written straight into a release. Where it is installed, the `verify-release-notes` check enforces it on release-bound PRs into the default branch carrying `major`/`minor`/`patch` (it re-runs when the label is added); it warns on `no-release` and unlabelled PRs, which must still be written this way because any of them may become releasable. `release-action` does not run for a `no-release` PR, so `(#n)` closes nothing there. Editing the description re-runs the check. HTML comments are not shown on the release page and the check ignores them for headings, keywords and placeholders, and `release-action` removes them before publishing, so a `(#n)` only inside a comment closes nothing; the check fails it, so never put an issue reference in a comment. The template's own comment can stay: its `(#123)` examples are inline code, and the comment is not published.
+**The PR description is published verbatim as the GitHub release. In repositories released by `cratis/release-action`, it also closes every issue written as `(#n)`; elsewhere, follow the repository's own release and issue-closing process.** Write the note the person upgrading should read, not a development write-up. The same contract applies to release notes typed into a manual workflow run or written straight into a release. Where it is installed, the `policy / verify` check enforces it on release-bound PRs into the default branch carrying `major`/`minor`/`patch` (it re-runs when the label is added); its release-note step warns on `no-release` and unlabelled PRs, which must still be written this way because any of them may become releasable. `release-action` does not run for a `no-release` PR, so `(#n)` closes nothing there. Editing the description re-runs the check. HTML comments are not shown on the release page and the check ignores them for headings, keywords and placeholders, and `release-action` removes them before publishing, so a `(#n)` only inside a comment closes nothing; the check fails it, so never put an issue reference in a comment. The template's own comment can stay: its `(#123)` examples are inline code, and the comment is not published.
 
 ### Allowed shape
 
@@ -82,12 +82,12 @@ Arc can now construct Chronicle reactors and reducers through its own dependency
 
 ### Before you create or edit a PR
 
-1. Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`. It runs the exact `verify-release-notes` rules plus the label and diff checks, and the Bash hook runs it on `gh pr create` and `gh pr edit`.
+1. Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`. It runs the exact `policy / verify` release-note rules plus the label and diff checks, and the Bash hook runs it on `gh pr create` and `gh pr edit`.
 2. Read the body against the forbidden list and the issue table above; delete every hit and verify every issue number.
 3. Sections in order, none empty, at most one summary form; every bullet user-facing.
 4. Test plan, verification and review notes are in a PR comment.
 
-If `verify-release-notes` fails, fix it by editing the description, not by pushing code.
+If the release-note rules fail, fix the description, not the code.
 
 ## Commits
 

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

@@ -51,7 +51,7 @@ The description is published verbatim as the release notes, so it follows the co
 - Post reviewer notes (checks run, what was not verified, review provenance, stacking, merge or
   deploy order) right after creating the PR with `gh pr comment <n> --body-file .ai-work/pr-notes.md`.
   Never put them in the description, even for `no-release`.
-- After pushing, if `verify-release-notes` fails, fix it by editing the description; it re-runs on edit.
+- After pushing, if `policy / verify` fails on the release notes, fix it by editing the description; it re-runs on edit.
 
 ## Cleanup — the last step, never skipped
 

package/package/corpus/rules/ai-distribution.md

@@ -89,10 +89,9 @@ Cratis behavior. The `engineering-` prefix identifies the maintainer audience;
 it does not imply confidential package contents or a private registry.
 
 The consuming repository owns its project facts, confidential behavior, local
-skills, and minimal host bootstraps. Use repository-owned documentation as canonical
-project context when that migration is active, `.agents/skills/` for private or
-repository-specific local workflows, and repository-owned documentation only as the
-documented legacy context fallback. Never merge, overwrite, or remove these
+skills, and minimal host bootstraps. Project-specific context is the repository's own
+documentation plus `.cratis/ai/rules/project.md`; `.agents/skills/` holds private or
+repository-specific local workflows. Never merge, overwrite, or remove these
 local files as a side effect of installing, updating, rolling back, or
 uninstalling shared AI capabilities.
 

package/package/corpus/rules/authoring-skills.md

@@ -84,7 +84,9 @@ When changing a description, run trigger evaluations before and after when autho
 
 ## 11. Always-on content
 
-Keep `general.md` to facts needed in every session, at most 200 lines. Warn above 24,000 bytes and above 91,000 combined bytes for rules without `paths`; line length alone can hide context bloat. Review globally applied Copilot instructions above 4,000 characters. These budgets leave room for source and task context, rather than promising a token count.
+Keep `general.md` to facts needed in every session, at most 200 lines. Warn above 24,000 bytes and above 91,000 combined bytes for rules without `paths`; line length alone can hide context bloat. Review globally applied Copilot instructions above 4,000 characters. These budgets leave room for source and task context, rather than promising a token count. The corpus verification caps the rule bytes each harness loads at session start and fails above a cap: displace or demote text to an on-demand skill, or raise the cap in a reviewed change.
+
+Every proposed rule names its enforcement: analyzer-enforceable, CI-enforceable or judgment-shaped. The first two ship as the analyzer, lint or CI check, with at most a one-line pointer in prose; only judgment-shaped rules are written out, because prose does not enforce itself and costs context in every session that loads it.
 
 Use path-scoped rules for file-specific invariants and skills for particular operations. Hooks and CI enforce mechanical constraints; natural-language rules do not replace permission controls.
 

package/package/corpus/rules/general.md

@@ -47,10 +47,8 @@ repository. Individual projects need extra context that does not belong here,
 such as product composition, approved environment names, directions for
 obtaining credentials, and other local conventions ("Product policy" above).
 
-- Read repository-owned documentation as the canonical project-specific context when it
-  exists.
-- Read repository-owned documentation only as the documented legacy fallback when
-  repository-owned documentation does not exist; never merge both contexts.
+- Project-specific context is the repository's own documentation plus
+  `.cratis/ai/rules/project.md`.
 - Project context may explain which approved secret mechanism or local setup to
   use, but it must never contain credential values, tokens, keys, passwords, or
   other secrets.

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

@@ -6,7 +6,7 @@ applyTo: "**/*"
 
 ## The description is the release note
 
-**The PR description is published verbatim as the GitHub release. In repositories released by `cratis/release-action`, it also closes every issue written as `(#n)`; elsewhere, follow the repository's own release and issue-closing process.** Write the note the person upgrading should read, not a development write-up. The same contract applies to release notes typed into a manual workflow run or written straight into a release. Where it is installed, the `verify-release-notes` check enforces it on release-bound PRs into the default branch carrying `major`/`minor`/`patch` (it re-runs when the label is added); it warns on `no-release` and unlabelled PRs, which must still be written this way because any of them may become releasable. `release-action` does not run for a `no-release` PR, so `(#n)` closes nothing there. Editing the description re-runs the check. HTML comments are not shown on the release page and the check ignores them for headings, keywords and placeholders, and `release-action` removes them before publishing, so a `(#n)` only inside a comment closes nothing; the check fails it, so never put an issue reference in a comment. The template's own comment can stay: its `(#123)` examples are inline code, and the comment is not published.
+**The PR description is published verbatim as the GitHub release. In repositories released by `cratis/release-action`, it also closes every issue written as `(#n)`; elsewhere, follow the repository's own release and issue-closing process.** Write the note the person upgrading should read, not a development write-up. The same contract applies to release notes typed into a manual workflow run or written straight into a release. Where it is installed, the `policy / verify` check enforces it on release-bound PRs into the default branch carrying `major`/`minor`/`patch` (it re-runs when the label is added); its release-note step warns on `no-release` and unlabelled PRs, which must still be written this way because any of them may become releasable. `release-action` does not run for a `no-release` PR, so `(#n)` closes nothing there. Editing the description re-runs the check. HTML comments are not shown on the release page and the check ignores them for headings, keywords and placeholders, and `release-action` removes them before publishing, so a `(#n)` only inside a comment closes nothing; the check fails it, so never put an issue reference in a comment. The template's own comment can stay: its `(#123)` examples are inline code, and the comment is not published.
 
 ### Allowed shape
 
@@ -81,12 +81,12 @@ Arc can now construct Chronicle reactors and reducers through its own dependency
 
 ### Before you create or edit a PR
 
-1. Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`. It runs the exact `verify-release-notes` rules plus the label and diff checks, and the Bash hook runs it on `gh pr create` and `gh pr edit`.
+1. Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`. It runs the exact `policy / verify` release-note rules plus the label and diff checks, and the Bash hook runs it on `gh pr create` and `gh pr edit`.
 2. Read the body against the forbidden list and the issue table above; delete every hit and verify every issue number.
 3. Sections in order, none empty, at most one summary form; every bullet user-facing.
 4. Test plan, verification and review notes are in a PR comment.
 
-If `verify-release-notes` fails, fix it by editing the description, not by pushing code.
+If the release-note rules fail, fix the description, not the code.
 
 ## Commits
 

package/package/corpus/skills/cratis-engineering-regression-cluster/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-regression-cluster/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: cratis-engineering-regression-cluster
+description: Stop fixing instances when one surface keeps breaking - name the failure class, add the gate that owns it, prove the gate fails, then fix the instance. Use when a third bug, regression, revert or review finding lands on the same screen, endpoint, command, workflow or module, when the same kind of fix keeps being reapplied, or when asked why something keeps breaking. Not for a first or isolated bug (fix it with a regression specification), for proving a consolidation dropped nothing (use cratis-engineering-consolidation-guard), or for a boundary that reports success after failing (use cratis-engineering-effect-boundaries).
+license: LICENSE
+---
+
+# The third issue on one surface names a failure class
+
+Each bug fixed alone adds one specification for one symptom. When the same
+**surface** (one screen, endpoint, command, query, workflow, module or rule
+area) breaks a third time, the instances share a cause that no specification
+owns yet, and the fourth instance is already on its way. Stop fixing instances:
+name the **failure class**, give it an **owning gate**, then fix the instance.
+
+## Count first
+
+Before fixing an issue, count the earlier ones on its surface:
+
+```bash
+gh issue list --state all --search "<surface> in:title,body" --limit 50
+git log --oneline -- <paths of the surface>
+```
+
+Count bugs, regressions, reverts and review findings, open or closed. Fewer
+than three: fix the instance with a regression specification. Three or more:
+follow the steps below before writing the fix.
+
+## Steps
+
+1. **Name the failure class** in one sentence that states the property being
+   violated, not the symptom. Each earlier issue must be an instance of it, and
+   a reader must be able to recognize the next one by it. "Owner filter shows
+   archived items" is a symptom; "list filters are not exercised through the
+   rendered list by any test" is a class.
+2. **Choose the owning gate by enforcement kind**, preferring the earliest that
+   can catch the class: an analyzer (compile time), a lint rule, a CI check or
+   verification script, or one specification suite that covers every member of
+   the class (every filter, every endpoint), not one specification per bug. A
+   class that only judgment can catch gets a review checklist entry, and the
+   choice is stated as judgment-shaped; see the enforcement rule in
+   [authoring-skills.md](../../rules/authoring-skills.md).
+3. **Prove the gate fails** on the current broken instance, or on the earlier
+   instances with their fixes reverted, before fixing anything. A gate that
+   passes on the broken code owns nothing; follow
+   [guards-and-fuses.md](../../rules/guards-and-fuses.md) so it cannot pass
+   vacuously.
+4. **Register the class.** When the repository keeps a failure-class table or
+   gate inventory, add one row: class, owning gate, where it runs. Otherwise
+   put the class name in the gate's failure message and the specification or
+   check name, so the next failure names its class.
+5. **Fix the instance**; the gate turns green. Run it with the repository's
+   normal gates, and make it a required CI check when it lives in CI.
+6. **Close the loop.** Link the earlier issues to the class in the pull request
+   comment, and leave a prose rule only for the judgment-shaped part.
+
+## Report
+
+State the surface and the issues counted, the class sentence, the gate and
+where it runs, that it failed before the fix and passes after, and anything
+left judgment-shaped.
+
+## Pitfalls
+
+- **A fourth instance specification.** Copying the third fix's specification
+  for the new symptom covers the symptom, not the class.
+- **A prose rule instead of a gate.** Rules nobody enforces were already in
+  place for the earlier instances; text costs context and catches nothing.
+- **A class named after the symptom.** If the next instance would not be
+  recognized by the sentence, the class is still too narrow.
+- **A gate that never ran red.** Without the failing run, nothing shows it can
+  catch the class.
+- **A loose surface.** Three unrelated bugs in one large module are not a
+  cluster; narrow the surface until the issues share a cause.

package/package/profile-catalog.json

@@ -993,6 +993,7 @@
         "cratis-engineering-decision-record",
         "cratis-engineering-docs-authoring",
         "cratis-engineering-effect-boundaries",
+        "cratis-engineering-regression-cluster",
         "cratis-release-notes",
         "cratis-technical-examples"
       ],

package/package.json

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