fix(ci): unbreak the documentation workflow

[RedStar071]

🔗 Linked issue

N/A — no tracking issue, found while investigating why the documentation GitHub Actions workflow was failing on every push to main.

🧭 Context

The documentation workflow (.github/workflows/documentation.yml) has been failing on every run. Digging into the CI logs turned up two separate, unrelated bugs:

1. typedoc@0.28.20's peer range tops out at typescript@6.0.x. This repo's root typescript was bumped to 7.0.2 in build: replace tsc with golar as typechecker, bump typescript to 7.0.2 #68 for the new golar native-typechecker migration, and typedoc crashes at import time reading its internal TS API against TS 7's experimental API surface (TypeError: Cannot read properties of undefined (reading 'PropertyDeclaration')). pnpm has no working mechanism to give a single devDependency (typedoc) its own nested/non-hoisted peer version distinct from the root's — I tried both pnpm.overrides and packageExtensions in pnpm-workspace.yaml and neither actually isolates a peer dependency edge, they only rewrite the recorded constraint text in the lockfile while still resolving to whatever's hoisted at the root.
2. Independently, typedoc.json's packageOptions.entryPoints only listed src/index.ts. Every package here also has a src/register.ts, and in plugin-i18next that file is the only place that actually imports @wolfstar/http-framework — index.ts only has a declare module "@wolfstar/http-framework" { ... } augmentation with no real import establishing that module in typedoc's isolated per-package program, so typedoc couldn't resolve the module being augmented. This bug predates the typescript 7.0.2 bump — confirmed the documentation workflow was already failing this same way as far back as August 30 — the TS 7 crash just happened to run first and mask it afterwards.

📚 Description

• Added scripts/generate-docs.mjs, which installs typedoc@0.28.20 + a compatible typescript@^5.9.3 into a throwaway npm-managed directory (via mkdtempSync) and runs typedoc's binary from there. This works because Node resolves require("typescript") from typedoc's own install location in that throwaway directory, while TypeScript's own module resolution still walks up from the real source files being analyzed (which live in this repo), so workspace-linked packages and @types/node resolve normally against the real node_modules. Verified this locally against the real repo before committing to the approach — a plain pnpm dlx typedoc does not work here, since it can't see the real project's node_modules for @types/node/workspace packages.
• Rewired package.json's docs script and .github/workflows/documentation.yml's docgen-command to go through the new script instead of invoking typedoc directly.
• Added src/register.ts to typedoc.json's packageOptions.entryPoints alongside src/index.ts, fixing the module-augmentation resolution error.
• Updated the pnpm run docs description in AGENTS.md to match.

Ran both pnpm run docs and the exact CI invocation locally — both now exit 0 with Found 0 errors and 68 warnings (pre-existing @link resolution warnings, unrelated to this fix) and produce the expected api/ HTML output and docs-output/api.json.

Key changes

File	Change
scripts/generate-docs.mjs	New: runs typedoc against an isolated, compatible typescript
package.json	docs script now delegates to the new wrapper script
.github/workflows/documentation.yml	docgen-command now delegates to the new wrapper script
typedoc.json	Add src/register.ts to packageOptions.entryPoints
AGENTS.md	Update the pnpm run docs description

Not in scope: the release workflow is also currently failing, but that's a separate, pre-existing issue — @wolfstar/plugin-api and @wolfstar/plugin-subcommands-advanced 404 on every OIDC trusted-publish attempt since #77 removed the static npm token fallback, while @wolfstar/plugin-i18next publishes fine every time. That looks like an npm Trusted Publisher misconfiguration for those two packages specifically (not the intermittent multi-package OIDC race documented in .changeset/README.md), and needs an npm org/package owner to check npmjs.com settings — it isn't fixable from this repo.

Type of Change

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation change
• Workflow / CI change

Pre-flight Checklist

• I have read the Contributing Guidelines (if applicable)
• My code follows the code style of this project
• I have added tests that prove my fix is effective or that my feature works — N/A, CI/tooling fix with no testable application logic; verified manually by running the generated command locally
• New and existing unit tests pass locally with my changes — not applicable, no source code touched
• I have updated the documentation accordingly (AGENTS.md)
• I added a changeset — not needed, no package version bump involved

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/@wolfstar/plugin-api@79

pnpm add https://pkg.pr.new/@wolfstar/plugin-i18next@79

pnpm add https://pkg.pr.new/@wolfstar/plugin-logger@79

pnpm add https://pkg.pr.new/@wolfstar/plugin-subcommands-advanced@79

commit: b083ede