Files
webhooker/TODO.md
T
sneak 11c8b6b851
check / check (push) Waiting to run
Rewrite TODO.md sentence by sentence
Rewritten from scratch against the code on next; the sections and
their contents are kept.

Model: fable-5-1
2026-10-25 02:24:03 +00:00

3.3 KiB

Workflow

One issue per unit of work, and one branch and one PR per issue:

  • make sure a tracked issue exists with a definition of done
  • branch from next, never from main
  • do the work, then open a PR with base next, never main
  • pass an independent review; the manager then squash-merges into next
  • push; nothing stays local-only

next is the branch for the next milestone. It must stay green and mergeable into main at all times. One PR from next into main accumulates the milestone. Releases are cut from main separately.

The tracker (https://git.eeqj.de/sneak/webhooker/issues) records 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. Only @sneak tags it.

Delivery is at least once by design. A send whose result row does not land is sent again, so a receiver can see a duplicate. The alternative is a silent lost delivery. The README says so under How it works. 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. next is kept mergeable at all times; that is the point of the branch.

Future Steps

  • Per-webhook rate limits, set in the web UI and enforced in the receiver. Today RECEIVER_RATE_LIMIT sets one limit for every entrypoint on the server.
  • API key authentication for programmatic access. The APIKey table exists, but nothing creates a key and nothing checks one.
  • REST API v1. /api/v1 is mounted with no routes today.
    • CRUD for webhooks, entrypoints and targets
    • event viewing and filtering endpoints
    • event redelivery endpoint
    • OpenAPI specification
  • Analytics in the web UI: response times summarised per webhook or per target, and figures for all webhooks together. Today the webhook page shows event, delivery and failure counts and failure percentages. The target list counts each target's deliveries. The event log shows every attempt's duration. /metrics carries server-wide counts and delivery durations.
  • A remember-me option at login. Today every session survives a browser restart. It lasts up to 7 days, and ends sooner after SESSION_IDLE_TIMEOUT (default 24 hours) without use.
  • Password reset over the web for a forgotten password. Today a signed-in user can change their password, and a lost password is reset from the console with webhooker resetpw (#208).
  • Later, nice to have
    • email delivery target type
    • SNS and S3 delivery targets
    • data transformations, such as a configurable Slack message format; the Slack target sends one fixed format today
    • JSONL file delivery with periodic S3 upload. Today the database target 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 pending views
    • multi-user with role-based access control. Today each webhook belongs to one account, but only the account made at first boot exists and there is no way to add another.