@flumecode/runner 0.21.0-beta.1 → 0.22.0

package/dist/cli.js

@@ -1065,56 +1065,35 @@ function buildRepairPrompt(ctx, hookLog) {
   ];
   return lines2.join("\n");
 }
-function buildReleasePrompt(ctx, baseChecks) {
-  const task = `Use the \`flumecode:create-release\` skill to handle this turn. You are driving a release: first analyse commits since the last tag, propose version bumps, and ask the user to confirm via widgets (Phase 1); once the user's widget answers appear in the thread, apply the bumps to package.json files and update CHANGELOG.md (Phase 2). Do NOT commit or push \u2014 the runner handles that and opens the bump PR.`;
+function buildReleasePrompt(ctx) {
+  const task = `Use the \`flumecode:create-release\` skill to handle this turn. You are driving a release: first analyse commits since the last tag, propose version bumps, and ask the user to confirm via widgets (Phase 1); once the user's widget answers appear in the thread, emit the final report with the confirmed versions (Phase 2). Do NOT edit package.json or CHANGELOG.md, do NOT commit, push, or open a PR.`;
   const orient = `Before investigating raw source, check for a FlumeCode wiki at \`.flumecode/wiki/\`. If it exists, read \`.flumecode/wiki/README.md\` first \u2014 it is the index \u2014 and follow its links to the pages and source paths relevant to this release. If there is no wiki, work from the code directly.`;
   const widgets = `When you need the user to choose, ask it as a widget rather than writing the options as prose: call \`single_select\` for a one-of-N choice (radio buttons) or \`multi_select\` for a "select all that apply" choice (checkboxes). Don't add your own "Other" option \u2014 the UI always provides one. After calling a widget tool, end your turn \u2014 the user's answer comes back as their next message and starts a fresh run.`;
   const lines2 = [
     `You are "${ctx.agentName}", an autonomous coding agent driving a FlumeCode release.`,
-    `The repository ${ctx.repo.fullName} is checked out in your current working directory on the release bump branch "${ctx.repo.checkoutBranch}".`,
+    `The repository ${ctx.repo.fullName} is checked out in your current working directory at the frozen release commit (branch "${ctx.repo.checkoutBranch}").`,
     task,
     orient,
     widgets,
     LANGUAGE_DIRECTIVE,
     "",
-    "These coding guidelines apply to all code produced in this run:",
-    "",
-    loadRule("coding-guideline"),
-    "",
     `# Release: ${ctx.request?.title ?? ""}`
   ];
   if (ctx.request?.body) {
     lines2.push("", ctx.request.body);
   }
-  if (baseChecks && !baseChecks.ok) {
-    lines2.push(
-      "",
-      "# Pre-release check status",
-      "",
-      "\u26A0\uFE0F The repository's pre-commit checks (lint / typecheck / tests) are currently FAILING on the base branch, independently of any version bump. A release must not ship a broken base:",
-      "",
-      "- **Phase 1 (propose):** tell the user, in your reply, that the base currently fails these checks and that the release will fix them as part of the bump.",
-      "- **Phase 2 (apply):** fix the failing code at its root so the checks pass, THEN apply the version bumps and CHANGELOG. Do NOT delete/skip tests or weaken assertions. The fixes ship in the same bump PR. Still do NOT commit or push \u2014 the runner does.",
-      "",
-      "Failing check output:",
-      "",
-      "```",
-      baseChecks.log,
-      "```"
-    );
-  }
   if (ctx.prerelease) {
     lines2.push(
       "",
       "# Pre-release",
       "",
-      "This is a PRE-RELEASE. When proposing and applying versions, use a semver pre-release version string (e.g. `0.9.0-beta.1`): take the next stable version you would otherwise pick and append `-beta.N`, where N is the next unused beta number for that version (check existing `v<version>-beta.*` tags). Offer these pre-release strings in the version-confirmation widgets, and write them to package.json, CHANGELOG.md, and the `flumecode:versions` comment as usual."
+      "This is a PRE-RELEASE. When proposing versions, use a semver pre-release version string (e.g. `0.9.0-beta.1`): take the next stable version you would otherwise pick and append `-beta.N`, where N is the next unused beta number for that version (check existing `v<version>-beta.*` tags). Offer these pre-release strings in the version-confirmation widgets, and include them in the `flumecode:versions` comment as usual."
     );
   }
   appendThread(lines2, ctx);
   lines2.push(
     "",
-    "Your final reply is posted verbatim as your comment in the release thread \u2014 if you called widgets (Phase 1), your reply text accompanies the questions; if you applied the bumps (Phase 2), make it the report the skill produced. The runner appends the pull-request link."
+    "Your final reply is posted verbatim as your comment in the release thread \u2014 if you called widgets (Phase 1), your reply text accompanies the questions; if you emitted the final report (Phase 2), make it the report the skill produced."
   );
   return lines2.join("\n");
 }
@@ -1311,27 +1290,6 @@ function commitFailureLog(err) {
   const parts = [e.stdout, e.stderr].map((s) => typeof s === "string" ? s.trim() : "").filter((s) => s.length > 0);
   return parts.length > 0 ? parts.join("\n") : e.message ?? String(err);
 }
-function isUnsupportedGitSubcommand(err) {
-  const e = err;
-  const text = `${typeof e.stderr === "string" ? e.stderr : ""}
-${e.message ?? ""}`;
-  return /is not a git command|unknown subcommand|usage: git hook/i.test(text);
-}
-async function runRepoChecks(dir) {
-  try {
-    await git(["-C", dir, "hook", "run", "pre-commit"]);
-    logEvent("checks", "pre-commit hook passed");
-    return { ok: true, log: "", skipped: false };
-  } catch (err) {
-    if (isUnsupportedGitSubcommand(err)) {
-      logEvent("checks", "pre-commit hook skipped (git too old)");
-      return { ok: true, log: "", skipped: true };
-    }
-    const log = commitFailureLog(err);
-    logEvent("checks:err", log);
-    return { ok: false, log, skipped: false };
-  }
-}
 async function commitChanges(ctx, dir) {
   if (!await hasChanges(dir)) return false;
   try {
@@ -1428,10 +1386,9 @@ async function openPullRequest(ctx) {
     return { number: data.number, url: data.html_url };
   }
   if (res.status === 422) {
-    const list = await fetch(
-      `${apiBase}/pulls?state=open&head=${owner}:${checkoutBranch}&base=${mergeBranch}`,
-      { headers }
-    );
+    const list = await fetch(`${apiBase}/pulls?state=open&head=${owner}:${checkoutBranch}`, {
+      headers
+    });
     if (list.ok) {
       const open = await list.json();
       if (open[0]) return { number: open[0].number, url: open[0].html_url };
@@ -1897,48 +1854,26 @@ async function processResolveJob(ctx, dir, config, abort) {
   reply += outcomeBanner(outcome, { branch: ctx.repo.checkoutBranch });
   return { text: reply, widgets: [], ...report ? { report } : {}, ...pr ? { pr } : {} };
 }
-async function processReleaseJob(ctx, dir, resumed, config, abort) {
+async function processReleaseJob(ctx, dir, _resumed, _config, abort) {
   console.log(`
 \u25B6 Release ${ctx.jobId} \u2014 ${ctx.repo.fullName}: "${jobTitle(ctx)}"`);
-  const installResult = await installDependencies(dir);
-  const checks = await runRepoChecks(dir);
-  if (checks.skipped) {
-    console.log(`  \u2026release ${ctx.jobId}: pre-release checks skipped (git too old for 'hook run')`);
-  } else {
-    console.log(`  \u2026release ${ctx.jobId}: pre-release checks ${checks.ok ? "passed" : "FAILED"}`);
-  }
-  const baseChecks = checks.ok ? void 0 : { ok: false, log: trimHookLog(checks.log) };
+  await installDependencies(dir);
   const result = await runClaudeCode({
     cwd: dir,
-    prompt: buildReleasePrompt(ctx, baseChecks),
+    prompt: buildReleasePrompt(ctx),
     permissionMode: ctx.permissionMode,
     model: orchestratorModel(ctx),
     maxTurns: ORCHESTRATOR_MAX_TURNS,
     abortController: abort
   });
-  let reply = result.text.trim() || "(the agent produced no reply)";
-  if (installResult.status === "failed") {
-    reply += `
-
-> \u26A0\uFE0F Dependencies failed to install (\`${installResult.manager}\`); tests may not have run.`;
-  }
+  const reply = result.text.trim() || "(the agent produced no reply)";
   if (result.widgets.length > 0) {
     console.log(
       `  \u2026release ${ctx.jobId} posted ${result.widgets.length} widget(s); awaiting reply`
     );
     return { text: reply, widgets: result.widgets };
   }
-  const { outcome, autoMerged } = await pushAndOpenPr(ctx, dir, config, abort, {
-    rebase: !resumed
-  });
-  if (outcome.kind !== "none") {
-    reply += outcomeBanner(outcome, { branch: ctx.repo.checkoutBranch, autoMerged });
-  }
-  return {
-    text: reply,
-    widgets: [],
-    ...outcome.kind === "pr" ? { pr: outcome.pr } : {}
-  };
+  return { text: reply, widgets: [] };
 }
 async function heartbeat(config) {
   const health = await checkClaudeCode();
@@ -2075,7 +2010,7 @@ ${trimmed}` : trimmed;
 }
 function formatJobError(ctx, err) {
   if (!(err instanceof PreCommitError)) return errorMessage2(err);
-  const nextStep = ctx.kind === "release" ? `These checks are failing on \`${ctx.repo.mergeBranch}\` independently of the version bump, and the release couldn't fix them after ${MAX_COMMIT_REPAIRS} automatic attempts. Open a request on **${ctx.repo.fullName}** to fix the failing checks above, then start the release again once that fix has merged.` : `The agent couldn't get its change past these checks after ${MAX_COMMIT_REPAIRS} automatic repair attempts. Open a request on **${ctx.repo.fullName}** describing the failing checks above so the agent can fix them at their root, then try again.`;
+  const nextStep = ctx.kind === "release" ? `These checks are failing on \`${ctx.repo.mergeBranch}\` independently of this release, and the release couldn't fix them after ${MAX_COMMIT_REPAIRS} automatic attempts. Open a request on **${ctx.repo.fullName}** to fix the failing checks above, then start the release again once that fix has merged.` : `The agent couldn't get its change past these checks after ${MAX_COMMIT_REPAIRS} automatic repair attempts. Open a request on **${ctx.repo.fullName}** describing the failing checks above so the agent can fix them at their root, then try again.`;
   return [
     "\u274C **Blocked by failing pre-commit checks.**",
     "",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flumecode/runner",
-  "version": "0.21.0-beta.1",
+  "version": "0.22.0",
   "type": "module",
   "description": "FlumeCode local runner — claims jobs and drives your local Claude Code against a real checkout.",
   "bin": {

package/skills-plugin/skills/create-release/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: create-release
 description: >-
-  Draft release notes and version suggestions for a release, then (after the
-  user confirms) open a bump PR that updates package.json version(s) and
-  CHANGELOG.md. Two-turn flow: first turn asks the user to confirm versions via
-  widgets; second turn (answers in thread) writes the bumps and opens the PR.
+  Draft release notes and version suggestions for a release. Two-turn flow:
+  first turn asks the user to confirm versions via widgets; second turn (answers
+  in thread) emits the structured report with confirmed versions and notes. Does
+  NOT edit package.json or CHANGELOG.md, and does NOT commit, push, or open a PR.
 ---
 
 # create-release
@@ -17,7 +17,7 @@ which one applies before acting.
 Check the thread (`# Conversation so far` in the prompt). If **no widget answers**
 appear in any prior agent turn, this is **Phase 1** — propose versions and ask.
 If a prior turn contains widget-answer selections (the user picked a version), this
-is **Phase 2** — apply the bumps and report.
+is **Phase 2** — emit the final report.
 
 ---
 
@@ -99,11 +99,11 @@ can read them inside the question widget:
 - `options`: `Yes, use these notes`, `I'll edit them in the PR`
   (You may still summarise in the reply text, but the notes MUST be in the widget `body`.)
 
-**After calling widgets, end your turn.** Do NOT open a PR in Phase 1.
+**After calling widgets, end your turn.** Do NOT edit any files in Phase 1.
 
 ---
 
-## Phase 2 — Apply the bumps and report
+## Phase 2 — Emit the final report
 
 ### 1. Read the widget answers
 
@@ -111,52 +111,19 @@ The user's confirmed version selections appear in the `# Conversation so far`
 thread as agent messages (the widget-answer turn). Extract the chosen version for
 each package from those selections.
 
-### 2. Update package.json files
+### 2. Emit the structured report
 
-For each package whose version changed, edit the `"version"` field in:
-
-- `apps/web/package.json` — for `@flumecode/web`
-- `apps/runner/package.json` — for `@flumecode/runner`
-
-Change only the `"version"` line; do not reformat the file.
-
-### 3. Update CHANGELOG.md
-
-Edit (or create) `CHANGELOG.md` at the repo root. Insert a new section at the
-top, below any existing `# Changelog` title line:
+Your final message must match this shape (adjust versions and notes to match what
+was confirmed):
 
 ```
-## [X.Y.Z / runner-X.Y.Z] - YYYY-MM-DD
+**Confirmed versions:**
+- `@flumecode/web`: `0.9.0`
+- `@flumecode/runner`: `0.5.0`
 
+**Release notes:**
 - Bullet point from release notes
 - Another bullet point
-```
-
-Use the ISO date format (`YYYY-MM-DD`). Preserve all existing entries — do not
-delete or rewrite prior sections.
-
-If both packages are bumped, list both versions in the heading (e.g.
-`## [0.9.0 / runner-0.5.0] - 2026-06-06`). If only one package is bumped, list
-only that version in the heading.
-
-### 4. Stop — do not commit or push
-
-Leave the edited files in the working tree. The runner commits them and opens the
-pull request.
-
-### 5. End with this exact report format
-
-Your final message must match this shape (adjust versions and files to match what
-actually changed):
-
-```
-**Bumped versions:**
-- `@flumecode/web`: `0.8.0` → `0.9.0`
-- `@flumecode/runner`: `0.4.0` → `0.5.0`
-
-**CHANGELOG updated** with release notes.
-
-**Files changed:** `apps/web/package.json`, `apps/runner/package.json`, `CHANGELOG.md`
 
 <!-- flumecode:versions {"@flumecode/web":"0.9.0","@flumecode/runner":"0.5.0"} -->
 ```
@@ -167,21 +134,20 @@ reads it to persist the confirmed versions on the release entity. Use the exact
 JSON key names `@flumecode/web` and `@flumecode/runner`; omit a package if its
 version did not change.
 
+**Do NOT edit package.json, CHANGELOG.md, or any other file. Do NOT commit,
+push, or open a pull request.** The GitHub Release is cut directly from the
+frozen commit by the web interface.
+
 ---
 
 ## Notes
 
-- **Runner-only bump:** if only `apps/runner/` has commits, bump only
-  `apps/runner/package.json`. Leave `apps/web/package.json` unchanged.
+- **Runner-only bump:** if only `apps/runner/` has commits, include only
+  `apps/runner/package.json`'s version in the `flumecode:versions` comment.
 - **Clear Phase 1 text:** be explicit about what changed since the last tag so the
   user can confidently confirm or override your suggestions.
-- **Edit only version files — with one exception.** Normally edit only
-  `apps/web/package.json`, `apps/runner/package.json`, and `CHANGELOG.md`. The sole
-  exception: when the prompt includes a **`# Pre-release check status`** section
-  reporting failing checks, you must also fix the failing code (any file needed) so
-  the tree is green — see "Pre-release checks" below. Never weaken or skip checks to
-  silence them.
-- **Never commit, push, or open a PR** — the runner does that.
+- **Read-only:** do not edit any files at any point. This skill is purely
+  analytical — it reads the repo, proposes versions, and emits a report.
 
 ## Pre-release
 
@@ -202,27 +168,6 @@ pre-release version strings instead of stable ones:
   `0.9.0-beta.1`) in the version-confirmation widgets instead of the stable
   version.
 
-- **Phase 2 (apply):** write the pre-release version string (e.g.
-  `0.9.0-beta.1`) to `package.json`, `CHANGELOG.md`, and the
-  `<!-- flumecode:versions {...} -->` comment — exactly as you would for a
-  stable release, just with the pre-release suffix included.
-
----
-
-## Pre-release checks
-
-We cannot release code with failing checks. Before this turn, the runner ran the
-repository's own pre-commit hook (lint / typecheck / tests). If the prompt contains
-a **`# Pre-release check status`** section, the base branch is currently broken
-_independently of the version bump_:
-
-- **Phase 1:** state plainly in your reply that the base currently fails these
-  checks and that the release will fix them as part of the bump, then ask the
-  version questions as usual.
-- **Phase 2:** fix the failing code at its root **first** (so the checks pass),
-  **then** apply the version bumps and CHANGELOG. The fixes ship in the same bump
-  PR. Do not delete or skip tests, weaken assertions, or disable checks. Still do
-  not commit or push — the runner commits everything together.
-
-If there is no `# Pre-release check status` section, the base is clean (or the check
-was skipped); proceed normally and edit only the version files.
+- **Phase 2 (emit):** include the pre-release version string (e.g.
+  `0.9.0-beta.1`) in the `<!-- flumecode:versions {...} -->` comment — exactly
+  as you would for a stable release, just with the pre-release suffix included.