feat: job registry — scalable job architecture

[jonit-dev]

Closes #75

Summary

• Adds a central JOB_REGISTRY (in packages/core/src/jobs/job-registry.ts) as the single source of truth for all job metadata — adding a new job now requires touching only 2-3 files instead of 15+
• Config normalization (config-normalize.ts) and env overrides (config-env.ts) now use generic registry loops instead of per-job if/else blocks for qa/audit/analytics
• Web-side WEB_JOB_REGISTRY (web/utils/jobs.ts) provides UI metadata (triggerEndpoint, getEnabled, getSchedule, buildEnabledPatch) consumed by Scheduling page and Zustand store
• Scheduling.tsx handleJobToggle and handleTriggerJob now registry-driven (no more triggerMap / if/else chains)
• Server action.routes.ts generates qa/audit/analytics/planner routes from registry loop

Test plan

• All 693 core tests pass (yarn workspace @night-watch/core test --run)
• yarn verify passes clean across all packages
• Web TypeScript passes (tsc --noEmit)
• New unit tests: packages/core/src/__tests__/jobs/job-registry.test.ts (normalizeJobConfig, buildJobEnvOverrides, camelToUpperSnake, migrateLegacy for all 6 jobs)
• Existing config-normalize tests still pass unchanged
• Legacy config formats (flat executor/reviewer fields, nested qa/audit/analytics) still normalized correctly

🤖 Generated with Claude Code

[jonit-dev]

🤖 Implemented by claude claude-sonnet-4-6 (fallback)

[github-actions]

DiffGuard AI Analysis

AI Review Summary

🏆 Overall Score: 88/100

This PR introduces a well-designed Job Registry pattern that centralizes job metadata, defaults, and configuration logic into a single source of truth. The implementation is clean, thoroughly tested, and maintains backward compatibility.

✅ Key Strengths

• Architectural Improvement: The registry pattern (JOB_REGISTRY) successfully consolidates scattered job metadata, eliminating duplication across constants, config normalization, and env handling. Adding new job types now requires only a single registry entry.
• Comprehensive Test Coverage: The new job-registry.test.ts (450+ lines) thoroughly covers registry lookups, config normalization, env overrides, legacy migration, and derived constants—demonstrating excellent testing discipline.
• Backward Compatibility: Legacy config migration (migrateLegacy functions) ensures smooth upgrades from older config formats without breaking existing deployments.

⚠️ Areas for Improvement

• Type Safety: The normalizeJobConfig function returns Record<string, unknown>, which loses type information. Consider using generics to preserve the config type: normalizeJobConfig<T extends IBaseJobConfig>(raw: Record<string, unknown>, jobDef: IJobDefinition<T>): T.
• Registry Duplication: The web frontend maintains a separate WEB_JOB_REGISTRY that duplicates some metadata from the core registry. Consider generating this from the core registry or creating a shared definition to ensure consistency.

🔚 Conclusion
This is a high-quality refactoring that significantly improves code maintainability. The registry pattern is well-implemented with excellent test coverage. Addressing the minor type safety concern would elevate this to exceptional quality. Ready to merge.

---

Analyzed using z-ai/glm-5

[github-actions]

DiffGuard AI Analysis

AI Review Summary

🏆 Overall Score: 82/100

This PR introduces a well-architected Job Registry pattern that centralizes job metadata, defaults, and configuration handling. The implementation significantly improves maintainability and extensibility, though there are some integration gaps and minor code quality issues.

---

✅ Key Strengths

• Architectural Improvement: The Job Registry pattern provides a single source of truth for job metadata, eliminating scattered job definitions across constants, config files, and frontend code. Adding new job types now only requires a single registry entry.

• Comprehensive Test Coverage: The new job-registry.test.ts provides thorough coverage of all registry functions, normalization logic, and environment variable overrides (~450 lines of well-structured tests).

• Code Deduplication: Successfully reduced repetitive config handling code in config-normalize.ts and config-env.ts by replacing 100+ lines of job-specific logic with a registry-driven loop.

---

⚠️ Areas for Improvement

• Unused Migration Logic: The migrateLegacy functions are defined in the registry and thoroughly tested, but are never called in the actual code flow. This is dead code that should either be integrated or removed. If intended for future use, add a TODO comment explaining the integration plan.

• Registry Duplication: Two separate registries exist (JOB_REGISTRY in core and WEB_JOB_REGISTRY in web frontend) with overlapping data. Consider deriving the web registry from the core registry via API or shared types to prevent drift.

---

🐛 Bugs Found

Bug Name	Affected Files	Description	Confidence
Unused migrateLegacy	packages/core/src/jobs/job-registry.ts	The migrateLegacy functions are defined on each job definition but are never invoked during config normalization or environment processing. Tests exist but the integration is missing.	High 🟢
Hardcoded endpoint mapping	web/api.ts	The triggerJob function contains a hardcoded endpointMap that duplicates data already in WEB_JOB_REGISTRY.triggerEndpoint. This will cause inconsistencies if registries drift.	Medium 🟡

---

📋 Issues Found

Issue Type	Issue Name	Affected Components	Description	Impact/Severity
Code Quality	Type safety compromises	config-normalize.ts, config-env.ts, job-registry.ts	Multiple uses of any type casting with eslint-disable comments to bypass TypeScript checks. While pragmatic, this reduces type safety.	Low
Testing	Missing integration tests	config-normalize.test.ts	The test file adds registry-driven config tests but doesn't verify that legacy flat configs (e.g., executorEnabled, cronSchedule) are properly migrated via the registry.	Medium
Maintainability	Inconsistent job naming	job-registry.ts, WEB_JOB_REGISTRY	The 'slicer' job uses 'planner' as CLI command and display label, creating potential confusion. Documentation should clarify this mapping.	Low

---

🔚 Conclusion

This is a solid architectural refactor that will pay dividends in maintainability. The Job Registry pattern is well-implemented with excellent test coverage. Addressing the unused migrateLegacy functions (either by wiring them up or removing them) and consolidating the dual registries would bring this to production-ready quality. The PR is close to merge-ready but would benefit from these fixes first.

---

Analyzed using z-ai/glm-5