clawbot
7aace1c089
Every issue branch added an entry to the same list, so each branch conflicted with `next` as soon as another one landed. The tracker already records what is done, in more detail than the list did. The Workflow section now says the tracker is that record, in place of the rule that issue branches leave this file alone. Status points to the 1.0.0 milestone for what is open, and Next Step says @sneak tags `v1.0.0` after running webhooker in limited production. In Future Steps, the per-webhook rate limit item says the receiver's server-wide limits already exist, the delivery status and retry UI item is gone because the event log, replay and resubmit cover it, and two items under Later name what already exists. Model: opus-5-5
2.6 KiB
Workflow
One issue per unit of work, one branch and one PR per issue:
- ensure a tracked issue exists with a definition of done
- branch from
next(never frommain) - do the work; open a PR based on
next(never onmain) - pass an independent review, then the manager squash-merges into
next - push; nothing stays local-only
next is the branch for the next milestone and must stay green and mergeable to
main without notice. One next -> main PR accumulates the milestone;
releases are cut from main separately.
The tracker (https://git.eeqj.de/sneak/webhooker/issues) is the record of what is done and what is under way. This file keeps no list of either.
Status
What is still open for 1.0.0 is in its milestone
(https://git.eeqj.de/sneak/webhooker/milestone/9). v1.0.0 is not tagged, and
only @sneak tags it.
Delivery is at-least-once by design, not by accident: a send whose result row does not land is attempted again, so a receiver can see a duplicate. That is deliberate — the alternative is a silent lost delivery — and the README says so under Rationale. It is not a defect to re-file.
Next Step
@sneak runs webhooker in limited production, then tags v1.0.0. Merging next
into main is a separate act from tagging and waits on neither of those: next
is kept mergeable at all times, which is the point of the branch.
Future Steps
- Per-webhook rate limits, set in the web UI and enforced in the receiver
handler, on top of the receiver's existing limits, which
RECEIVER_RATE_LIMITsets for the whole server (see Rate Limiting in the README) - API key authentication for programmatic access (APIKey model exists; Bearer token middleware does not)
- REST API v1
- CRUD for webhooks, entrypoints, targets
- event viewing and filtering endpoints
- event redelivery endpoint
- OpenAPI specification
- Analytics dashboard: success rates, response times, volume
- A remember-me option at login
- Password reset flow for a forgotten password over the web. The authenticated
password change flow already landed, and a lost password is recoverable from
the console with
webhooker resetpw(#208) - Later, nice to have
- email delivery target type
- SNS and S3 delivery targets
- data transformations (e.g. a configurable Slack message format; the Slack target sends one fixed format today)
- JSONL file delivery with periodic S3 upload
- webhook event search, and filtering beyond the event log's failed and pending views
- multi-user with role-based access control