@cratis/pi 7.130.0 → 7.131.0

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

@@ -16,8 +16,10 @@ Authority in [`general.md`](../../../rules/general.md). Read this before any bro
   request or an applicable policy names that exact action. A configured browser tool is not
   a permit.
 - **[contract] One production tab per session.** No parallel polling or parallel findings on
-  production. Run the health check first, close idle browsers, and look for stale tabs from
-  other sessions before opening one.
+  production. Run the health check first and close your own idle pages before opening one.
+- **[contract] Close only what you opened.** Promptly close the browser backend you
+  started; if no shutdown tool exists, close your pages and report it. Subagents do the
+  same. Never touch a user's or shared session; no `pkill`/`killall`. One browser per lane.
 - **[convention] Prefer staging or a local copy** for interactive and visual smoke runs.
 - **[contract] Only the `browser-operator` agent receives browser tools.** Hand it the URL,
   scope, permit and artifact directory. The main session does not do browser work itself

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

@@ -33,5 +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 (build, built specs, lint and type-check; zero warnings), 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`.
+- The release train is the PR: fold finished branches into the repository's one train (see the skill). Open it once, when verified, as the orchestrator (`cratis-engineering-release-trains`) with `--assignee @me`. Split only for a named major, an urgent security fix authorized in writing, or an accepted outsider issue (patch or minor, own release).

package/package/corpus/rules/browser.md

@@ -15,8 +15,10 @@ Authority in [`general.md`](./general.md). Read this before any browser call.
   request or an applicable policy names that exact action. A configured browser tool is not
   a permit.
 - **[contract] One production tab per session.** No parallel polling or parallel findings on
-  production. Run the health check first, close idle browsers, and look for stale tabs from
-  other sessions before opening one.
+  production. Run the health check first and close your own idle pages before opening one.
+- **[contract] Close only what you opened.** Promptly close the browser backend you
+  started; if no shutdown tool exists, close your pages and report it. Subagents do the
+  same. Never touch a user's or shared session; no `pkill`/`killall`. One browser per lane.
 - **[convention] Prefer staging or a local copy** for interactive and visual smoke runs.
 - **[contract] Only the `browser-operator` agent receives browser tools.** Hand it the URL,
   scope, permit and artifact directory. The main session does not do browser work itself

package/package/corpus/rules/general.md

@@ -63,9 +63,9 @@ obtaining credentials, and other local conventions ("Product policy" above).
 
 Default to agentic behavior: inspect local rules, skills, code, tests, and generated patterns; make conservative assumptions supported by that context; implement and verify end to end when feasible. A user's direct request authorizes every clearly named in-scope action, including external effects such as pushing, opening or merging a pull request, applying the requested label, deployment, issue mutation, and operations against a named environment. The user is the authority for their request; do not require them to identify another approver, decision record, or formal operation profile.
 
-Don't interrupt with questions the repository can answer. Make reversible implementation choices and report them rather than asking the user to approve an implementation plan they already asked you to carry out. Once the user authorizes an action, do not ask them to authorize it again unless the target or consequence materially changes. Ask only when the answer can't be found locally, reasonable product or domain choices have meaningfully different consequences, a consequential effect was not included in the request, the change is hard to reverse and its scope is unclear, or the user asked for checkpoints.
+Decide what the repository or research can answer, record the evidence, and get a cross-provider check when the decision is risky. Report reversible choices instead of asking approval for a plan the user requested; do not re-ask for an authorized action unless its target or consequence materially changes. Deciding never widens the task's authorization ([capability-is-not-authority.md](./capability-is-not-authority.md)). Ask only about human-only matters (credentials, money, production access, legal, merging majors), undecided product choices with different consequences, an effect the request did not include, a hard-to-reverse change with unclear scope, or requested checkpoints.
 
-When a question is necessary, write it for the person doing the work, not for the governance system: explain the concrete choice, why it matters now, the consequence of each option, and the recommended option in plain language. Never present unexplained internal labels such as "execution authority," "capability contract," "delegation architecture," "operation profile," or "decider." Do not bundle unrelated verdicts. Ask who should be named in a durable decision record only after explaining that a significant decision has been made and why preserving it is warranted; a decision record is never a prerequisite for carrying out the user's direct request.
+Write a necessary question plainly: the choice, why now, each option's consequence, your recommendation. No unexplained internal labels ("execution authority," "operation profile," "decider"); do not bundle verdicts. A decision record never gates a direct request; offer one only after explaining the decision.
 
 ## Destructive operations
 

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

@@ -32,5 +32,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 (build, built specs, lint and type-check; zero warnings), 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`.
+- The release train is the PR: fold finished branches into the repository's one train (see the skill). Open it once, when verified, as the orchestrator (`cratis-engineering-release-trains`) with `--assignee @me`. Split only for a named major, an urgent security fix authorized in writing, or an accepted outsider issue (patch or minor, own release).

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

@@ -70,7 +70,7 @@ Do not open a pull request per task when the tasks belong to the same body of wo
 
 Before a consolidation or a re-land of reverted work merges, prove it dropped nothing with `cratis-engineering-consolidation-guard`.
 
-Split into separate pull requests when the changes are genuinely unrelated, when one is urgent and the others are not, or when one is risky enough to want its own revert.
+Split into a separate pull request only for the exceptions in `cratis-engineering-release-trains`: a named major awaiting human confirmation, an urgent security fix authorized in writing, or an accepted outsider issue. Unrelated or riskier work rides a later train instead.
 
 ## Quality gates
 

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

@@ -134,10 +134,20 @@ After the run completes with a failure:
 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.
+4. Flaky tests never hang a release. Classify within about 15 minutes from one
+   failed-log read and the test's history on main: real (in code the change
+   touched) or flaky. A flaky or pre-existing claim needs independent root-cause
+   validation; an unknown or repeating failure without a matching signature is
+   real and a blocker, not a quarantine candidate.
+   - Confirmed flake: after the run completes, rerun once, e.g.
+     `gh run rerun <id> --repo OWNER/REPO --failed`; a known flake with a
+     matching signature may go straight to quarantine. If it fails again,
+     quarantine the test in the same train via the repo's mechanism, open a
+     tracked "Flaky: <test>" issue with the evidence (label `flaky`), and push
+     once. Never quarantine silently or disable security or critical-path
+     coverage; if the security lens vetoes, evict the item or escalate.
+   - Real failure: fix in one round or evict the item. Never retry in loops; a
+     train waits at most one CI cycle on a flake.
 
 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.

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

@@ -13,7 +13,8 @@ compatibility: Requires git and the GitHub CLI (gh).
 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.
+separate branches. One person or session assembles the candidate. Even a single
+item ships as a train: the train is the PR, and item branches get no PR.
 
 ## Authority and routing
 
@@ -39,8 +40,8 @@ run handling, and `cratis-engineering-review-rounds` for proportionate review.
 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
+or CI found. Do not open a draft PR to see what CI says. All work goes into
+the repository's one train 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.
 
@@ -53,7 +54,7 @@ push to a PR unless the request says so. Pass `--assignee @me` when creating it.
    gh pr list --state open --json number,headRefName,title,author
    ```
 
-2. Group related, ready deliveries under one candidate and one PR. Check with
+2. Group 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
@@ -67,10 +68,14 @@ push to a PR unless the request says so. Pass `--assignee @me` when creating it.
    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.
+5. Keep one train per repository. Split only for a named major awaiting human
+   confirmation, an urgent security fix authorized in writing, or an accepted
+   issue reported by someone outside the organization (patch or minor), which
+   ships promptly on its own release right after private security work; issues
+   captured by internal bots are not outsider issues. Name the exception in the
+   reviewer comment. Other unrelated or differently risky work rides a later
+   train, not its own PR. Item branches get no PR, CI or
+   `run-integration` label; they get local gates and a delta review.
 
 Minimal assembly, after agreeing on the included deliveries:
 
@@ -103,19 +108,19 @@ 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
+## Cadence, 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.
+A train holds at most about 10 items, or one review slot of glue. Cut the next
+train as soon as the previous one merges, or at least every 4 hours while ready
+items wait. Never hold the cut for work that is not yet ready; keep items blocked
+on a design decision, consumer proof, or another repository out.
 
 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
+Record the cut 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
@@ -128,9 +133,17 @@ queued, do the next independent piece of work.
 - 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.
+- Evict a stuck or failing item instead of holding the train (next section).
+- Cut a train at least every 4 hours with whatever is green.
+
+## Evict, don't hold
+
+If train CI or the glue review fails and the failure is attributable to one
+item, revert that item out of the train with a revert commit (never rewrite
+history), push once, ship the rest, and send the item to the next train after
+its fix. Diagnose an unattributable failure; never evict the whole train blindly.
+Merge as soon as CI is green and the review passed (majors stay with a human),
+then cut the next train. A train's gate and CI run on the real merged state.
 
 ## Apply the ship bar
 
@@ -143,9 +156,10 @@ making a speculative shipping push. Recheck the merge conditions after CI.
    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.
+3. **Reviewed.** Each item head is certified in the review log and the
+   train's glue review (merge resolutions, fix-ups, main-merge conflict
+   resolutions) completed without Blockers or missing required evidence. A
+   whole-change review is needed only for an item without a review-log entry.
 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.
@@ -185,7 +199,7 @@ 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
+- **A PR per item or a delivery outside the train:** 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
@@ -195,7 +209,7 @@ steps. The next session must recheck the ship bar, not blindly merge on green.
 
 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.
+head. Confirm the review-log-certified items and glue 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-review-rounds/SKILL.md

@@ -22,12 +22,25 @@ advisory preference is not a merge gate. Missing required evidence yields
 
 ## 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.
+- Review each branch whole once, the first time or when the coordinator orders
+  it; a second round only after a blocker, not to seek reassurance.
+- After that, review deltas only: from the last reviewed head in the review
+  log to the new head. A certified item is never re-reviewed whole.
+- For a release train, review glue only: recreate the merge of the certified
+  item heads and review `git diff <that merge> <train head>` (merge resolutions,
+  fix-ups; for main merges, the conflict resolutions). Item reviews are not an
+  integration pass; the train's gate and CI still run on the merged state.
+- Start review 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.
+- Keep a review log at the path the coordinator names, default
+  `.ai-work/review-log.tsv` (ignored work area, configurable). Append one row per
+  attempt: repo, branch/PR, full base and head SHAs, run id, mode, ranges
+  covered, verdict (PASS / NOT PASS / INCOMPLETE), date. An attempt is always
+  recorded, but an unexamined partition never advances certified coverage.
+  Rerunning a missing partition at a later head covers its original base to head
+  range plus the new delta. An item is certified only with complete coverage, the
+  security lens run and blockers resolved; an incomplete slot is not a pass.
 - 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
@@ -84,8 +97,8 @@ later completes a valid review.
 
 ## 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
+A delta round is the default after a first whole review and reviews from the last
+reviewed SHA, not from an arbitrary base; take that SHA from the review log. 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.
 
@@ -106,8 +119,9 @@ 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. Dirty-tree feedback
 is preliminary, not reusable committed approval. Do not duplicate completed
-premium reviews or gates on unchanged exact reviewed scope; a bounded loop does
-not replace the final independent whole-change review or full required gates.
+premium reviews or gates on unchanged exact reviewed scope. Certified item
+coverage plus the train's glue or delta review replaces a repeat whole-change
+review; it never replaces the required gates, which run on the merged state.
 
 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.

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

@@ -4,9 +4,11 @@
   "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": "Review each branch whole once" },
+    { "kind": "skill-contains", "value": "review glue only" },
     { "kind": "skill-contains", "value": "SHA, not from an arbitrary base" },
+    { "kind": "skill-contains", "value": "covers its original base to head" },
+    { "kind": "skill-contains", "value": "an incomplete slot is not a pass" },
     { "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" },

package/package.json

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