Record the reopened 1.0.0 milestone in TODO.md #213

Merged
clawbot merged 1 commits from mgr-todo-milestone-reopened into next 2026-08-20 05:58:03 +02:00

35
TODO.md
View File

@@ -24,10 +24,23 @@ event retention (#63), the database archiving target (#43), the admin
password change flow (#65), policy compliance (#6), pinned lint tooling password change flow (#65), policy compliance (#6), pinned lint tooling
(#55), and fail-loud configuration parsing (#80). (#55), and fail-loud configuration parsing (#80).
`next` holds the **complete 1.0.0 milestone**: every issue in it is `next` is green — verified both by CI and by cache-defeated container
closed, and it is verified green both by CI and by cache-defeated runs (`docker build --no-cache-filter=lint --no-cache-filter=builder`) —
container runs (`docker build --no-cache-filter=lint but the **1.0.0 milestone is no longer complete**. It was reopened on
--no-cache-filter=builder`). 2026-08-20 by a code-level deployability audit that ran the service end
to end (verdict:
https://git.eeqj.de/sneak/webhooker/issues/33#issuecomment-66686).
The bar for 1.0 is not "the milestone is empty" but "sneak can deploy
this and use it in low-volume production". The audit found the gap
between those two: two instances on one `DATA_DIR` both deliver
(reproduced), a failed listen leaves a live non-serving process that
restart policies never fire on, there is no inbound authentication of
any kind, delivery failures render as a bare word with no status code or
error, a terminally failed delivery can never be replayed, the SSRF
blocklist has no escape hatch so the proxy cannot forward to your own
network at all, and target credentials leak into the per-webhook event
databases.
One caveat on reading a green check, narrower than it used to be. A One caveat on reading a green check, narrower than it used to be. A
docs-only commit deliberately replays from the layer cache (#119), so a docs-only commit deliberately replays from the layer cache (#119), so a
@@ -44,8 +57,13 @@ of 2026-07-06.
# Next Step # Next Step
Merge the milestone PR (#111) to `main` and tag 1.0.0 from it. The Clear the reopened 1.0.0 milestone. The milestone PR
milestone is empty and `next` is green; nothing else blocks the tag. (https://git.eeqj.de/sneak/webhooker/pulls/111) is held: it carries a
`WIP: ` prefix, no labels and is assigned to `clawbot`, and it stays
that way until the milestone is empty. Correctness first — the
duplicate-delivery lock and the listen-failure shutdown — then the
operability gaps that make the service usable in production, then the
three credential exposures.
Three items belong to the owner, none of them blocking. #150 was decided Three items belong to the owner, none of them blocking. #150 was decided
by the manager rather than left to stall the queue and is flagged on the by the manager rather than left to stall the queue and is flagged on the
@@ -59,8 +77,9 @@ bug the 20-60s band requires, and should be milestoned instead if the
cap is read as covering the whole invocation. cap is read as covering the whole invocation.
After the tag, the largest open cluster is the unmilestoned follow-up After the tag, the largest open cluster is the unmilestoned follow-up
backlog these units generated: #183, #184, #185, #190, #191, #193 and backlog these units generated: #183, #184, #185, #190, #191, #193, #198,
#198. #211 and #212 (encrypting target config at rest, split out of the
credential-leak fix because it needs a key-rotation and re-wrap story).
# Completed Steps # Completed Steps