fix(tui): derive required setup fields from schema

[w-up]

Summary

Derive first-run required-field checks from the TUI schema instead of hardcoding LLM provider paths in hasRequiredFields.

Background

src/cli/tui/state/required-fields.ts duplicated setup rules for llmProvider and llmApiKey. This made the entry-routing logic drift-prone and left the schema unable to express unconditional or conditional requirements.

Changes

• Add FieldDef.required as either a boolean or a predicate over Ctx.
• Mark llmProvider as always required and llmApiKey as required only for providers other than Ollama.
• Derive active required fields from CATALOG, ignoring fields hidden in the current schema context.
• Validate strings, numbers, toggles, and multiselect values according to their field kind.
• Recognize persisted <settingsPath>KeyLocation secret references without reading secret values.
• Preserve compatibility with the legacy provider block only for a matching llmApiKey provider.
• Add unit and entry-routing coverage for unconditional, conditional, hidden, keyless, secret-reference, legacy-provider, and empty-value cases.

Verification

• npm test -- --run tests/unit/cli/tui/state/required-fields.test.ts tests/unit/cli/tui/schema/llm.test.ts tests/unit/cli/tui/entry-required-fields.test.ts — 34 tests passed.
• npm run lint — passed.
• npm run build — passed.
• git diff --check — passed.
• Independent review — passed after tightening legacy provider matching.
• env -u NODE_ENV npm test — 8,361 tests passed; 18 unrelated environment/timing failures remained in browser teardown, REPL readline, daemon health, REST timeout, and packaged-binary suites.

Fixes #257

Summary by CodeRabbit

• New Features

  • LLM provider selection is now required.
  • API keys are required for supported providers and optional for Ollama.
  • Required settings are validated based on field visibility, type, and configuration.

• Bug Fixes

  • Improved detection of completed settings, including stored-secret references and legacy provider configurations.
  • Enhanced automatic routing for configurations using stored secrets.
  • Improved validation across text, list, number, and toggle settings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: f05e41e4-5d08-43c7-b1be-f4d24e4d4c3c

📥 Commits

Reviewing files that changed from the base of the PR and between 9e07bdd and cdf9d81.

📒 Files selected for processing (2)

• src/cli/tui/state/required-fields.ts
• tests/unit/cli/tui/state/required-fields.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• tests/unit/cli/tui/state/required-fields.test.ts

---

📝 Walkthrough

Walkthrough

The TUI schema now defines required fields and provider-dependent API-key requirements. hasRequiredFields validates persisted configuration from the schema, including typed values, visibility, secret references, and legacy provider settings. Tests cover schema validation and home routing.

Changes

Required field validation

Layer / File(s)	Summary
Schema requiredness contract src/cli/tui/schema/types.ts, src/cli/tui/schema/llm.ts, tests/unit/cli/tui/schema/llm.test.ts	FieldDef supports static or context-dependent requiredness. The LLM provider is always required. The API key is required for non-Ollama providers.
Schema-driven completion checks src/cli/tui/state/required-fields.ts	hasRequiredFields derives active required fields from the catalog and validates typed values, secret references, and legacy provider key locations.
Completion and routing coverage tests/unit/cli/tui/state/required-fields.test.ts, tests/unit/cli/tui/entry-required-fields.test.ts	Tests cover conditional and hidden fields, missing values, secret references, provider matching, and home routing.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant PersistedConfig
  participant hasRequiredFields
  participant CATALOG
  PersistedConfig->>hasRequiredFields: provide persisted configuration
  hasRequiredFields->>CATALOG: collect active required fields
  CATALOG-->>hasRequiredFields: return field definitions
  hasRequiredFields-->>PersistedConfig: return completion status

Loading

Suggested reviewers: knockoutez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 11.11% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: deriving TUI required setup fields from the schema.
Linked Issues check	✅ Passed	The changes satisfy #257 by adding schema metadata and validating visible, conditional, secret-backed, legacy, and typed required fields.
Out of Scope Changes check	✅ Passed	All production and test changes support schema-derived required-field validation and provider setup behavior required by #257.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/cli/tui/state/required-fields.ts`:
- Around line 47-51: Update the legacy key-location check in the required-field
predicate to use hasCompleteValue instead of only checking string type and
length, so whitespace-only values are rejected consistently with regular
secret-location references. Add a regression test covering
config.provider.keyLocation set to whitespace.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: dca11e68-1c66-4044-8dd4-f384bb20999c

📥 Commits

Reviewing files that changed from the base of the PR and between b3ccf92 and 9e07bdd.

📒 Files selected for processing (6)

• src/cli/tui/schema/llm.ts
• src/cli/tui/schema/types.ts
• src/cli/tui/state/required-fields.ts
• tests/unit/cli/tui/entry-required-fields.test.ts
• tests/unit/cli/tui/schema/llm.test.ts
• tests/unit/cli/tui/state/required-fields.test.ts

[w-up]

CI follow-up: all lint/build/unit jobs, CodeRabbit, and every clean-machine smoke job passed on commit cdf9d81a. The only failure is the unrelated REST research integration assertion in tests/integration/rest-tools.test.ts:153: the response did not include brief (8,379 other tests passed). The first CI run on the parent commit passed this same full-suite job, and the follow-up changes only validate whitespace in a TUI key-location reference. I attempted to rerun the failed job, but GitHub requires repository admin permission.

[KnockOutEZ]

Hi @w-up — thank you for this PR, and I'm sorry it's been sitting here without a proper review.

I've been heads-down building some pretty big features and improvements for wigolo, and as a solo dev, shipping that while also reviewing and maintaining every issue and PR has been genuinely hard. This one isn't forgotten — it just hasn't had the attention it deserves yet.

I'd really appreciate your patience here. I'm going to work through the open PRs and issues properly over the next few weeks (sooner if I can free up), and I'll follow up right here.

In the meantime, the wigolo Discord is open if you'd like to follow what's being built, ask questions, or nudge me directly: https://discord.gg/BkUUgz2bNF

Thanks again for contributing, and for understanding — it genuinely means a lot. 🙏