Best possible solution:

Land this bounded foundation after ordinary maintainer review, while keeping the canonical tracker and broader draft available for follow-up migration batches.

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

Not applicable as a bug reproduction: this is an internal cleanup refactor. Current-main source inspection does confirm the cleanup target, including separate lazy-runtime cache ownership and five manual library facade memoizers.

Is this the best way to solve the issue?

Yes: delegating lazy-runtime caching to the existing lazy-promise owner and migrating one bounded facade batch is the narrow maintainable first step. The broader repository-wide migration remains better handled in follow-up batches rather than forcing the draft reference implementation into this PR.

AGENTS.md: found and applied where relevant.

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

Label justifications:

• P3: This is a low-risk internal maintainability refactor with no intended user-visible behavior change.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Not applicable: this is a maintainer-labeled internal refactor PR, so the external contributor real-behavior proof gate does not apply.

PR surface:

Source +2, Tests +54. Total +56 across 5 files.

What I checked:

• Protected live PR state: Live PR metadata shows this PR is open, authored by RomneyDa, labeled maintainer, mergeable/CLEAN, and carrying the current P3 ready-for-maintainer-look state, so conservative cleanup should not auto-close it. (66731b504bcc)
• Current main still has separate lazy-runtime cache ownership: Current main createLazyRuntimeSurface still owns its own cached promise and does not delegate to createLazyPromiseLoader, so the central PR change is not implemented on main. (src/shared/lazy-runtime.ts:6, e701dc76b060)
• Current main still has the library memoizers this PR migrates: Current main src/library.ts still declares five module-level runtime promise caches and loader functions for the public facade imports. (src/library.ts:32, e701dc76b060)
• PR implementation preserves sticky lazy-runtime rejection caching: The PR head makes lazy-runtime helpers delegate to createLazyPromiseLoader with cacheRejections: true, matching the old sticky dynamic-import rejection behavior while adding peek/clear controls. (src/shared/lazy-runtime.ts:16, 66731b504bcc)
• Plugin SDK boundary remains enumerated: The public Plugin SDK lazy-runtime subpath still enumerates only lazy-runtime helper exports, so the shared helper re-export does not automatically broaden the public plugin API surface. (src/plugin-sdk/lazy-runtime.ts:4, e701dc76b060)
• Latest shipped release lacks the central change: The latest release tag still has the separate lazy-runtime cache owner and manual library memoizers, confirming this PR is not redundant with shipped behavior. (src/shared/lazy-runtime.ts:6, e085fa1a3ffd)

Likely related people:

• steipete: GitHub path history shows steipete introduced and iterated the lazy-runtime helper family used by core and Plugin SDK callers. (role: feature-history owner; confidence: high; commits: 9648e7fecb28, 795f1f438b1d, 39a8dab0da60; files: src/shared/lazy-runtime.ts, src/plugin-sdk/lazy-runtime.ts)
• vincentkoc: GitHub path history shows recent work on the lazy-promise option surface that this PR reuses and extends. (role: recent area contributor; confidence: medium; commits: 884a6a113ccf; files: src/shared/lazy-promise.ts)
• RomneyDa: RomneyDa authored the canonical cleanup issue, the broader reference implementation, and this bounded foundation PR, making them a routing contact for the series direction. (role: cleanup series owner; confidence: medium; commits: 66731b504bcc, f756733f7088; files: src/shared/lazy-promise.ts, src/shared/lazy-runtime.ts, src/library.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

• 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.