Why can't see downloads numbers in clawhub

[Kyro-Ma]

yesterday it's still using downloads as first metrics for skills in dashboard, today it changes to installs numbers. Why don't use downloads anymore?

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 18, 2026, 4:21 PM ET / 20:21 UTC.

Summary
Keep open: current main still intentionally shows install-based adoption metrics on the dashboard and shared skill-card/detail surfaces, while downloads remain available in public data. The open fix at #2728 only covers the skill detail page, so the broader dashboard/card metric policy is still a maintainer product decision tracked more concretely by #2684.

Reproducibility: yes. at source level: current main renders Installs on the dashboard and detail metadata and has a dashboard test asserting Downloads is absent. I did not run a browser because this is a read-only review.

Root-cause cluster
Relationship: partial_overlap
Canonical: #2684
Summary: This issue belongs to the downloads-versus-installs presentation cluster; the canonical open item is the concrete request to show Downloads alongside Installs on public skill cards, while this issue specifically mentions dashboard visibility.

Members:

• canonical: feat: Restore Download count display alongside Install count on skill cards #2684 - It is open and directly requests restoring Downloads alongside Installs on public skill cards after the metric switch.
• partial_overlap: Public skill page shows Installs = 1 while CLI stats show downloads = 803 #2691 - It reports the same metric confusion with a concrete skill detail example and has an open closing PR for that narrower detail-page surface.
• partial_overlap: fix: show downloads on skill detail stats #2728 - It is a viable open candidate for the detail-page part of the cluster, but it does not change dashboard or compact card metrics.
• same_root_cause: fix: use installs across public adoption surfaces #2653 - The merged PR explicitly replaced public-facing download adoption metrics with installs across several ClawHub surfaces.
• superseded: Clarify downloads vs installs across ClawHub and OpenClaw CLIs #2405 - It was the broader closed issue about downloads-versus-installs semantics across CLI/API/UI, while the remaining open work is now split into narrower UI-surface decisions.

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

Next step
Do not queue a separate fix PR from this support question; maintainers should first decide the downloads-versus-installs display policy in the canonical related issue and account for the narrower open detail-page PR.

Review details

Best possible solution:

Settle the downloads-versus-installs metric hierarchy in the canonical related issue, then update dashboard/cards/detail/docs/tests together so publishers can predict what each public number means.

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

Yes, at source level: current main renders Installs on the dashboard and detail metadata and has a dashboard test asserting Downloads is absent. I did not run a browser because this is a read-only review.

Is this the best way to solve the issue?

Unclear until maintainers choose the metric policy. A narrow detail-page addition is already proposed, but the dashboard/card request should not be auto-fixed before the broader product decision in #2684.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Maintainers still need to decide whether downloads should reappear on dashboard/card surfaces or remain hidden behind install-first adoption metrics.
• The open detail-page PR would improve publisher clarity for one surface, but it does not answer the dashboard/card behavior reported here.

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

Label changes

Label changes:

• remove clawsweeper:fix-shape-clear: Current issue advisory state no longer selects this label.

Label justifications:

• P3: This is low-risk public metric presentation and publisher ergonomics work, not an urgent runtime, security, or data-integrity issue.
• impact:other: The issue affects how publishers and users interpret public ClawHub adoption metrics outside the specific owned impact categories.

Evidence reviewed

What I checked:

• Current dashboard behavior: The dashboard skill row builds its first visible stat as label "Installs" from skill.stats.installsAllTime, matching the reported disappearance of Downloads from that surface. (src/routes/dashboard.tsx:333, 22d3cd133cb6)
• Dashboard test expectation: The dashboard test asserts that Installs appears and Downloads is absent, so the current behavior is deliberate test-covered source behavior rather than missing backend data. (src/routes/-dashboard.test.tsx:302, 22d3cd133cb6)
• Skill detail still installs-only on main: The skill detail metadata block on current main renders a large Installs value from formattedStats.installsAllTime and does not render downloads in that block. (src/components/SkillHeader.tsx:486, 22d3cd133cb6)
• Shared skill card stat line: The shared SkillStatsTripletLine renders stars plus all-time installs, not downloads, for compact skill-card/list style surfaces. (src/components/SkillStats.tsx:13, 22d3cd133cb6)
• Downloads remain available in public data: toPublicSkill still exposes canonical downloads, installsCurrent, and installsAllTime, so the remaining question is display/product semantics rather than absent backend stats. (convex/lib/public.ts:124, 22d3cd133cb6)
• Related open candidate is narrower: Live GitHub state shows fix: show downloads on skill detail stats #2728 is open, mergeable, and closes Public skill page shows Installs = 1 while CLI stats show downloads = 803 #2691 by adding Downloads only to the skill detail metadata sidebar, leaving dashboard/cards unchanged. (b864293f47a8)

Likely related people:

• Patrick-Erichsen: Authored the installs-across-public-surfaces rollout and current blame points the dashboard/detail/stat metadata lines to Patrick Erichsen's later public-publisher refactor on main. (role: recent area contributor; confidence: high; commits: 44ce895b442c, 911515194911; files: src/routes/dashboard.tsx, src/components/SkillHeader.tsx, src/components/SkillStats.tsx)
• jesse-merhi: History search shows the merged install-primary work in Make installs the primary plugin and skill usage signal #2633 changed SkillHeader, SkillStats, SkillListItem, and home card surfaces from downloads toward install-based usage signals. (role: introduced adjacent behavior; confidence: high; commits: 078425f074da; files: src/components/SkillHeader.tsx, src/components/SkillStats.tsx, src/components/SkillListItem.tsx)
• vyctorbrzezowski: Recent public stats hydration work switched the public mapper to canonical stat reads for downloads and install counters, confirming the data remains available to the UI layer. (role: recent adjacent contributor; confidence: medium; commits: f3ab8663e3f3; files: convex/lib/public.ts, convex/lib/skillStats.ts)

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.