@flumecode/runner 0.18.0 → 0.19.0

package/dist/cli.js

@@ -188,6 +188,12 @@ import { query } from "@anthropic-ai/claude-agent-sdk";
 import { randomUUID } from "node:crypto";
 import { createSdkMcpServer, tool } from "@anthropic-ai/claude-agent-sdk";
 import { z } from "zod";
+
+// src/schema-hints.ts
+var INLINE_CODE_HINT = "Wrap code identifiers (function, variable, type, and file names, commands, and flags) in inline backticks, e.g. `getCodingSessionsForRequest`.";
+var WIDGET_LANGUAGE_HINT = "Write this in the same natural language as the incoming thread (the request body and the user's messages). If the thread is in English, keep it in English; do not switch languages. Keep code identifiers, file paths, and quoted code verbatim.";
+
+// src/widgets.ts
 var SERVER_NAME = "flume_widgets";
 var SINGLE_SELECT = "single_select";
 var MULTI_SELECT = "multi_select";
@@ -195,15 +201,15 @@ var WIDGET_TOOL_NAMES = [
   `mcp__${SERVER_NAME}__${SINGLE_SELECT}`,
   `mcp__${SERVER_NAME}__${MULTI_SELECT}`
 ];
-var optionsSchema = z.array(z.string().min(1)).min(2).max(8).describe("2\u20138 short, distinct choices for the user to pick from.");
-var TAIL = "Do NOT add an 'Other' or 'None of these' catch-all \u2014 the UI always offers an 'Other' free-text option automatically. After calling this, END YOUR TURN and wait: the user's answer arrives as their next message and starts a fresh run.";
+var optionsSchema = z.array(z.string().min(1)).min(2).max(8).describe("2\u20138 short, distinct choices for the user to pick from. " + WIDGET_LANGUAGE_HINT);
+var TAIL = "Do NOT add an 'Other' or 'None of these' catch-all \u2014 the UI always offers an 'Other' free-text option automatically. " + WIDGET_LANGUAGE_HINT + " After calling this, END YOUR TURN and wait: the user's answer arrives as their next message and starts a fresh run.";
 function createWidgetTooling() {
   const collected = [];
   const singleSelect = tool(
     SINGLE_SELECT,
     "Ask the user a single-select (radio-button) question \u2014 exactly one answer. Use this for a genuine either/or choice (competing approaches, scope decisions, yes/no) instead of writing the options as prose. " + TAIL,
     {
-      question: z.string().min(1).describe("The question to ask the user."),
+      question: z.string().min(1).describe("The question to ask the user. " + WIDGET_LANGUAGE_HINT),
       body: z.string().optional().describe(
         "Optional markdown shown above the question so the user can read the context they're confirming (e.g. the drafted release notes). Omit for plain questions."
       ),
@@ -226,7 +232,7 @@ function createWidgetTooling() {
     MULTI_SELECT,
     "Ask the user a multi-select (checkbox) question \u2014 they may pick any number of options, including none of the presets if they use 'Other'. Use this for 'select all that apply' questions (which features to include, which files to touch). " + TAIL,
     {
-      question: z.string().min(1).describe("The question to ask the user."),
+      question: z.string().min(1).describe("The question to ask the user. " + WIDGET_LANGUAGE_HINT),
       body: z.string().optional().describe(
         "Optional markdown shown above the question so the user can read the context they're confirming (e.g. the drafted release notes). Omit for plain questions."
       ),
@@ -288,9 +294,6 @@ function langFromPath(path) {
   return ext ? EXT_TO_LANG[ext] : void 0;
 }
 
-// src/schema-hints.ts
-var INLINE_CODE_HINT = "Wrap code identifiers (function, variable, type, and file names, commands, and flags) in inline backticks, e.g. `getCodingSessionsForRequest`.";
-
 // src/plan.ts
 var SERVER_NAME2 = "flume_plan";
 var SUBMIT_PLAN = "submit_plan";
@@ -773,6 +776,7 @@ function appendRule(lines2, intro, ruleName) {
   lines2.push("", intro, "", loadRule(ruleName));
 }
 var WRITING_INTRO = "These technical-writing guidelines apply to the plan and report prose you author in this run:";
+var LANGUAGE_DIRECTIVE = "First, determine the dominant natural language of the incoming thread (the request title/body and the user's messages). Use that one language for EVERYTHING you author this run - your reply body, any plan or report fields, AND every clarifying question and its widget options. Never mix languages: if the thread is in English, your questions and options must be in English too. Keep code identifiers, file paths, and quoted code verbatim.";
 function turnHeading(turn, agentName) {
   if (turn.role === "user") return "User";
   if (turn.failed) return `${agentName} (this run ended in an error)`;
@@ -796,7 +800,8 @@ function buildPrompt(ctx) {
     `The repository ${ctx.repo.fullName} is checked out in your current working directory on branch "${ctx.repo.checkoutBranch}" at commit ${ctx.repo.checkoutSha.slice(0, 7)}.`,
     task,
     orient,
-    widgets
+    widgets,
+    LANGUAGE_DIRECTIVE
   ];
   if (ctx.permissionMode !== "plan") {
     lines2.push(
@@ -828,6 +833,7 @@ function buildRevisePrompt(ctx) {
     task,
     orient,
     widgets,
+    LANGUAGE_DIRECTIVE,
     "",
     "These coding guidelines apply to all code produced in this run:",
     "",
@@ -943,6 +949,7 @@ function buildReleasePrompt(ctx, baseChecks) {
     task,
     orient,
     widgets,
+    LANGUAGE_DIRECTIVE,
     "",
     "These coding guidelines apply to all code produced in this run:",
     "",
@@ -970,6 +977,14 @@ function buildReleasePrompt(ctx, baseChecks) {
       "```"
     );
   }
+  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."
+    );
+  }
   appendThread(lines2, ctx);
   lines2.push(
     "",

package/package.json

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

package/skills-plugin/rules/technical-writing.md

@@ -16,9 +16,9 @@ This convention applies to all free-text fields in plans and reports: goals, ste
 
 ## Output language
 
-Write all free-text prose in the same natural language as the user's request
-(Korean in → Korean out, English in → English out). This applies to every
-free-text field you author — plan goals/steps/risks, report summaries,
-clarifying questions, and push-backs. Keep code identifiers, file paths,
-commands, and quoted code/diffs verbatim; only the surrounding prose follows
-the request language.
+Before writing anything, determine the dominant natural language of the incoming thread (the
+request title/body and the user's messages). Use that one language for all free-text prose in
+this run — your reply body, plan goals/steps/risks, report summaries, clarifying questions,
+widget options, and push-backs. Never switch languages mid-response. Keep code identifiers, file
+paths, commands, and quoted code/diffs verbatim; only the surrounding prose follows the thread
+language.

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

@@ -183,6 +183,32 @@ version did not change.
   silence them.
 - **Never commit, push, or open a PR** — the runner does that.
 
+## Pre-release
+
+When the prompt contains a `# Pre-release` section, this release uses semver
+pre-release version strings instead of stable ones:
+
+- **Compute versions:** take the next stable version you would otherwise propose
+  (patch or minor bump), then append `-beta.N`, where N is the next unused beta
+  number for that base version. Check existing tags with:
+
+  ```
+  git tag -l --sort=-version:refname 'v<version>-beta.*' | head -1
+  ```
+
+  If no beta tags exist for that base version, start at `-beta.1`.
+
+- **Phase 1 (propose):** offer the pre-release version string (e.g.
+  `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

package/skills-plugin/skills/request-to-plan/SKILL.md

@@ -108,6 +108,13 @@ own independently-acceptable "Accept as plan" draft. After a plan is accepted th
 keep commenting to refine it; treat a later turn as a fresh **Plan** phase and call
 `submit_plan` again with a `plans[]` array containing the revised fields.
 
+Before adding an entry to `plans[]`, apply this right-sizing checklist — if a plan fails any criterion, split it into separate entries:
+
+- **Single, clear outcome** — one bug fixed, one feature increment, one refactor. If the `title` needs "and", consider splitting.
+- **Fits in a sprint comfortably** — if it can't fit in one iteration, it's likely an epic that needs breaking down.
+- **Reviewable PR** — small enough that a reviewer can hold it in their head (often cited as under ~200–400 lines of diff, though this varies).
+- **Testable acceptance criteria** — you can state up front what "done" looks like; use the `acceptanceCriteria` field to capture this.
+
 ## Always
 
 - Stay read-only. Propose; do not edit.