refactor(plugins): delete the never-provided ctx.devJobs surface (epic #470 C2a)

[Weegy]

Deletes a published plugin surface that no code has ever provided. Ratchet 3,303 → 3,220 (−83).

What was dead

ctx.devJobs resolves its host service lazily, per call — and provide('devJobs', …) exists nowhere in middleware/src. So every invocation throws dev-platform host service unavailable. Verified: zero permissions.devJobs declarations in this repo, in omadia-byte5-plugins (six production private plugins), or in any sibling repo. No consumer has ever existed.

Five layers were independently missing: no provider, no grant writer (DevRepoPluginGrantStore was never constructed, so dev_repo_plugin_grants had no writer at all), no grant API, no consent surface, no consumer.

Deleted

PluginContext.devJobs + the six DevJob* types from @omadia/plugin-api · the permissions.devJobs gate, DevJobsHostService and createPluginDevJobsAccessor from platform/pluginContext.ts · the manifest parse and its two summary fields · the dev_jobs / dev_jobs_repos_hint admin DTO fields · devRepoPluginGrantStore.ts (whole file) · pluginDevJobsAccessor.test.ts (whole file).

Types moved to a local src/devplatform/devJobTypes.ts — not a new published package — so they travel with the tree at P4. src/devplatform/types.ts already owned DevJobKind/DevJobStatus as as const unions backing the runtime validators, so the new file re-exports rather than redefines. DevJobCreateRequest had no surviving consumer and was dropped outright.

devJobsHostService.ts survives and shrinks — 163 → 113 lines, deps six → one. chatDevJobService calls exactly getJob, listJobs, listJobEvents; everything else was plugin-only and the chat surface was already faking it (it passed async () => [] for grants and a finalize that unconditionally threw — which is itself the proof those paths were never live).

Migrations 0024/0025 kept and annotated as knowingly orphaned. Forward-only repo.

Scope

Pure deletion. No package manifest, no serviceRegistry.ts, no builder codegen, no permission gate added to ctx.services.

That is deliberate. A previous attempt bundled this with a capability gate on services.get and was rejected: three private byte5 integration plugins call ctx.services.provide() while declaring provides: [], so they would have failed to activate outright — and channel-teams resolves graphTenantId with a ?? 'default' fallback, so a silently-undefined get would have written graph data under the wrong tenant id. Data corruption, not an outage.

The gate is still needed, and it remains a real hole — but it is not a prerequisite for this deletion. Both ctx.devJobs and ctx.services.get('devJobs') already yield nothing today, so removing the accessor opens no path that was not already open. The gate becomes a prerequisite before the extracted plugin registers devJobs (P4), and it needs a compat path for out-of-repo plugins.

Backward compatibility

A manifest still declaring permissions.devJobs installs and activates cleanly with ctx.devJobs === undefined. Unknown manifest keys being ignored was implicit — nothing stated it — so manifestDevJobsLegacyKey.test.ts now asserts it explicitly, in both the true and { repos_hint: [...] } forms, so a future strict-validation change cannot silently start rejecting stale manifests.

Test plan

• 5,290 pass / 0 fail; npx tsc --noEmit clean; workspace typecheck (31 packages) exit 0; build exit 0
• Ratchet 3,303 → 3,220; four zones fell, none rose
• Chat path proven green: devJobOrchestratorTool.test.ts (19 tests incl. the authorization suite), chatDevJobToolWiring.test.ts, chatDevJobService.pg.test.ts
• Verified no manifest, no serviceRegistry.ts, no codegen touched — every installed plugin resolves exactly what it resolved before
• web-ui/app/_lib/storeTypes.ts needed no change: its PluginPermissionsSummary never mirrored dev_jobs (nor mcp), which independently corroborates the "no consent surface" finding

Two intermittent full-suite failures were investigated rather than assumed: different tests each run, both green in isolation, and a stash-rebuild-baseline run was clean — the documented load-sensitivity, not this change.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}