@cspeach/cli 1.1.4 → 1.1.6

package/dist/agent/tool-dispatch.js

@@ -25,7 +25,13 @@ export async function dispatchTool(name, args, ctx) {
     // Rule 8 — no batch without plan. 2nd+ mutating call this turn requires
     // explicit confirmation. Fires regardless of /safety-mode toggle (batch
     // detection is unconditional per Plan 3 §6.6).
-    if (tool.isMutating && shouldGateRule8()) {
+    // Scratch-output exemption (2026-09-16): files under ./cspeach-out/ are the
+    // standalone Manual Implementation Guide outputs (NN-<OBJECT>.<ext>,
+    // GUIDE.md) — local scratch, not SAP objects. Rule 8 protects SAP batches;
+    // applying it here made the 2nd+ file (GUIDE.md) hit the batch card and,
+    // headless, get refused. Exempt from the gate AND from the batch count.
+    const scratchWrite = isScratchOutputWrite(tool, args);
+    if (tool.isMutating && !scratchWrite && shouldGateRule8()) {
         const r = await presentSafetyConfirmation({
             rule: 'RULE_8_BATCH_PLAN',
             op: tool.name,
@@ -67,7 +73,7 @@ export async function dispatchTool(name, args, ctx) {
         // Always record AFTER successful mutating dispatch — applies to 1st and
         // 2nd+ writes alike. The 1st write seeds the counter; without this the
         // gate would never fire on the 2nd write.
-        if (tool.isMutating && !(result.is_error ?? false)) {
+        if (tool.isMutating && !scratchWrite && !(result.is_error ?? false)) {
             recordWriteOp(tool.name, args);
         }
         return { content: result.content, is_error: result.is_error ?? false };
@@ -76,3 +82,22 @@ export async function dispatchTool(name, args, ctx) {
         return { content: JSON.stringify({ error: String(err) }), is_error: true };
     }
 }
+/**
+ * True for a mutating filesystem tool whose target sits under ./cspeach-out/
+ * (relative to cwd). Accepts `cspeach-out/…`, `./cspeach-out/…` and the
+ * Windows backslash form; rejects anything that climbs out (`..`) or is
+ * absolute. Deliberately narrow: only this one folder is exempt.
+ */
+export function isScratchOutputWrite(tool, args) {
+    if (!tool.isMutating || tool.category !== 'filesystem')
+        return false;
+    const raw = args?.path;
+    if (typeof raw !== 'string' || raw.length === 0)
+        return false;
+    const p = raw.replace(/\\/g, '/').replace(/^\.\//, '');
+    if (p.startsWith('/') || /^[A-Za-z]:\//.test(p))
+        return false;
+    if (p.split('/').some((seg) => seg === '..'))
+        return false;
+    return p === 'cspeach-out' || p.startsWith('cspeach-out/');
+}

package/dist/router/intent-extractor.js

@@ -108,7 +108,12 @@ export function formatFactBlock(facts, sapSystemBlock = '') {
     if (facts.objectNames && facts.objectNames.length > 0) {
         lines.push(`  <object_names>${facts.objectNames.join(', ')}</object_names>`);
     }
-    if (facts.environmentHint) {
+    // 2026-09-16: the environment hint is a regex guess over the prompt text.
+    // When a real system block is present (live probe, or the standalone
+    // profile the user answered), that block is authoritative — a stray
+    // "ABAP Cloud" in the prompt must not contradict it. Only emit the hint
+    // when there is no <sap_system …/> element to defer to.
+    if (facts.environmentHint && !sapSystemBlock.includes('<sap_system')) {
         lines.push(`  <environment_hint>${facts.environmentHint}</environment_hint>`);
     }
     if (facts.createIntent)

package/dist/sap/standalone-profile.js

@@ -218,13 +218,13 @@ export function renderStandaloneSapSystemBlock(profile) {
  */
 export const STANDALONE_NOTE = '<standalone_note>No SAP system is connected (standalone mode). Do not call SAP tools. ' +
     'Work from code the user pastes or describes; when a task needs system data (source, table definitions, ATC output, dumps), ask the user to paste it. ' +
-    'Target the platform and release in sap_system exactly — use only syntax and APIs available on that release. ' +
+    'Package, transport and system facts the user states are confirmed facts in standalone mode: record them, never re-validate them, and never treat "validated to exist" as a gate to check. When resuming a plan, do not re-open a phase whose gate only lacks a system check; note the waiver once and move to the next phase. Target the platform and release in sap_system exactly — use only syntax and APIs available on that release. ' +
     'Because nothing can be created or activated here, every task that would normally write to SAP must instead end with a "Manual Implementation Guide": ' +
     'numbered steps in dependency order, one object per step, each stating the object type and name, where to create it (ADT wizard path, or SE80/SE11/SE24/SE38 transaction for SE80 teams), ' +
     'the exact source to paste, the activation step, and any prerequisite (package, transport, number range, message class). ' +
     'Finish with a short verification checklist (syntax check, activation, ATC, unit test) the user can run themselves.\n' +
-    'File outputs: when file tools are available (local build is on), also write every produced object to the working folder as ./cspeach-out/<yyyy-mm-dd>-<short-task-name>/NN-<OBJECT_NAME>.<abap|ddls|bdef|srvd|srvb|ddlx|dcls|txt> in dependency order, and write the Manual Implementation Guide to GUIDE.md in the same folder, with each step pointing at its file. Tell the user the folder path once. If file tools are not available, say so once and keep everything in the reply.\n' +
-    'Step failures: when the user reports a failure at a step ("step 3 failed" plus an error message or screenshot), ask only for what is missing to diagnose it, fix only the affected object, rewrite its file, re-issue that step and any step that depends on it, and state which steps are unchanged. Never restart the whole guide.</standalone_note>';
+    'File outputs: when file tools are available (local build is on), you MUST write every produced object to the working folder as ./cspeach-out/<yyyy-mm-dd>-<short-task-name>/NN-<OBJECT_NAME>.<abap|ddls|bdef|srvd|srvb|ddlx|dcls|txt> in dependency order, and you MUST write the Manual Implementation Guide to GUIDE.md in the same folder before finishing the reply — each step pointing at its file and carrying a status (pending, done, failed, fixed). Tell the user the folder path once. If file tools are not available, say so once and keep everything in the reply. Analysis outputs (spec-gap reports, designs, estimates, reviews, explanations) stay IN THE REPLY in their full standard structure — CSPeach saves their canonical envelope files itself from the reply; write them to a file only as an additional copy, never instead, and never hand-write a .cspeach.json envelope.\n' +
+    'Step failures: when the user reports a failure at a step ("step 3 failed" plus an error message or screenshot), first re-read GUIDE.md and the affected object file from disk so you work from the exact current state, then ask only for what is missing to diagnose it, fix only the affected object, rewrite its file, update that step in GUIDE.md (status and what changed), re-issue that step and any step that depends on it, and state which steps are unchanged. If the user pastes an error without naming a step, identify the object from the error and confirm it in one line. Never restart the whole guide.</standalone_note>';
 /**
  * The full standalone contribution to `<session_context>`: the sap_system
  * element followed by the hand-off note.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cspeach/cli",
-  "version": "1.1.4",
+  "version": "1.1.6",
   "description": "CSPeach — AI-assisted ABAP development CLI. Direct SAP access, 34 skills, safety gates.",
   "keywords": [
     "abap",