@f5xc-salesdemos/xcsh 18.4.1 → 18.5.0

package/package.json

@@ -1,7 +1,7 @@
 {
 	"type": "module",
 	"name": "@f5xc-salesdemos/xcsh",
-	"version": "18.4.1",
+	"version": "18.5.0",
 	"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.0",
+		"@f5xc-salesdemos/pi-agent-core": "18.5.0",
+		"@f5xc-salesdemos/pi-ai": "18.5.0",
+		"@f5xc-salesdemos/pi-natives": "18.5.0",
+		"@f5xc-salesdemos/pi-tui": "18.5.0",
+		"@f5xc-salesdemos/pi-utils": "18.5.0",
 		"@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.0",
+	"commit": "50d87af3879c08179ba1f0bb790ec3928c3b41ea",
+	"shortCommit": "50d87af",
 	"branch": "main",
-	"tag": "v18.4.1",
-	"commitDate": "2026-04-21T06:41:15Z",
-	"buildDate": "2026-04-21T07:03:57.574Z",
+	"tag": "v18.5.0",
+	"commitDate": "2026-04-21T07:29:16Z",
+	"buildDate": "2026-04-21T07:56:37.534Z",
 	"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/50d87af3879c08179ba1f0bb790ec3928c3b41ea",
+	"releaseUrl": "https://github.com/f5xc-salesdemos/xcsh/releases/tag/v18.5.0"
 };

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>