fix: Pass SettingsService to spec generation so runtime uses persisted model

[mcbodge]

Previously the App Spec generation background task used the server defaults (for
example the opus → claude-opus-4-5-20251101 mapping) instead of the model selected in the
UI and persisted via the global settings API.

This change forwards the SettingsService into the App Spec /create handler so
generateSpec() reads the persisted phaseModels.specGenerationModel at runtime. Two files
were updated to pass the service through the route stack.

Related Issue

Closes #528 (and for users that are not using Claude also 585, because it was providing log-in request response instead of actual response)

Changes

• apps/server/src/routes/app-spec/index.ts — pass settingsService into the /create route factory.
• apps/server/src/routes/app-spec/routes/create.ts — accept and forward settingsService to generateSpec().
• Removed duplicated eventHooks keys that appeared twice in hydrateStoreFromSettings / buildSettingsUpdateFromStore within apps/ui/src/hooks/use-settings-migration.ts, causing test failure

These edits ensure the background spec generation resolves the user's chosen model (including
dynamic provider model strings such as Opencode) and logs the resolved
model via the existing logger.info('Using model:', model) statement.

Testing & Verification

I tested and verified the following:

1. Update the global settings to pick a non-default model (via the UI or API). Example API flow:

• Authenticate with the server (session cookie or API key)
• PUT /api/settings/global with phaseModels.specGenerationModel.model set to your desired model

2. Trigger App Spec generation from the UI (Create App Spec) or call the create route.

3. Tail the server logs and confirm to see a line similar to:

info: Using model: opencode/grok-code

4. Confirm the generated .automaker/app_spec.txt contains the expected structured spec output
   (XML/JSON per the generator expectations) and that the earlier error about missing structured
   output is resolved.

Notes

• This is a targeted fix to ensure runtime settings are consulted by the spec generator. It does
  not change the model resolution logic or provider routing; if a settings value references a
  provider/model string that does not exist on the server, the provider discovery and error
  handling will still apply (see GET /api/models/available).

Summary by CodeRabbit

• Refactor
  • Improved internal handler dependency management by propagating service dependencies through the configuration layer, enabling better resource sharing across the application stack.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[gemini-code-assist]

Summary of Changes

Hello @mcbodge, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue where the application specification generation process was not utilizing the user-configured model settings. By integrating the SettingsService into the spec generation route, the system now consistently respects and applies the user's chosen model, ensuring that generated specifications align with their preferences and resolving previously reported discrepancies.

Highlights

• Spec Generation Model Resolution: The App Spec generation background task now correctly uses the model selected by the user in the UI and persisted via the global settings API, instead of falling back to server defaults.
• SettingsService Integration: The SettingsService is now passed through the route stack to the /create handler, allowing generateSpec() to read the phaseModels.specGenerationModel at runtime.
• Bug Fixes: This change resolves issues Spec generation ignores user model settings and fails with non-Claude providers #528 and [Bug]: Spec generation fails #585, which were related to incorrect model usage and potential log-in request responses instead of actual model responses.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR injects an optional SettingsService into the app-spec create handler and passes it through to generateSpec; additionally, UI settings migration no longer reads or persists eventHooks.

Changes

Cohort / File(s)	Summary
App-spec route wiring apps/server/src/routes/app-spec/index.ts, apps/server/src/routes/app-spec/routes/create.ts	createCreateHandler signature updated to accept settingsService?: SettingsService; SettingsService type imported; route registration updated to pass settingsService; the handler forwards settingsService into generateSpec.
Settings migration (UI) apps/ui/src/hooks/use-settings-migration.ts	Removed reading and persisting of eventHooks during hydration and when building settings updates (no public API changes).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat: automaticly load claude.md files and settings json globally / per project #267 — Adds/adjusts SettingsService wiring through app-spec generation routes and generateSpec (highly related).
• docs: Add comprehensive JSDoc docstrings to settings module (80% cove… #189 — Introduces/exports SettingsService implementation/types used by the injection.

Suggested labels

Enhancement, Ready-To-Merge

Poem

🐰 I hopped along the handler trail,
A tiny service in my tail,
I passed a setting, soft and quick,
So specs align with each user's pick,
Hooray — new hops, no broken trail! 🥕✨

🚥 Pre-merge checks | ✅ 2 | ❌ 3

❌ Failed checks (3 warnings)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR addresses Bug 1 from issue #528 by passing settingsService to the /create endpoint and generateSpec, but does not address Bug 2 regarding structured output detection logic.	Apply the structured output fix by changing useStructuredOutput from !isCursorModel(model) to isClaudeModel(model) in generate-spec.ts to fully resolve issue #528.
Out of Scope Changes check	⚠️ Warning	The removal of eventHooks from use-settings-migration.ts appears unrelated to issue #528 objectives of passing SettingsService and fixing structured output detection.	Clarify the relationship between eventHooks removal and issue #528, or consider separating this change into a distinct PR to maintain scope clarity.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: passing SettingsService to spec generation to enable runtime use of persisted model settings.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request correctly passes the SettingsService to the /create app spec handler, ensuring that the spec generation process uses the user-configured model from settings instead of the default. The changes are straightforward, consistent with other route handlers, and effectively resolve the described issue. The implementation is clean and correct, and I have no further suggestions.

[mcbodge]

@webdevcody Hello, may I ask why this was closed? This way I can maybe try to create it again with the requested corrections for the new release branch. It's a bug fix to actually use the models defined in global settings instead of always use the default ones (se the related issues).

Kind regards