docs(plugins): internal codenames "Group F" and "T1" are in published JSDoc, so they render on JSR and now on the docs site

[rickylabs]

Summary

packages/plugin-triggers-core describes its public types with the internal workstream codenames
"Group F" and "T1" in JSDoc. That JSDoc renders on JSR, and it has now propagated to the
documentation site, because a reference page written faithfully against deno doc reproduces
whatever the JSDoc says.

A consumer reading @netscript/plugin-triggers-core is told a type is "known by the Group F public
surface". Nothing published explains what Group F is, because it is an internal planning name.

Evidence

Verified at cd24e1679:

packages/plugin-triggers-core/src/domain/constants.ts:4
  /** Trigger kinds implemented by the Group F T1 runtime. */
packages/plugin-triggers-core/src/domain/constants.ts:18
  /** Canonical trigger kinds known by Group F. */
packages/plugin-triggers-core/src/domain/constants.ts:41
  /** Default durability tier for Group F trigger definitions. */
packages/plugin-triggers-core/src/domain/constants.ts:98
  /** Trigger kind implemented by the Group F T1 runtime. */
packages/plugin-triggers-core/src/domain/trigger-definition.ts:126
  /** Trigger definitions implemented by the Group F runtime. */

Propagated into the new reference page (docs/site/reference/plugin-triggers-core/index.md, PR
#1541), which mirrors the verified deno doc surface:

• :89 — "Trigger definitions known by the Group F public surface."
• :93 — "Canonical trigger kinds known by Group F."
• :107 — "Payload union for known Group F trigger kinds."
• :146 — "T1 trigger processor with idempotency, retry, concurrency, DLQ, and circuit breaker
  handling."

Why it matters

This is the third instance of the same class found in milestone 0.0.6, all in published JSDoc:

• fix(sdk): JSDoc example still imports the removed ./api-clients.ts module, rendering on JSR #1425 — a JSDoc example importing a module the golden path removed.
• test(docs): nothing compiles JSDoc @example blocks, so a published JSR reference can import a module that does not exist #1533 — nothing in the repo compiles JSDoc examples, which is how fix(sdk): JSDoc example still imports the removed ./api-clients.ts module, rendering on JSR #1425 survived.
• this issue — internal vocabulary in JSDoc prose, invisible to every existing gate.

deno doc --lint checks that JSDoc exists and flags private type references; nothing checks what
it says. The documentation lane's audit gate does scan changed lines for internal wording, but it
scans docs/site, not packages/** source comments — which is why a docs pass caught this only
after the words had already been copied onto a public page.

The docs-side symptom is fixable by rewording the page, but that would make the page disagree with
deno doc, which is the authority the reference pages are written against. The fix belongs in the
source.

Scope

• Replace "Group F" and "T1" in packages/plugin-triggers-core/** JSDoc with language a consumer can
  act on — what the type is, not which internal workstream produced it.
• Sweep the rest of the publish set for the same class: internal workstream names, wave/epic
  codenames, and issue numbers in published JSDoc.
• Consider extending the internal-wording scan to packages/**/plugins/** JSDoc, not only
  docs/site changed lines. Without that, the next codename reaches JSR the same way.

Boundaries

• test(docs): nothing compiles JSDoc @example blocks, so a published JSR reference can import a module that does not exist #1533 owns compiling JSDoc @example blocks. This is prose content, not compilation — related
  class, different check.
• docs(reference): publish-readiness paths still disagree with the plugin-core reference IA, and public README drift remains #1377 / PR docs(reference): reference IA completeness, README truth, and CLI verb coverage #1541 owns the reference page, which correctly mirrors the current JSDoc. It should
  not be edited to diverge from deno doc; it will follow once the source is fixed.
• Not a goal: renaming types, or changing any runtime behaviour.

Acceptance criteria

• No occurrence of "Group F" or "T1" in any published JSDoc under packages/**/plugins/**.
• A repo-wide sweep records how many internal-codename occurrences were found and fixed, across
  the whole publish set rather than one package.
• docs/site/reference/plugin-triggers-core/index.md matches the corrected deno doc output.
• Negative test: reintroducing an internal codename into published JSDoc fails a check.

Provenance

Found by the docs_polish lane of the 0.0.6 documentation lane while reviewing PR #1541, and
returned as a doubt rather than edited — correctly, since the page mirrors the source. Confirmed
against packages/plugin-triggers-core/src/** by the orchestrator.

[rickylabs]

Absorbed into the 0.0.6 documentation lane

This issue is now owned by the 0.0.6 docs topical orchestrator, alongside #1374, #1377, #1425 and
#1531. It ships as PR-E, docs/1554-jsdoc-internal-codenames, carrying Closes #1554.

Sequencing

Blocked on PR #1541 merging. The page this issue must realign —
docs/site/reference/plugin-triggers-core/index.md — does not exist yet; PR #1541 creates it. It is
also the reason the codenames became visible on the docs site: a reference page written faithfully
against deno doc reproduces whatever the JSDoc says, so the source defect propagated the moment the
page was authored.

Runs parallel with the #1377 gate PR once unblocked — the file sets are disjoint (that PR touches
.llm/tools/release/** and the reference index; this one touches packages/plugin-*/** JSDoc and one
reference page), and this issue is unaffected by that PR's path-convention decision, which concerns
the four short-named deployable-plugin directories. plugin-triggers-core is already name-exact.

Scope note — the sweep is repo-wide, not one package

The acceptance asks for a census across the whole publish set, not just
packages/plugin-triggers-core where the codenames were found. Internal workstream names, wave/epic
codenames, and issue numbers in published JSDoc are the same class; "Group F" and "T1" are the
instance that happened to be caught.

The page is deliberately not being edited first

docs/site/reference/plugin-triggers-core/index.md currently reproduces "Group F" and "T1" because
it correctly mirrors deno doc. Rewording the page ahead of the source would make it disagree with
its own stated authority — the reference index says pages are written against deno doc, and PR
#1541's whole contribution was making that claim honest. The source is fixed first; the page follows.

Why this keeps happening on this surface

Third instance of the same class in this milestone, all in published JSDoc: #1425 (an example
importing a module the golden path removed), #1533 (nothing compiles JSDoc examples, which is
how #1425 survived), and this one (internal vocabulary in JSDoc prose). deno doc --lint checks
that JSDoc exists and flags private type references; nothing checks what it says. The docs audit's
internal-wording scan does catch this class — but it scans docs/site, not packages/** source
comments, which is why a docs pass found it only after the words had already been copied onto a
public page.

Extending that scan to published JSDoc is in this issue's scope and is the part that stops the next
one.