Repository navigation
fix(push): publish only team-shared skill names in stats - #1056
Conversation
|
|
Filing team here — we opened #1055, and we have a direct answer to the design call in your Notes for Reviewers. Prune: yes, please. The names in already-pushed One reverse case worth covering: filtering strictly by the repo catalog also drops the built-in Context that may help the review: our team runs Codex only, where no payload records a real skill use (no |
|
Thanks for the fix. Please don't prune names already in |
No additional findings confidently established from the specified diff. Nothing from the PR was run, built, or installed. |
Per maintainer review on Tencent#1056: names already published in stats/<user>.yaml stay as-is (they remain in git history either way; rewriting is costly), so the filter only blocks new additions. The publishable catalog now also carries the CLI's built-in skills, which are never present in skills/ — without them, adoption of the built-in teamai skill would silently disappear from the digest.
|
@hsuchifeng Done — 9f0b872 flips to conservative: previously-published names are kept as-is (the function now only filters new usage; the doc comment records the maintainer call), and the prune test inverted to pin the new contract. @shusun-lu Your built-in point is covered too: Real-CLI verification (the P1 record, built Setup: team repo with
skills:
shared-skill: { count: 2, ... }
teamai: { count: 1, ... }
|
Nothing from the PR was run, built, or installed. |
|
CI is currently failing across all Node/OS jobs: 4 unit tests in |
|
Both points are already handled on the branch:
The 74ad8d1 run hasn't started yet — it looks like the fork CI trigger still needs authorization. Could you approve the workflow run when you get a chance? Happy to adjust further if anything else comes up. |
|
CI on the current head
That is all six Lint & Test jobs plus E2E (fork-safe). Run 38337680378.
|
|
Apologies — Verified the three suites you named, locally:
|
No additional findings confidently established from the specified diff. Nothing from the PR was run, built, or installed. |
|
Please resolve the conflict. |
Per maintainer review on Tencent#1056: names already published in stats/<user>.yaml stay as-is (they remain in git history either way; rewriting is costly), so the filter only blocks new additions. The publishable catalog now also carries the CLI's built-in skills, which are never present in skills/ — without them, adoption of the built-in teamai skill would silently disappear from the digest.
e9248b8 to
5f865fe
Compare
|
Rebased onto main — the conflict was the |
No additional findings confidently established from the specified diff. Nothing from the PR was run, built, or installed. |
|
The CI failure on 5f865fe is a timing flake, not a regression: |
… test The test asserted the pre-Tencent#1056 behavior: a skill name outside the team's shared catalog ('legacy') reaches the published stats. With the privacy filter the published stats keep only shared names, so the slow receiver fixture now expects legacy to stay out and review to carry the capped count — same shape as the rejected-then-retry test above it. The earlier 'CI flake' read was wrong: the failure was deterministic against a rebuilt dist; the local greens came from a stale dist built from a different branch.
|
Correction on the earlier CI read: the Root cause: the over-cap slow-receiver test asserted the pre-#1056 behavior — a skill name outside the team's shared catalog ( Fixed in 93a1c6a: the fixture now expects |
No additional findings confidently established from the specified diff. Nothing from the PR was run, built, or installed. |
teamai pull commits stats/<user>.yaml with a skills map merged verbatim from local usage events, so a member's local-only skills, slash-command names and stray SKILL.md reads became visible to everyone who pulls. The only escape was turning usage reporting off entirely, which also drops votes, digest stats and token contributions (Tencent#1055). Filter at the push boundary: aggregateUsage output is reduced to names present in the team repo's shared skills catalog before merging, and names published before this filter existed are pruned on the same rewrite. The catalog is always enumerated from the default-branch repo path - the reports branch is an orphan branch and never carries skills/, so enumerating from the write worktree would wrongly drop all stats. Local usage.jsonl keeps full fidelity; votes, session metrics and token contributions are untouched. A team that shares no skills gets an empty skills map: every skill is local-only there. Fixes Tencent#1055
Per maintainer review on Tencent#1056: names already published in stats/<user>.yaml stay as-is (they remain in git history either way; rewriting is costly), so the filter only blocks new additions. The publishable catalog now also carries the CLI's built-in skills, which are never present in skills/ — without them, adoption of the built-in teamai skill would silently disappear from the digest.
… test The test asserted the pre-Tencent#1056 behavior: a skill name outside the team's shared catalog ('legacy') reaches the published stats. With the privacy filter the published stats keep only shared names, so the slow receiver fixture now expects legacy to stay out and review to carry the capped count — same shape as the rejected-then-retry test above it. The earlier 'CI flake' read was wrong: the failure was deterministic against a rebuilt dist; the local greens came from a stale dist built from a different branch.
93a1c6a to
c657ae7
Compare
No additional findings confidently established from the specified diff. Nothing from the PR was run, built, or installed. |
|
Two updates: (1) real-CLI verification record added to the description (P1) — a real |
* fix(push): publish only team-shared skill names in stats teamai pull commits stats/<user>.yaml with a skills map merged verbatim from local usage events, so a member's local-only skills, slash-command names and stray SKILL.md reads became visible to everyone who pulls. The only escape was turning usage reporting off entirely, which also drops votes, digest stats and token contributions (Tencent#1055). Filter at the push boundary: aggregateUsage output is reduced to names present in the team repo's shared skills catalog before merging, and names published before this filter existed are pruned on the same rewrite. The catalog is always enumerated from the default-branch repo path - the reports branch is an orphan branch and never carries skills/, so enumerating from the write worktree would wrongly drop all stats. Local usage.jsonl keeps full fidelity; votes, session metrics and token contributions are untouched. A team that shares no skills gets an empty skills map: every skill is local-only there. Fixes Tencent#1055 * fix(push): keep already-published names, include built-ins in catalog Per maintainer review on Tencent#1056: names already published in stats/<user>.yaml stay as-is (they remain in git history either way; rewriting is costly), so the filter only blocks new additions. The publishable catalog now also carries the CLI's built-in skills, which are never present in skills/ — without them, adoption of the built-in teamai skill would silently disappear from the digest. * test(e2e): expect the Tencent#1056 filter in the over-cap slow-report test The test asserted the pre-Tencent#1056 behavior: a skill name outside the team's shared catalog ('legacy') reaches the published stats. With the privacy filter the published stats keep only shared names, so the slow receiver fixture now expects legacy to stay out and review to carry the capped count — same shape as the rejected-then-retry test above it. The earlier 'CI flake' read was wrong: the failure was deterministic against a rebuilt dist; the local greens came from a stale dist built from a different branch. --------- Co-authored-by: kittimzhe <kittimzhe@users.noreply.github.com>
Summary
stats/<user>.yamlis team-visible, but nothing on the push path filtered skill names: a member's local-only skills, slash-command names and straySKILL.mdreads were merged verbatim and published to everyone who pulls (#1055). The only escape wasusageReport: false, which also drops votes, digest stats and token contributions.This filters at the push boundary — the privacy-relevant edge — while local
usage.jsonlkeeps full fidelity:mergeStatsWithinTeamSkillsreducesaggregateUsageoutput to names present in the team repo's shared skills catalog (collectTeamRepoSkills, now exported) before merging, and prunes names published before the filter existed on the same rewrite — they were published by accident. This is the "prune" default I flagged in the issue comment; if maintainers prefer conservative (stop new additions, keep already-published names), dropping the prune loop is a two-line change.utils/reports-branch.ts) and never carriesskills/, so enumerating fromwriteRootin reports-branch mode would wrongly drop all stats. This is called out in a comment at the enumeration site.Type of Change
Test Plan
npx tsc --noEmitpassesnpm run lintpasses (oxlint, 0 warnings / 0 errors)npx vitest run— newteam-push-privacy.test.ts(6 tests) plus the push/stats/usage family (165 tests) all pass; the only failure anywhere remains the pre-existing environmentaldsh-hookscase (DSH installed locally, fails identically on cleanmain)src/team-push.ts/src/agent-skills.tsand pass with the fixRelated Issues
Fixes #1055
Notes for Reviewers
event.skillrecords and the catalog keys use. An exotic namespaced spelling would be filtered rather than leak (privacy-safe direction of the false negative).Real-CLI verification record (P1)
After
npm run build, against a bare-origin fixture whose team repo sharesskills/review, with the user scope's usage seeded as 3×legacy(older) + 2×review(newest) in~/.teamai/user-usage.jsonl:reviewpublishes with its count;legacy— a name outside the team catalog — is kept out of the team-visible stats while the local usage file keeps full fidelity. (Workflow-run stats from the earlier fixture history were replaced by this fresh report.)Branch note (CI failures root-caused)
The earlier E2E failures on this branch were not caused by these commits: the PR's merge ref was built against a
mainstate whose squash of #1126 had dropped the two e2e expectation fixes (d25b7aepredates them being restored onmainby #1161), so the merge ref combined the records engine with the pre-records test expectations. The branch is now recreated on currentmain(same three commits,56bb9cc..c657ae7); all four affected e2e files pass locally after a fresh build (65/65), unit suites 172/172, tsc and lint clean.