@remits/remits-cli 0.1.89 → 0.1.90

package/index.js

@@ -268,6 +268,19 @@ function printResolvedBaseUrl(baseUrl) {
   console.log('Base URL:', normalizeBaseUrl(baseUrl || DEFAULT_BASE_URL));
 }
 
+// A tool's OWN verdict, which is separate from whether the call was dispatched. Only an explicit
+// failure signal counts: tools legitimately return strings, arrays, and maps with no `success` key.
+// Used as a fallback when the platform build predates the envelope's `toolSuccess`.
+function toolResultFailed(result) {
+  if (!result || typeof result !== 'object' || Array.isArray(result)) return false;
+  return result.success === false || result.is_error === true;
+}
+
+function toolResultMessage(result) {
+  if (!toolResultFailed(result)) return null;
+  return result.message || result.error || 'The tool returned an error';
+}
+
 function readConfig() {
   if (!fs.existsSync(CONFIG_FILE)) {
     return {};
@@ -2485,7 +2498,12 @@ async function toolCommand(flags) {
     if (data.threadGroupingId) console.log('Thread grouping ID:', data.threadGroupingId);
     console.log('Session log:', sessionJsonlFile(cwd));
     console.log('Tool response file:', statusResponse.responseFile);
-    if (data.status === 'failed') process.exitCode = 1;
+    // A completed run can still carry a tool-level refusal — see toolResultFailed.
+    const polledFailed = data.toolSuccess === false || toolResultFailed(data.result);
+    if (polledFailed) {
+      console.log('Tool error:', data.toolMessage || toolResultMessage(data.result));
+    }
+    if (data.status === 'failed' || polledFailed) process.exitCode = 1;
     return;
   }
 
@@ -2507,9 +2525,19 @@ async function toolCommand(flags) {
     throw new Error(data.message || 'Tool execution failed');
   }
 
+  // `data.success` only means the tool was found and DISPATCHED. A tool that ran and refused (unmet
+  // precondition, rejected enum value, validation failure) still comes back 200 with its own
+  // success:false, and printing "Tool call succeeded" for that has caused agents to report work as
+  // done that never happened. Prefer the server's hoisted verdict; fall back to introspecting the
+  // result so this still works against an older platform build.
+  const toolFailed = data.toolSuccess === false || toolResultFailed(data.result);
+  const toolFailureMessage = data.toolMessage || toolResultMessage(data.result);
+
   printSessionResolutionWarning(sessionContext);
   printResolvedBaseUrl(baseUrl);
-  console.log(asyncMode ? 'Tool call started.' : 'Tool call succeeded.');
+  console.log(asyncMode ? 'Tool call started.'
+    : (toolFailed ? 'Tool call FAILED — the tool ran and returned an error.' : 'Tool call succeeded.'));
+  if (toolFailed && toolFailureMessage) console.log('Tool error:', toolFailureMessage);
   console.log('Call ID:', callId);
   console.log('Data mode:', data.dataMode || dataMode);
   if (data.variantBranch || variantBranch) console.log('Variant branch:', data.variantBranch || variantBranch);
@@ -2523,6 +2551,9 @@ async function toolCommand(flags) {
   console.log('Session log:', sessionJsonlFile(cwd));
   console.log('Tool response file:', response.responseFile);
 
+  // Non-zero exit so scripted/agent callers that check status notice the refusal too.
+  if (toolFailed) process.exitCode = 1;
+
   if (asyncMode && waitForAsync) {
     const finalStatus = await waitForToolStatus(api, cwd, {
       token: session.token,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remits/remits-cli",
-  "version": "0.1.89",
+  "version": "0.1.90",
   "description": "Local CLI for auth, component sync, and live test execution against Remits",
   "license": "MIT",
   "private": false,

package/skills/remits-cli/SKILL.md

@@ -917,6 +917,7 @@ summary: One-line statement of what this component is for.
 description: |
   Longer technical description with line-number references to the key logic.
 path: /page/merchant-portal        # Readers and Embeddables only
+injectionType: DIRECT              # Embeddables only: DIRECT or IFRAME
 category: default
 auxiliary: false                   # `true` means the sync SKIPS the file entirely — see Auxiliary
 mermaid: |
@@ -1135,7 +1136,7 @@ account:<accountId>:cli:<cliUserId>:components:<branch>:<family>:name:<normalize
 component's OWN type enum such as `ObjectType`/`RuleType`, or absent — **never** the family), `hash`,
 `updatedAt`, the staged content field(s) (`source`/`prompt`/`html`/`javascript`/`schema`/
 `inputSchema`/`previewData`), and `.meta.yml` metadata fields such as `description`, `summary`, `mermaid`,
-`path`, `category`, and Schema flags (`enableTrigger`, `enableFullText`, `enableRAG`, `enableRevisions`,
+`path`, Embeddable `injectionType`, `category`, and Schema flags (`enableTrigger`, `enableFullText`, `enableRAG`, `enableRevisions`,
 `enableBigQuerySync`, `enableRules`, `anchor`, `auxiliary`).
 
 ### How the platform picks staged vs DB (the compile signature)
@@ -1406,7 +1407,7 @@ changes validation and where the subscriber's documents physically land. Treat s
 same care as a trunk schema change.
 
 **What a branch may override.** A variant speaks the same `.meta.yml` vocabulary trunk does — `name`,
-`description`, `summary`, `mermaid`, `category`, `type`, `path`, `collectionName`, `job`, `model`,
+`description`, `summary`, `mermaid`, `category`, `type`, `path`, `injectionType`, `collectionName`, `job`, `model`,
 `agentTimeout`, `mcp`, `cli`, `global`, `purpose`, `auxiliary`, plus Schema flags (`enableTrigger`,
 `enableFullText`, `enableRAG`, `enableRevisions`, `enableBigQuerySync`, `enableRules`, `anchor`) — and the
 component's content files. Keys outside that set are ignored, deliberately: trunk cannot express them either,
@@ -1727,6 +1728,23 @@ remits-cli tool --name "mcp_firestore_search" --input '{"accountId": 37, "collec
 
 Response saved to `./.remits-cli/tool-responses/<callId>.json`. Read the file to see results.
 
+**"Tool call succeeded" means DISPATCHED, not that the tool did what you asked.** A tool that runs
+and refuses — an unmet precondition, a rejected enum value, a failed validation — returns HTTP 200
+with its own `success: false` inside `result`. The CLI now prints `Tool call FAILED — the tool ran
+and returned an error.` plus a `Tool error:` line and exits non-zero, and the response envelope
+carries `toolSuccess` / `toolMessage`. **For any MUTATING call, confirm the tool's own verdict before
+reporting the work as done** — do not grep the terminal output for "succeeded":
+
+```bash
+F=$(remits-cli tool --name mcp_support_ticket --input "$(cat payload.json)" --data-mode prod 2>&1 \
+    | grep -o '[^ ]*tool-responses/[a-f0-9-]*\.json' | tail -1)
+python3 -c "import json;r=json.load(open('$F'))['result'];print(r.get('success'), r.get('message'))"
+```
+
+Build non-trivial JSON into a file (e.g. with `python3 -c 'json.dumps(...)'`) and pass it as
+`--input "$(cat payload.json)"`. Long inline single-quoted JSON intermittently produces no response
+file at all.
+
 For long-running Action/Agent runners, use the tool's own async mode (`executionMode:"async"`), which returns
 the `actionRunId`/`agentRunId` (and, for agents, `sessionId`) immediately:
 
@@ -2141,10 +2159,10 @@ Create and manage the full lifecycle of account-relative `support_tickets`.
 | `affectedComponent` | no | Component or platform area affected (`create`) |
 | `implementationAccountId` / `implementationAccountName` | no | Owning `PLATFORM`/`PRODUCT` account when the ticket concerns shared implementation (e.g. a back-stage platform fix) |
 | `stepsToReproduce` / `acceptanceCriteria` / `tags` | no | Extra `create` fields for defect/enhancement tickets |
-| `assignee` | no | Required for `accept` |
-| `status` | no | Required for `update_status`. Valid values: `in_progress`, `pending_review` |
+| `assignee` | no | Required for `accept`. The agent's own name by convention — `claude`, `codex`, `gemini` |
+| `status` | no | Required for `update_status`. Valid values: `in_progress`, `pending_review`. **The ticket must be `accept`ed first** — otherwise the call is rejected with *"Ticket must be accepted before updating status"* |
 | `resolution` | no | Required for `complete` |
-| `category` / `summary` / `details` / `findings` / `nextStep` | no | Worklog fields for `record_progress` (`category` + `summary` required) |
+| `category` / `summary` / `details` / `findings` / `nextStep` | no | Worklog fields for `record_progress` (`category` + `summary` required). `category` is a **fixed enum** — `triage`, `investigation`, `reproduction`, `fix`, `verification`, `handoff`, `other` — and any other value fails the whole call. `findings` is a **list of strings**, not a paragraph |
 | `artifactType` / `artifactLabel` / `contentBase64` / `gcsPath` / `url` | no | Evidence fields for `add_artifact` (screenshot/trace/log/test_result/link) |
 | `notes` | no | Optional lifecycle note stored with the ticket activity |
 | `attachmentIndex` | no | Zero-based index of the attachment to download. Used with `get_attachment`. |
@@ -2159,13 +2177,24 @@ Create and manage the full lifecycle of account-relative `support_tickets`.
 
 This keeps file retrieval self-contained — no separate download endpoint is needed.
 
-**Recommended flow:**
-1. `read` with the ticket's `accountId` — check ticket state and any attachments
-2. `accept` with the ticket's `accountId`
+**Recommended flow** — `accountId` is optional throughout; `ticketId` resolves the owning account:
+1. `read` — check ticket state and any attachments
+2. **`accept`** (with `assignee`) — this is a **hard precondition for `update_status`**, not just etiquette
 3. `get_attachment` if attachments are present and relevant to the investigation
-4. `update_status` with the ticket's `accountId`
-5. investigate/fix/verify on the owning ticket account or its implementation account as appropriate
-6. `complete` or `release` with the ticket's `accountId`
+4. `update_status` — `in_progress` while working, `pending_review` when the fix is done but not yet deployed
+5. `record_progress` as you go — one `investigation` entry for the root cause, one `verification` entry for the proof
+6. investigate/fix/verify on the owning ticket account or its implementation account as appropriate
+7. `complete` (with `resolution`) or `release` if handing off
+
+**Check each mutation actually landed.** Every action above is a write that can be refused while the
+CLI still reports the *call* as fine — see "Execute a Tool" for why, and read `result.success` from
+the response file. A silent no-op here means telling the user a ticket moved when it did not.
+
+**Duplicates are common.** The same defect is often filed twice — once against the `CLIENT`/subscriber
+account where it was observed and once against the owning `PLATFORM`/`PRODUCT` account. Before
+starting, check `mcp_support_ticket_queue` for the same subject or affected component. Close the
+duplicate with a `resolution` naming the ticket that carries the real work, rather than investigating
+it twice.
 
 **Automation rule:** If a ticket is involved, you should usually:
 - `read` at the start