@cratis/pi 7.90.0 → 7.90.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (4) hide show
  1. package/package/corpus/harnesses/copilot/instructions/pull-requests.instructions.md +3 -3
  2. package/package/corpus/prompts/ship-changes.prompt.md +1 -1
  3. package/package/corpus/rules/pull-requests.md +3 -3
  4. package/package.json +1 -1
package/package/corpus/harnesses/copilot/instructions/pull-requests.instructions.md CHANGED
@@ -7,7 +7,7 @@ applyTo: "**/*"
7
7
 
8
8
  ## The description is the release note
9
9
 
10
- **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.
10
+ **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.
11
11
 
12
12
  ### Allowed shape
13
13
 
@@ -82,12 +82,12 @@ Arc can now construct Chronicle reactors and reducers through its own dependency
82
82
 
83
83
  ### Before you create or edit a PR
84
84
 
85
- 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`.
85
+ 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`.
86
86
  2. Read the body against the forbidden list and the issue table above; delete every hit and verify every issue number.
87
87
  3. Sections in order, none empty, at most one summary form; every bullet user-facing.
88
88
  4. Test plan, verification and review notes are in a PR comment.
89
89
 
90
- If `verify-release-notes` fails, fix it by editing the description, not by pushing code.
90
+ If the release-note rules fail, fix the description, not the code.
91
91
 
92
92
  ## Commits
93
93
 
package/package/corpus/prompts/ship-changes.prompt.md CHANGED
@@ -51,7 +51,7 @@ The description is published verbatim as the release notes, so it follows the co
51
51
  - Post reviewer notes (checks run, what was not verified, review provenance, stacking, merge or
52
52
  deploy order) right after creating the PR with `gh pr comment <n> --body-file .ai-work/pr-notes.md`.
53
53
  Never put them in the description, even for `no-release`.
54
- - After pushing, if `verify-release-notes` fails, fix it by editing the description; it re-runs on edit.
54
+ - After pushing, if `policy / verify` fails on the release notes, fix it by editing the description; it re-runs on edit.
55
55
 
56
56
  ## Cleanup — the last step, never skipped
57
57
 
package/package/corpus/rules/pull-requests.md CHANGED
@@ -6,7 +6,7 @@ applyTo: "**/*"
6
6
 
7
7
  ## The description is the release note
8
8
 
9
- **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.
9
+ **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.
10
10
 
11
11
  ### Allowed shape
12
12
 
@@ -81,12 +81,12 @@ Arc can now construct Chronicle reactors and reducers through its own dependency
81
81
 
82
82
  ### Before you create or edit a PR
83
83
 
84
- 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`.
84
+ 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`.
85
85
  2. Read the body against the forbidden list and the issue table above; delete every hit and verify every issue number.
86
86
  3. Sections in order, none empty, at most one summary form; every bullet user-facing.
87
87
  4. Test plan, verification and review notes are in a PR comment.
88
88
 
89
- If `verify-release-notes` fails, fix it by editing the description, not by pushing code.
89
+ If the release-note rules fail, fix the description, not the code.
90
90
 
91
91
  ## Commits
92
92
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@cratis/pi",
3
- "version": "7.90.0",
3
+ "version": "7.90.1",
4
4
  "description": "Configuration-aware Cratis AI integration for Pi",
5
5
  "type": "module",
6
6
  "files": [