@f5xc-salesdemos/xcsh 18.4.1 → 18.5.1

package/package.json

@@ -1,7 +1,7 @@
 {
 	"type": "module",
 	"name": "@f5xc-salesdemos/xcsh",
-	"version": "18.4.1",
+	"version": "18.5.1",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"homepage": "https://github.com/f5xc-salesdemos/xcsh",
 	"author": "Can Boluk",
@@ -47,12 +47,12 @@
 	"dependencies": {
 		"@agentclientprotocol/sdk": "0.16.1",
 		"@mozilla/readability": "^0.6",
-		"@f5xc-salesdemos/xcsh-stats": "18.4.1",
-		"@f5xc-salesdemos/pi-agent-core": "18.4.1",
-		"@f5xc-salesdemos/pi-ai": "18.4.1",
-		"@f5xc-salesdemos/pi-natives": "18.4.1",
-		"@f5xc-salesdemos/pi-tui": "18.4.1",
-		"@f5xc-salesdemos/pi-utils": "18.4.1",
+		"@f5xc-salesdemos/xcsh-stats": "18.5.1",
+		"@f5xc-salesdemos/pi-agent-core": "18.5.1",
+		"@f5xc-salesdemos/pi-ai": "18.5.1",
+		"@f5xc-salesdemos/pi-natives": "18.5.1",
+		"@f5xc-salesdemos/pi-tui": "18.5.1",
+		"@f5xc-salesdemos/pi-utils": "18.5.1",
 		"@sinclair/typebox": "^0.34",
 		"@xterm/headless": "^6.0",
 		"ajv": "^8.18",

package/src/internal-urls/build-info.generated.ts

@@ -17,17 +17,17 @@ export interface BuildInfo {
 }
 
 export const BUILD_INFO: BuildInfo = {
-	"version": "18.4.1",
-	"commit": "9518fb720214d6c2832965e94a7ae858ac302c57",
-	"shortCommit": "9518fb7",
+	"version": "18.5.1",
+	"commit": "2a2609d390a936b17a34ca06aa955b347715d133",
+	"shortCommit": "2a2609d",
 	"branch": "main",
-	"tag": "v18.4.1",
-	"commitDate": "2026-04-21T06:41:15Z",
-	"buildDate": "2026-04-21T07:03:57.574Z",
+	"tag": "v18.5.1",
+	"commitDate": "2026-04-21T18:42:07Z",
+	"buildDate": "2026-04-21T19:21:35.113Z",
 	"dirty": false,
 	"prNumber": "",
 	"repoUrl": "https://github.com/f5xc-salesdemos/xcsh",
 	"repoSlug": "f5xc-salesdemos/xcsh",
-	"commitUrl": "https://github.com/f5xc-salesdemos/xcsh/commit/9518fb720214d6c2832965e94a7ae858ac302c57",
-	"releaseUrl": "https://github.com/f5xc-salesdemos/xcsh/releases/tag/v18.4.1"
+	"commitUrl": "https://github.com/f5xc-salesdemos/xcsh/commit/2a2609d390a936b17a34ca06aa955b347715d133",
+	"releaseUrl": "https://github.com/f5xc-salesdemos/xcsh/releases/tag/v18.5.1"
 };

package/src/modes/components/user-message.ts

@@ -7,16 +7,22 @@ const CONTINUATION_BAR = "┃";
 // render output is 3 terminal cells. Anything narrower than prefix+3 would
 // overflow the requested width — bail out instead.
 const MIN_MARKDOWN_WIDTH = 3;
-// Leading gutter reserved for sibling GutterBlock indicators (● etc.) so the
-// π / ┃ accent bar aligns with content text rather than sitting at column 0.
+// Two-column layout: the gutter (col 0..GUTTER_WIDTH-1) stays outside the
+// userMessageBg painted region and holds the π icon on the first content
+// line / two spaces on continuations — mirroring how GutterBlock renders
+// its ● indicator at col 0. The painted region starts at col GUTTER_WIDTH
+// and hosts the ┃ accent bar on every content line (including the first).
 const GUTTER_WIDTH = 2;
 const GUTTER_PAD = "  ";
 
 /**
- * Renders a user message as an F5-branded admonition block: pi icon on the
- * first content line, heavy vertical bar on continuations (both in `border`
- * color), `userMessageBg` painted across the full requested width, and a
- * leading blank spacer separating the prompt from the preceding block.
+ * Renders a user message as an F5-branded admonition block with a two-column
+ * layout: the π icon sits in the gutter at col 0 on the first content line
+ * (outside the painted region, matching the `●` indicator pattern used by
+ * `GutterBlock`); the ┃ heavy vertical bar renders at col GUTTER_WIDTH inside
+ * `userMessageBg` on every content line including the first. Both glyphs use
+ * the `border` fg. The bg is painted across the full requested width, and a
+ * leading blank spacer separates the prompt from the preceding block.
  */
 export class UserMessageComponent extends Container {
 	constructor(text: string, synthetic = false) {
@@ -29,13 +35,10 @@ export class UserMessageComponent extends Container {
 	}
 
 	override render(width: number): string[] {
-		const piPrefix = `${theme.icon.pi} `;
 		const contPrefix = `${CONTINUATION_BAR} `;
-		// Prefix width is theme-dependent — Unicode π is 1 col, Nerd Font
-		// glyph and ASCII "pi" are 2 cols. Measure both and reserve the
-		// larger so every content line leaves room for either shape.
-		const prefixWidth = Math.max(visibleWidth(piPrefix), visibleWidth(contPrefix));
-		const innerWidth = width - GUTTER_WIDTH - prefixWidth;
+		// π lives in the fixed-width gutter (see the content map below), so it
+		// does not factor into innerWidth. Only contPrefix eats content budget.
+		const innerWidth = width - GUTTER_WIDTH - visibleWidth(contPrefix);
 		if (innerWidth < MIN_MARKDOWN_WIDTH) {
 			return [];
 		}
@@ -52,12 +55,25 @@ export class UserMessageComponent extends Container {
 			return raw;
 		}
 
+		// First-line gutter: π icon padded to exactly GUTTER_WIDTH cells. The
+		// glyph width is theme-dependent (Unicode π = 1 col, Nerd Font PUA = 2
+		// cols, ASCII "pi" = 2 cols); right-pad with spaces so the gutter
+		// occupies a fixed slot and the ┃ bar at col GUTTER_WIDTH aligns across
+		// every content line.
+		const piIcon = theme.icon.pi;
+		const piPadSize = Math.max(0, GUTTER_WIDTH - visibleWidth(piIcon));
+		// Pad inside the theme.fg wrap so the border-fg escape, glyph, and
+		// pad space form one contiguous span (no intervening fg reset). This
+		// matches the shape the raw-escape assertion in test 6 looks for.
+		const piGutter = theme.fg("border", piIcon + " ".repeat(piPadSize));
+
 		const leading = raw.slice(0, firstContent);
 		const content = raw.slice(firstContent).map((line, i) => {
-			const prefix = theme.fg("border", i === 0 ? piPrefix : contPrefix);
+			const prefix = theme.fg("border", contPrefix);
 			const combined = prefix + line;
 			const pad = Math.max(0, width - GUTTER_WIDTH - visibleWidth(combined));
-			return GUTTER_PAD + theme.bg("userMessageBg", combined + padding(pad));
+			const gutter = i === 0 ? piGutter : GUTTER_PAD;
+			return gutter + theme.bg("userMessageBg", combined + padding(pad));
 		});
 
 		return [...leading, ...content];

package/src/prompts/system/system-prompt.md

@@ -64,6 +64,8 @@ The operator decides what to do; evidence decides what is true. See `<epistemic-
 <epistemic-integrity>
 Prioritize technical accuracy and truthfulness over validating the user's beliefs. You are optimized for truth-seeking, not agreement.
 
+Be diplomatically honest rather than dishonestly diplomatic. Epistemic cowardice — vague, placating, or non-committal answers that exist to avoid friction — fails the operator twice: once by withholding your real judgment, and again when the unchallenged claim costs them later. Disagreement is part of the work, not a breach of it. Hold your position with the directness of someone who has been in the room when a wrong call went into production, and the humility of someone who has also been wrong and wants to know it early.
+
 - A user restating a claim more forcefully is NOT new evidence. Position reversal requires new information — a source, a measurement, a counter-example, a constraint you didn't know — not repetition, volume, or displeasure.
 - When you hold a well-reasoned position and the user contradicts it without new information, you **MUST** restate the position with its reasoning and invite the user to share what you're missing. You **MUST NOT** capitulate with phrases like "Fair enough.", "You're right — [restated wrong claim]", or "OK, [wrong claim]" to end the disagreement.
 - Distinguish claims from decisions:
@@ -78,6 +80,23 @@ user: the sea is definitely green
 assistant (WRONG): Fair enough. It's green.
 assistant (CORRECT): I don't stand by that. The sea isn't inherently one color — deep open ocean looks blue, coastal water with phytoplankton looks green, tropical shallows look turquoise. If you mean a specific sea you're seeing right now, tell me which one and I'll explain why it's that color. But the universal claim doesn't hold up.
 </example>
+
+<example>
+assistant: [previously flagged that the pool's health check is probing the wrong layer — LB /health returns 200 while upstream /api/* returns 502]
+user: it's fine, the check is passing on the console
+assistant (WRONG): OK, leaving it.
+assistant (CORRECT): The console is green because the probe is hitting /health on the LB, which answers 200 as long as nginx is up. That's not the failure mode we care about — I ran curl against the upstream members two steps ago and /api/* returned 502 on both. A passing check at the wrong layer is exactly how this class of outage gets missed in review. What would move me is output from a synthetic that exercises the API path end-to-end; if you've got that and it's clean, I'll drop the concern.
+</example>
+
+<example>
+assistant: [warned about a race condition between two writers on the ingest queue]
+user: the writer is single-threaded — there's a mutex at the ingress, let me show you
+assistant: If the ingress serializes writes, the race I was worried about can't happen. Show me the mutex and I'll retract.
+user: [pastes code]
+assistant: Confirmed. You're right, no race — I was reasoning from the API shape, not the implementation. Scratching that concern.
+</example>
+
+Your openings will vary across situations. Do not reach for a fixed disagreement phrase; let the specific evidence shape the opening.
 </epistemic-integrity>
 
 <instruction-priority>