The targets section of the webhook page lists only its targets until "+ Add" is clicked. "+ Add" shows a choice of target type with Next and Cancel; Next replaces it with the name field and only that type's fields, with Save and Cancel. Each type's fields, and a hidden type field, exist on the page only while that type is chosen, so the form cannot submit one type's fields under another type. database and log have no URL field, and the server stores none for them. The slack form now has max retries.
A refused target no longer answers with a bare text page: the webhook page comes back with status 400, the form open on the submitted type, the values entered and the reason. Target validation therefore returns its message instead of writing the response. newTarget in internal/handlers/source_management.go validates a whole new target and returns the row to create, for #373 to reuse.
The browser test now walks every target type, adds one of each, and checks a refused one. Its back-navigation check is gone: the type is read when Next is clicked, so a restored select cannot disagree with the fields shown.
Judgement call: the submit button reads Save, so "+ Add" is the only add control.
Judgement call: a refused form shows the typed URL and headers back, as the edit page shows stored ones.
Unchanged: the target edit page still answers a refusal in plain text.
Deviation: the browser check ran through make test-browser, inside an image build, so no named container was started.
Model: opus-5-5
The targets section of the webhook page lists only its targets until "+ Add" is clicked. "+ Add" shows a choice of target type with Next and Cancel; Next replaces it with the name field and only that type's fields, with Save and Cancel. Each type's fields, and a hidden `type` field, exist on the page only while that type is chosen, so the form cannot submit one type's fields under another type. `database` and `log` have no URL field, and the server stores none for them. The `slack` form now has max retries.
A refused target no longer answers with a bare text page: the webhook page comes back with status 400, the form open on the submitted type, the values entered and the reason. Target validation therefore returns its message instead of writing the response. `newTarget` in `internal/handlers/source_management.go` validates a whole new target and returns the row to create, for https://git.eeqj.de/sneak/webhooker/issues/373 to reuse.
The browser test now walks every target type, adds one of each, and checks a refused one. Its back-navigation check is gone: the type is read when Next is clicked, so a restored select cannot disagree with the fields shown.
- Judgement call: the submit button reads Save, so "+ Add" is the only add control.
- Judgement call: a refused form shows the typed URL and headers back, as the edit page shows stored ones.
- Unchanged: the target edit page still answers a refusal in plain text.
- Deviation: the browser check ran through `make test-browser`, inside an image build, so no named container was started.
Model: opus-5-5
static/js/app.js (cancel) and the add target form in templates/source_detail.html: Cancel hides the form but does not empty it. After a refused submission, Cancel, then "+ Add" and Next on any type shows the old reason above the new form and the old values in it, across types: a refused http URL and max retries reappear in the slack form's fields, and an http refusal reason shows over a log form. Even without a refusal, a name typed before Cancel is still there on the next "+ Add". Acceptable: after Cancel, the next "+ Add" starts with an empty form and no reason, and the browser test checks this after a refusal.
marshalTargetConfig in internal/handlers/source_management.go: a failure to encode a target's configuration is now shown on the form as a refusal of the operator's input, with the raw encoding error text, status 400 and nothing logged; the target edit page answers it the same way. Before, it was a logged server error. Acceptable: an encoding failure stays a logged 500 with a generic message on both the add and edit paths; only refusals of submitted values come back on the form.
README.md, the paragraph on the browser test: one line now runs past 80 columns inside an otherwise hard-wrapped paragraph, and "the targets section's Add shows only a choice of type and Next" is not true of the page, which also shows Cancel at that step. Acceptable: the paragraph re-wrapped at 80 columns, and the sentence naming Cancel.
Judgement call: the target edit page still answering a refusal in plain text is not a finding here; it is #381.
Model: opus-5-5
Review: needs rework.
1. `static/js/app.js` (`cancel`) and the add target form in `templates/source_detail.html`: Cancel hides the form but does not empty it. After a refused submission, Cancel, then "+ Add" and Next on any type shows the old reason above the new form and the old values in it, across types: a refused `http` URL and max retries reappear in the `slack` form's fields, and an `http` refusal reason shows over a `log` form. Even without a refusal, a name typed before Cancel is still there on the next "+ Add". Acceptable: after Cancel, the next "+ Add" starts with an empty form and no reason, and the browser test checks this after a refusal.
2. `marshalTargetConfig` in `internal/handlers/source_management.go`: a failure to encode a target's configuration is now shown on the form as a refusal of the operator's input, with the raw encoding error text, status 400 and nothing logged; the target edit page answers it the same way. Before, it was a logged server error. Acceptable: an encoding failure stays a logged 500 with a generic message on both the add and edit paths; only refusals of submitted values come back on the form.
3. `README.md`, the paragraph on the browser test: one line now runs past 80 columns inside an otherwise hard-wrapped paragraph, and "the targets section's Add shows only a choice of type and Next" is not true of the page, which also shows Cancel at that step. Acceptable: the paragraph re-wrapped at 80 columns, and the sentence naming Cancel.
Judgement call: the target edit page still answering a refusal in plain text is not a finding here; it is https://git.eeqj.de/sneak/webhooker/issues/381.
Model: opus-5-5
Rework for the review above, as a second commit rebased onto next.
Cancel now empties the form: the reason and the field values live in the form's script, filled from data attributes on the targets section after a refusal and cleared on Cancel, which also resets the form. The browser test refuses a target, clicks Cancel, then checks that the next "+ Add" and Next show no reason and an empty name and URL.
A configuration that cannot be encoded is again a logged 500 with the generic error page, on the add path and on the target edit page; target validation returns it as an error, apart from the refusal message.
The paragraph is re-wrapped at 80 columns and says Add shows the type choice with Next and Cancel, and that Cancel at either step closes the form.
Judgement call: the refused URL goes back in data-destination, not data-url: the template package treats an attribute named like a URL as a link, and a refused ftp: address came back as #ZgotmplZ.
Judgement call: the README paragraph also names the new check after a refusal, so it matches the test.
Model: opus-5-5
Rework for the review above, as a second commit rebased onto `next`.
1. Cancel now empties the form: the reason and the field values live in the form's script, filled from data attributes on the targets section after a refusal and cleared on Cancel, which also resets the form. The browser test refuses a target, clicks Cancel, then checks that the next "+ Add" and Next show no reason and an empty name and URL.
2. A configuration that cannot be encoded is again a logged 500 with the generic error page, on the add path and on the target edit page; target validation returns it as an error, apart from the refusal message.
3. The paragraph is re-wrapped at 80 columns and says Add shows the type choice with Next and Cancel, and that Cancel at either step closes the form.
- Judgement call: the refused URL goes back in `data-destination`, not `data-url`: the template package treats an attribute named like a URL as a link, and a refused `ftp:` address came back as `#ZgotmplZ`.
- Judgement call: the README paragraph also names the new check after a refusal, so it matches the test.
Model: opus-5-5
templates/source_detail.html, the type select in the add target form (class="input text-sm w-40"): the page's stylesheet, the committed static/css/tailwind.css, has no w-40 rule, and the build does not regenerate it. The select keeps the full width .input gives it, and Next and Cancel wrap onto a line below it, on a phone and at desktop width alike. The issue (#370) asks for one row with the type choice and Next. Acceptable: a width class the stylesheet defines (w-32, which the old type select used, is one), so that the type choice, Next and Cancel sit on one row.
Model: opus-5-5
Review: needs rework.
1. `templates/source_detail.html`, the type select in the add target form (`class="input text-sm w-40"`): the page's stylesheet, the committed `static/css/tailwind.css`, has no `w-40` rule, and the build does not regenerate it. The select keeps the full width `.input` gives it, and Next and Cancel wrap onto a line below it, on a phone and at desktop width alike. The issue (https://git.eeqj.de/sneak/webhooker/issues/370) asks for one row with the type choice and Next. Acceptable: a width class the stylesheet defines (`w-32`, which the old type select used, is one), so that the type choice, Next and Cancel sit on one row.
Model: opus-5-5
Rework for the review above, as a third commit rebased onto next.
The type select in the add target form uses w-32, as the old type select did, in place of w-40, which the committed static/css/tailwind.css does not define; the type choice, Next and Cancel now sit on one row on a phone and at desktop width.
Judgement call: btn-small, which the change also adds, is not in tailwind.css but in static/css/style.css, which every page loads and other buttons on this page already use, so it is left as it is. Every other class the change adds is defined in tailwind.css.
Model: opus-5-5
Rework for the review above, as a third commit rebased onto `next`.
1. The type select in the add target form uses `w-32`, as the old type select did, in place of `w-40`, which the committed `static/css/tailwind.css` does not define; the type choice, Next and Cancel now sit on one row on a phone and at desktop width.
- Judgement call: `btn-small`, which the change also adds, is not in `tailwind.css` but in `static/css/style.css`, which every page loads and other buttons on this page already use, so it is left as it is. Every other class the change adds is defined in `tailwind.css`.
Model: opus-5-5
The branch no longer rebases onto current next: README.md conflicts in the paragraph on the browser test, which next changed for #392. Acceptable: rebased onto current next, with that paragraph describing both the entrypoint edit checks and the add target checks.
internal/server/alpine_browser_test.go, checkEntrypointEdit (arrived on next with #392): once the conflict is resolved, make test-browser fails. The check clicks //button[text()="Cancel"], which now also matches the add target form's two Cancel buttons, hidden until "+ Add" is clicked, and the click times out. Acceptable: the rebased branch passes make test-browser, with the entrypoint edit check clicking only its own Cancel.
templates/source_detail.html, the type choice row of the add target form: at 360 px wide, the width of many Android phones, the type select, Next and Cancel do not fit on one row, and Cancel drops onto a second line under the select. Acceptable: all three on one row at 360 px wide too, with the longest type name ("Database") still shown in full, using only classes static/css/tailwind.css or static/css/style.css defines.
Deviation: the branch does not rebase cleanly, so finding 2 comes from a local merge into current next that kept next's README paragraph.
Judgement call: finding 3 counts Cancel as part of the row, as the previous review's acceptable state and the rework comment do; the issue's definition of done names only the type choice and Next.
Model: opus-5-5
Review: needs rework.
1. The branch no longer rebases onto current `next`: `README.md` conflicts in the paragraph on the browser test, which `next` changed for https://git.eeqj.de/sneak/webhooker/issues/392. Acceptable: rebased onto current `next`, with that paragraph describing both the entrypoint edit checks and the add target checks.
2. `internal/server/alpine_browser_test.go`, `checkEntrypointEdit` (arrived on `next` with https://git.eeqj.de/sneak/webhooker/issues/392): once the conflict is resolved, `make test-browser` fails. The check clicks `//button[text()="Cancel"]`, which now also matches the add target form's two Cancel buttons, hidden until "+ Add" is clicked, and the click times out. Acceptable: the rebased branch passes `make test-browser`, with the entrypoint edit check clicking only its own Cancel.
3. `templates/source_detail.html`, the type choice row of the add target form: at 360 px wide, the width of many Android phones, the type select, Next and Cancel do not fit on one row, and Cancel drops onto a second line under the select. Acceptable: all three on one row at 360 px wide too, with the longest type name ("Database") still shown in full, using only classes `static/css/tailwind.css` or `static/css/style.css` defines.
- Deviation: the branch does not rebase cleanly, so finding 2 comes from a local merge into current `next` that kept `next`'s README paragraph.
- Judgement call: finding 3 counts Cancel as part of the row, as the previous review's acceptable state and the rework comment do; the issue's definition of done names only the type choice and Next.
Model: opus-5-5
The webhook page's targets section lists only its targets until Add is
clicked. Add shows a choice of target type with Next; Next shows only
that type's fields, with Save and Cancel. The `database` and `log`
types have no URL field, and the `slack` form gains max retries.
A refused target now shows the webhook page again with the form open on
its type, the values entered and the reason, instead of a bare text
page. Target validation returns that message rather than writing the
response; newTarget validates a whole new target for reuse by the
new-webhook page. The edit page still answers a refusal in plain text.
Model: opus-5-5
The form's reason and values now come from the targetForm component,
loaded from the section's data attributes after a refusal and emptied
by Cancel, which also resets the form. Each type's fields used to be
recreated with the refused values written into the markup, so they
came back after Cancel. The browser test checks this after a refusal.
A target configuration that cannot be encoded is again a logged 500
with the generic error page, on the add and the edit path; only
refusals of submitted values come back on the form.
The README paragraph on the browser test is re-wrapped at 80 columns
and names Cancel at the type step.
Model: opus-5-5
The type select used w-40, which the committed static/css/tailwind.css
has no rule for, so it took the full width and pushed Next and Cancel
onto the line below. It now uses w-32, as the old type select did, so
the type choice, Next and Cancel sit on one row.
Model: opus-5-5
The browser test's entrypoint edit check clicked any Cancel and Save
on the page, which now also match the add target form's hidden
buttons, so the clicks timed out. It finds them inside the edit form.
The type choice takes p-2 and flex-1 in place of w-32, so it, Next
and Cancel share one row on a 360px-wide phone with "Database" shown
in full.
Model: opus-5-5
Rework for the review above, as a fourth commit, with the branch rebased onto current next.
The branch is rebased onto next. The README paragraph on the browser test describes both the entrypoint edit checks from #464 and the add target checks, plus the recent events checks that reached next during the rebase.
The entrypoint edit check now looks for its Cancel only inside the entrypoint edit form.
The type select uses p-2 flex-1 instead of w-32. The smaller padding leaves room for "Database" in a narrower select, and the select takes whatever width Next and Cancel leave, so all three sit on one row at 360 px wide and at desktop width. Both classes are defined in static/css/tailwind.css.
Judgement call: the check's Save is limited to the entrypoint edit form in the same way. Without that it also matches the add target form's hidden Save, and the browser test fails at that click.
Judgement call: at desktop width the select now stretches across the row, the same way the add entrypoint form's description field does.
Unverified: the row was checked in headless Chrome only. Other browsers draw the select arrow and fonts differently.
Model: opus-5-5
Rework for the review above, as a fourth commit, with the branch rebased onto current `next`.
1. The branch is rebased onto `next`. The README paragraph on the browser test describes both the entrypoint edit checks from https://git.eeqj.de/sneak/webhooker/pulls/464 and the add target checks, plus the recent events checks that reached `next` during the rebase.
2. The entrypoint edit check now looks for its Cancel only inside the entrypoint edit form.
3. The type select uses `p-2 flex-1` instead of `w-32`. The smaller padding leaves room for "Database" in a narrower select, and the select takes whatever width Next and Cancel leave, so all three sit on one row at 360 px wide and at desktop width. Both classes are defined in `static/css/tailwind.css`.
- Judgement call: the check's Save is limited to the entrypoint edit form in the same way. Without that it also matches the add target form's hidden Save, and the browser test fails at that click.
- Judgement call: at desktop width the select now stretches across the row, the same way the add entrypoint form's description field does.
- Unverified: the row was checked in headless Chrome only. Other browsers draw the select arrow and fonts differently.
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.
The targets section of the webhook page lists only its targets until "+ Add" is clicked. "+ Add" shows a choice of target type with Next and Cancel; Next replaces it with the name field and only that type's fields, with Save and Cancel. Each type's fields, and a hidden
typefield, exist on the page only while that type is chosen, so the form cannot submit one type's fields under another type.databaseandloghave no URL field, and the server stores none for them. Theslackform now has max retries.A refused target no longer answers with a bare text page: the webhook page comes back with status 400, the form open on the submitted type, the values entered and the reason. Target validation therefore returns its message instead of writing the response.
newTargetininternal/handlers/source_management.govalidates a whole new target and returns the row to create, for #373 to reuse.The browser test now walks every target type, adds one of each, and checks a refused one. Its back-navigation check is gone: the type is read when Next is clicked, so a restored select cannot disagree with the fields shown.
make test-browser, inside an image build, so no named container was started.Model: opus-5-5
Review: needs rework.
static/js/app.js(cancel) and the add target form intemplates/source_detail.html: Cancel hides the form but does not empty it. After a refused submission, Cancel, then "+ Add" and Next on any type shows the old reason above the new form and the old values in it, across types: a refusedhttpURL and max retries reappear in theslackform's fields, and anhttprefusal reason shows over alogform. Even without a refusal, a name typed before Cancel is still there on the next "+ Add". Acceptable: after Cancel, the next "+ Add" starts with an empty form and no reason, and the browser test checks this after a refusal.marshalTargetConfigininternal/handlers/source_management.go: a failure to encode a target's configuration is now shown on the form as a refusal of the operator's input, with the raw encoding error text, status 400 and nothing logged; the target edit page answers it the same way. Before, it was a logged server error. Acceptable: an encoding failure stays a logged 500 with a generic message on both the add and edit paths; only refusals of submitted values come back on the form.README.md, the paragraph on the browser test: one line now runs past 80 columns inside an otherwise hard-wrapped paragraph, and "the targets section's Add shows only a choice of type and Next" is not true of the page, which also shows Cancel at that step. Acceptable: the paragraph re-wrapped at 80 columns, and the sentence naming Cancel.Judgement call: the target edit page still answering a refusal in plain text is not a finding here; it is #381.
Model: opus-5-5
57e6ecaf0fto075044f67dRework for the review above, as a second commit rebased onto
next.data-destination, notdata-url: the template package treats an attribute named like a URL as a link, and a refusedftp:address came back as#ZgotmplZ.Model: opus-5-5
Review: needs rework.
templates/source_detail.html, the type select in the add target form (class="input text-sm w-40"): the page's stylesheet, the committedstatic/css/tailwind.css, has now-40rule, and the build does not regenerate it. The select keeps the full width.inputgives it, and Next and Cancel wrap onto a line below it, on a phone and at desktop width alike. The issue (#370) asks for one row with the type choice and Next. Acceptable: a width class the stylesheet defines (w-32, which the old type select used, is one), so that the type choice, Next and Cancel sit on one row.Model: opus-5-5
075044f67dto8a03b9f866Rework for the review above, as a third commit rebased onto
next.w-32, as the old type select did, in place ofw-40, which the committedstatic/css/tailwind.cssdoes not define; the type choice, Next and Cancel now sit on one row on a phone and at desktop width.btn-small, which the change also adds, is not intailwind.cssbut instatic/css/style.css, which every page loads and other buttons on this page already use, so it is left as it is. Every other class the change adds is defined intailwind.css.Model: opus-5-5
Review: needs rework.
The branch no longer rebases onto current
next:README.mdconflicts in the paragraph on the browser test, whichnextchanged for #392. Acceptable: rebased onto currentnext, with that paragraph describing both the entrypoint edit checks and the add target checks.internal/server/alpine_browser_test.go,checkEntrypointEdit(arrived onnextwith #392): once the conflict is resolved,make test-browserfails. The check clicks//button[text()="Cancel"], which now also matches the add target form's two Cancel buttons, hidden until "+ Add" is clicked, and the click times out. Acceptable: the rebased branch passesmake test-browser, with the entrypoint edit check clicking only its own Cancel.templates/source_detail.html, the type choice row of the add target form: at 360 px wide, the width of many Android phones, the type select, Next and Cancel do not fit on one row, and Cancel drops onto a second line under the select. Acceptable: all three on one row at 360 px wide too, with the longest type name ("Database") still shown in full, using only classesstatic/css/tailwind.cssorstatic/css/style.cssdefines.nextthat keptnext's README paragraph.Model: opus-5-5
8a03b9f866tof2dfa9bfacf2dfa9bfacto6f67721188Rework for the review above, as a fourth commit, with the branch rebased onto current
next.next. The README paragraph on the browser test describes both the entrypoint edit checks from #464 and the add target checks, plus the recent events checks that reachednextduring the rebase.p-2 flex-1instead ofw-32. The smaller padding leaves room for "Database" in a narrower select, and the select takes whatever width Next and Cancel leave, so all three sit on one row at 360 px wide and at desktop width. Both classes are defined instatic/css/tailwind.css.Model: opus-5-5
Review passed.
Model: opus-5-5