Repository navigation
Conversation
Adds `urlbox report <renderId>` to file a render report with the Urlbox team (category + comment), a post-render hint that prints the ready-to-run report command, and `urlbox support` to open the contact page. - Every render response prints a muted hint line naming the render id and the report command, text-mode + TTY only (json/quiet/piped unchanged). - `urlbox report` is session-authed (needs `urlbox login`): --category and --comment for scripts and agents, an interactive picker + comment prompt otherwise. Errors map to the closed exit-code set (auth 3, not-found 5, conflict 7). - The api client captures the render id from the x-urlbox-request-id response header and error-body requestId, in-memory only so envelopes are byte-identical. - `urlbox support` mirrors `urlbox dashboard`: opens the contact page, prints the URL when headless, never launches a browser in json/quiet. - Also scrubs review-round shorthand and private-repo references out of existing comments.
cjroebuck
left a comment
There was a problem hiding this comment.
Really nice work on this, Arnold. urlbox report feels at home in the CLI: support mirrors dashboard exactly, the report reuses the session plumbing, and the hint gating (text + TTY only, JSON/quiet envelopes byte-identical) is exactly the right call for agents. Capturing the render id from the header in-memory, so no API change is needed, is a neat solution too. The tests cover every output mode, which made this easy to review.
I checked it out locally: go build, go vet and go test ./... are all green. I also checked it against the render-reports contract on mono main. The path, the six categories and the 2000-char comment cap all line up.
A few things I'd like us to close before merging:
1. The report hint also appears on errors that aren't render failures
The API attaches requestId to every presentable error body: invalid API key, validation errors, rate limits, quota exhausted. do() in internal/api/http_client.go wraps any error carrying a requestId in RenderIDError, so e.g. a render with a bad secret prints:
Error: …invalid API key…
Something wrong with this render? Report it: urlbox report <id>
No render doc exists for that id, so following the hint would most likely 404 (exit 5). Could we only attach the hint for genuine render outcomes, i.e. 5xx / engine failure codes, and skip auth/usage/validation/rate-limit? appendReportHint looks like the natural place for that check since it already has the CLIError code.
2. Planning docs: happy for them to go in, with internal details kept out
Keeping the spec/plan/handoff in docs/superpowers/ is fine by me. This repo is public though, so let's adopt a rule for these docs: no mentions of internal infrastructure, setup, configs or services. In this PR that means taking out things like the mono repo and its internal file paths, Crisp/Slack side effects, "renders are free on his staff account", the in-flight worktree notes and the author email/commit-process instructions. It would be great to add that rule to CLAUDE.md too, so the agents writing these docs follow it automatically. (Ironically the same commit does a great job scrubbing exactly this kind of thing from the code comments 🙂)
Smaller things (nice-to-haves, not blockers)
- Session-less users: someone rendering with only an API secret still sees the hint, then gets exit 3 from
urlbox report. Maybe skip the hint when there's no session, or mentionurlbox loginin it? - Cancelling a prompt: pressing Esc/Ctrl-C in the category picker or the comment prompt currently returns "missing --category / --comment" (usage, exit 1). A plain "cancelled" would read more naturally.
- Comment length:
len(comment)counts bytes, while the server's zodmax(2000)counts UTF-16 units. So the CLI rejects non-ASCII comments the API would accept.utf8.RuneCountInStringwould bring them in line. - Commit shape: the comment clean-up across ~50 files is a welcome change! As a separate commit it would make the feature diff much easier to follow.
One open question
For sync renders the id comes from x-urlbox-request-id. On a cache HIT, that header is the current request's id. The report service does Render.findOne({ reqId }), so do cache hits get a Render doc of their own? If not, reports on cached renders would 404. A quick live check on your staff account would settle it.
Great feature overall. Once #1 and the docs tweak are in, I'm very happy to approve. Shout if you'd like to pair on the hint gating.
Adds a way to report a bad render straight from the CLI, plus a shortcut to the support page (as a precursor to reporting an issue with the CLI itself).
urlbox report <renderId>files a render report with the Urlbox team (a category and a short comment).--categoryand--commentand get no prompts.A post-render hint. After a render, the CLI prints one muted line naming the render id and the ready-to-run report command:
It only appears in a real terminal in text mode. Piped, JSON, and quiet output aren't changed.
urlbox supportopens the contact page in the browser (prints the URL instead when there's no browser, and never launches one in JSON/quiet mode) — the same shape asurlbox dashboard.Notes