1 Commits
Author SHA1 Message Date
clawbot c474b8f881 Drop Completed Steps from TODO.md; the tracker is the record (closes #112)
check / check (push) Successful in 8m20s
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 and Next Step now
say what is true today: the 1.0.0 milestone has no open issues, and
@sneak tags `v1.0.0` after running webhooker in limited production. Two
Future Steps items now name what already exists: the Slack target's fixed
message format and the event log's failed and pending views.

Model: opus-5-5
2026-10-13 02:00:32 +00:00
+8 -6
View File
@@ -17,9 +17,8 @@ is done and what is under way. This file keeps no list of either.
# Status # Status
What is still open for 1.0.0 is in its milestone The 1.0.0 milestone (https://git.eeqj.de/sneak/webhooker/milestone/9) has no
(https://git.eeqj.de/sneak/webhooker/milestone/9). `v1.0.0` is not tagged, and open issues, and `v1.0.0` is not tagged. Only @sneak cuts that tag.
only @sneak tags it.
Delivery is at-least-once by design, not by accident: a send whose result row 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 does not land is attempted again, so a receiver can see a duplicate. That is
@@ -34,9 +33,12 @@ is kept mergeable at all times, which is the point of the branch.
# Future Steps # Future Steps
- Per-webhook rate limits, set in the web UI and enforced in the receiver - Delivery status and retry management UI. Replay of a terminally failed
handler, on top of the receiver's existing limits, which `RECEIVER_RATE_LIMIT` delivery and per-attempt detail already landed
sets for the whole server (see Rate Limiting in the README) (https://git.eeqj.de/sneak/webhooker/issues/203,
https://git.eeqj.de/sneak/webhooker/issues/202)
- Per-webhook rate limiting in the receiver handler (per-webhook config plus
handler enforcement; global limits must not apply to receiver endpoints)
- API key authentication for programmatic access (APIKey model exists; Bearer - API key authentication for programmatic access (APIKey model exists; Bearer
token middleware does not) token middleware does not)
- REST API v1 - REST API v1