fix(cli): top-align scaffold action rows; Delete no longer floats 4px high - #3609
Merged
Merged
Conversation
… high
`buttonTo` renders a <form>, so in the flex row the form is the flex item and
the visible button sits one level down. simple.css gives that nested button
`margin-bottom: 8px`, which the existing `.wheels-actions > *` reset could not
reach (it stops at the form). The form was therefore 8px taller than the
sibling <a> links, and `align-items: center` floated its button up by half
the difference — measured at exactly 4px (top 295.9 vs 299.9).
Two changes, each sufficient on its own, both kept:
- `.wheels-actions > form > .button { margin-bottom: 0 }` equalises height.
- `align-items: flex-start` top-justifies, so a future height difference
cannot re-centre the row.
Measured after: all three actions at top 295.9 / bottom 338.3.
CLI suite: 1357 pass, the 4 pre-existing DbCommandSpec failures, 0 errors.
Signed-off-by: Peter Amiri <peter@alurium.com>
bpamiri
added a commit
that referenced
this pull request
Sep 13, 2026
* ci: pin Homebrew/actions/setup-homebrew to a tag Homebrew/actions renamed its default branch from master to main. Both docs workflows referenced @master, so every PR opened after the rename fails at "Set up job" with: Unable to resolve action `homebrew/actions@master`, unable to find version `master` The same job passed 18 hours earlier on PR #3609 with an unchanged workflow — nothing in the repo moved; upstream did. Pinned to the 2026.09.07.1 tag rather than swapping @master for @main: a branch reference is exactly what just broke, and upstream tags weekly. setup-homebrew/action.yml is byte-identical (1421 bytes) at that tag and at today's 2026.09.13.1. Found while landing #3611, whose only red check was this job. Signed-off-by: Peter Amiri <peter@alurium.com> * ci: grant tap trust before tapping Second half of the docs-verify breakage. After pinning the action, the job ran and failed inside `brew tap`: Invalid formula (golden_gate): .../Formula/wheels-be.rb Refusing to load formula wheels-dev/wheels/wheels-be from untrusted tap. Run `brew trust wheels-dev/wheels` to trust it. Homebrew now validates every formula in a tap WHILE cloning it, and on Linuxbrew refuses untrusted ones at that moment. docs-verify already had `brew trust wheels-dev/wheels` — one line AFTER the tap, so it ran too late; docs-validation had no trust at all. Both now trust first. The earlier run proved `brew trust` accepts a not-yet-installed tap (it printed "Trusted tap" after the failed clone). The "Invalid formula" wording is a consequence of the refusal, not a separate syntax problem; the tap's own macOS CI audits and installs the same formula green. Signed-off-by: Peter Amiri <peter@alurium.com> --------- Signed-off-by: Peter Amiri <peter@alurium.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.
The Delete button in a scaffolded action row sat a few pixels above Edit and ← all posts. Cause confirmed by measurement, not guessed.
Why
buttonTorenders a<form>, so in the flex row the form is the flex item and the visible button sits one level down. simple.css gives that nested buttonmargin-bottom: 8px, which the existing.wheels-actions > *reset could not reach — it stops at the form. So the form was 8px taller than the sibling<a>links, andalign-items: centerfloated its button up by half the difference.<a>)<form>→<button>)<a>)Exactly 4px.
Fix
Two changes, each sufficient alone, both kept:
.wheels-actions > form > .button { margin-bottom: 0 }— equalises heightalign-items: flex-start— top-justifies, so a future height difference can't re-centre the rowAfter: all three at top 295.9 / bottom 338.3.
CLI suite: 1357 pass, the 4 pre-existing
DbCommandSpecfailures, 0 errors.