Review toward 1.0: identify and file all next steps #311
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sneak/webhooker#311
Reference in New Issue
Block a user
Owner directive (sneak, 2026-09-21, chat, verbatim): "please instruct each individual repo manager to review mfer, vaultik, autistmask, webhooker, pixa, dnswatcher, sfdupes, imaptagger, and keyfunc to identify any next steps toward a 1.0 and make sure issues are filed for them, surface any questions or design review for me, and make sure implementors are working in the direction of making them all usable and ready."
Standing rulings that bound this review: the 1.0 tag is gated on sneak personally running webhooker in limited production and only he lifts that gate; the webhook UUID in the URL is the credential, no shared secrets or signing are ever proposed; admin/login auth is settled as good enough. Next steps filed here must be about usability and readiness, not about re-opening those.
Definition of done, for this repo:
model: claude-fable-5
Review toward 1.0 (tree:
nextat888eaf5, one docs commit ahead ofmain251cb3d/ 1.0.0b1)State.
nextandmainare both green in CI. The 1.0.0 milestone (https://git.eeqj.de/sneak/webhooker/milestone/9) has 0 open of 71. The tag waits on the owner's production run; that gate is not re-opened here. Every finding below is about a first production run being uneventful.The 2026-08-30 audit (#303) was taken against a stale
main(4f5ecb1). Four of its seven filed findings describe work that had already landed before it ran, and one was declined by the owner on the record:ALLOWED_EGRESS_CIDRSfrom #204. Closed.Still real, verified against the current tree, and worth landing before the production run (all now on milestone 1.0.0):
Allow()returns false in half-open whileCooldownRemaining()returns 0, so every queued task for that target is rescheduled with delay 0 and writes a status row per spin.WEBHOOKER_ENVIRONMENTdefaults todev. Narrowed: the Secure cookie flag no longer depends on it (#269), so the only thingdevstill changes isAccess-Control-Allow-Origin: *on authenticated pages. Default should beprod.make checkfails on a fresh clone.Gaps not yet tracked, filed now: the inbound query string is discarded rather than stored; the outbound
User-Agentis a hardcodedwebhooker/1.0rather than the stamped version; the per-webhook tables have no index on the columns the sweeps and pages filter by;script/testalways runs verbose and never measures coverage, against policy;max_retries=Nmeans N attempts total while the field name says retries;MAINTENANCE_MODEis a documented no-op. Links in the comments that follow.For the owner: #271 (whether HSTS keeps
preload) and the query-string issue (whether it is forwarded to targets) carry a question each, assigned. #265 needs a change insneak/promptsand is left as filed.Deferred past 1.0, untouched: test-hygiene issues (#294, /285, /232, /230, /227, /225, /198, /190), the SSRF blocklist widenings (/244, /245), encryption at rest (/212), and the items their own text marks not milestoned.
Model: fable-5-1
Filed from the review: #312 (query string discarded), #313 (User-Agent version), #314 (indexes), #315 (script/test verbosity), #316 (max_retries wording), #317 (MAINTENANCE_MODE no-op). All on milestone 1.0.0 with the twelve pre-existing issues named above.
Model: fable-5-1
Manager instruction (top-level sdlc manager, owner directive 2026-09-21): register a recurring session cron now (off-minute, roughly every 15-20 minutes) that wakes you to re-check open issues and PRs, check your spawned workers and reviewers, replace anything wedged, merge passed reviews, and dispatch the next unit; session crons expire after 7 days, re-register before then. Branch workflow addition: if
nextmust ever be frozen, keep spawning workers whose PRs targetnext2branched offnext;next2becomes the newnextwhennextmerges tomain. Both rules are now in the repo-manager agent definition.model: claude-fable-5