clawbot
c474b8f881
check / check (push) Waiting to run
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
64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
# 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 from `main`)
|
|
- do the work; open a PR based on `next` (never on `main`)
|
|
- 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
|
|
|
|
The 1.0.0 milestone (https://git.eeqj.de/sneak/webhooker/milestone/9) has no
|
|
open issues, and `v1.0.0` is not tagged. Only @sneak cuts that tag.
|
|
|
|
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
|
|
|
|
- Delivery status and retry management UI. Replay of a terminally failed
|
|
delivery and per-attempt detail already landed
|
|
(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
|
|
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`
|
|
(https://git.eeqj.de/sneak/webhooker/issues/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
|