Land the work from #11 and #12, which merged into their base branches - #14
Merged
Conversation
Found by watching the agent answer with it. Asked what needed attention in a project with four open issues, it said "1 page of open issues detected" and then guessed at what that might mean. The tool listed events and issues with `limit=1` and returned the length of each page, so `failed_events_page_count` and `open_issues_page_count` could only ever be 0 or 1. The names were honest and the numbers were useless: the agent's primary status tool could not report how much of anything there was. Issues have a dedicated count endpoint, so open issues are now counted exactly. Events do not, so failures are counted over a page of 100 with `failed_events_is_at_least` saying when that page was full — a floor the model can report as a floor, rather than a ceiling it will report as a total. Same question now answers "Open issues: 4". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes #9. `dist/index.js` ships in the wheel and had no tests of any kind. It was also invisible in the 86% figure, which is Python only — so the number read better than the coverage was. Takes the issue's preferred option. The bundle gets React, its hooks, its components and its fetch from the injected SDK, so faking that SDK and running the file under `node:vm` exercises the shipped bytes with no package.json, no lockfile and no second ecosystem. `createElement` returns plain objects rather than rendering: every question here is about the tree and the requests, and none of them need a DOM. Node's own test runner runs it, so CI adds a job and nothing else. 15 tests, each one mutation-checked. Inverting the pause/resume expression, inverting only its label, dropping `disabled: busy`, removing the SDK guard, changing the retry endpoint and typo'ing the registered name all now fail. Two of them failed to catch their mutation on the first pass, and both were the test's fault rather than the code's: * the SDK-guard test could not express "this host has no SDK", because the harness always built a complete one and merged the caller's over it. It was asserting that a valid host loads. * the busy-on-failure test asserted no button was left disabled, and passed because a failed action swaps the whole page for the error card — which has no disabled buttons at all. It would have passed against anything. The second is worth recording: the issue expected `setBusy(false)` in `act()`'s catch to be what stops the panel wedging. It is not. The error card replaces the page and its Retry has no `disabled` binding, so the way back is open whatever `busy` holds. The test now asserts the recovery that actually exists. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both PRs show as merged. Neither reached
main.fix/dashboard-copyfix/queue-status-countsSame failure as #6: a stacked PR keeps its original base, so merging it puts the work on the branch below rather than on
main. GitHub retargets when the base PR merges, but not if you merge the stack quickly or out of order — and the PR still goes green and says Merged, which is what makes it easy to miss.Verified rather than assumed:
#10's dashboard copy did land (via its own merge to
main), so this cherry-picks only the two commits that did not:c66ef7bandf0617c9, clean onto currentmain.303 Python tests, 15 dashboard tests, ruff clean.
Once this is in,
fix/dashboard-copy,fix/queue-status-countsandtests/dashboard-bundlehold nothing unique and can be deleted.hookdeck/tools.pyandhookdeck/api.pyship, so this restores a patch-release-worthy change that was silently absent frommain— worth noting before the next release, since v0.1.2 does not contain it either.