bug(plugin-workers): built-in `workers-plugin-health-check` job entrypoint not resolvable under the thin-plugin surface (Module not found)

[rickylabs]

Summary

The @netscript/plugin-workers plugin registers a built-in cron job workers-plugin-health-check whose entrypoint is resolved to a local source path in the consuming app — <projectRoot>/plugins/workers/jobs/health-check.ts — which does not exist under the current thin-plugin surface (#172 / #191: "no plugin-source copy"). When the job actually runs, the worker fails with Module not found.

Repro / evidence (eis-chat, observed on @netscript/plugin-workers@0.0.1-alpha.19; the resolution model is unchanged in beta.1)

Triggering the job via the workers-api (POST /api/v1/workers/jobs/workers-plugin-health-check/trigger) → the workers processor logs:

[Worker …] Processing job 'workers-plugin-health-check' (trigger: api)
[Worker …] Resolving entrypoint for job 'workers-plugin-health-check': source=plugin, entrypoint=./plugins/workers/jobs/health-check.ts, projectRoot=C:\…\eis-chat
[Worker …] Plugin job resolved to: C:\…\eis-chat/plugins/workers/jobs/health-check.ts
[Worker …] Job 'workers-plugin-health-check' failed: Module not found "file:///…/plugins/workers/jobs/health-check.ts".

There is no plugins/workers/jobs/health-check.ts in the consuming app — the thin-plugin model does not copy plugin source into the project, so the plugin's OWN built-in job entrypoint is unresolvable.

Why it surfaced only now

In eis-chat this was latent: a separate split-brain per-process Deno KV meant the health-check job was enqueued but never delivered cross-process, so its entrypoint was never resolved. After fixing the queue to deliver cross-process (shared Garnet backend — see rickylabs/eis-chat #135 / netscript #372), the job is delivered and executed, and the missing entrypoint fails immediately. So this is a real, previously-masked defect, not eis-chat-specific.

Root cause

The plugin's built-in job registration resolves source=plugin entrypoints against a ./plugins/<name>/jobs/*.ts project-local path that assumes the pre-thin-surface source-copy model. Under the thin surface the plugin ships only its published JSR package, so that path never exists.

Suggested fix (any of)

1. Resolve source=plugin built-in job entrypoints from the published JSR package (jsr:@netscript/plugin-workers/.../jobs/health-check.ts) rather than a project-local ./plugins/… path.
2. Or register the built-in health-check job with an inline/embedded handler (no external module to resolve).
3. Or, if plugins are meant to contribute job source, have netscript generate/plugin scaffolding vendor the built-in job files the plugin registers.

Whichever is chosen, the invariant to restore: a plugin's own built-in jobs must be resolvable in a consuming app without hand-copying plugin source. Related architecture: #172, #191 (thin plugin surface).