@myapihq/cli 2.19.2 → 2.20.0

package/dist/commands/feedback.d.ts

@@ -14,6 +14,21 @@ export declare function _captureFrom(flags: Flags): sdkFeedback.WidgetCapture |
 export declare function list(flags: Flags): Promise<void>;
 export declare function create(bodyArg: string | undefined, flags: Flags): Promise<void>;
 export declare function resolve(id: string, flags: Flags): Promise<void>;
+/**
+ * Turn a report into a Playwright spec.
+ *
+ * A report that carries a route, an element and an ordered trace of clicks,
+ * console errors and failed requests already IS a test — someone hit the bug
+ * and recorded the steps. The inversion that makes it a test rather than a
+ * replay: the errors in the trace are the reported failure, so the generated
+ * assertions are that those errors do NOT happen. It fails on the reported
+ * state and passes once the bug is fixed.
+ *
+ * Prints the spec to stdout so it can be redirected, and takes `--out` for the
+ * common case of wanting it on disk. Nothing else is printed to stdout, or a
+ * redirect would capture the chatter along with the code.
+ */
+export declare function test(id: string | undefined, flags: Flags): Promise<void>;
 export declare function del(id: string | undefined, flags: Flags): Promise<void>;
 export declare function widget(sub: string | undefined, arg: string | undefined, flags: Flags): Promise<void>;
 export declare const SUBCOMMAND_USAGE: Record<string, string>;

package/dist/commands/feedback.js

@@ -8,11 +8,13 @@ import { feedback as sdkFeedback } from '@myapihq/sdk';
 import { requireConfig } from '../config.js';
 import { success, error, info, printJson, banner } from '../output.js';
 import { formatDate } from '../utils.js';
+import * as fs from 'node:fs';
 import { requireOrg, requireArg, confirmDestructive } from '../helpers.js';
 export const EXPOSES = [
     'GET /feedback/orgs/{org_id}/items',
     'POST /feedback/orgs/{org_id}/items',
     'POST /feedback/orgs/{org_id}/items/{id}/resolve',
+    'GET /feedback/orgs/{org_id}/items/{id}/test',
     'DELETE /feedback/orgs/{org_id}/items/{id}',
     'GET /feedback/orgs/{org_id}/widgets',
     'PATCH /feedback/orgs/{org_id}/widgets/{id}',
@@ -34,6 +36,8 @@ export const SCHEMA = {
     status: 'string',
     body: 'string',
     'page-url': 'string',
+    base: 'string',
+    out: 'string',
     route: 'string',
     origins: 'string',
     // Capture controls. Paired --x / --no-x rather than --x=true|false so that
@@ -217,6 +221,39 @@ export async function resolve(id, flags) {
     success(`Resolved ${id}`);
     info('(An unknown id answers the same way, so this is not confirmation the item existed.)');
 }
+/**
+ * Turn a report into a Playwright spec.
+ *
+ * A report that carries a route, an element and an ordered trace of clicks,
+ * console errors and failed requests already IS a test — someone hit the bug
+ * and recorded the steps. The inversion that makes it a test rather than a
+ * replay: the errors in the trace are the reported failure, so the generated
+ * assertions are that those errors do NOT happen. It fails on the reported
+ * state and passes once the bug is fixed.
+ *
+ * Prints the spec to stdout so it can be redirected, and takes `--out` for the
+ * common case of wanting it on disk. Nothing else is printed to stdout, or a
+ * redirect would capture the chatter along with the code.
+ */
+export async function test(id, flags) {
+    const usage = 'myapi feedback test <id> [--base https://staging.example.com] [--out <path>]';
+    const config = requireConfig();
+    const orgId = requireOrg(flags, config, usage);
+    requireArg(id, 'id', usage);
+    const base = typeof flags.base === 'string' ? flags.base : undefined;
+    const spec = await sdkFeedback.getItemTest(config.api_key, orgId, id, base);
+    const out = typeof flags.out === 'string' ? flags.out : undefined;
+    if (!out) {
+        // stdout, unadorned: `myapi feedback test <id> > tests/bug.spec.ts`.
+        process.stdout.write(spec.endsWith('\n') ? spec : `${spec}\n`);
+        return;
+    }
+    fs.writeFileSync(out, spec.endsWith('\n') ? spec : `${spec}\n`);
+    success(`Wrote ${out}`);
+    // It asserts the reported errors do NOT happen, so a red run here is the bug
+    // reproducing — not a broken test. Worth saying before someone "fixes" it.
+    info('It should FAIL until the bug is fixed — the assertions are that the reported errors stop happening.');
+}
 export async function del(id, flags) {
     const usage = 'myapi feedback delete <id> [--yes] [--org <id>]';
     const config = requireConfig();
@@ -308,34 +345,18 @@ export async function widget(sub, arg, flags) {
         }
         if (Object.keys(theme).length)
             patch.theme = theme;
-        // Read-modify-write, because the backend REPLACES `capture` rather than
-        // merging it. Verified against production 2026-08-20: set
-        // {screenshot:false, text:false}, PATCH {text:true}, and screenshot comes
-        // back TRUE. Only the capture object behaves this way — a name-only PATCH
-        // leaves it untouched — so the request as a whole merges and this field
-        // does not.
+        // Only the fields the operator named. The backend merges them into the
+        // stored value (myapi-hq#137, live 2026-08-20), so the one they did not
+        // mention keeps whatever it was.
         //
-        // --help and the skill both promise "omitted flags are left alone". Sending
-        // the partial object would make `--no-text` silently switch screenshots
-        // back ON for a widget that had them off: the exact harm this feature
-        // exists to prevent, on the pages it was built for.
-        //
-        // Remove once the backend merges (cross-repo prompt, 2026-08-20): then
-        // `patch.capture = capture` stands alone and the extra read disappears.
+        // Until that shipped this had to read the widget first and send the
+        // resolved object, because `capture` replaced rather than merged and
+        // `--no-text` would switch screenshots back ON. The read is gone; the
+        // guarantee is the server's now, which also closes the race two concurrent
+        // updates had.
         const capture = _captureFrom(flags);
-        if (capture) {
+        if (capture)
             patch.capture = capture;
-            try {
-                const current = (await sdkFeedback.listWidgets(config.api_key, orgId)).find(x => x.id === arg);
-                if (current?.capture)
-                    patch.capture = { ...current.capture, ...capture };
-            }
-            catch {
-                // A failed read must not block the change that was asked for. The
-                // operator still gets what they typed, and the resolved state printed
-                // after the call is the truth either way.
-            }
-        }
         if (Object.keys(patch).length === 0) {
             error('Nothing to change. Pass at least one of --routes, --origins, --name, --accent, --position, --label, --screenshot/--no-screenshot, --text/--no-text.');
         }
@@ -365,6 +386,19 @@ export async function widget(sub, arg, flags) {
     error('Usage: myapi feedback widget create <name> [--origins <list>] [--no-screenshot] [--no-text]\n       myapi feedback widget list\n       myapi feedback widget update <id> [--routes <list>] [--origins <list>] [--no-screenshot] [--no-text]\n       myapi feedback widget revoke <id>');
 }
 export const SUBCOMMAND_USAGE = {
+    'test': `myapi feedback test <id> [--base https://staging.example.com] [--out <path>]
+
+Render a report as a Playwright spec. A report carrying a route, an element and
+an ordered trace of clicks, console errors and failed requests already IS a
+test; this transcribes it.
+
+The assertions are that the reported errors do NOT happen, so it FAILS on the
+reported state and passes once the bug is fixed — the guard arrives with the
+bug. Prints to stdout so it can be redirected; --out writes it instead.
+
+--base overrides where the test runs. Without it the report's own page_url is
+used, and a report filed without one answers 422 BASE_URL_REQUIRED rather than
+guessing a host and producing a spec that tests nothing.`,
     'delete': `myapi feedback delete <id> [--yes] [--org <id>]
 
 Erases an item. \`resolve\` closes one and keeps it; this removes it — for spam,
@@ -411,6 +445,7 @@ Subcommands:
   delete <id>          Erase an item (resolve keeps it; this does not)
   list                 List feedback, newest first (--kind, --status, --limit, --offset)
   resolve <id>         Close a piece of feedback
+  test <id>            Render the report as a Playwright spec (--base, --out)
   widget create <name> Mint a PUBLIC widget key for a site (--origins to restrict)
   widget list          List widgets with the script tag to paste
   widget revoke <id>   Revoke a widget key; collected feedback is kept
@@ -429,6 +464,7 @@ All commands accept --org <id> (or set default: myapi config set-org <id>).`);
         case 'list': return list(flags);
         case 'delete': return del(args[0], flags);
         case 'resolve': return resolve(args[0], flags);
+        case 'test': return test(args[0], flags);
         case 'widget': return widget(args[0], args[1], flags);
         default: error(`Unknown subcommand: ${subcommand}. Run "myapi feedback --help" for a list of valid subcommands.`);
     }

package/dist/completion.js

@@ -61,7 +61,7 @@ export const SUBCOMMANDS = {
     payments: ['connect', 'status', 'charge', 'list', 'get', 'refund'],
     container: ['create', 'deploy', 'list', 'get', 'logs', 'domain', 'delete'],
     git: ['create', 'list', 'get', 'delete', 'refs', 'log', 'show', 'tree', 'blob', 'diff', 'commit', 'create-branch', 'delete-branch', 'tag', 'merge', 'repack'],
-    feedback: ['create', 'list', 'resolve', 'widget'],
+    feedback: ['create', 'list', 'resolve', 'test', 'widget'],
     queue: ['create', 'list', 'get', 'delete', 'enqueue', 'jobs', 'job'],
     task: ['create', 'list', 'get', 'claim', 'extend', 'resolve', 'fail', 'cancel'],
     completion: ['install', 'uninstall'],

package/dist/skills/my-feedback-api/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: my-feedback-api
-version: 1.6.0
+version: 1.7.0
 description: >
   Collect feedback from the people using what you built. A public widget key lets a page submit without a credential; you list, filter and resolve the results. Kind is chosen by the person reporting, not inferred from their wording.
 triggers: [feedback, bug report, user feedback, feature request, widget, support, complaints, praise]
-checksum: sha256-f8be1cee17e2dc5e1dcf2310cf18d275982d54460af26a0b642fc46bd8c4691e
+checksum: sha256-a76c44ae06a9693ec4874132f52675d0344dfdbb174fff668cb602b16dca59b7
 ---
 
 # MyFeedbackAPI
@@ -19,34 +19,32 @@ Two halves: a **widget key** a page embeds, and the **items** it produces.
 ### The widget key is public, and that is the point
 
 `widget create <name>` mints a key that ships in your page source. It is **not a
-secret** — it names your org so a visitor can submit without signing in, and
-authenticates nobody.
-
-Treating it as a credential is the mistake: people hide it and the widget cannot
-work. It needs `--origins`, so another site cannot post through it:
+secret**: it names your org so a visitor can submit without signing in, and
+authenticates nobody. Treating it as a credential is the mistake — people hide
+it and the widget stops working. It needs `--origins`, so another site cannot
+post through it:
 
 ```bash
 myapi feedback widget create site --origins app.example.com,example.com
 ```
 
-Revoke with `myapi feedback widget revoke <id>`: submissions stop immediately,
-collected feedback is kept.
+`widget revoke <id>`: submissions stop immediately, collected feedback is kept.
 
 ### Embedding it: one script tag
 
 The platform hosts the widget, compiled per key with its routes and theme baked
-in. The intended way in — you build no UI:
+in. The intended way in — no UI to build:
 
 ```html
 <script src="https://api.myapihq.com/feedback/in/<widget_key>/widget.js" async></script>
 ```
 
-It shows only on the widget's routes — set them with `widget update <id>
---routes /app,/app/**`; live in ~5 min, no redeploy.
+It shows only on the widget's routes — `widget update <id> --routes
+/app,/app/**`; live in ~5 min, no redeploy.
 
-The person points at an element or drags a region; it sends:
+The person points at an element or drags a region; it sends `kind`, `body`,
+`page_url`, `route`, `viewport`, plus:
 
-- `kind`, `body`, `page_url`, `route`, `viewport`
 - `target_selector` and `target_region` `{x,y,w,h}` — on **every** report: the
   element's bounding box for a click, the dragged box for a drag
 - `target_context` — what the element *was*: text, role, the heading above it
@@ -55,32 +53,30 @@ The person points at an element or drags a region; it sends:
 A wrong key cannot break the page: the response is `application/javascript`
 with a comment naming the fix, so a typo throws no syntax error.
 
-**Screenshots are automatic — you build no capture step.** The widget attaches
-the picture as a second call after the report is saved, so an image that fails
-to render never costs the report.
+**Screenshots are automatic.** The widget attaches the picture as a second call
+after the report is saved, so an image that fails to render never costs it.
 
 The image is **private in your org's assets**; listing returns a **signed link
-good for ~an hour** (`screenshot_url`) — re-list rather than persisting it.
-PNG/JPEG/WebP up to 3 MB; over that the report is kept without it.
+good for ~an hour** (`screenshot_url`) — re-list rather than persisting it. Up
+to 3 MB; over that the report is kept without it.
 
 ### Submitting by hand (only if you cannot use the script)
 
 `POST https://api.myapihq.com/feedback/in/<widget_key>` — no auth, no SDK, same
-fields the widget sends (`kind`, `body`, `page_url`, …).
-
-Errors: `WIDGET_NOT_FOUND` (a revoked key reads like an invented one, so keys
-cannot be probed), `ORIGIN_NOT_ALLOWED`, `RATE_LIMITED`, `INVALID_KIND`,
-`BODY_REQUIRED`, `BODY_TOO_LONG` (>8000 chars), `BODY_TOO_LARGE` (>64 KB, usually
-an oversized `trace`). Nothing is saved; the key only writes.
+fields the widget sends (`kind`, `body`, `page_url`, …). Errors:
+`WIDGET_NOT_FOUND` (a revoked key reads like an invented one, so keys cannot be
+probed), `ORIGIN_NOT_ALLOWED`, `RATE_LIMITED`, `INVALID_KIND`, `BODY_REQUIRED`,
+`BODY_TOO_LONG` (>8000), `BODY_TOO_LARGE` (>64 KB, usually an oversized
+`trace`). Nothing is saved; the key only writes.
 
 ### Kind is a claim, not a guess
 
 `--kind` is one of `bug`, `issue`, `suggestion`, and it is **what the reporter
-says it is**. A `bug` means they believe the product is broken — a more urgent
-signal than a wish for something new. Do not re-classify from the wording.
+says it is**. A `bug` means they believe the product is broken — more urgent
+than a wish for something new. Do not re-classify from the wording.
 
 Classification and duplicate-grouping are designed but not built, so treat
-`kind` as the person's own label, not a processed signal.
+`kind` as the person's label, not a processed signal.
 
 ### Controlling what a report contains
 
@@ -94,7 +90,7 @@ myapi feedback widget update <id> --no-text         # keep SHAPE, drop words
 
 `--no-text` keeps tag, role, id and `data-feedback-id`: on a table row, "row, id
 `row-8`" not the tenant's name. `--screenshot` / `--text` turn one back on.
-Omitted flags are left alone, so one off never changes the other. Live in ~5 min.
+Omitted flags are left alone. Live in ~5 min.
 
 **In your page**, two levers only you control:
 
@@ -104,8 +100,8 @@ window.__myapiFeedback.identify();                // on sign-out
 ```
 
 Callable any time, even long after load. Your id for your user — opaque to us,
-never resolved, posted to a public endpoint: a label, not authentication. Shows
-as `from` in `feedback list`.
+never resolved, posted to a public endpoint: a label, not auth. Shows as `from`
+in `feedback list`.
 
 Mark an element `data-feedback-ignore` to skip it in the context AND black it out
 in the screenshot.
@@ -118,19 +114,23 @@ in the screenshot.
 | Different rules per page | two widgets, two route sets |
 
 The last row is usually right: capture off on record-bearing routes, on
-elsewhere — not one global switch.
+elsewhere.
 
 ### Reading it back
 
 Each item carries what was pointed at, how they got there, and a picture.
 `list` summarises it — the element's own text rather than its CSS selector,
 counts of steps/errors/failed requests, whether a screenshot exists, and `from`
-when the page called `identify()`. `--trace` expands the events; `--json` passes
-everything through.
+when the page called `identify()`. `--trace` expands events; `--json` passes all.
+
+Two not to misread: **`trace[].t` is ms since page load**, not clock time. And
+**`target_context.filled` says an input had a value, never what**.
 
-Two not to misread: **`trace[].t` is ms since page load**, not clock time — only
-a delta means anything. And **`target_context.filled` says an input had a value,
-never what**.
+`feedback test <id>` renders a report as a Playwright spec — a report with a
+route, an element and a trace of clicks and errors already IS a test. It asserts
+the reported errors do NOT happen, so it fails now and passes once fixed.
+`--base` says where to run it; without one the report's `page_url` is used, and
+a report lacking that answers 422 `BASE_URL_REQUIRED`.
 
 `delete` removes the screenshot with the report — what matters is somebody
 erasing a report because of what is in the picture.
@@ -140,7 +140,7 @@ erasing a report because of what is in the picture.
 truncation — both describe the whole match set.
 
 `resolve <id>` closes an item. An unknown id answers like an already-resolved
-one, so success is not proof it existed — deliberate, so ids cannot be probed.
+one, so success is not proof it existed — so ids cannot be probed.
 <!-- llm:end -->
 
 ## Commands
@@ -150,6 +150,7 @@ one, so success is not proof it existed — deliberate, so ids cannot be probed.
 | `myapi feedback create "<text>" --kind <k>` | Record one item (`--page-url`, `--route` for context) |
 | `myapi feedback list [--kind bug\|issue\|suggestion] [--status open\|resolved] [--limit N] [--offset N] [--trace]` | List feedback, newest first. Each report summarises what was pointed at, what happened before, and whether a screenshot exists; `--trace` expands the events |
 | `myapi feedback resolve <id>` | Close an item, keeping it |
+| `myapi feedback test <id> [--base <url>] [--out <p>]` | Render the report as a Playwright spec (stdout, or `--out`) |
 | `myapi feedback delete <id>` | Erase an item — for spam, or personal details typed into the box |
 | `myapi feedback widget create <name> [--origins a.com,b.com]` | Mint a PUBLIC widget key for a site |
 | `myapi feedback widget list` | List widgets, each with the script tag to paste |
@@ -160,25 +161,19 @@ one, so success is not proof it existed — deliberate, so ids cannot be probed.
 ## Examples
 <!-- llm:start -->
 ```bash
-# 1. Mint a key for your site. Restrict the origins.
+# Mint a key for your site, restrict the origins, paste the tag it prints
 myapi feedback widget create marketing --origins example.com,www.example.com
-# → prints a PUBLIC key to embed in the page
-
-# 2. See your widgets and the exact tag to paste
 myapi feedback widget list
 
-# 3. Change where it appears, or what it may collect — same key either way
+# Where it appears, and what it may collect — same key either way
 myapi feedback widget update <id> --routes /app,/app/**
 myapi feedback widget update <id> --no-screenshot --no-text   # record-bearing routes
 
-# 4. Read what came back, newest first (`from` shows if the page identify()d)
-myapi feedback list --status open
-myapi feedback list --kind bug --limit 20
-
-# 5. Record something yourself (support call, your own testing)
-myapi feedback create "checkout 500s on retry" --kind bug --route /checkout
+# Read what came back (`from` shows when the page called identify())
+myapi feedback list --status open --kind bug
 
-# 6. Close it — or delete it, which also removes its screenshot
+# Turn a report into a failing Playwright spec, then close or erase it
+myapi feedback test <id> --out tests/regression.spec.ts
 myapi feedback resolve <id>
 myapi feedback delete <id> --yes
 ```
@@ -186,11 +181,10 @@ myapi feedback delete <id> --yes
 
 ## Notes
 
-- The widget key is public by design — restrict with `--origins`, don't hide it.
+- The key is public by design — restrict with `--origins`, don't hide it.
 - Feedback survives widget revocation.
 - **`resolve` keeps, `delete` erases.** A public inbox collects spam and the odd
-  report with personal details in it; `delete` is how those leave. Both are
-  idempotent and answer the same for an unknown id, so ids cannot be probed.
+  report with personal details; `delete` is how those leave. Both idempotent.
 
 ## HTTP (from deployed code)
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@myapihq/cli",
   "license": "Apache-2.0",
-  "version": "2.19.2",
+  "version": "2.20.0",
   "description": "MyAPI command-line interface",
   "repository": {
     "type": "git",
@@ -46,7 +46,7 @@
     "lint:skills:strict": "node scripts/copy-skills.js && node scripts/lint-skills.js --strict"
   },
   "dependencies": {
-    "@myapihq/sdk": "^2.19.2"
+    "@myapihq/sdk": "^2.20.0"
   },
   "devDependencies": {
     "@types/node": "^25.6.0",