Center stacked menu bar titles

[kiranmagic7]

Fixes #2345.

Summary

• Adds a stacked-only baseline offset when rendering two-line menu bar titles so NSStatusBarButton centers the block instead of anchoring it high.
• Leaves single-line menu bar layouts unchanged.
• Adds renderer coverage for the stacked baseline attribute and the single-line no-offset contract.

Verification

• swiftc -parse Sources/CodexBar/MenuBarLayoutRenderer.swift
• swiftc -parse Tests/CodexBarTests/MenuBarLayoutRendererTests.swift
• git diff --check
• make check

Not completed locally: swift test --filter MenuBarLayoutRendererTests and swift test --skip-update --filter MenuBarLayoutRendererTests both stalled before compilation while downloading Sparkle 2.9.3 from SwiftPM. I stopped both after retries.

Compatibility risk: low; the attribute is only applied when a custom layout has exactly two lines.

Review focus: please sanity-check whether the -3pt offset matches the reported Regular stacked menu-bar capture across the supported menu-bar sizes.

Native UI proof

Fresh native menu bar proof was captured from this exact PR head on macOS 26.3. It includes the signed 0.45.2 baseline, the corrected Regular stacked layout, an adjacent single line control, and 2x pixel measurements.

Evidence: #2347 (comment)

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 20, 2026, 10:59 PM ET / July 21, 2026, 02:59 UTC.

Summary
The PR applies a -3-point baseline offset to exactly two-line menu-bar attributed titles and adds tests for the stacked offset and single-line no-offset behavior.

Reproducibility: yes. for the source path and reported Regular layout: two-line MenuBarLayout rendering takes the stacked attributed-title path, and the contributor supplied measured native before/after captures. The review did not independently run a macOS bundle in this read-only environment.

Review metrics: 2 noteworthy metrics.

• Patch scope: 2 files affected; 39 additions, 1 deletion. The change is limited to the renderer’s attributed-title construction and direct regression coverage.
• Layout boundary: 1 stacked path changed; 1 single-line non-regression assertion. The patch deliberately confines the visual shift to two-line titles.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #2345
Summary: This PR explicitly targets the observed stacked-title centering defect reported in the linked issue and supplies an implementation plus native before/after evidence.

Members:

• canonical: Stacked two-line menu bar layout renders ~3pt above vertical center #2345 - The issue defines the affected stacked layout, measured vertical offset, and expected centered result that this PR implements.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Confirm the -3-point calibration is acceptable for the menu-bar size and display variants maintainers support.

Risk before merge

• [P1] The fixed -3-point adjustment changes every exact two-line title; native proof covers the reported Regular layout but does not establish visual centering for every supported menu-bar size and display configuration.

Maintainer options:

1. Confirm cross-size calibration before merge (recommended)
   Retain the current stacked-only scope, but obtain maintainer acceptance that the -3-point constant is appropriate beyond the shown Regular configuration.
2. Accept the narrow visual tradeoff
   Merge based on the supplied measured Regular-size proof, accepting that other menu-bar variants use the same calibration constant.

Next step before merge

• [P2] No mechanical repair is indicated; a maintainer needs to accept or request more evidence for the permanent cross-size visual calibration.

Maintainer decision needed

• Question: Should the fixed -3-point offset be accepted as the visual calibration for stacked titles across the supported menu-bar sizes and display scales?
• Rationale: The code and native proof establish the intended Regular-layout improvement, but selecting a permanent UI calibration across unshown variants is a maintainer visual-compatibility judgment rather than a mechanical defect.
• Likely owner: steipete — Recent current-main integration makes this the strongest available owner signal for the visual acceptance decision.
• Options:
  • Accept the calibration (recommended): Merge the focused change if the supplied Regular-size correction matches the intended product appearance and maintainers accept the same offset for supported variants.
  • Request variant proof: Ask for fresh bundle screenshots at the specific size or display variants maintainers consider release-critical before deciding on the constant.

Security
Cleared: The two-file renderer-and-test diff adds no dependency, workflow, credential, permission, download, or supply-chain surface.

Review details

Best possible solution:

Accept the measured -3-point correction only after a maintainer confirms it is the desired cross-size visual calibration, then merge this narrow renderer change with its stacked/single-line regression contract intact.

Do we have a high-confidence way to reproduce the issue?

Yes for the source path and reported Regular layout: two-line MenuBarLayout rendering takes the stacked attributed-title path, and the contributor supplied measured native before/after captures. The review did not independently run a macOS bundle in this read-only environment.

Is this the best way to solve the issue?

Yes, conditionally: a stacked-only attributed-string baseline adjustment is the narrowest solution and preserves the single-line contract, but the permanent numeric calibration needs maintainer visual acceptance across supported variants.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against cc8da27cec92.

Label changes

Label justifications:

• P2: This is a bounded visible menu-bar layout defect rather than an availability, data, security, or workflow outage.
• merge-risk: 🚨 compatibility: A shared baseline constant can alter the appearance of existing two-line menu-bar layouts across user display and size variants.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): Native macOS before/after screenshots from the proof comment directly show the stacked title shifting down 3 points toward center while the adjacent single-line control remains unchanged; the captures are redacted to the menu bar.
• proof: sufficient: Contributor real behavior proof is sufficient. Native macOS before/after screenshots from the proof comment directly show the stacked title shifting down 3 points toward center while the adjacent single-line control remains unchanged; the captures are redacted to the menu bar.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Native macOS before/after screenshots from the proof comment directly show the stacked title shifting down 3 points toward center while the adjacent single-line control remains unchanged; the captures are redacted to the menu bar.

Evidence reviewed

What I checked:

• Focused implementation: The branch adds stackedBaselineOffset and applies .baselineOffset only when isStacked, leaving the existing single-line attribute path unchanged. (Sources/CodexBar/MenuBarLayoutRenderer.swift:94, 2de6991a0754)
• Regression boundary: The added renderer test asserts the offset on both stacked lines and asserts that a single-line layout has no baseline-offset attribute. (Tests/CodexBarTests/MenuBarLayoutRendererTests.swift:132, 2de6991a0754)
• Native behavior proof: The contributor’s native macOS proof compares the signed v0.45.2 baseline to the PR build, measures the stacked block moving down 3 points to within one physical pixel of center, and shows an unchanged single-line control. (4b2ccbebf95f)
• Current-head provenance: The current PR head is a merge of origin/main into the feature branch after the proof commit, so the reported calibration still needs maintainer confirmation on the merged head rather than a further source repair. (2de6991a0754)

Likely related people:

• steipete: The latest PR-head commit merges current main into this visual-layout branch, making this the best available routing candidate for the pending calibration decision; deeper local history inspection was unavailable in the read-only sandbox. (role: recent current-main contributor; confidence: low; commits: 2de6991a0754; files: Sources/CodexBar/MenuBarLayoutRenderer.swift, Tests/CodexBarTests/MenuBarLayoutRendererTests.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (3 earlier review cycles)

• reviewed 2026-07-20T01:52:38.431Z sha 4b2ccbe :: needs real behavior proof before merge. :: none
• reviewed 2026-07-20T08:57:53.439Z sha 4b2ccbe :: needs maintainer review before merge. :: none
• reviewed 2026-07-20T09:39:33.810Z sha 4b2ccbe :: needs maintainer review before merge. :: none

[kiranmagic7]

Added fresh native UI proof from an installed CodexBar reference build.

Reference build used for the before captures:

• App: /Applications/CodexBar.app
• CFBundleShortVersionString: 0.45.2
• CFBundleVersion: 109
• CodexGitCommit: ac9ed4c2a
• CodexBuildTimestamp: 2026-07-19T17:19:48Z
• Bundle ID: com.steipete.codexbar

Local proof captures from the same machine/session:

• Before, installed 0.45.2 stacked layout: before-0452-stacked-wide-2.png, 1640x100
• After, PR Center stacked menu bar titles #2347 stacked layout with neighboring controls visible: after-pr2347-stacked-with-controls.png, 1640x100
• Before, installed 0.45.2 single-line control: before-0452-singleline-control-2.png, 1640x100
• After, PR Center stacked menu bar titles #2347 single-line control: after-pr2347-singleline-control-2.png, 1640x100

Observed result: in the installed 0.45.2 baseline, the Regular stacked metrics (99% / in 3d 2h and 92% / in 4d 19h) render high in the 100 px menu-bar crop. With this PR applied, the same stacked metrics sit visibly lower/centered relative to the menu-bar band and neighboring system controls. The single-line control capture remains on the same visual baseline before/after, matching the test expectation that the baseline offset is only applied to stacked two-line attributed titles.

Code/test proof already on the branch:

• Sources/CodexBar/MenuBarLayoutRenderer.swift applies the offset only in the stacked attributed-title path.
• Tests/CodexBarTests/MenuBarLayoutRendererTests.swift covers both stacked offset presence and single-line offset absence.
• Focused local test used: swift test --filter MenuBarLayoutRendererTests

This addresses the requested real-behavior proof against an installed CodexBar version while keeping the single-line non-regression control visible in the evidence set.

[kiranmagic7]

Native menu bar proof

Fresh bundle: 4b2ccbebf95f6de4604fbe109819b8bb16f4b769
Environment: macOS 26.3 (25D125), Apple M3, built in Retina display.
Layout: Regular size and gap, automatic percentage on line 1, reset countdown on line 2.

Signed CodexBar 0.45.2 baseline:

PR head with the corrected stacked title and an adjacent single line Codex control:

Signed 0.45.2 single line control:

Pixel measurements at 2x:

1. Menu bar: rows 0 through 65, center 32.5.
2. Signed 0.45.2 stacked title: rows 10 through 41, center 25.5.
3. PR head stacked title: rows 16 through 47, center 31.5. The patch moves the block down 6 physical pixels, equal to 3 points, and leaves it within 1 physical pixel of center.
4. The Codex single line title occupies rows 22 through 41 on both the signed release and PR head. Its bounds are unchanged.

The crops contain only the menu bar. No account identity or private window content is included. The PR head is unchanged, mergeable, and its eight successful checks plus one neutral security check are complete.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The durable review comment was published and its verdict was queued for target-serialized routing.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29739213924
• Updated: 2026-07-20T11:42:33.748Z

[kiranmagic7]

Current status on head 2de6991a0754e54145806da4d5623924ab243a48: the branch is mergeable and all nine visible checks are green.

The remaining review question is the visual calibration called out by ClawSweeper: whether the stacked-only -3pt baseline offset is acceptable across the supported menu bar size/display variants. The PR keeps the change limited to exact two-line titles, includes the single-line non-regression test, and has native before/after menu bar proof attached above.