Add Fedora KDE integration

[dudu1111685]

Summary

• add a repeatable Fedora Plasma 6 installer for the official CodexBar Linux CLI and KDE panel widget
• verify published SHA-256 checksums and default to the static musl CLI to avoid Fedora host libcurl ABI warnings
• pin the MIT-licensed Plasma widget and apply tested Plasma 6.6 QML/KCM compatibility fixes while staging it
• support optional idempotent panel insertion through Plasma D-Bus
• add Linux-specific verification, Make targets, documentation, and changelog coverage

Why

CodexBar already publishes a Linux CLI, but its application UI is SwiftUI/AppKit and remains macOS-only. Fedora KDE users currently have to assemble the CLI and community Plasma integration manually. This change provides a user-scoped, reproducible path while keeping provider/auth logic in the official CLI.

User impact

Running ./Scripts/install-fedora-kde.sh --add-to-panel installs the latest verified static CLI into ~/.local/bin, installs or upgrades the pinned Plasma widget, applies the Fedora/Plasma compatibility patch, and optionally adds one widget instance to the first panel. Existing macOS build and release paths are unchanged.

The Linux UI covers provider overview/tabs, quota windows, reset countdowns, pace, credits, local cost, provider status, identity, settings, and structured provider errors. Browser-cookie import and WebKit scraping remain macOS-only, as documented.

Validation

• bash -n Scripts/install-fedora-kde.sh
• compatibility patch dry-run against pinned widget commit 4ab8e365b789243b12fe853a53f0987efd1d54af
• published CLI SHA-256 verification
• ./Scripts/install-fedora-kde.sh --check on Fedora 43 / KDE Plasma 6.6.4 / Wayland
• verified CodexBar 0.43.0 static x86_64 binary and clean config validation
• verified exactly one applet in the live Plasma panel layout and active plasmashell service
• rendered popup and settings through plasmawindowed; recent Plasma logs were clean of CodexBar QML assignment/config errors
• live Codex OAuth usage smoke passed; Claude surfaced a transient upstream rate-limit error correctly
• git diff --check

Repository-wide checks could not complete on this Fedora host: make check requires Apple plutil, and make test requires a Swift toolchain that is not installed.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 16, 2026, 5:22 PM ET / 21:22 UTC.

Summary
The PR adds a Fedora Plasma 6 installer that downloads the official Linux CLI, stages and patches a pinned third-party KDE widget, optionally inserts it into a panel, and adds related documentation and Make targets.

Reproducibility: not applicable. This PR proposes a new Fedora/KDE installation workflow rather than fixing broken behavior with an established reproduction contract.

Review metrics: 3 noteworthy metrics.

• Patch size: 6 files, +537/-1. A platform-specific integration adds a substantial new maintenance surface despite leaving the macOS application code unchanged.
• Runtime installation code: 346 installer lines plus 85 patch lines. Most of the change executes or modifies software in a user's live Plasma environment rather than providing documentation alone.
• Required repository suites: 0 of 2 completed. The PR reports Fedora-specific validation but could not run the repository-required make check and make test suites.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦐 gold shrimp
Result: blocked until stronger 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:

• Attach redacted terminal output or a short recording showing a clean install, idempotent rerun, panel insertion, settings, and provider rendering on the stated Fedora/Plasma setup.
• Run make check and make test on a supported macOS environment and report the results without changing unrelated code.
• Obtain maintainer confirmation on whether the installer and external-widget patch belong in this repository.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR describes a detailed live Fedora/Plasma run, but it needs an attached redacted terminal transcript, screenshot or recording, or linked logs showing installation, panel insertion, and the working widget; updating the PR body should trigger review, otherwise a maintainer can request @clawsweeper re-review. 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] Merging would make CodexBar responsible for compatibility between future CLI output and a separately maintained widget pinned to a specific upstream revision.
• [P1] The installer introduces a new supply-chain boundary by fetching and installing third-party widget code into the user's Plasma environment; the commit pin limits drift but does not establish an ongoing audit and update policy.
• [P1] The live validation is currently a narrative rather than inspectable proof, and the repository-required macOS check and test suites were not completed.
• [P1] The supplied installer patch was truncated in the review context and local read-only shell inspection was unavailable, so no claim is made that the unshown installer paths received a complete line-by-line audit.

Maintainer options:

1. Keep the installer with the widget (recommended)
   Pause or narrow this PR and move the Fedora installer and compatibility patch to the externally maintained Plasma integration.
2. Adopt with an explicit maintenance contract
   Merge only after maintainers accept responsibility for upstream revision updates, CLI/widget compatibility, rollback behavior, and third-party code review.

Next step before merge

• [P1] A maintainer must first choose whether core should own the external KDE integration and review the attached real-environment proof; there is no narrow automated repair to dispatch.

Maintainer decision needed

• Question: Should CodexBar core own and maintain a Fedora-specific installer that downloads, patches, installs, and updates a third-party Plasma widget?
• Rationale: Current documentation uses externally maintained Linux desktop integrations, while accepting this PR creates an ongoing compatibility, supply-chain, and support commitment that cannot be inferred from code correctness alone.
• Likely owner: steipete — They own the repository and have the strongest history across the Linux CLI, packaging, and integration-documentation boundary.
• Options:
  • Keep KDE ownership upstream (recommended): Move the installer and Plasma compatibility patch to the widget or a dedicated integration repository, retaining only an endorsed documentation link in CodexBar.
  • Adopt the integration in core: Accept ongoing Fedora, Plasma, widget-revision, checksum, update, rollback, and support ownership after adding explicit maintenance policy and proof.

Security
Needs attention: The patch adds a meaningful third-party runtime installation boundary that needs explicit ownership and supply-chain review before merge.

Review details

Best possible solution:

Keep the official Linux CLI in CodexBar, place the Fedora installer and Plasma compatibility maintenance in psimaker/codexbar-plasmoid or a dedicated integration repository, and link that supported package from CodexBar documentation unless maintainers explicitly choose to own the full KDE lifecycle here.

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

Not applicable: this PR proposes a new Fedora/KDE installation workflow rather than fixing broken behavior with an established reproduction contract.

Is this the best way to solve the issue?

No, not without an explicit ownership decision; the narrower maintainable default is to keep the Plasma installer and compatibility patch with the external widget while CodexBar owns the Linux CLI and documentation link.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P3: This is a useful but optional, platform-specific integration proposal with limited urgency and no reported regression.
• add merge-risk: 🚨 compatibility: Core would need to keep a pinned external widget and embedded Plasma patch compatible with future CLI output and Fedora/Plasma releases.
• add merge-risk: 🚨 security-boundary: The new installer fetches and installs third-party widget code into the user's desktop environment, creating an ongoing supply-chain review boundary.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR describes a detailed live Fedora/Plasma run, but it needs an attached redacted terminal transcript, screenshot or recording, or linked logs showing installation, panel insertion, and the working widget; updating the PR body should trigger review, otherwise a maintainer can request @clawsweeper re-review. 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:

• P3: This is a useful but optional, platform-specific integration proposal with limited urgency and no reported regression.
• merge-risk: 🚨 compatibility: Core would need to keep a pinned external widget and embedded Plasma patch compatible with future CLI output and Fedora/Plasma releases.
• merge-risk: 🚨 security-boundary: The new installer fetches and installs third-party widget code into the user's desktop environment, creating an ongoing supply-chain review boundary.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR describes a detailed live Fedora/Plasma run, but it needs an attached redacted terminal transcript, screenshot or recording, or linked logs showing installation, panel insertion, and the working widget; updating the PR body should trigger review, otherwise a maintainer can request @clawsweeper re-review. 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

Security concerns:

• [medium] Define trust and update policy for the fetched widget — Scripts/install-fedora-kde.sh:5
  The installer fetches and installs code from an external widget repository. Pinning a commit limits unexpected drift, but maintainers should review that revision and define who audits, updates, and rolls back the dependency before CodexBar endorses it as an official installer.
  Confidence: 0.91

What I checked:

• Existing integration boundary: Current main presents Linux desktop interfaces such as Waybar, GNOME, Cinnamon, and Quickshell as links to externally maintained projects rather than repository-owned installers. citeturn0search0turn3search2. (README.md:240, 6ffdfeba6c6e)
• Official Linux foundation already exists: The repository already provides and documents the standalone Linux CLI, so the unresolved question is ownership of the KDE packaging and UI integration rather than a missing Linux backend. citeturn3search0turn9search0. (docs/cli.md:1, 6ffdfeba6c6e)
• New third-party installation surface: The branch adds a 346-line installer configured to fetch psimaker/codexbar-plasmoid at a pinned revision and apply a repository-maintained compatibility patch before installing it. (Scripts/install-fedora-kde.sh:5, cd3dd76e4308)
• Proof needs an inspectable artifact: The PR body names a Fedora 43, Plasma 6.6.4, Wayland live run and several observed outcomes, but provides no attached screenshot, recording, terminal transcript, linked artifact, or redacted runtime log showing the after-fix behavior. (cd3dd76e4308)
• Required repository checks were not completed: The PR body states that make check and make test were not run; repository policy requires both before handoff, although the Fedora-specific checks provide useful supplemental validation. (AGENTS.md:1, 6ffdfeba6c6e)
• Relevant feature history: Linux CLI packaging and documentation history is concentrated around repository owner steipete, including the initial Linux CLI and later packaging/documentation updates. citeturn8view2. (docs/cli.md:1)

Likely related people:

• steipete: Repository history connects this person to the initial Linux CLI, later Linux packaging work, integration documentation, and the current project boundary, making them the strongest owner for deciding whether KDE installation belongs in core. (role: feature owner and recent area contributor; confidence: high; commits: 6a57296, c40dd88, 8a85173; files: README.md, docs/cli.md, Package.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.