@sous-io/sous 0.2.12 → 0.2.13

package/docs/markdown/commands.md

@@ -207,7 +207,8 @@ and `git config user.email`), because it commits and cuts annotated tags. Takes
 - `--no-bump`: raise nothing; a changed recipe that was never raised is then an error.
 - `--include-unchanged`: release every recipe in scope, changed or not.
 - `--tag`, `--push`: tag even on a non-default branch, and push the commit and this run's tags.
-- `--check`: only validate, and fail when the committed index is out of date.
+- `--check`: only validate. It fails on a problem the release would refuse, and reports, without failing, how
+  merging would rewrite the committed index.
 - `--ci`: the merge preset. Never bump, never ask, and fail on anything unbumped. It still needs `--yes` to
   accept the plan it prints, so a merge job runs `sous repo release --ci --yes --push`.
 

package/docs/markdown/repositories-authoring.md

@@ -195,8 +195,9 @@ third case is what a merge looks like to continuous integration: the bump is don
 
 `--namespace <ns>` and `--recipe <ns/name>` narrow the run and both repeat; `--bump <level>` is `patch` (the
 default), `minor`, `major` or `prerelease`; `--no-bump` raises nothing; `--include-unchanged` releases every
-recipe in scope, changed or not; `--check` only reads, validating and failing when the committed index is stale;
-and `--ci` is the merge preset: never bump, accept the plan, never ask, fail on anything unbumped. Every flag
+recipe in scope, changed or not; `--check` only reads, validating, failing on any problem the release would
+refuse, and reporting how merging would rewrite the committed index without failing on it, since that index is
+the release's output; and `--ci` is the merge preset: never bump, accept the plan, never ask, fail on anything unbumped. Every flag
 this command takes, `--tag`, `--push` and `--non-interactive` among them, is in the
 [command reference](commands.md#sous-repo-release).
 
@@ -244,7 +245,8 @@ give that identity to the account a continuous integration job runs as (the scaf
 `sous repo init` writes `.github/workflows/sous-release.yml`, which runs the same command in its two presets,
 calling the CLI from npm so nothing is installed into the repository. On a **pull request** it runs
 `npx --yes @sous-io/sous repo release --check`, which only reads, so it is safe on an untrusted branch and
-fails the pull request when a manifest is wrong or the committed index is stale. On a **push to `main`** it
+fails the pull request when a manifest is wrong or a published version changed, and notes how the merge will
+rewrite the index. On a **push to `main`** it
 runs `npx --yes @sous-io/sous repo release --ci --push --yes`; edit the workflow's `branches` list if your
 default branch has another name. `--ci` accepts the plan on its own, the redundant `--yes` keeping the file
 working with an older published sous. Both jobs check out with `fetch-depth: 0`, so existing tags are visible

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sous-io/sous",
-  "version": "0.2.12",
+  "version": "0.2.13",
   "description": "Compiles AI coding agent configuration (CLAUDE.md, skills, memories) from LiquidJS templates",
   "type": "module",
   "license": "Apache-2.0",

package/recipes/core/sous-skills/sous.recipe.yaml

@@ -11,7 +11,7 @@ formatVersion: 1
 
 namespace: core
 name: sous-skills
-version: 0.2.12
+version: 0.2.13
 
 description: >-
   The skills that teach an agent what sous is and how it works: which files sous

package/src/commands/repo/release.ts

@@ -40,12 +40,15 @@ import {
   type ValidationProblem,
 } from "../../lib/repos/release/index.js";
 import {
+  BULLET,
   blankLine,
   displayErrorBlock,
   dryRunNotice,
   footer,
   header,
   log,
+  note,
+  paragraph,
   section,
   showCommandVars,
   showVariables,
@@ -373,23 +376,22 @@ export default class RepoRelease extends Command {
     reportProblems(result.problems);
     if (hasErrors(result.problems)) return this.stopForErrors(result.problems);
 
-    if (!result.stale) {
+    // The index is the release's output, not the author's: the release that
+    // runs after a merge rewrites it before tagging. So drift here is reported
+    // as what merging will change, never as a failure; only the problems the
+    // index build raises above stop a check.
+    if (result.stale) {
+      note(`Merging rewrites the committed ${INDEX_FILENAME}, because:`);
+      for (const line of describeIndexDrift(existing, result.index)) {
+        paragraph(`${BULLET} ${line}`, { indent: 4, hangingIndent: 2 });
+      }
+      blankLine();
+    } else {
       log(`  The committed ${INDEX_FILENAME} is current, and so are the dependencies it`);
       log("  records for every version it publishes.");
-      reportPending(result, "These versions have no tag yet; they publish when this merges:");
-      footer();
-      return;
     }
-
-    const lines = [
-      `The committed ${INDEX_FILENAME} is out of date:`,
-      "",
-      ...describeIndexDrift(existing, result.index).map((line) => `  ${line}`),
-      "",
-      "Run 'sous repo release' to regenerate it, and commit what it writes.",
-    ];
-    displayErrorBlock(lines.join("\n"));
-    this.exit(1);
+    reportPending(result, "These versions have no tag yet; they publish when this merges:");
+    footer();
   }
 
   // --- Output ---------------------------------------------------------------------------------

package/src/lib/repos/scaffold/templates.ts

@@ -327,10 +327,10 @@ export function buildReleaseWorkflow(): string {
 # installed into this repository:
 #
 #   'sous repo release --check' validates every manifest, confirms each recipe
-#   folder matches what the repo manifest lists, and confirms the committed
-#   index agrees with the versions and dependencies the recipe manifests
-#   declare. It only reads; it never writes, commits or tags. That makes it the
-#   right thing to run on a pull request.
+#   folder matches what the repo manifest lists, and reports how merging would
+#   rewrite the committed index, which the release after a merge regenerates.
+#   It only reads; it never writes, commits or tags. That makes it the right
+#   thing to run on a pull request.
 #
 #   'sous repo release --ci --push --yes' does the same validation and then
 #   publishes. '--ci' raises no versions, accepts the plan it prints, and asks