Skip to content

fix: restore smooth Collapsible panel height animation - #113

Merged
LineIndent merged 1 commit into
LineIndent:mainfrom
elviskahoro:fix/collapsible-height-animation
Oct 21, 2026
Merged

LineIndent merged 1 commit into
LineIndent:mainfrom
elviskahoro:fix/collapsible-height-animation

Conversation

@elviskahoro

Copy link
Copy Markdown
Collaborator

Collapsible panels snap open and closed because the height state selectors (data-[ending-style]:h-0, data-[starting-style]:h-0) had no transition applied to height.

Adds transition-[height] duration-200 ease-out to the panel class, matching the Accordion timing so both components animate consistently. Updates both the component and its doc example.

Collapsible panels snap open and closed because the height state selectors have no transition. Match Accordion timing so both interactions animate consistently.
@LineIndent
LineIndent merged commit 8243916 into LineIndent:main Oct 21, 2026
1 check passed
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants