Repository navigation
feat: take a published page down with stele delete - #6
Conversation
The server has answered DELETE /pages/:slug since the beginning; this gives the CLI a verb for it. `SteleClient.delete` bypasses the JSON-decoding `send` helper — success is a 204 with no body, and routed through `send` every successful delete would surface as a malformedResponse. Its 404 advice is written for the reader a delete actually has: "already gone" is the work being done, not a page to publish first. On success stdout stays empty, deliberately — every other page command's stdout is a URL, and a deleted page has none to print. The confirmation goes to stderr; --json echoes the slug back. A delete aimed at a slug with no live page behind it exits 7 rather than claiming work the server never did. Co-Authored-By: Claude Fable 5 <[email protected]>
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (7)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
What
stele delete <slug>— the CLI verb for theDELETE /pages/:slugendpoint the server has offered all along. Publish-scoped, so an agent's own credential is enough.Design notes
SteleClient.deletebypasses thesendhelper. Success is a 204 with no body (the server strips evenContent-Length), andsendhands every response to aJSONDecoderunconditionally — routed through it, every successful delete would surface as amalformedResponse. It callsperformdirectly, the wayfetchSkilldoes, and keeps thecredential.hostrule by hand since it no longer inherits it.Expectation.deleterather than reusing.write: that one's 404 advice namesstele updateand says to publish the page first, which on a delete is the opposite instruction — an agent following it would recreate the page it was asked to remove. The delete advice frames "already gone" as the work being done.conflict: .none, because this route asks for no name and a 409 on it is a genuine surprise.url=$(stele publish page.html)safe; a confirmation line here would be captured by the same idiom and handed onward as an address. The dimdeleted <slug>goes to stderr beside the deadline line;--jsonechoes the slug on stdout.update/amend— a typo'd slug is an error to branch on, not a 0 that means nothing happened. No new exit code.Testing
Path.segment, the 204 empty-body no-decode regression, and the 404/403 mappings. Full suite: 152 tests passing.Not in this PR
publish-to-steleskill claims to cover "delete or unpublish"; updating it to point atstele deleteis queued as a follow-up.🤖 Generated with Claude Code