All my 5 skills' install counts (`installsCurrent`) reset to 0 at the same time

[LuoJiangYong]

All of my published skills on ClawHub have had their install counts (installsCurrent) reset to 0 simultaneously. This is not an issue with a single skill, but seems to be an account-level data problem.

Affected skills (5 in total)

• [缪斯视频创作skill]
• [微信文章格式转换]
• [地产项目前期产策报告]
• [地产品牌社群运营顶层策略咨询]
• [地产项目品牌故事线策略]

My account info

• ClawHub username: [@luojiangyong]

What I have checked

• I did NOT click the "Delete telemetry" button on my dashboard.
• My GitHub account is in good standing, and I have not deleted any repos or changed permissions recently.
• All 5 skills are still visible on my dashboard and can be published/installed normally.
• I have tried reinstalling one of the skills (clawhub install <slug>) to trigger a new install event, but the count did not recover.

Expected behavior
The install counts should reflect the actual number of unique users who have installed these skills. At the very least, my own test installations should be counted.

Additional context
Since all 5 skills were affected at the same time, I suspect this might be caused by:

• A platform-side data cleanup or migration issue
• A bug in the telemetry data aggregation logic
• An accidental reset of my account's telemetry data (though I did not trigger it manually)

Please help investigate this on the backend. Let me know if you need any additional logs or information.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 21, 2026, 2:12 AM ET / 06:12 UTC.

Summary
Keep open: current main has a stat-field sync fix and a merged all-time install backfill, but neither restores or proves correctness for the reported installsCurrent reset from retained current-install rows.

Reproducibility: yes. for the non-recovery path: source and tests show reinstalling an already-recorded user/skill only refreshes the retained row and does not enqueue a new count event. The original production reset still needs live Convex confirmation.

Next step
Maintainers need production Convex access and approval of the current-count restoration strategy before a safe repair lane can be selected.

Review details

Best possible solution:

Keep the current stat-field sync fix, then run an operator-approved current-count reconciliation that audits userSkillInstalls by skill and updates skill, search, and publisher denormalized stats together if the rows are trustworthy.

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

Yes for the non-recovery path: source and tests show reinstalling an already-recorded user/skill only refreshes the retained row and does not enqueue a new count event. The original production reset still needs live Convex confirmation.

Is this the best way to solve the issue?

No, current main is not a complete solution. It prevents one stat-field overwrite path and adds an all-time estimate backfill, but it does not restore statsInstallsCurrent from retained current-install rows.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Production data state is not verifiable from the checkout, so maintainers still need to confirm whether userSkillInstalls rows exist for the affected skills.
• A repair would rewrite persisted public counters and denormalized stats, so it needs a dry-run-first production migration/backfill plan and maintainer approval.
• The merged all-time install backfill may improve installsAllTime, but it can leave the reported installsCurrent reset unresolved.

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

Label changes

Label changes:

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

Label justifications:

• P2: The issue reports a production-visible stats data-loss problem with limited known blast radius rather than an outage or security emergency.
• impact:data-loss: The report and corroborating comment describe historical installsCurrent telemetry counters being reset or lost across published skills.

Evidence reviewed

Acceptance criteria:

• Read-only production audit comparing affected skills' statsInstallsCurrent and nested stats.installsCurrent against userSkillInstalls rows by skill.
• If approved, use a dry-run-first Convex migration/backfill path with batching/resume behavior and real Convex runtime validation.
• Run targeted telemetry/stat reconciliation tests and bun run ci:unit for any source changes.

What I checked:

• Documented counter contract: Telemetry docs define installsCurrent as unique users who reported an install and have not deleted telemetry, so a zeroed current counter is a stats correctness problem against an existing contract. (docs/telemetry.md:37, 6f28659e7bfb)
• Reinstall does not self-heal drifted current counters: When userSkillInstalls already has a user/skill row, install telemetry only patches lastSeenAt/lastVersion and returns without inserting a new skillStatEvents row. (convex/telemetry.ts:114, 6f28659e7bfb)
• Regression coverage confirms repeated installs are idempotent: The telemetry test asserts repeated installs patch the existing row and do not insert a skillStatEvents record, matching the reporter's observation that reinstalling did not recover a zeroed counter. (convex/telemetry.test.ts:181, 6f28659e7bfb)
• Current main fixed one stat-field overwrite class: buildSkillStatPatch now prefers top-level stat fields and syncs nested fields to them; the adjacent test documents the prior nested-to-top-level overwrite bug, but this prevents future drift rather than restoring already-zeroed top-level current counts. (convex/statsMaintenance.test.ts:197, 6f28659e7bfb)
• Merged backfill is all-time only: The install backfill patch type only writes statsInstallsAllTime and nested stats.installsAllTime; it does not write statsInstallsCurrent. (convex/lib/skillInstallBackfill.ts:49, 6f28659e7bfb)
• Backfill avoids current install source rows: The all-time backfill model explicitly uses aggregate daily stats and does not read userSkillInstalls, install dedupe rows, IP hashes, or user-level telemetry, so it cannot restore current counts from current install rows. (convex/lib/skillInstallBackfill.ts:14, 6f28659e7bfb)

Likely related people:

• Patrick-Erichsen: Blame and history tie the current install upsert path, stat delta dual-write helper, stat-field sync backfill, retention policy, and root telemetry cleanup to this history. (role: introduced and recently maintained current stat pipeline; confidence: high; commits: 5be7035a691c, e8a75de2b1a9, 9c50b60e355b; files: convex/telemetry.ts, convex/lib/skillStats.ts, convex/statsMaintenance.ts)
• jesse-merhi: Merged history includes install telemetry hardening/ranking work and the all-time install backfill migration that partially overlaps the reported stats recovery problem. (role: recent adjacent telemetry and install-backfill contributor; confidence: high; commits: 2c1b331be0ff, 8090d4ecea75; files: convex/telemetry.ts, convex/schema.ts, convex/lib/skillInstallBackfill.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.