feat(backends): co-locate engine settings schemas with engines

[aaight]

Summary

• Moves CodexSettingsSchema definition from src/config/engineSettings.ts to src/backends/codex/settings.ts
• Moves OpenCodeSettingsSchema definition from src/config/engineSettings.ts to src/backends/opencode/settings.ts
• Replaces the hardcoded ENGINE_SETTINGS_SCHEMAS map with a dynamic Map registry in engineSettings.ts
• Adds optional getSettingsSchema?() method to the AgentEngine interface in types.ts
• Both CodexEngine and OpenCodeEngine implement getSettingsSchema() returning their local schema
• bootstrap.ts registers each engine's settings schema via registerEngineSettingsSchema() during registerBuiltInEngines()
• Re-exports CodexSettingsSchema/OpenCodeSettingsSchema and their types from engineSettings.ts for backward compatibility
• Updates schema.test.ts and projects.test.ts to call registerBuiltInEngines() in beforeAll

Test plan

• npm run typecheck passes (zero errors)
• npm run lint passes (zero errors)
• Engine settings validation tests pass (tests/unit/config/schema.test.ts, tests/unit/api/routers/projects.test.ts)
• Pre-existing unrelated test failures unchanged (postComment, github gadget tests)

Trello card: https://trello.com/c/SiKIeCHO/353-as-a-developer-i-want-engine-settings-co-located-with-engines-so-that-each-engine-owns-its-configuration-schema

🤖 Generated with Claude Code

🕵️ claude-code · claude-sonnet-4-6 · run details

[nhopeatall]

Summary

Clean refactoring that co-locates engine settings schemas with their engines and replaces a hardcoded lookup object with a dynamic registry. The change is well-structured, backward-compatible, CI is green, and the architecture direction (engines own their configuration) is sound.

Architecture & Design

The move from a static Record to a dynamic Map registry is the right pattern for an extensible engine system. The backward-compatibility re-exports from engineSettings.ts are thoughtful and prevent breaking downstream consumers.

Circular import note: The re-exports in engineSettings.ts create a circular dependency with backends/codex/settings.ts and backends/opencode/settings.ts (each re-exports from the other). This works correctly in ESM because both sides export standalone declarations that don't depend on each other at initialization time — the live bindings resolve before any code calls these functions. TypeScript and the test suite confirm this. However, if this backward-compat layer is ever removed, the circularity goes away cleanly.

Initialization ordering: The EngineSettingsSchema validation now depends on registerBuiltInEngines() having been called first. All current call sites (agent registry, API routers, tests) correctly ensure this. Worth keeping in mind for future consumers.

Minor Observations (non-blocking)

• getEngineSettingsSchema() is exported from engineSettings.ts but has zero call sites — it's dead code. If it's intended for future use by third-party engine plugins, a brief comment noting that would help. Otherwise it could be removed.
• The inline import('./types.js').AgentEngine type annotation in registerEngineWithSettings is unconventional — a top-level import type { AgentEngine } from './types.js' would be more idiomatic. Not a problem, just a style note.
• The engine-contract.test.ts already tests optional interface methods (resolveModel, beforeExecute, afterExecute) but doesn't cover getSettingsSchema. Adding a similar check would complete the contract surface.

🕵️ claude-code · claude-opus-4-6 · run details