Repository navigation
chore: remove dead barchart_v8 component - #107
Closed
elviskahoro wants to merge 1 commit into
Closed
elviskahoro wants to merge 1 commit into
elviskahoro wants to merge 1 commit into
Conversation
Co-authored-by: detail-app[bot] <180357370+detail-app[bot]@users.noreply.github.com>
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
**Detail bug report:** [View on Detail](https://app.detail.dev/org_d38a878f-9df9-4c4b-a96a-f5180b860085/bugs/bug_8185aa14-ba60-48d5-86c5-db23c1465112) Closes #91 ## Bug `demo_wrapper` in `app/www/wrapper.py` wraps every live component demo on the docs site. Its preview container was styled with `!p-2 !sm:p-6` — 8px on mobile, 24px from the `sm` breakpoint up. But `!sm:p-6` puts Tailwind's `!` important marker *before* the `sm:` variant, which is invalid in both v3 and v4: the compiler silently drops it and emits no CSS rule at all. With no `@media (width >= 40rem)` padding rule, the `!p-2` (8px, important) declaration was the highest-priority padding at every viewport, so all demos rendered with 8px padding on tablet/desktop instead of the intended 24px — a 3x reduction in breathing room, site-wide (every demo routes through `demo_wrapper`). Introduced in `755f3ed` (v0.9.1), which lowered the mobile base from `p-6` to `!p-2` and added the malformed `!sm:p-6` to restore 24px at `sm`. Every other important+variant usage in the repo uses the valid `variant:!…` ordering (e.g. `md:!hidden`, `md:!block`), so this was a typo. ## Fix Reorder the important marker to the valid form (one token swap in `app/www/wrapper.py`): ```diff -class_name="w-full min-h-[250px] flex items-center justify-center !p-2 !sm:p-6 my-10", +class_name="w-full min-h-[250px] flex items-center justify-center !p-2 sm:!p-6 my-10", ``` `sm:!p-6` compiles to `.sm\:\!p-6 { @media (width >= 40rem) { padding: calc(var(--spacing) * 6) !important } }`, which overrides `!p-2` at `≥ 40rem` and leaves 8px in place below `sm` — exactly the v0.9.1 author's intent. Added two regression tests in `tests/test_wrapper.py`: one pins the exact preview `class_name`, the other scans the module for any `!<variant>:` token (the malformed shape) so the same typo can't recur silently. ## Testing - **Unit tests, typecheck, lint, and format all pass.** New `tests/test_wrapper.py` (2 tests); full suite `826 passed` (824 pre-existing + 2 new). `pyright` reports 0 errors; `ruff format`/`ruff check` clean. - **Bug reproduction against the project's pinned Tailwind v4.3.0**: compiled the old class list `!p-2 !sm:p-6 md:!hidden` with `@tailwindcss/cli@4.3.0` (the version pinned in `reflex.lock/package.json`). Output emitted `.\!p-2` and `.md\:\!hidden` but **no** `.\!sm\:p-6` selector — confirming the malformed token produces zero CSS. Repeating with the fixed class list `!p-2 sm:!p-6 md:!hidden` emits the missing `.sm\:\!p-6` rule with body `@media (width >= 40rem) { padding: calc(var(--spacing) * 6) !important }`. - **No compensating CSS**: `assets/globals.css` and `assets/prism/prism.css` contain only `prefers-reduced-motion` and `print` media blocks — neither sets padding at a width breakpoint, so the cascade conclusion is mechanical, not a runtime assumption. - **End-to-end computed-style check** against a running `reflex run` dev server using Playwright + headless Chromium: on `/docs/components/button`, at viewport 375px the preview `<div>` computed padding is `8px` on all sides; at 800px it is `24px` on all sides. The rendered `className` carries `sm:!p-6` and no `!sm:p-6`. Cross-checked on `/docs/components/popover` with identical results. Inspecting the browser-served CSS bundle confirmed `.sm\:\!p-6` is present and `.!sm\:p-6` is absent. - **Genealogy**: `git log -S "!sm:p-6"` returns only `755f3ed`; the prior version (`7d27209`) used plain `p-6`, confirming the override intent. `grep -rn '!sm:' app/www/ components/` returns no matches after the fix. --- _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.
Removes the dead
v8bar-chart example component fromapp/www/library/charts/bar/v8.py. Nothing links to or renders it — pure deletion, no behavior change.Part of a series of independent cleanup PRs — each one is self-contained and can be reviewed/merged in any order.