1 Commits
Author SHA1 Message Date
clawbot 7aace1c089 Drop Completed Steps from TODO.md; the tracker is the record (closes #112)
check / check (push) Successful in 15m9s
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
2026-10-13 02:42:48 +00:00
+6 -17
View File
@@ -37,22 +37,15 @@ is kept mergeable at all times, which is the point of the branch.
- Per-webhook rate limits, set in the web UI and enforced in the receiver - 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_LIMIT` handler, on top of the receiver's existing limits, which `RECEIVER_RATE_LIMIT`
sets for the whole server (see Rate Limiting in the README) sets for the whole server (see Rate Limiting in the README)
- API key authentication for programmatic access (the `APIKey` model exists, but - API key authentication for programmatic access (APIKey model exists; Bearer
nothing creates a key and no middleware checks one) token middleware does not)
- REST API v1 - REST API v1
- CRUD for webhooks, entrypoints, targets - CRUD for webhooks, entrypoints, targets
- event viewing and filtering endpoints - event viewing and filtering endpoints
- event redelivery endpoint - event redelivery endpoint
- OpenAPI specification - OpenAPI specification
- Analytics in the web UI: response times summarised per webhook or per target, - Analytics dashboard: success rates, response times, volume
and figures for all webhooks together. The webhook page already shows event, - A remember-me option at login
delivery and failure counts and failure percentages, the target list counts
each target's deliveries, the event log and each event's page show every
attempt's duration, and `/metrics` carries server-wide counts and delivery
durations
- A remember-me option at login. Every session already survives a browser
restart: it lasts up to 7 days, and ends sooner after `SESSION_IDLE_TIMEOUT`
(default 24 hours) without activity
- Password reset flow for a forgotten password over the web. The authenticated - Password reset flow for a forgotten password over the web. The authenticated
password _change_ flow already landed, and a lost password is recoverable from password _change_ flow already landed, and a lost password is recoverable from
the console with `webhooker resetpw` the console with `webhooker resetpw`
@@ -62,11 +55,7 @@ is kept mergeable at all times, which is the point of the branch.
- SNS and S3 delivery targets - SNS and S3 delivery targets
- data transformations (e.g. a configurable Slack message format; the Slack - data transformations (e.g. a configurable Slack message format; the Slack
target sends one fixed format today) target sends one fixed format today)
- JSONL file delivery with periodic S3 upload (the `database` target already - JSONL file delivery with periodic S3 upload
archives events to SQLite files, rotated hourly, daily or monthly if set,
and the webhook page offers them as one gzipped JSON download)
- webhook event search, and filtering beyond the event log's failed and - webhook event search, and filtering beyond the event log's failed and
pending views pending views
- multi-user with role-based access control (each webhook already belongs to - multi-user with role-based access control
one account, but there is only the account made at first boot and no way
to add another)