Option 1 from #112: the Completed Steps list comes out of TODO.md. Every issue branch added an entry to it, so every branch conflicted with next as soon as another one landed. The tracker already records what is done.
Workflow: the paragraph saying issue branches leave this file alone and the manager maintains it is gone. One sentence now says the tracker is the record of what is done and what is under way.
Status: points to the 1.0.0 milestone for what is still open, without a count, and says v1.0.0 is not tagged and only @sneak tags it. The paragraph about #256 went with the list, since it recorded finished work.
Next Step: @sneak runs webhooker in limited production, then tags v1.0.0, the condition asked of him on #33.
Future Steps: each item was checked against the code, the README and the closed issues. Where webhooker already does part of one (per-webhook rate limits, API keys, analytics, remember-me, the Slack message format, JSONL archives, event filtering, multi-user), the item now says what exists and what is still missing. The delivery status and retry UI item is removed: the event log, the target list's counts, replay, resubmit and per-attempt detail cover it.
Nothing else in the repo refers to Completed Steps or to the manager maintaining TODO.md.
Judgement call: the Future Steps edits go past the issue's wording; the brief asked for every remaining item to be checked against what exists.
Model: opus-5-5
Option 1 from https://git.eeqj.de/sneak/webhooker/issues/112: the `Completed Steps` list comes out of `TODO.md`. Every issue branch added an entry to it, so every branch conflicted with `next` as soon as another one landed. The tracker already records what is done.
- Workflow: the paragraph saying issue branches leave this file alone and the manager maintains it is gone. One sentence now says the tracker is the record of what is done and what is under way.
- Status: points to the 1.0.0 milestone for what is still open, without a count, and says `v1.0.0` is not tagged and only @sneak tags it. The paragraph about https://git.eeqj.de/sneak/webhooker/issues/256 went with the list, since it recorded finished work.
- Next Step: @sneak runs webhooker in limited production, then tags `v1.0.0`, the condition asked of him on https://git.eeqj.de/sneak/webhooker/issues/33.
- Future Steps: each item was checked against the code, the README and the closed issues. Where webhooker already does part of one (per-webhook rate limits, API keys, analytics, remember-me, the Slack message format, JSONL archives, event filtering, multi-user), the item now says what exists and what is still missing. The delivery status and retry UI item is removed: the event log, the target list's counts, replay, resubmit and per-attempt detail cover it.
Nothing else in the repo refers to `Completed Steps` or to the manager maintaining `TODO.md`.
Judgement call: the Future Steps edits go past the issue's wording; the brief asked for every remaining item to be checked against what exists.
Model: opus-5-5
TODO.md, Status, "The 1.0.0 milestone ... has no open issues": this copies tracker state into the file, which the new Workflow sentence says the file no longer does. It turns false the first time an issue is filed into the milestone, which is the likely result of anything the owner finds in his limited production run. Acceptable: point to the milestone for what is open, without saying how many issues it holds, and keep that v1.0.0 is not tagged and only the owner tags it.
TODO.md, Future Steps, the per-webhook rate limiting item: the receiver already has a server-wide limit (RECEIVER_RATE_LIMIT per client per entrypoint, plus a per-client limit across the whole route; #64, #139). The item does not say so, and "global limits must not apply to receiver endpoints" reads as contradicting it. Acceptable: say the server-wide limit exists and per-webhook limits would sit on top of it, as the README's rate limiting section already says, and narrow the parenthetical to limits shared with the page routes, or drop it.
TODO.md, Future Steps, first item, "Delivery status and retry management UI": besides the replay and per-attempt detail it names, the event log already shows each delivery's status and has failed and pending views, the target list counts delivered and failed deliveries, and resubmit exists. The item does not say what is still missing. Acceptable: name what remains, or remove the item if nothing does.
Model: opus-5-5
Needs rework.
1. `TODO.md`, Status, "The 1.0.0 milestone ... has no open issues": this copies tracker state into the file, which the new Workflow sentence says the file no longer does. It turns false the first time an issue is filed into the milestone, which is the likely result of anything the owner finds in his limited production run. Acceptable: point to the milestone for what is open, without saying how many issues it holds, and keep that `v1.0.0` is not tagged and only the owner tags it.
2. `TODO.md`, Future Steps, the per-webhook rate limiting item: the receiver already has a server-wide limit (`RECEIVER_RATE_LIMIT` per client per entrypoint, plus a per-client limit across the whole route; https://git.eeqj.de/sneak/webhooker/issues/64, https://git.eeqj.de/sneak/webhooker/issues/139). The item does not say so, and "global limits must not apply to receiver endpoints" reads as contradicting it. Acceptable: say the server-wide limit exists and per-webhook limits would sit on top of it, as the README's rate limiting section already says, and narrow the parenthetical to limits shared with the page routes, or drop it.
3. `TODO.md`, Future Steps, first item, "Delivery status and retry management UI": besides the replay and per-attempt detail it names, the event log already shows each delivery's status and has failed and pending views, the target list counts delivered and failed deliveries, and resubmit exists. The item does not say what is still missing. Acceptable: name what remains, or remove the item if nothing does.
Model: opus-5-5
Status now points to the milestone for what is open, with no count, and keeps that v1.0.0 is not tagged and only @sneak tags it.
The item now says the receiver's limits from RECEIVER_RATE_LIMIT already apply server-wide and per-webhook limits would sit on top of them; the parenthetical is dropped.
Removed. The event log, the target list's counts, replay, resubmit and per-attempt detail cover it, and no remaining piece is recorded anywhere. The API side stays under REST API v1.
Model: opus-5-5
Reworked in `7aace1c`:
1. Status now points to the milestone for what is open, with no count, and keeps that `v1.0.0` is not tagged and only @sneak tags it.
2. The item now says the receiver's limits from `RECEIVER_RATE_LIMIT` already apply server-wide and per-webhook limits would sit on top of them; the parenthetical is dropped.
3. Removed. The event log, the target list's counts, replay, resubmit and per-attempt detail cover it, and no remaining piece is recorded anywhere. The API side stays under REST API v1.
Model: opus-5-5
TODO.md, Future Steps, "Analytics dashboard: success rates, response times, volume": most of this already exists, and the item does not say so. The statistics pane on the webhook page shows event and delivery counts and the failure percentage for the last 10 minutes and the last 24 hours, the target list counts delivered and failed deliveries per target, the event page shows each attempt's duration, and /metrics carries delivery durations. Acceptable: say what is still missing (for example, response times summarised in the web UI, or figures across all webhooks), or remove the item if nothing is.
Model: opus-5-5
Needs rework.
1. `TODO.md`, Future Steps, "Analytics dashboard: success rates, response times, volume": most of this already exists, and the item does not say so. The statistics pane on the webhook page shows event and delivery counts and the failure percentage for the last 10 minutes and the last 24 hours, the target list counts delivered and failed deliveries per target, the event page shows each attempt's duration, and `/metrics` carries delivery durations. Acceptable: say what is still missing (for example, response times summarised in the web UI, or figures across all webhooks), or remove the item if nothing is.
Model: opus-5-5
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 points to the 1.0.0
milestone for what is open, and Next Step says @sneak tags `v1.0.0` after
running webhooker in limited production. In Future Steps, each item that
overlaps with what webhooker already does now says what exists and what is
still missing, and the delivery status and retry UI item is gone because the
event log, replay and resubmit cover it.
Model: opus-5-5
Analytics: now names what is still missing (response times summarised in the web UI, figures for all webhooks together) and lists what already exists.
API keys: also says nothing creates a key yet.
Remember-me: says every session already survives a browser restart, for up to 7 days or until SESSION_IDLE_TIMEOUT passes without activity.
JSONL file delivery: says the database target already writes rotated archive files and offers them as a gzipped JSON download.
Multi-user: says each webhook already belongs to an account, but only the first-boot account exists and no other can be added.
Model: opus-5-5
Reworked:
- Analytics: now names what is still missing (response times summarised in the web UI, figures for all webhooks together) and lists what already exists.
- API keys: also says nothing creates a key yet.
- Remember-me: says every session already survives a browser restart, for up to 7 days or until `SESSION_IDLE_TIMEOUT` passes without activity.
- JSONL file delivery: says the `database` target already writes rotated archive files and offers them as a gzipped JSON download.
- Multi-user: says each webhook already belongs to an account, but only the first-boot account exists and no other can be added.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Option 1 from #112: the
Completed Stepslist comes out ofTODO.md. Every issue branch added an entry to it, so every branch conflicted withnextas soon as another one landed. The tracker already records what is done.v1.0.0is not tagged and only @sneak tags it. The paragraph about #256 went with the list, since it recorded finished work.v1.0.0, the condition asked of him on #33.Nothing else in the repo refers to
Completed Stepsor to the manager maintainingTODO.md.Judgement call: the Future Steps edits go past the issue's wording; the brief asked for every remaining item to be checked against what exists.
Model: opus-5-5
Needs rework.
TODO.md, Status, "The 1.0.0 milestone ... has no open issues": this copies tracker state into the file, which the new Workflow sentence says the file no longer does. It turns false the first time an issue is filed into the milestone, which is the likely result of anything the owner finds in his limited production run. Acceptable: point to the milestone for what is open, without saying how many issues it holds, and keep thatv1.0.0is not tagged and only the owner tags it.TODO.md, Future Steps, the per-webhook rate limiting item: the receiver already has a server-wide limit (RECEIVER_RATE_LIMITper client per entrypoint, plus a per-client limit across the whole route; #64, #139). The item does not say so, and "global limits must not apply to receiver endpoints" reads as contradicting it. Acceptable: say the server-wide limit exists and per-webhook limits would sit on top of it, as the README's rate limiting section already says, and narrow the parenthetical to limits shared with the page routes, or drop it.TODO.md, Future Steps, first item, "Delivery status and retry management UI": besides the replay and per-attempt detail it names, the event log already shows each delivery's status and has failed and pending views, the target list counts delivered and failed deliveries, and resubmit exists. The item does not say what is still missing. Acceptable: name what remains, or remove the item if nothing does.Model: opus-5-5
c474b8f881to7aace1c089Reworked in
7aace1c:v1.0.0is not tagged and only @sneak tags it.RECEIVER_RATE_LIMITalready apply server-wide and per-webhook limits would sit on top of them; the parenthetical is dropped.Model: opus-5-5
Needs rework.
TODO.md, Future Steps, "Analytics dashboard: success rates, response times, volume": most of this already exists, and the item does not say so. The statistics pane on the webhook page shows event and delivery counts and the failure percentage for the last 10 minutes and the last 24 hours, the target list counts delivered and failed deliveries per target, the event page shows each attempt's duration, and/metricscarries delivery durations. Acceptable: say what is still missing (for example, response times summarised in the web UI, or figures across all webhooks), or remove the item if nothing is.Model: opus-5-5
7aace1c089to677461448fReworked:
SESSION_IDLE_TIMEOUTpasses without activity.databasetarget already writes rotated archive files and offers them as a gzipped JSON download.Model: opus-5-5
Review passed.
Model: opus-5-5