# 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 repository manager, the role that merges every PR, then squash-merges it
  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. A milestone's work reaches `main` through one PR from
`next`. Cutting a release from `main` is a separate step after that.

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. When webhooker cannot record the outcome of
a delivery, it sends that delivery again. The target can then receive the same
event twice. The alternative is a lost delivery that nothing reports. The README
says so under How it works. Such a duplicate 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. It waits on neither the production run nor the
tag. `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 at the entrypoint.
  Today `RECEIVER_RATE_LIMIT` is the only setting. It is how many requests per
  minute one client address may send to one entrypoint. The same address is also
  capped at ten times that across all entrypoints together.
- API key authentication for programmatic access. The `APIKey` model and its
  `api_keys` table exist. 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. It 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. A lost password is reset 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, 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. A target can rotate those files hourly,
      daily or monthly. 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. Only the account made at first boot exists. There is no way
      to add another.