# 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