Repository navigation
fix: preserve terminal icon while copying block commands - #114
Merged
LineIndent merged 1 commit intoOct 21, 2026
Merged
Conversation
elviskahoro
added a commit
that referenced
this pull request
Oct 25, 2026
<!-- entire-trail-link-start --> https://entire.io/gh/elviskahoro/buridan-ui/trails/5 <!-- entire-trail-link-end --> ## What `pullfrog-approval` (Pullfrog's AI review verdict) is now a **required check in both enforcement layers**: - **GitHub side** — ruleset `main - PR requirements` plus classic branch protection on `main`, both pinned to the Pullfrog app (id 1768019). `enforce_admins` and the strict up-to-date policy are unchanged. This blocks direct merges and gates **Trunk merge queue admission** (the queue only admits PRs GitHub considers mergeable). - **Trunk queue side** — added to `.trunk/trunk.yaml` `merge.required_statuses`, so the queue also waits for a **fresh Pullfrog verdict on the exact merge state it tests**, not just the PR head at admission. ## Why it is safe to require during queue testing The queue tests in **draft-PR mode**: trunk-io opens a draft PR from the `trunk-merge/**` branch, and Pullfrog auto-reviews draft PRs (`review.drafts` on; the trunk-io app is not in Pullfrog's bot-exclusion list, which covers Dependabot/Renovate/Greenkeeper/Snyk/`github-actions[bot]`/changesets). So `pullfrog-approval` posts on the tested head and the queue requirement is satisfiable. The comment in `trunk.yaml` and the paragraph in `AGENTS.md` document the load-bearing assumptions: if a queue entry ever stalls on a missing `pullfrog-approval`, check (1) the queue is still in draft-PR mode, (2) Pullfrog is still reviewing queue draft PRs, (3) the Pullfrog run itself didn't fail or get cancelled — a failed run posts no check. ## Effects to know - New PRs: Pullfrog auto-reviews on open and re-reviews on push, so the check lands on every head automatically. Unresolved Pullfrog feedback fails the check and blocks the merge — that is the point. - Queue submissions: the queue now waits for Pullfrog's verdict on the tested merge state before landing, adding one LLM review (typically a few minutes, PR-size dependent) per queue test. - Existing open PRs whose heads were last reviewed before the approval-check toggle was enabled (e.g. #119, #118, #114, #113, #112, #108, #107) show `pullfrog-approval` as *Expected — waiting for status*. Unblock with a one-off `@pullfrog review` comment or a new push. - If a Pullfrog run fails or is cancelled, no check posts on that head and the merge/queue stays blocked until the next run reports (documented Pullfrog behavior). - A negative verdict on the tested merge state fails the check and ejects the PR from the queue — address the feedback, push to the original PR, and resubmit; the new submission opens a new draft PR, which gets a fresh verdict. No human override exists short of editing the config. ## Verification - The GitHub-side gate is verified live on this PR: #126 sat `BLOCKED` with all CI green while Pullfrog's review was running, cleared once `pullfrog-approval: SUCCESS` posted, and blocked again on the new merge-commit head until re-review — exactly the intended per-commit gate. PR #125 also merged (13:56Z, after the rule went live) with `pullfrog-approval: SUCCESS` among its checks. - The queue-side requirement is verified by this PR's own queue run: the queue reads `required_statuses` from `main`'s trunk.yaml, so #126 is tested under the old three-check list while Pullfrog independently auto-reviews the queue's draft PR. During Testing, `gh pr checks <draft-pr>` will show whether `pullfrog-approval` posts on the `trunk-merge/**` head. If it does not, the queue entry is cancelled before landing and the `required_statuses` addition is reverted; if it does, that evidence is the confirmation the new config is safe for future submissions.
elviskahoro
added a commit
that referenced
this pull request
Oct 25, 2026
…#114) **Detail bug report:** [View on Detail](https://app.detail.dev/org_d38a878f-9df9-4c4b-a96a-f5180b860085/bugs/bug_128133ca-cbba-4727-8096-f3f816d5b394) ## Bug The `TooltipRoot.track_cursor_axis` prop in `components/ui/tooltip.py` exposes Base UI's `trackCursorAxis`, whose contract is `'none' | 'x' | 'y' | 'both'`. The Python alias was misdefined as `Literal["none", "bottom", "x", "y"]` — the side value `"bottom"` (borrowed from the adjacent `LiteralSide`) leaked into the axis type, and the valid `"both"` axis was dropped. This caused two failures: - `track_cursor_axis="both"` (the Base UI-documented way to follow the cursor on both axes) raised `TypeError` from Reflex's runtime literal validator, making the behavior unreachable. - `track_cursor_axis="bottom"` was accepted and silently forwarded to floating-ui's `useClientPoint`, where `isXAxis`/`isYAxis` both evaluate `false`, so cursor tracking did nothing without any error. Closes #99 ## Fix Replaced the stray `"bottom"` with the missing `"both"` so the alias matches Base UI's union: ```python LiteralTrackCursorAxis = Literal["none", "x", "y", "both"] ``` Applied to: - `components/ui/tooltip.py` — the wrapper the app imports (the durable fix). - `assets/docs/components/tooltip.md` — the generated docs mirror, so the `git diff --exit-code assets/docs` CI guard stays green. This is the idiomatic fix because `"bottom"` is a *side* (a value of `LiteralSide` one line above), never an axis, and `"both"` is the only value missing from the upstream contract. ## Testing - A focused regression test (`test_track_cursor_axis_accepts_both_and_rejects_bottom`) pins the Base UI contract: the accepted `Literal` set equals `{"none", "x", "y", "both"}`, `"both"` renders `trackCursorAxis:"both"` to the client, and `"bottom"` raises `TypeError`. - Unit tests (full suite), pyright typecheck, and ruff lint/format all pass clean. - Verified end-to-end by running the full Reflex app (`reflex run`): the `/docs/components/tooltip` page served HTTP 200, a headless-browser smoke test confirmed tooltip triggers render and a popup opens on hover, and the serialized `render()` dict forwards `trackCursorAxis:"both"` — the exact payload sent to the React client. - Confirmed the unrelated `side` prop still correctly accepts `"bottom"` (a legitimate side value), so the fix has no collateral impact. --- _Automatic Fixes PRs can be [configured here](https://app.detail.dev/org_d38a878f-9df9-4c4b-a96a-f5180b860085/settings/repos/repo_04b9d58c-daa0-46b6-9560-7f39569ec6eb/bugs)._ Co-authored-by: detail-app[bot] <180357370+detail-app[bot]@users.noreply.github.com> Co-authored-by: elvis kahoro <github@elvis.ai>
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
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.
The block-command copy button swapped the entire button's
innerTextto "Copied!", which wiped out the TerminalIcon SVG until the timeout restored the text.Wraps the command text in a dedicated span and only swaps that span's text, so the icon stays visible throughout the copy feedback.