fix(cli): `main` fails the published-JSDoc codename guard — bare issue reference `#1589` in netscript-web-runtime-closure.ts

[rickylabs]

Summary

main currently fails deno task test. The JSDoc-codename guard shipped by #1554 flags an internal
issue reference in published JSDoc that landed after that guard merged:

packages/cli/src/kernel/domain/dependency-closures/netscript-web-runtime-closure.ts:6
 * runtime. A second fresh-ui instance therefore cannot own the cache-provider singleton in #1589.

Evidence — this is on main, not on a branch

Verified by exporting base 0551ff592 to a clean tree and running the guard there:

$ git archive 0551ff592 | tar -x -C <tmp> && cd <tmp>
$ deno test --allow-all .llm/tools/fitness/check-public-jsdoc-codenames_test.ts
FAILED | 3 passed | 1 failed

git grep "#1589" 0551ff592 -- packages plugins confirms the occurrence is committed on main.

Why this is the guard working, not a false positive

#1554 defines the class as "internal workstream names, wave/epic codenames, and issue numbers in
published JSDoc". A bare #1589 in a doc comment is exactly that: it renders on JSR, and a consumer
cannot resolve it — the referenced issue explains nothing to someone outside this repository.

The guard scans published entrypoint closures, and netscript-web-runtime-closure.ts is inside one.
It caught a genuine new occurrence within hours of shipping, which is the outcome it was built for.

Fix

Reword the comment to state the mechanism rather than cite the issue — why a second fresh-ui
instance cannot own the cache-provider singleton, which is the useful half for a reader. If the issue
link has value for maintainers, a backticked reference is ignored by the guard (inline code spans are
stripped), or it belongs in the commit message rather than in published JSDoc.

Boundaries

• docs(plugins): internal codenames "Group F" and "T1" are in published JSDoc, so they render on JSR and now on the docs site #1554 shipped the guard and is closed. This is not a defect in the guard; it is the guard
  reporting.
• The occurrence is in packages/cli, outside the 0.0.6 documentation lane's ownership, which is why
  it is filed rather than absorbed into that lane's final PR (fix(mcp): agent-docs prose corpus is a stale pre-#1373 snapshot — 60 api-clients references still ship to agents, and no CI check can see it #1531). Fixing it there would have
  hidden the fact that main is red.

Acceptance criteria

• No bare issue reference remains in that file's published JSDoc.
• deno test .llm/tools/fitness/check-public-jsdoc-codenames_test.ts passes on main.
• A repo-wide sweep confirms no other occurrence landed in the same window.

Provenance

Found by the 0.0.6 documentation-lane orchestrator while gating PR #1531, by testing whether that
PR's root-test failure reproduced on its base. It did — so the failure belongs to main.

[github-actions]

Acceptance evidence mirrored from #1614.

• "No bare issue reference remains in that file's published JSDoc." — Commit 2ae64cc removes the bare Fresh defer canary permits split SDK cache-provider singleton #1589 pointer and states the supported cache-provider mechanism; codename guard exits 0.
• "deno test .llm/tools/fitness/check-public-jsdoc-codenames_test.ts passes on main." — Codename guard: exit 0, 4 passed / 0 failed on this branch over merge base 6aee2b4. The orchestrator will re-verify merged main.
• "A repo-wide sweep confirms no other occurrence landed in the same window." — Repo-wide publishable-JSDoc guard-class sweep over packages and plugins, ignoring only closure membership: exit 0, 0 findings.

Provenance: updatedAt=2026-08-12T18:52:48Z; bodySha256=402e0137ba780e09896fd9271b52587a68f7ebc5d4bacbeb0398f77b811a2c5a