Skip to content

Make merged-Overview provider limit user-configurable#2339

Open
Vit129 wants to merge 1 commit into
steipete:mainfrom
Vit129:pr-configurable-overview-limit
Open

Make merged-Overview provider limit user-configurable#2339
Vit129 wants to merge 1 commit into
steipete:mainfrom
Vit129:pr-configurable-overview-limit

Conversation

@Vit129

@Vit129 Vit129 commented Jul 19, 2026

Copy link
Copy Markdown

Summary

  • The merged-icon Overview tab's provider cap was hardcoded (docs/ui.md, issue Allow more than 3 providers in the Overview tab (compact density mode) #2107). This makes it user-configurable via a Settings stepper (1-12), backed by UserDefaults.
  • Rebased on current main, which already raised the hardcoded default from 3 to 6 — kept that as the new configurable default so existing users see no behavior change.

Test plan

  • swift build --product CodexBar -c debug succeeds
  • Manual: Settings > Menu Bar > "Overview tab limit" stepper changes how many providers render in the merged Overview icon

Was hardcoded to 3 (docs/ui.md, issue steipete#2107). Now backed by
UserDefaults (static var, since it's used as a default-parameter
value elsewhere and Swift disallows self in those) with a Settings
stepper (1-12, default 3 for no behavior change).

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3017da8f53

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

private static let maxOverviewProviders = SettingsStore.mergedOverviewProviderLimit
private static var maxOverviewProviders: Int { SettingsStore.mergedOverviewProviderLimit }

@AppStorage("mergedOverviewProviderLimit") private var overviewProviderLimitSetting = 6

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Invalidate menus when overview limit changes

When this setting changes after the merged Overview menu has already been rendered, only UserDefaults.standard is updated. StatusItemController invalidates/rebuilds menu content via observation of settings.menuObservationToken, and that token never reads this new key, so menuNeedsUpdate can consider the existing menu fresh and keep showing the old number of Overview rows until an unrelated observed setting/store change or app restart. Please route the limit through SettingsStore/defaultsState and include it in menu observation, or otherwise invalidate the merged menu when the value changes.

Useful? React with 👍 / 👎.

@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P2 Normal priority bug or improvement with limited blast radius. labels Jul 19, 2026
@clawsweeper

clawsweeper Bot commented Jul 19, 2026

Copy link
Copy Markdown

Codex review: needs real behavior proof before merge. Reviewed July 19, 2026, 12:45 PM ET / 16:45 UTC.

Summary
The PR adds a persistent 1–12 Settings stepper for the merged Overview provider cap and changes the menu limit lookup from a fixed constant to a UserDefaults-backed value.

Reproducibility: yes. at source level: open a merged Overview menu, change the new stepper, and reopen or refresh the menu without another observed settings change; the added UserDefaults key is not incorporated into the menu freshness dependency. This has not been run against a fresh app bundle in this review.

Review metrics: 2 noteworthy metrics.

  • Patch scope: 3 files affected; 31 additions, 3 deletions. The patch is narrowly scoped to preferences, settings storage, and menu rendering, so the missing invalidation path can be repaired without broad churn.
  • New preference: 1 persistent setting; UI range 1–12. This adds a new user-facing configuration contract whose range and refresh behavior should be deliberate before merge.

Root-cause cluster
Relationship: partial_overlap
Canonical: #2107
Summary: This PR implements the configurable-cap portion of the canonical Overview-density request, while the compact-layout portion remains unaddressed.

Members:

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

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦐 gold shrimp
Result: blocked until real behavior proof is added.

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

Rank-up moves:

  • Route the limit through observed menu state or invalidate/rebuild the merged menu after a stepper change.
  • [P1] Add focused coverage for the menu freshness/invalidation path.
  • [P1] Post redacted fresh-bundle proof of changing the setting and seeing the Overview row count update; after updating the PR body, a maintainer can request @clawsweeper re-review if needed.

Proof guidance:

  • [P1] Needs real behavior proof before merge: The PR body reports a successful build, but its only after-fix manual verification remains unchecked and no live Settings-to-Overview result is shown. Before merge, provide a redacted fresh-bundle recording or screenshots showing the stepper changes the rendered Overview row count, including an already-open/cached menu path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

  • [P1] Changing the stepper currently may not refresh an open or cached merged menu, leaving visible Overview rows inconsistent with the selected limit.
  • [P1] The new 1–12 persistent preference expands product surface beyond the canonical request's currently unsponsored density/cap direction.

Maintainer options:

  1. Decide the mitigation before merge
    If a maintainer sponsors a configurable cap, model it in SettingsStore’s observed defaults state, invalidate or rebuild the merged menu when it changes, add focused regression coverage, and validate the chosen range in a freshly built app bundle.
  2. Pause or close
    Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

  • [P1] A maintainer must first sponsor the new preference and range; afterward, the contributor needs to fix menu invalidation and provide real native-app behavior proof before merge.

Maintainer decision needed

  • Question: Should CodexBar expose a user-adjustable 1–12 Overview row cap now, independently of the compact-density work tracked by Allow more than 3 providers in the Overview tab (compact density mode) #2107?
  • Rationale: The related canonical request describes the cap as a partial UX lever and leaves the appropriate range and density tradeoff to product judgment; no maintainer approval is visible in this PR discussion.
  • Likely owner: ratulsarna — They are the available history-backed contributor for the original merged Overview feature and its provider-selection controls.
  • Options:
    • Sponsor a bounded configurable cap (recommended): Accept the setting as a separately useful feature, but require observed menu invalidation, regression coverage, real app proof, and a maintainer-approved range.
    • Defer to compact-density design: Keep the canonical issue as the product vehicle and defer this preference until the Overview density behavior and cap are designed together.

Security
Cleared: The three-file Swift/UI preference change adds no dependency, workflow, secret, permission, download, or supply-chain surface.

Review findings

  • [P2] Invalidate the merged menu when the Overview limit changes — Sources/CodexBar/PreferencesMenuBarPane.swift:80-90
Review details

Best possible solution:

If a maintainer sponsors a configurable cap, model it in SettingsStore’s observed defaults state, invalidate or rebuild the merged menu when it changes, add focused regression coverage, and validate the chosen range in a freshly built app bundle.

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

Yes, at source level: open a merged Overview menu, change the new stepper, and reopen or refresh the menu without another observed settings change; the added UserDefaults key is not incorporated into the menu freshness dependency. This has not been run against a fresh app bundle in this review.

Is this the best way to solve the issue?

No. The direct @AppStorage/static UserDefaults path does not keep the merged menu state coherent; the setting should flow through observed SettingsStore state or explicitly invalidate the merged menu, subject to maintainer approval of the feature and range.

Full review comments:

  • [P2] Invalidate the merged menu when the Overview limit changes — Sources/CodexBar/PreferencesMenuBarPane.swift:80-90
    Changing this standalone @AppStorage value does not update the SettingsStore observation state used to decide whether mergedMenu is stale. An already-rendered Overview can therefore keep the old number of provider rows until an unrelated settings update or restart. Route the value through observed settings state or explicitly invalidate/rebuild the merged menu when the stepper changes.
    Confidence: 0.98

Overall correctness: patch is incorrect
Overall confidence: 0.98

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

  • add P2: The PR introduces a visible settings behavior defect in the merged Overview menu, but it has a bounded blast radius and a focused repair path.
  • add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
  • add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports a successful build, but its only after-fix manual verification remains unchecked and no live Settings-to-Overview result is shown. Before merge, provide a redacted fresh-bundle recording or screenshots showing the stepper changes the rendered Overview row count, including an already-open/cached menu path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

  • P2: The PR introduces a visible settings behavior defect in the merged Overview menu, but it has a bounded blast radius and a focused repair path.
  • rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports a successful build, but its only after-fix manual verification remains unchecked and no live Settings-to-Overview result is shown. Before merge, provide a redacted fresh-bundle recording or screenshots showing the stepper changes the rendered Overview row count, including an already-open/cached menu path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed

What I checked:

  • Unresolved refresh defect: The added @AppStorage binding writes mergedOverviewProviderLimit directly, while the merged menu's freshness path is not made dependent on that key; the existing inline review correctly identifies that a menu already built can continue rendering the previous row count. (Sources/CodexBar/PreferencesMenuBarPane.swift:80, 3017da8f5382)
  • Menu consumes the dynamic cap: The menu path reads SettingsStore.mergedOverviewProviderLimit while constructing Overview rows, so the cap affects visible content but requires an explicit observed-state or invalidation path when it changes. (Sources/CodexBar/StatusItemController+Menu.swift:9, 3017da8f5382)
  • Canonical product context: The related request remains open and explicitly treats a higher cap as only one lever, with compact density as the primary UX work; it is the canonical discussion for the desired behavior.
  • Feature provenance: Current release history credits @ratulsarna with the original merged-menu Overview feature and persisted provider-selection controls, making them the strongest available routing candidate for the affected behavior. (CHANGELOG.md, 3b4d9a85cbec)

Likely related people:

  • ratulsarna: Release history credits this person for the merged-menu Overview tab, configurable provider selection, and row-to-provider navigation introduced with the feature. (role: original feature contributor; confidence: medium; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/PreferencesMenuBarPane.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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

P2 Normal priority bug or improvement with limited blast radius. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant