@trawlme/cli 3.12.6 → 3.12.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -1
- package/dist/commands/create.d.ts +1 -0
- package/dist/commands/create.js +7 -1
- package/docs/agent-quickstart.md +5 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -220,7 +220,7 @@ Every command exits with one of these codes — scripts and agents driving the C
|
|
|
220
220
|
| Code | Meaning |
|
|
221
221
|
|------|--------------------------------------------------------------------------|
|
|
222
222
|
| `0` | Success |
|
|
223
|
-
| `1` | Unknown/generic error (an unmapped failure — API errors other than 401/404, an unhandled bug — or a business-logic refusal like `data`'s `run_failed`/`in_progress` states, or `trawl create`'s honest `success:false` first-run outcome). **Known overload:** `create`'s domain-level failure and an arbitrary unmapped bug both land on `1` — a script needs to read the `--json` payload's own `success` field (for `create`) to tell them apart; this is intentional (the REST contract's outcome states are a separate axis from the CLI's transport-error taxonomy) and documented here rather than "resolved" by inventing a new code that would only apply to one command. |
|
|
223
|
+
| `1` | Unknown/generic error (an unmapped failure — API errors other than 401/404, an unhandled bug — or a business-logic refusal like `data`'s `run_failed`/`in_progress` states, or `trawl create`'s honest `success:false` first-run outcome). **Known overload:** `create`'s domain-level failure and an arbitrary unmapped bug both land on `1` — a script needs to read the `--json` payload's own `success` field (for `create`) to tell them apart (and its `verified` field: `success: true` with `verified: false` exits `0` but the wizard never confirmed the script, so check the rows); this is intentional (the REST contract's outcome states are a separate axis from the CLI's transport-error taxonomy) and documented here rather than "resolved" by inventing a new code that would only apply to one command. |
|
|
224
224
|
| `2` | Usage error (bad flag/value, invalid ID, missing required argument, unknown option/command — including the [non-interactive rule](#non-interactive-rule) refusing to prompt) |
|
|
225
225
|
| `3` | Auth error (not logged in, the session token is expired/invalid, or a JWT-only command was run under an API key — see [Authentication](#authentication)) — run `trawl login` |
|
|
226
226
|
| `4` | Not found (no such resource, or — for `data` — no persisted payload to read) |
|
package/dist/commands/create.js
CHANGED
|
@@ -8,7 +8,12 @@ import { requireUrl, requireString } from '../lib/validate.js';
|
|
|
8
8
|
import { UsageError, RefusalError, HUMAN_ERROR_MAX } from '../lib/errors.js';
|
|
9
9
|
import { renderPinch, pinchEnabled } from '../lib/pinch.js';
|
|
10
10
|
import { startPinchAnimation } from '../lib/pinchAnimation.js';
|
|
11
|
+
function unverifiedSuccess(data) {
|
|
12
|
+
return data.success && data.verified === false;
|
|
13
|
+
}
|
|
11
14
|
function firstRunLabel(data, autoFixEnabled) {
|
|
15
|
+
if (unverifiedSuccess(data))
|
|
16
|
+
return 'succeeded — script not verified by the wizard, check the rows';
|
|
12
17
|
if (data.success)
|
|
13
18
|
return 'succeeded';
|
|
14
19
|
if (!data.scrap)
|
|
@@ -169,7 +174,8 @@ export const create = new Command('create')
|
|
|
169
174
|
`Auto-fix is retrying in the background — do NOT re-run create; poll ${pollTarget}.`);
|
|
170
175
|
}
|
|
171
176
|
if (!opts.json && pinchEnabled()) {
|
|
172
|
-
|
|
177
|
+
const mood = !data.success ? 'confused' : unverifiedSuccess(data) ? 'idle' : 'celebrating';
|
|
178
|
+
console.log(renderPinch(mood));
|
|
173
179
|
}
|
|
174
180
|
}
|
|
175
181
|
if (!data.success)
|
package/docs/agent-quickstart.md
CHANGED
|
@@ -101,7 +101,11 @@ first run, and auto-fix on failure (default on; `--no-autofix` disables it).
|
|
|
101
101
|
`success` is an honest outcome of that first run, not "did the HTTP call
|
|
102
102
|
succeed" — a failed first run is still a 200 response (the scrap was still
|
|
103
103
|
created), and the CLI exits `1` in that case even though `--json` always
|
|
104
|
-
prints the raw payload verbatim.
|
|
104
|
+
prints the raw payload verbatim. A `success: true` with `verified: false` means
|
|
105
|
+
the first run returned rows but the wizard never confirmed that exact script
|
|
106
|
+
(it stopped before `finish`): check the rows before trusting it — human mode
|
|
107
|
+
says "succeeded — script not verified by the wizard, check the rows", `--json`
|
|
108
|
+
callers read `verified`. The call legitimately runs many minutes
|
|
105
109
|
server-side (AI generation + a proxy-tier probe ladder + an iteration loop +
|
|
106
110
|
a real run), so the CLI reads the wizard's NDJSON progress stream: human mode
|
|
107
111
|
prints one short line per stage on stderr, `--json` prints only the final
|