feat(search): capture bounded manual plugin-search observations - #3630
feat(search): capture bounded manual plugin-search observations#3630Patrick-Erichsen wants to merge 2 commits into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Codex review: blocked before merge. Reviewed September 8, 2026, 7:18 PM ET / 23:18 UTC. ClawSweeper reviewWhat this changesRecord bounded, attributed plugin searches and their returned result counts in Convex, with automatic cleanup after 30 days. Merge readiness⛔ Blocked before merge - 2 items remain Keep open: current main lacks this capture capability, and the related drafts build on it rather than replace it. No blocking code findings were identified; the collaborator-authored draft explicitly reserves landing for human review. Priority: P2 Review scores
Verification
How this fits togetherClawHub’s plugin search API combines visible package results before returning them to clients. This change records selected search facts at that boundary for later analytics, without changing package access checks. flowchart TD
A[Plugin search request] --> B[Rate limits and package visibility]
B --> C[Combine and limit results]
C --> D[Return search response]
C --> E[Check source and text bounds]
E --> F[Store search observation]
F --> G[Daily expiration cleanup]
Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Keep capture at the assembled-response boundary, with an additive rollout that preserves existing data and verifies bounded retention before client attribution is enabled. Do we have a high-confidence way to reproduce the issue? Not applicable: this adds an analytics capability rather than repairing a reported existing-behavior defect. Is this the best way to solve the issue? Yes, the response boundary is the appropriate capture layer: per-family collection could count discarded results, while client-only collection cannot independently establish authoritative returned counts. Deployment and retention validation remain outstanding. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 651a7641a204. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
Capture bounded manual plugin-search observations
Problem
Record manual search demand at the response boundary so counts describe exactly what the user receives.
Change
Record only bounded manual-source plugin searches. Official counts use exact returned packages with authoritative
isOfficial === true; ordinary authorization and private visibility remain unchanged. No request, user, or device identity is stored.Validation
491 focused boundary/retention tests passed. Real web and Control UI requests were paired with persisted observations, including community-only and zero-result searches.
Review status
Draft for human review. This is a dedicated search-intelligence stack, independent of the plugin-page/category work. No merge or production deployment is authorized.
The full integrated stack at
ca843a963apassedbun run ci:unit(6,582 passed, 3 skipped),bun run ci:types-build, package/HTTP/browser checks, and the non-audit static constituents.bun run ci:staticremains red on seven dependency advisories in the unchanged baseline lockfile; that repair is deliberately outside this stack. These results are from the saved reviewed head, not a claim that CI on this PR has passed.The official gap is exactly zero authoritative official results in the returned response. The model never assigns provenance. Unknown/unmarked traffic and non-plugin responses are excluded.
Related draft PRs
Review ClawHub bottom-to-top: capture → web attribution → dashboard/API/CLI → weekly producer.
Separate-repository companions: OpenClaw Control UI and Hermit receiver. The producer requires the Hermit receiver; the Control UI source marker requires the capture boundary. No plugin-page/category stack branches are included.