Repository navigation
fix: remove duplicate social link input ID - #112
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
**Detail bug report:** [View on Detail](https://app.detail.dev/org_d38a878f-9df9-4c4b-a96a-f5180b860085/bugs/bug_013fac0e-28f3-4e5e-b280-3ea368953801) ## Bug `kbd.root(..., class_name="custom-kbd", unstyled=True)` and `kbd.group(..., class_name="custom-grp", unstyled=True)` silently dropped **both** the default Tailwind classes and the caller's own `class_name`, emitting `className: ""`. Root cause: in `components/ui/kbd.py`, `KbdRoot.create` / `KbdGroupContainer.create` pre-popped `class_name` from `props` and folded it into the default via `cn(...)` *before* calling `set_class_name`. `set_class_name`'s `unstyled` branch (`core.py:37-39`) discards the default and preserves only `props["class_name"]` — which `kbd` had already popped — so the caller's class was lost as `""`. The bug only surfaced under `unstyled=True` + `class_name` (default and `class_name`-only usage both worked), which is why it went undetected. Closes #97 ## Fix `KbdRoot.create` and `KbdGroupContainer.create` now pass the raw default (`ClassNames.KBD` / `ClassNames.GROUP`) to `set_class_name` and let it own the merge, leaving the caller's `class_name` in `props` for the `unstyled` branch to preserve. The now-unused `cn` import was removed. `data-slot` plumbing and the `unstyled` exclusion (`_exclude_props`) are unchanged. This mirrors the contract used by ~40 sibling `CoreComponent`s — e.g. `ContextMenuShortcut` (`context_menu.py:343-348`), whose `unstyled`-keeps-`class_name` behavior is pinned by `tests/test_context_menu.py`. `kbd` was the only `set_class_name` caller that pre-popped `class_name`; this brings it back in line. ## Testing - **New unit tests:** Added `tests/test_kbd.py` (8 tests, mirroring `tests/test_context_menu.py`): default classes, custom merge, `unstyled` omits default, and `unstyled` keeps custom — for both `kbd.root` and `kbd.group`. All 8 pass; the two `*_unstyled_keeps_custom_class_name` tests pin the previously-broken behavior. - **Routine checks:** Full suite passes (832 tests — 824 baseline + 8 new, no regressions); `pyright` reports 0 errors on the test file; `ruff format`/`ruff check` are clean on both changed files; the sibling `test_context_menu_shortcut_unstyled_keeps_custom_class_name` still passes; the generated-assets gate `tests/test_generated_assets.py` passes (457 tests) on a clean tree. - **End-to-end verification:** Confirmed directly that `kbd.root('K', class_name='custom-kbd', unstyled=True)` now yields `'custom-kbd'` (was `''`), and `kbd.group` yields `'custom-grp'`; default-only and custom-only paths still render the expected default + custom classes. Via the `tests/test_input.py` capture pattern (monkeypatching the base `create`), confirmed `unstyled` is excluded from the props handed to the base component and `data-slot` is set to `kbd` / `kbd-group` for both default and `unstyled` constructions. - **Docs idempotency:** Re-ran `scripts/generate_markdown.py`; `docs/components/kbd.md` and `assets/docs/components/kbd.md` are unchanged by this fix (`unstyled` is inherited and undocumented, so it isn't in the API table). - **Anatomy CI gate (`scripts/generate_anatomy.py --check`):** Reports "OUT OF DATE" both with the fix applied and on the clean baseline (verified by stashing the fix), so the failure is pre-existing — committed anatomy assets are stale relative to HEAD — and unrelated to this change, a Python class-name merge fix that touches no component anatomy. Not resolvable within the scope of this bug. --- _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.
Every social-link input in
card_tenrendered with the same hardcodedid="inline-start-input", producing duplicate DOM IDs on the landing page.Removes the hardcoded ID so each input gets a unique generated one.