README: add "v1 release requirements" checklist (verified done vs not) and a Backlog section #286
Labels
No labels
actions
bug
cli
duplicate
enhancement
fork
forum
git storage
help wanted
insights
invalid
issues
moderation
oidc
ownership transfer
packages
pr/merge protection rules
projects
pull requests
question
releases
sponsorships
tags
webhooks
wiki
wontfix
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
crueber/walhub#286
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What's requested
Add a "v1 release requirements" section to the README: the base-level foundations of a GitHub alternative as a checklist — checked boxes for what is 100% done today, unchecked for what isn't. Plus a Backlog section listing the explicitly post-v1 items.
The list (as specified)
v1 requirements:
Backlog: projects, wiki, insights, moderation, sponsorships, forum, ownership transfer, pr/merge protection rules
Where the checks go (evidence from the tree — the implementer verifies each before committing the box)
Present as
internal/packages with HTTP surfaces today (candidates for checked):internal/store,internal/wal,internal/git: smart HTTP v0/v2, LFS, bundle-uri — the core of the project, done.internal/issues: threads, comments, labels, milestones, assignees, reactions, attachments.internal/pulls+internal/review: CRUD, merge, review threads/anchors.internal/tagsexists; verify create-from-UI (#253 territory) before checking.internal/releases: CRUD, assets, autodraft, latest.internal/notify: webhook bridge/event fan-out; verify management UI/endpoint completeness.cmd/walhubsubcommands (import --urletc.); verify coverage breadth before checking.internal/server/auth.go(authOIDC, :172): any OpenID Connect issuer, pluswgt_access tokens; README auth section already documents it. Verify end-to-end login flow through/setupbefore checking.Likely unchecked (no package or surface found):
The README already has a "What's in the box" table (README.md:71-81) — the new section goes after it, before "Development". Keep each checkbox item to the single word from the list above (no essays); link the word to the relevant
internal/package or docs page where one exists.Backlog placement: a short
## Backlogsection after v1 requirements, one comma-separated line or an unchecked-list — either reads fine; prefer a plain list so items don't look like tracked work.Acceptance criteria
PR #303 (#303) implements this — branch fix/issue-286, docs-only README change. Verification notes for the boxes are in the PR description; the two checked items (git storage, oidc) were spot-verified against origin/main@051c206, everything else left unchecked with reasons recorded there.
Review: PR #303 (fix/issue-286) — README v1 checklist + Backlog
Verified in scratch worktree at
origin/fix/issue-286(detached HEAD306f6a4). Main worktree untouched. No browser drive (reasoning: README-markdown-only change, no browser-facing code; per brief).Scope — PASS
git diff main...origin/fix/issue-286 --stat→README.md | 25 ++++...(1 file, +25). No code touched.## What's in the box(README.md:71-81), before## Development(README.md:108). Markdown eyeballed (README.md:83-106), renders sane.Checked items — both TRUE (spot-verified)
[x] git storage → internal/store: smart-HTTPinfo/refs+ upload/receive-pack routes live (internal/server/smart.go:91, router tests), LFS + bundle-uri (internal/bundle/) present.[x] oidc → internal/server:authOIDCatinternal/server/auth.go:172, JWKS/discovery (auth_oidc.go), browser flow with full-flow tests (x_auth_test.go:285).Links/backlog — PASS
internal/{store,issues,pulls,tags,releases,social,notify,server},cmd/walhub.packagescorrectly unlinked (no surface anywhere).actions→ absolute.../issues/288, and #288 is genuinely the open runner-research issue.BLOCKER —
[ ] webhookslooks falsely modestThe unchecked webhooks box contradicts the tree. End-to-end surface exists on every layer, all in the scratch worktree:
internal/notify/http.go:241-296— GET/POST/PATCH/DELETE/ping/deliveries, admin-gated).internal/notify/webhooks.go:399 DeliverRepo,:481 deliverHook), driven by the drain loop (internal/notify/tasks.go:397), SSRF-guarded (webhooks_ssrf_test.go), fan-out-bounded.web/src/pages/Settings.jsx:913-1026, nav entryweb/src/lib/settingsNav.js:20).web/sdk/src/notifications.js:81+) + API docs (web/src/pages/Apidocs.jsx:99-102).Per #286's own acceptance rule ("every checked item has a working end-to-end surface… when in doubt leave unchecked") and this review's brief (a present webhooks UI must not be marked not-done), please do one of:
- [x] [webhooks](internal/notify)after confirming one live delivery (push → hook POST visible via the deliveries tab), noting the verification in the PR; or[ ]but name the concrete gap in the PR body (what specific piece is missing that keeps it below the v1 bar?).The other unchecked boxes are defensible as-is and match #286's specified list:
forkis only a counter (internal/social/service.go:354 IncForks, no creation flow),tagshas no UI page,packageshas no surface,actionsawaits #288, andissues/pulls/releases/clicompleteness against the v1 bar is genuinely judgment-call territory where "when in doubt, unchecked" applies.Verdict
Blocked: resolve the webhooks checkbox (option 1 or 2 above). Everything else is ready; no other changes needed. I did not push anything to
origin/fix/issue-286.Webhooks checkbox resolved (review option 1): flipped to [x] in
749fa05on fix/issue-286 (PR #303).Proof — live end-to-end delivery, re-run just now in scratch worktree: TestWebhookDeliveryEndToEnd + TestWebhookPing PASS, full internal/notify package green (go test -count=1). The sink (webhooks_test.go newSink) is a real httptest HTTP server verifying per POST: Content-Type, X-Walgit-Delivery (sha256 body+seq), X-Walgit-Event, and X-Walgit-Signature HMAC-SHA256. Path: CreateHook -> EmitIssue(commented) -> DeliverRepo -> exactly 1 POST with valid HMAC, cursor=1, deliveries ring 200/commented; second pass no redelivery. PingHook goes through the same postEvent wire path the Settings Ping button hits.
Precision note: v1 webhooks fire on collab activity events (commented/opened/.../ping), not git pushes, by design (webhooks.go header: delivered from the collab activity log, NOT the WAL bridge). So the proof is collab-event -> POST with valid HMAC, the actual v1 contract.
Layers confirmed present: API CRUD+ping+deliveries (notify/http.go), DeliverRepo via StartWebhooks drain loop (notify/tasks.go), Settings Webhooks tab (Settings.jsx WebhooksTab: list/create/remove/ping/deliveries), SDK repo.webhooks (sdk/src/notifications.js).
No browser drive (README one-line change, UI code untouched, verified by reading). Main worktree untouched.
Re-review of delta
749fa05(webhooks checkbox [ ] -> [x]): VERIFIED. Proof tests exist and pass in scratch worktree: TestWebhookDeliveryEndToEnd + TestWebhookPing PASS (go test ./internal/notify/ -run 'TestWebhookDeliveryEndToEnd|TestWebhookPing' -count=1). Sink (webhooks_test.go newSink) asserts keeper headers X-Walgit-Delivery/X-Walgit-Event, delivery key hex(sha256(body+seq)), HMAC-SHA256 signature, secret write-only, cursor advance + no-redelivery + deliveries log. File list clean: branch vs main touches README.md only (25 insertions; delta commit itself is the 1-line flip). Precision note: proof covers collab-activity delivery (issue commented event via DeliverRepo scanning collab-events/) — not git-push delivery. Checkbox claim 'webhooks (internal/notify)' matches that scope. No browser per instructions. Recommendation: ready to merge.Fixed by PR #303 incl. webhooks live-proof flip (review verified; all green), merged. Closing.