@flumecode/runner 0.17.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."
       ),
@@ -266,8 +272,27 @@ function widgetPosted(kind) {
 import { createSdkMcpServer as createSdkMcpServer2, tool as tool2 } from "@anthropic-ai/claude-agent-sdk";
 import { z as z2 } 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`.";
+// src/code-lang.ts
+var EXT_TO_LANG = {
+  ts: "typescript",
+  tsx: "tsx",
+  js: "javascript",
+  jsx: "jsx",
+  json: "json",
+  css: "css",
+  md: "markdown",
+  sh: "bash",
+  py: "python",
+  yaml: "yaml",
+  yml: "yaml",
+  html: "markup",
+  xml: "markup",
+  sql: "sql"
+};
+function langFromPath(path) {
+  const ext = path.split(".").pop()?.toLowerCase();
+  return ext ? EXT_TO_LANG[ext] : void 0;
+}
 
 // src/plan.ts
 var SERVER_NAME2 = "flume_plan";
@@ -357,7 +382,8 @@ function renderPlan(plan) {
         lines2.push("");
         lines2.push(`\`${entry.file}\``);
         lines2.push("");
-        lines2.push("```");
+        const lang = langFromPath(entry.file);
+        lines2.push(lang ? "```" + lang : "```");
         lines2.push(entry.pseudoCode);
         lines2.push("```");
       }
@@ -446,6 +472,15 @@ var STATUS_ICON = {
   not_met: "\u274C",
   unclear: "\u26A0\uFE0F"
 };
+var CICD_STATUS_ICON = {
+  passed: "\u2705",
+  failed: "\u274C"
+};
+var cicdCheckSchema = z3.object({
+  command: z3.string().min(1).describe("The exact verification command run, e.g. `pnpm typecheck`."),
+  status: z3.enum(["passed", "failed"]).describe("Whether the command passed or failed."),
+  output: z3.string().optional().describe("Short excerpt of failing output; include on failure.")
+});
 var evidenceSchema = z3.object({
   file: z3.string().min(1).describe("Repo-relative path the hunk comes from."),
   hunk: z3.string().min(1).describe(
@@ -477,6 +512,9 @@ var reportInputSchema = {
   ),
   conflictResolution: z3.string().optional().describe(
     "Markdown: present ONLY when a merge conflict was actually resolved. Explain, per conflicted file, how ours/theirs were integrated. Rendered under '## Conflict resolution'. Omit entirely when no conflict occurred."
+  ),
+  cicd: z3.array(cicdCheckSchema).optional().describe(
+    "Verify-phase build/typecheck/lint/test results. Omit when the repo has no verification setup. Rendered under '## CI/CD'."
   )
 };
 var reportSchema = z3.object(reportInputSchema);
@@ -504,6 +542,15 @@ function renderReport(report) {
   if (report.conflictResolution?.trim()) {
     lines2.push("", "## Conflict resolution", "", report.conflictResolution.trim());
   }
+  if (report.cicd && report.cicd.length > 0) {
+    lines2.push("", "## CI/CD");
+    for (const check of report.cicd) {
+      lines2.push("", `- ${CICD_STATUS_ICON[check.status]} \`${check.command}\``);
+      if (check.status === "failed" && check.output?.trim()) {
+        lines2.push("", "```", check.output.trim(), "```");
+      }
+    }
+  }
   lines2.push("", "## Code quality", "", report.codeQuality.trim());
   lines2.push("", "## Caveats / follow-ups", "", report.caveats.trim());
   return lines2.join("\n");
@@ -512,7 +559,7 @@ function createReportTooling() {
   let submittedReport = null;
   const submitReport = tool3(
     SUBMIT_REPORT,
-    "Submit the final implementation report as structured data. Call this exactly once, at the end of the run. `acceptanceCriteria` must contain one entry per plan criterion, each with a met / not_met / unclear verdict and the diff hunk(s) that prove it. `summary`, `filesChanged`, `codeQuality`, and `caveats` are the four named markdown sections. Do NOT include a PR link \u2014 the runner appends it.",
+    "Submit the final implementation report as structured data. Call this exactly once, at the end of the run. `acceptanceCriteria` must contain one entry per plan criterion, each with a met / not_met / unclear verdict and the diff hunk(s) that prove it. `summary`, `filesChanged`, `codeQuality`, and `caveats` are the four named markdown sections. `cicd` (optional) holds Verify-phase check results (one entry per command with `command`, `status` `passed`/`failed`, and `output` on failure); omit when no verification setup exists. Do NOT include a PR link \u2014 the runner appends it.",
     reportInputSchema,
     async (args) => {
       submittedReport = reportSchema.parse(args);
@@ -729,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)`;
@@ -752,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(
@@ -784,6 +833,7 @@ function buildRevisePrompt(ctx) {
     task,
     orient,
     widgets,
+    LANGUAGE_DIRECTIVE,
     "",
     "These coding guidelines apply to all code produced in this run:",
     "",
@@ -899,6 +949,7 @@ function buildReleasePrompt(ctx, baseChecks) {
     task,
     orient,
     widgets,
+    LANGUAGE_DIRECTIVE,
     "",
     "These coding guidelines apply to all code produced in this run:",
     "",
@@ -926,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.17.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

@@ -1,8 +1,9 @@
 ---
 name: technical-writing
 description: >-
-  Inline-code conventions for agent-authored plan and report prose: wrap code
-  identifiers in backticks so they render as inline code.
+  Inline-code and output-language conventions for agent-authored plan and report
+  prose: wrap code identifiers in backticks, and write prose in the same natural
+  language as the user's request.
 ---
 
 # Technical Writing
@@ -12,3 +13,12 @@ description: >-
 Wrap code identifiers — function names, variable names, type names, file names, commands, and flags — in inline backticks so they render as inline code. For example: `getCodingSessionsForRequest`, not getCodingSessionsForRequest.
 
 This convention applies to all free-text fields in plans and reports: goals, step descriptions, acceptance criteria, summaries, code-quality notes, and caveats.
+
+## Output 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/document/SKILL.md

@@ -88,11 +88,26 @@ contain, in this order:
 
 ### Every page: front-load an "At a glance" block
 
+Before the "At a glance" block on **every** page (component pages, README,
+architecture, glossary), place a TL;DR blockquote immediately after the H1:
+
+```
+> **TL;DR** — one plain-language sentence on what this page covers.
+```
+
+Then a blank line, then the existing `> **Purpose**` / "At a glance" block
+(where applicable). For `README.md`, place the TL;DR after the
+`<!-- wiki-synced-to -->` marker and H1. The blank line between the TL;DR and
+the next blockquote is required — without it, markdown merges the two
+blockquotes into one. This rule applies in both Bootstrap and Update modes.
+
 So an agent can grab context in seconds, begin each component page with:
 
 ```
 # <component>
 
+> **TL;DR** — one plain-language sentence on what this page covers.
+
 > **Purpose** — one or two sentences.
 > **Key files** — `path/a.ts`, `path/b.ts` (the entry points worth opening).
 > **Depends on** — what it relies on. **Used by** — what relies on it.

package/skills-plugin/skills/implement-plan/SKILL.md

@@ -138,7 +138,11 @@ the next step.
 7. **Report** — Task, `model: "opus"`, read-only. Give the subagent the AC
    verdicts (with criterion text, from step 4), the Verify results (from step 3),
    and the quality findings, and tell it to run `git --no-pager diff` itself as
-   the **single source of truth** for the report. Do not pass the full plan — the
+   the **single source of truth** for the report. Pass the Verify results as the
+   `cicd` field — one entry per check with `command`, `status` (`passed`/`failed`),
+   and (on failure) a short `output` excerpt. Omit `cicd` when no verification
+   setup exists. A failing check does NOT block the report — include the failing
+   entry and continue. Do not pass the full plan — the
    AC verdicts carry each criterion verbatim, and the live `git --no-pager diff`
    is the authoritative source for evidence; re-inlining the full plan is
    redundant. Keep each subagent prompt to the minimal self-contained slice it
@@ -181,6 +185,7 @@ The report subagent calls `submit_report` with these fields:
     verbatim from the live `git --no-pager diff`, including each hunk's `@@ -a,b +c,d @@` header line(s) (do not strip them — the report renders file line numbers from them), and proves the verdict (`note`
     optionally explains it). Never include a hunk that isn't in the actual diff. Cite
     the supporting hunk(s) for a met criterion; may be empty for not_met / unclear.
+- **`cicd`** (optional) — array of Verify-phase check results. Each entry: `command` (exact command run), `status` (`"passed"` / `"failed"`), `output` (short failing-output excerpt, on failure only). Omit when the repo has no verification setup. Rendered under `## CI/CD`. A failing check does not block the report.
 
 ## Always
 

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.

package/skills-plugin/skills/resolve-merge-conflict/SKILL.md

@@ -104,5 +104,6 @@ Call **`submit_report`** with the structured report. Fields:
   file, explaining which side you kept and why (or how you merged both intents). Wrap file names
   and code identifiers in inline backticks. This is what the user reads to understand how each
   conflict was integrated.
+- `cicd` (optional): array of Verify-phase check results from Step 3, each with `command`, `status` (`"passed"`/`"failed"`), and `output` on failure. Omit when no build/test setup exists.
 
 The runner renders the report and appends the pull-request link — do not add one yourself.

package/skills-plugin/skills/revise-implementation/SKILL.md

@@ -84,6 +84,8 @@ user:
   `implement-plan` does. Include one `acceptanceCriteria` entry per plan AC (with a
   met / not_met / unclear verdict and the diff hunk(s) that prove it), plus the four
   required markdown sections (`summary`, `filesChanged`, `codeQuality`, `caveats`).
+  Include `cicd` from the Verify results (one entry per check, same shape as
+  `implement-plan`; omit when no verification setup).
   Base `filesChanged` and evidence on the actual `git --no-pager diff`, not on what
   a subagent claimed; if the diff is empty, say nothing was changed. The runner
   renders the report and appends the pull-request link — do not add one yourself.