refactor(plugins): require initialized registry collections#100990
Conversation
|
@clawsweeper review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Codex review: needs maintainer review before merge. Reviewed July 6, 2026, 12:45 PM ET / 16:45 UTC. Summary PR surface: Source -147, Tests -57. Total -204 across 30 files. Reproducibility: not applicable. this is an internal refactor PR rather than a bug report. Source inspection confirms current main still marks initialized PluginRegistry collections optional while createEmptyPluginRegistry initializes them. Review metrics: 1 noteworthy metric.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Next step before merge
Security Review detailsBest possible solution: Review and land this as the PluginRegistry slice of #100977 if maintainers are comfortable with the internal type-contract cleanup; keep the remaining issue slices tracked separately. Do we have a high-confidence way to reproduce the issue? Not applicable: this is an internal refactor PR rather than a bug report. Source inspection confirms current main still marks initialized PluginRegistry collections optional while createEmptyPluginRegistry initializes them. Is this the best way to solve the issue? Yes: making constructor-owned registry collections required and updating runtime/test callers is the narrow maintainable fix for this slice. Preserving optional fallbacks would keep the duplicate contract the PR is trying to remove. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against cc147c6a4060. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source -147, Tests -57. Total -204 across 30 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
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
|
…#100990) * refactor(plugins): require initialized registry collections * test(plugins): keep empty registry imports lightweight
…#100990) * refactor(plugins): require initialized registry collections * test(plugins): keep empty registry imports lightweight
Related: #100977
What Problem This Solves
PluginRegistrymarked 16 collection fields optional even though the canonical registry constructor always initializes them. That mismatch forced callers and tests to preserve unreachable fallback branches, duplicate large empty-registry literals, and use unsafe casts that obscured the actual loader invariant.Why This Change Was Made
Make only the collections initialized by
createEmptyPluginRegistry()required, then consume them directly throughout plugin registration, loader snapshots, host cleanup, and gateway policy paths. TruePluginRegistrytest fixtures now delegate to the canonical empty constructor; the distinct SDK hook-runner registry keeps its legitimately optional trusted-policy collection. Plugin lifecycle unions, provider APIs, SDK facades, gateway architecture, and runtime behavior remain out of scope.User Impact
No user-visible behavior changes. Maintainers get one explicit registry construction contract, fewer defensive branches, and test fixtures that fail at compile time if the canonical registry shape changes.
Evidence
tbx_01kww0q91z73mwy5j0aepqecsr(violet-shrimp)oxfmt --checkpassed for all 30 changed files;scripts/run-oxlint.mjspassed..agents/skills/autoreview/scripts/autoreview --mode local --stream-engine-outputreported no accepted/actionable findings (patch is correct, confidence 0.84).extensions/qa-lab/src/cli.tsfailing to resolve./mantis/cli.js; this PR changes no extension files.