@manny-est/node-red-flowpilot 0.4.0 → 0.5.0

package/CHANGELOG.md

@@ -2,6 +2,39 @@
 
 All notable changes to FlowPilot are documented here.
 
+## [0.5.0] - 2026-07-06
+
+### Added
+- **Slash autocomplete**: type `/` in the compose box and a panel shows all available commands with descriptions. Arrow keys, Tab, and Enter navigate; Escape dismisses.
+- **Mode-suggestion chips**: FlowPilot detects when you describe a Generate, Modify, or Build task while in a different mode and offers a one-click chip to switch — no need to type the slash command manually. A chip also surfaces after a Generate response if the flow looks like it needs a follow-up Build loop.
+- **Build loop — hold-at-next-step pacing**: a new Settings → Behavior toggle pauses the loop at each waypoint for review instead of auto-advancing. Useful for carefully inspecting each iteration.
+- **Build loop — checkpoint questions**: the loop can now ask a focused clarifying question at any waypoint (e.g. "the debug output shows X — did you mean to test Y?") with prefilled quick-reply options, the same mechanism Modify uses. The loop only continues once you answer.
+- **Build loop — context-aware start**: `/build` now reads your current selection as the starting context (same as `/modify`), letting you target an existing sub-flow to extend or fix rather than always building from scratch.
+- **Build loop — done confirmation**: a "Done" confirmation step with an explicit success/fail verdict now closes the loop instead of silently stopping.
+- **Pop-out — debug log**: the debug log panel is now fully mirrored in the pop-out window, including the "Clear debug" button and the "Attach N to context" indicator.
+- **Pop-out — Recall and flight log**: the Recall panel and flight-log history are now accessible from the pop-out; opening a past conversation or recalling a message works the same as in the main window.
+- **Pop-out — prompt resize handle**: the compose box in the pop-out can now be resized vertically, matching the main window.
+
+### Fixed
+- **Partial id-validation** (`finalizeModifyResult`): a Modify response containing a mix of valid patches and one bad node id no longer rejects the whole response — valid patches are applied and the bad ones are silently dropped. Previously a single unrecognized id caused every change in the batch to be discarded.
+- **Redaction round-trip poisoning** (issue #7): when a Modify request targets a field that FlowPilot redacted (e.g. an HTTP Authorization header), the model's response — echoing back the `[redacted: ...]` placeholder — previously produced a silent empty diff. Now the diff step recognises placeholder values, skips those fields, and if ALL proposed changes were redacted-field-only, shows an explicit warning explaining the limitation and instructing the user to edit that field directly in the node editor.
+- **Token credential redaction**: `Authorization: Token <value>` headers (used by Django REST Framework and similar APIs) were not caught by the existing bearer-token pattern and could be sent to the model in plain text. The `Token <credential>` form is now recognised as a separate pattern.
+- **Recursive sentinel check**: `isSanitizeSentinel` now walks into nested arrays and objects, so a placeholder buried inside a list property (e.g. `rules[0].v`) is correctly detected and skipped instead of producing a spurious empty diff.
+- **Group data corruption**: a plain `changes` patch could reach the `nodes` membership array of a group container (since context exposes it as a plain field), overwriting the live group membership with a stringified copy. The `nodes` array is now in `DIFF_SKIP` so Modify patches never touch it directly.
+- **Group create/extend on mixed-membership selections**: creating or extending a group when the selection contained nodes from more than one existing group (or some grouped and some ungrouped) could silently fail or corrupt membership. The membership reconciliation step now handles the mixed case correctly.
+- **Invalid port wiring**: FlowPilot now guards against wiring to or from a port index that doesn't exist on a node (e.g. connecting output 3 of a node that only has 2 outputs) — the bad wire is skipped with a warning instead of being applied and then causing a Node-RED canvas error.
+- **Pop-out — settings auth failure**: opening Settings from the pop-out could fail with a 404 or 401 in certain auth configurations because the settings request was issued from the pop-out's nested route rather than through the main window. All settings reads and writes are now relayed through the parent window.
+- **Pop-out — recall and flight-log relay**: recall and flight-log API calls are now relayed through the parent window so they resolve correctly from the pop-out.
+
+### Internal
+- Phase 9 refactor complete: `flowpilot-core.js` is now assembled at runtime from focused fragments under `lib/core/` (redaction, history, markdown, selection-context, apply-review, modes, main, init). The assembled script is functionally identical to the old single file; the split is purely for maintainability.
+
+## [0.4.1] - 2026-06-29
+
+### Fixed
+- **Critical**: the editor hung at "Loading plugins" on any Node-RED instance with `adminAuth` enabled, due to a 401 on `/flowpilot/core.js`. 0.4.0's pop-out refactor moved FlowPilot's frontend into a separately-served script, but the route serving it (along with `core.css` and the pop-out's `view.html`) was gated behind `RED.auth.needsPermission(...)` — a check that requires an `Authorization` header, which a plain `<script src>`/`<link>`/`window.open` request can never carry. These three static client-asset routes are no longer gated (they contain no secrets); every data/action route is unaffected and still requires authentication exactly as before.
+- **Critical**, found while verifying the fix above: every settings/chat/generate/document/modify/build request (anything going through the shared `ajaxJson` helper) also failed with "Unauthorized" on `adminAuth` instances, for the same root cause — these requests use an absolute URL (needed for the pop-out to resolve correctly), and Node-RED's editor only auto-attaches the admin auth token to relative URLs. The SSE-streaming `fetch()` calls already worked around this (`fetchHeaders()`); `ajaxJson` now attaches the same bearer token itself.
+
 ## [0.4.0] - 2026-06-27
 
 ### Added

package/PROJECT-OVERVIEW.md

@@ -115,13 +115,13 @@ including every step of the `/build` loop and every group mutation.
 
 - **`flowpilot.html`** — the editor-side plugin entry point: registers the
   sidebar panel and loads the shared client module below.
-- **`flowpilot-core.js`** — the shared client logic (chat/generate/modify/
-  document/build, selection/context handling, settings UI, diff review and
-  apply, group mutations) — used by both the sidebar and the pop-out window,
-  so they stay in sync by construction rather than by copy-pasted code.
-  Served via a dedicated static route alongside the pop-out's own minimal
-  page (`lib/popout/view.html`), which loads this same module and relays
-  state to/from the main editor window over `postMessage`.
+- **`lib/core/*.js`** — the shared client logic, split into focused fragments
+  (redaction, history, markdown, selection-context, apply-review, modes, main,
+  init) and assembled at request time by `lib/build-core-script.js` into one
+  complete IIFE served at `/flowpilot/core.js`. Used by both the sidebar and
+  the pop-out window so they stay in sync by construction. The pop-out's
+  minimal page (`lib/popout/view.html`) loads this same assembled module and
+  relays state to/from the main editor window over `postMessage`.
 - **`flowpilot.js`** — the Node-RED runtime plugin: HTTP routes
   (`/flowpilot/*`), provider calls, response parsing/validation, and audit
   logging.

package/README.md

@@ -93,26 +93,32 @@ See the [User Guide](USER-GUIDE.md#privacy-and-safety) for the full details.
 
 Node-RED 4.x and 5.x, tested. Node.js 16+.
 
-## Install in a local Node-RED user directory
+## Install
 
-From your Node-RED user directory:
+In the Node-RED editor: **Menu → Manage palette → Install**, search for
+`@manny-est/node-red-flowpilot`, and click **Install**.
+
+Or, from your Node-RED user directory:
 
 ```bash
 cd ~/.node-red
-npm install /path/to/node-red-flowpilot
+npm install @manny-est/node-red-flowpilot
 node-red
 ```
 
-For a Docker/container setup, place or install the package inside the
-mounted Node-RED user directory. If your user directory is
-`/data` (or `/workspaces/nodered`, etc.), this folder should exist:
+Restart Node-RED (or the container) after installing or updating — FlowPilot's
+editor UI is cached server-side, so a browser refresh alone is not enough.
+
+For a Docker/container setup, install into the mounted Node-RED user directory.
+If your user directory is `/data` (or `/workspaces/nodered`, etc.), this folder
+should exist:
 
 ```text
 <node-red-userDir>/node_modules/@manny-est/node-red-flowpilot
 ```
 
-Restart the Node-RED container/process after installing or updating —
-plugin HTML is cached server-side, so a browser refresh alone is not enough.
+Restart the Node-RED container/process after updating the package files
+directly — the plugin server caches assembled scripts in memory.
 
 FlowPilot stores its own settings and logs separately from the plugin code,
 under `<node-red-userDir>/flowpilot/`:

package/USER-GUIDE.md

@@ -212,14 +212,23 @@ and apply like any other change.
 ### Build (the agentic loop)
 
 Describe a goal (e.g. "fetch the weather every hour and log it to a file")
-and arm **Build**, or type `/build <goal>` directly. FlowPilot plans the
-work, proposes a first flow, and once you apply and deploy it, walks an
-interactive loop with you: attach the resulting Debug output, FlowPilot
-reviews it against the goal, and either confirms it's working or proposes a
-fix — repeating until it works or a configurable attempt limit is reached
-(**Settings → Behavior → Build loop iteration cap**). Every proposal and fix
-still goes through the same review-then-apply flow as Modify — FlowPilot
-never deploys for you.
+and arm **Build**, or type `/build <goal>` directly. If you have nodes
+selected, FlowPilot uses them as the starting context (like Modify) — useful
+for targeting an existing sub-flow to extend or fix.
+
+FlowPilot plans the work, proposes a first flow, and once you apply and
+deploy it, walks an interactive loop: attach the resulting Debug output,
+FlowPilot reviews it against the goal, and either confirms it's working
+(with a Done confirmation showing the debug output that proved success) or
+proposes a fix — repeating until it works or a configurable attempt limit is
+reached (**Settings → Behavior → Build loop iteration cap**). At any waypoint
+FlowPilot may ask a focused clarifying question with quick-reply buttons
+before continuing. Every proposal and fix still goes through the same
+review-then-apply flow as Modify — FlowPilot never deploys for you.
+
+**Hold at next step** (**Settings → Behavior**): when enabled, the loop pauses
+at each waypoint for you to review before auto-advancing — useful for
+careful, step-by-step inspection of each iteration.
 
 ### Document
 
@@ -263,13 +272,18 @@ them from there or by clicking **Clear chat**.
 
 ![A debug message attached, shown in the status strip](https://github.com/manny-est/flowpilot/releases/download/v0.2.1/debug-log-attached.png)
 
-### Action chips
+### Action chips and mode suggestions
 
 When FlowPilot's reply describes a change you could make, it may offer an
 action chip — a one-click button that switches to the suggested mode
 (Generate/Modify/Document/Chat) with the request pre-filled. Nothing is sent
 until you review and hit Send yourself.
 
+FlowPilot also watches what you type: if your prompt reads like a Generate,
+Modify, or Build task but a different mode is armed, it surfaces a suggestion
+chip below the reply so you can switch with one click instead of typing the
+slash command manually.
+
 ![A reply with an action chip below it](https://github.com/manny-est/flowpilot/releases/download/v0.2.1/action-chip.png)
 
 ![The full chat thread leading up to an action chip](https://github.com/manny-est/flowpilot/releases/download/v0.2.1/action-chip-full.png)
@@ -303,7 +317,9 @@ Behavior → Stream chat replies**.
 
 ### Slash commands
 
-Type these directly into the prompt box:
+Type `/` in the prompt box to see a floating panel listing all available
+commands with descriptions. Arrow keys or Tab to highlight, Enter or Tab to
+complete, Escape to dismiss.
 
 - `/help` — show the full command/feature briefing
 - `/generate`, `/document`, `/modify`, `/build` — arm that Execute mode
@@ -312,6 +328,7 @@ Type these directly into the prompt box:
 - `/history` — open the Flight log
 - `/settings` — open Settings
 - `/demo` — load a sample Generate request into the prompt box
+- `/feedback` — links to the repo and issue tracker
 - `/compact` / `/expand` — hide/restore labels on the selected node(s),
   instant and deterministic, no AI round-trip
 - `/disable` / `/enable` — disable/re-enable the selected node(s) (skipped on

package/flowpilot-core.css

@@ -1056,6 +1056,50 @@
     background: rgba(127, 127, 127, 0.15);
 }
 
+/* Slash-command autocomplete panel */
+#fp-slash-suggest {
+    position: absolute;
+    bottom: 100%;
+    left: 0;
+    right: 0;
+    margin-bottom: 4px;
+    background: var(--red-ui-primary-background, #fff);
+    border: 1px solid var(--red-ui-form-input-border-color, #ccc);
+    border-radius: 6px;
+    box-shadow: 0 4px 12px rgba(0, 0, 0, 0.12);
+    overflow: hidden;
+    z-index: 100;
+}
+
+.fp-slash-row {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    padding: 6px 10px;
+    cursor: pointer;
+    user-select: none;
+}
+
+.fp-slash-row:hover,
+.fp-slash-row.fp-slash-active {
+    background: var(--red-ui-secondary-background, #f5f5f5);
+}
+
+.fp-slash-cmd {
+    font-weight: 600;
+    font-size: 13px;
+    min-width: 90px;
+    color: var(--red-ui-primary-text-color, #333);
+}
+
+.fp-slash-desc {
+    font-size: 12px;
+    color: var(--red-ui-secondary-text-color, #777);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+}
+
 #fp-provider-status {
     flex: 0 1 auto;
     min-width: 0;

package/flowpilot.js

@@ -7,6 +7,8 @@ const documentSystemPrompt = require("./lib/document-system-prompt");
 const modifySystemPrompt = require("./lib/modify-system-prompt");
 const buildSystemPrompt = require("./lib/build-system-prompt");
 const personaPrompt = require("./lib/persona-prompt");
+const { buildCoreScript } = require("./lib/build-core-script");
+const { extractJsonObject } = require("./lib/envelope");
 
 module.exports = function flowPilotRuntime(RED) {
   const storage = createStorage(RED.settings.userDir);
@@ -623,18 +625,35 @@ module.exports = function flowPilotRuntime(RED) {
   // pop-out's own minimal page — mirroring core Node-RED's debug-node
   // pattern (RED.httpAdmin.get("/debug/view/view.html", ...) serving a
   // static lib/debug/view.html that loads the SAME debug-utils.js the
-  // sidebar uses). Gated the same as every other FlowPilot route, unlike
-  // NR5's own debug view route, which has no permission check at all.
-
-  RED.httpAdmin.get("/flowpilot/core.js", RED.auth.needsPermission("settings.read"), function (req, res) {
-    res.sendFile(path.join(__dirname, "flowpilot-core.js"));
+  // sidebar uses).
+  //
+  // Phase 9 refactor: the SOURCE is now split into lib/core/*.js fragments
+  // (see lib/build-core-script.js for why and how), but this route's
+  // behavior is unchanged — it still serves one complete script at this
+  // same URL, just assembled instead of read off disk verbatim.
+  //
+  // INTENTIONALLY UNGATED (fixed in 0.4.1 — was needsPermission("settings.
+  // read") in 0.4.0, which broke the editor on every adminAuth-enabled
+  // instance): these are static client assets, fetched via plain <script
+  // src>/<link>/window.open — none of which can carry the admin auth
+  // bearer token (that only gets attached to FlowPilot's own ajax/fetch
+  // calls, via Node-RED's editor-side request wrapper). needsPermission's
+  // bearer/tokens/anon strategies have no fallback for a request with no
+  // Authorization header, so the gate 401's unconditionally for this kind
+  // of request — confirmed against @node-red/editor-api's auth middleware.
+  // This is the same reason NR5's own debug-view route has no permission
+  // check either. No secrets live in these files; the real data/action
+  // routes (settings, chat, generate, modify, etc. below) stay gated.
+
+  RED.httpAdmin.get("/flowpilot/core.js", function (req, res) {
+    res.type("application/javascript").send(buildCoreScript());
   });
 
-  RED.httpAdmin.get("/flowpilot/core.css", RED.auth.needsPermission("settings.read"), function (req, res) {
+  RED.httpAdmin.get("/flowpilot/core.css", function (req, res) {
     res.sendFile(path.join(__dirname, "flowpilot-core.css"));
   });
 
-  RED.httpAdmin.get("/flowpilot/popout/view.html", RED.auth.needsPermission("settings.read"), function (req, res) {
+  RED.httpAdmin.get("/flowpilot/popout/view.html", function (req, res) {
     res.sendFile(path.join(__dirname, "lib", "popout", "view.html"));
   });
 
@@ -951,125 +970,6 @@ module.exports = function flowPilotRuntime(RED) {
   // types or wire integrity yet (that's the next chunk) — it returns the parsed
   // envelope so the frontend can display it for review.
 
-  // Given s[startIdx] === "{", scans forward with brace-depth counting that
-  // ignores braces inside string literals (so a value like "{{payload}}"
-  // can't be mistaken for structure) to find the index of the MATCHING
-  // closing "}". Returns -1 if the braces never balance before the string
-  // ends (truncated/malformed input).
-  function findMatchingBrace(s, startIdx) {
-    let depth = 0;
-    let inString = false;
-    let escaped = false;
-    for (let i = startIdx; i < s.length; i++) {
-      const ch = s[i];
-      if (inString) {
-        if (escaped) { escaped = false; }
-        else if (ch === "\\") { escaped = true; }
-        else if (ch === "\"") { inString = false; }
-        continue;
-      }
-      if (ch === "\"") { inString = true; }
-      else if (ch === "{") { depth++; }
-      else if (ch === "}") {
-        depth--;
-        if (depth === 0) { return i; }
-      }
-    }
-    return -1;
-  }
-
-  function extractJsonObject(text) {
-    if (!text) { throw new Error("Empty response from provider."); }
-    let s = String(text).trim();
-    // Strip markdown code fences if the model wrapped the JSON.
-    s = s.replace(/^```(?:json)?\s*/i, "").replace(/\s*```$/i, "").trim();
-
-    const firstBrace = s.indexOf("{");
-    const firstBracket = s.indexOf("[");
-
-    // The model occasionally returns a bare top-level array (e.g.
-    // `[ {...node...} ]`) instead of the {explanation, flow} envelope. If we
-    // fell through to the {...} extraction below, indexOf("{")/lastIndexOf("}")
-    // would grab just the first node object — which has no "flow" key and
-    // fails validation. Detect this case up front and wrap it as a minimal
-    // envelope instead.
-    if (firstBracket !== -1 && (firstBrace === -1 || firstBracket < firstBrace)) {
-      const lastBracket = s.lastIndexOf("]");
-      if (lastBracket !== -1 && lastBracket > firstBracket) {
-        try {
-          const arr = JSON.parse(s.slice(firstBracket, lastBracket + 1));
-          if (Array.isArray(arr)) {
-            return { explanation: "", flow: arr };
-          }
-        } catch (e) {
-          // Not a parseable array — fall through to the {...} extraction.
-        }
-      }
-    }
-
-    const firstObjIdx = s.indexOf("{");
-    if (firstObjIdx === -1) {
-      // No JSON object found at all — flagged separately from a found-
-      // but-unparseable ({...} present, JSON.parse failed) "garbled" error,
-      // so callers can distinguish "model just answered in prose" (tolerate)
-      // from "model's JSON envelope is broken" (still an error).
-      const err = new Error("Provider did not return a JSON object.");
-      err.noJsonFound = true;
-      throw err;
-    }
-
-    // There may be more than one "{" before the real envelope — e.g. prose
-    // explaining a fix that mentions inline code like "{{payload}}" before
-    // the actual JSON (seen live: a review response started with "The
-    // template node is using `{{payload}}` with...", and slicing from THAT
-    // brace to the envelope's real closing "}" produced unparseable
-    // garbage). Try each candidate "{" in order with string-aware brace
-    // matching (findMatchingBrace, which ignores braces inside quoted
-    // strings) rather than just slicing from the first "{" to the last
-    // "}".
-    //
-    // A candidate must not just PARSE, it must also look like one of the
-    // known envelope shapes (have at least one recognized top-level key) —
-    // seen live: a pure-prose advice response that mentioned structured
-    // logging included the illustrative example
-    // `{"level":"info","event":"trivia_answer","user":"alex","correct":true}`,
-    // which IS valid standalone JSON, so the old "first candidate that
-    // parses wins" rule accepted it as "the envelope" and the caller threw
-    // "no recognizable modify fields" — when the right answer was to treat
-    // the whole reply as prose, since there was no real envelope at all.
-    const ENVELOPE_KEYS = ["explanation", "flow", "question", "changes", "newNodes", "newWires", "removeNodes", "newGroups", "prose"];
-    function looksLikeEnvelope(obj) {
-      if (!obj || typeof obj !== "object" || Array.isArray(obj)) { return false; }
-      return ENVELOPE_KEYS.some(function (k) { return k in obj; });
-    }
-
-    let lastError = null;
-    let searchFrom = firstObjIdx;
-    while (searchFrom !== -1 && searchFrom < s.length) {
-      const end = findMatchingBrace(s, searchFrom);
-      if (end !== -1) {
-        try {
-          const candidate = JSON.parse(s.slice(searchFrom, end + 1));
-          if (looksLikeEnvelope(candidate)) { return candidate; }
-          // Valid JSON, but not envelope-shaped (e.g. an illustrative
-          // example embedded in prose) — keep searching rather than
-          // accepting it.
-        } catch (e) {
-          lastError = e;
-        }
-      }
-      searchFrom = s.indexOf("{", searchFrom + 1);
-    }
-    // No candidate both parsed AND looked like a real envelope — equivalent
-    // to "the model just answered in prose," not "the envelope is broken."
-    // Let callers fall back to rendering this as a normal message instead
-    // of surfacing a parse error (same noJsonFound flag the "no { at all"
-    // branch above uses).
-    const err = lastError || new Error("Provider's JSON object could not be parsed.");
-    err.noJsonFound = true;
-    throw err;
-  }
-
   // ---------------------------------------------------------------------
   // Shared helper: resolve the active provider and assemble the messages
   // array for a generation-style request (generate/document/modify). Split
@@ -1526,29 +1426,42 @@ module.exports = function flowPilotRuntime(RED) {
     // Validate that changes contains no hallucinated ids, and that no id is
     // both patched and marked for removal. A group id from contextGroupIds
     // is allowed here too (see above) even though it's not in originalIds.
+    // Instead of rejecting the whole response when some ids are bad, drop
+    // only the offending patches and apply the rest — same philosophy as the
+    // applyInsertions partial-failure fix (Phase 8.5 #11). A skippedNote in
+    // the response body tells the user what was dropped and why.
     const extraIds = changeIds.filter(function (id) { return !originalIds.has(String(id)) && !contextGroupIds.has(String(id)); });
     const wronglyRemovedIds = changeIds.filter(function (id) { return removeSet.has(String(id)); });
 
-    const idProblems = [];
-    if (extraIds.length) { idProblems.push("unexpected id(s) in changes: " + extraIds.join(", ")); }
-    if (wronglyRemovedIds.length) { idProblems.push("id(s) in both changes and removeNodes: " + wronglyRemovedIds.join(", ")); }
-
-    if (idProblems.length > 0) {
-      storage.appendAudit({ action: "modify_id_mismatch", problems: idProblems });
-      return {
-        status: 422,
-        body: {
-          error: "The model returned inconsistent node ids (" + idProblems.join("; ") + "). Try again.",
-          raw: JSON.stringify(changes)
-        }
-      };
+    const skippedDescriptions = [];
+    if (extraIds.length) {
+      skippedDescriptions.push(
+        extraIds.length === 1
+          ? "Skipped 1 change — that node wasn't in your current selection; reselect it to include it"
+          : "Skipped " + extraIds.length + " changes — those nodes weren't in your current selection; reselect them to include them"
+      );
+    }
+    if (wronglyRemovedIds.length) {
+      skippedDescriptions.push(
+        wronglyRemovedIds.length === 1
+          ? "Skipped 1 change — that node was also marked for removal"
+          : "Skipped " + wronglyRemovedIds.length + " changes — those nodes were also marked for removal"
+      );
     }
+    if (skippedDescriptions.length > 0) {
+      storage.appendAudit({ action: "modify_id_mismatch_partial", skipped_extra: extraIds, skipped_conflict: wronglyRemovedIds });
+    }
+
+    const badIdSet = new Set(extraIds.map(String).concat(wronglyRemovedIds.map(String)));
+    const validChanges = changes.filter(function (c) {
+      return c && c.id !== undefined && c.id !== null && !badIdSet.has(String(c.id));
+    });
 
     // Each patch's "set" is shallow-merged onto a copy of the original node.
     // "id", "x", "y", "z" can never move via a patch — strip them
     // defensively even though the prompt already forbids them.
     const patchById = {};
-    changes.forEach(function (c) {
+    validChanges.forEach(function (c) {
       const set = (c.set && typeof c.set === "object") ? c.set : {};
       const clean = Object.assign({}, set);
       delete clean.id;
@@ -1575,7 +1488,8 @@ module.exports = function flowPilotRuntime(RED) {
     // is, and findLiveNode() already resolves a group id to the live
     // group object (Phase 8.5 C2 slice 1). This is how a group gets
     // renamed/restyled — pure property edit, no new apply-side code.
-    const groupPatchIds = changeIds.filter(function (id) {
+    const validChangeIds = validChanges.map(function (c) { return c.id; });
+    const groupPatchIds = validChangeIds.filter(function (id) {
       return contextGroupIds.has(String(id)) && !originalIds.has(String(id));
     });
     groupPatchIds.forEach(function (id) {
@@ -1686,6 +1600,7 @@ module.exports = function flowPilotRuntime(RED) {
       removeNodes: finalRemoveNodes,
       newGroups: newGroups
     };
+    if (skippedDescriptions.length > 0) { body.skippedNote = skippedDescriptions.join(". ") + "."; }
     if (result.suggestedAction) { body.suggestedAction = result.suggestedAction; }
 
     return { status: 200, body: body };

package/lib/build-core-script.js

@@ -0,0 +1,44 @@
+"use strict";
+
+const fs = require("fs");
+const path = require("path");
+
+// flowpilot-core.js is loaded directly in the BROWSER via a single
+// <script src="flowpilot/core.js"> tag - one big IIFE, no module system,
+// every function/var sharing one closure by lexical scope (not via
+// require/import). Phase 9's refactor splits the SOURCE into focused files
+// under lib/core/ for maintainability, but the served SCRIPT must stay
+// exactly what it was: one concatenated text, so cross-fragment references
+// keep working unmodified and script-loading/timing behavior never changes.
+//
+// Order matters only for top-level code that runs immediately at load time
+// (e.g. a `var x = (function(){...})();` initializer) - plain function
+// declarations are hoisted within the shared closure and safe in any
+// order. Keep new fragments appended in the same relative order they held
+// in the original single file unless a specific dependency says otherwise.
+const FRAGMENT_ORDER = [
+  "redaction.js",
+  "history.js",
+  "markdown.js",
+  "selection-context.js",
+  "apply-review.js",
+  "modes.js",
+  "main.js",
+  "init.js"
+];
+
+const HEADER = "(function () {\n    \"use strict\";\n";
+const FOOTER = "\n})();\n";
+
+let cached = null;
+
+function buildCoreScript() {
+  if (cached) { return cached; }
+  const body = FRAGMENT_ORDER.map(function (name) {
+    return fs.readFileSync(path.join(__dirname, "core", name), "utf8");
+  }).join("\n");
+  cached = HEADER + body + FOOTER;
+  return cached;
+}
+
+module.exports = { buildCoreScript: buildCoreScript };

package/lib/build-system-prompt.js

@@ -25,6 +25,12 @@ Example "explanation" for a trivial goal:
 
 Deploy and trigger it; let me know what the debug output shows."
 
+ALWAYS include at least one debug node in your proposed flow so the test-and-review cycle has something to observe. This is REQUIRED, not optional. Specific rules:
+- HTTP endpoint flows (http in → function/change → http response): add a debug node tapping the function/change output BEFORE the http response node — wire the function/change output to BOTH the debug node AND the http response node.
+- Inject-triggered flows: the debug node at the end is fine.
+- Any other flow shape: add a debug node at the last meaningful output point.
+Never generate a build flow without a debug node. The loop cannot review what it cannot see.
+
 Everything below describes the envelope/rules for THIS step specifically — they work exactly as written, including the parts that say "Generate mode": for the purposes of this prompt, treat that phrase as describing this build step, not a separate mode. The "explanation" field's content rules below still apply — your "Plan:" block comes first, then that content follows immediately after it in the same field.
 
 ---