Profile page: voice commands are editable in two places (one silently ignored), and candidate fields show for every user

[serge-ivo]

Corrected after reading the code. The first version of this issue claimed voice settings were hidden inside the Candidate Profile section and proposed creating a Preferences page. Both were wrong: /preferences already exists (store/console/src/pages/Preferences.tsx, routed in App.tsx:54, in the nav in Layout.tsx:22) and already carries Appearance, Voice and Translation. The real defect is narrower and worse — the same setting is editable in two places, and one of them silently loses.

1. Two UIs write the same global voice setting, and one of them is dead

Where	Writes	Read path
/preferences → VoiceFields (Preferences.tsx:110)	PUT /v1/preferences → users.preferences.voice	merged server-side by effectiveVoice (routes/instances.ts:522) into /v1/instances/:id/voice-settings
/profile → "Hands-free voice commands" (Profile.tsx:215-227)	PUT /v1/profile → voiceMuteWords / voiceRepeatWords / …	client-side fallback in config.ts:118-130, applied only when the effective value is empty

So the precedence is: per-instance override → account preferences → profile fields. A user who has ever set command words in Preferences will find that editing them on the Profile page does nothing — their input is written, stored, and then never read, because the Preferences value already won.

The Profile block is the legacy path from #129 ("move hands-free control words to the global user profile"), left behind when Preferences was built. It should be deleted, not restyled.

This is also why the section looks over-long: the bloat is misplaced content, not too many legitimate settings.

2. Apply-specific fields are shown to every user

The "Candidate Profile" section is gated on cpFields.length > 0 (Profile.tsx:190) — i.e. whether the profile schema returned any fields — rather than on whether the user actually runs an apply agent. A Coder-only or Repo-Chat-only user sees job-application PII fields (work authorisation, salary, target roles) they have no use for.

The correct pattern already exists in the codebase: SettingsTab.tsx:904 renders its candidate copy behind {isApply && …}, derived from the instance's capabilities.surfaces including 'apply'. Profile is user-level rather than instance-level, so it needs "does this user have ANY apply-surface instance" — available from /v1/instances/my/instances, which already returns resolved capabilities per instance.

3. The wording

Two user-visible "Candidate" strings remain (Profile.tsx:192 header, :229 button). Tracked separately as #174 as a ship-in-minutes copy fix; this issue subsumes it if done first.

Scope

1. Delete the voiceFields block from Profile.tsx (:215-227) and its state. Preferences is the single home for voice command words.
2. Apply-gate the remaining candidate fields on "user has an apply-surface instance", and rename the section to something honest ("Job application details").
3. Rename the header + save button (subsumes Profile page: rename 'Save Candidate Profile' button to 'Save Profile' #174).
4. Decide the fallback's fate. With the Profile UI gone, config.ts:118-130 still reads voiceMuteWords etc. from /v1/profile. Keep it as a read-only migration path for users whose words only exist there, or write a one-time migration into users.preferences.voice and delete it. Do not leave a writable orphan.

Tabs on Profile are not part of this. Once the voice block is gone and the candidate fields are gated, what remains is Account / Edit Profile / API Token / Billing / API Keys / Sign out — coherent and short enough to stay one page. Revisit only if it grows again.

Acceptance criteria

• Voice command words are editable in exactly ONE place (/preferences).
• No user-visible "Candidate" string on /profile.
• A user with no apply-surface instance sees no job-application fields on /profile.
• A user who previously saved command words via /v1/profile still has them take effect (migrated or read-fallback) — no silent loss on upgrade.
• SettingsTab.tsx:904 unchanged; it is already correctly gated.
• No mobile horizontal overflow at /profile or /preferences (Shared <Page> container to kill the missing-w-full horizontal-scroll class at the source #148/CI test: assert no mobile horizontal overflow across all console routes #149 hold).

Related

• Profile page: rename 'Save Candidate Profile' button to 'Save Profile' #174 — the copy fix; close as superseded if this ships first
• Voice: move hands-free control words to the global user profile #129 — created the profile-based control words this removes (closed)
• Voice: unmute command word — dictation-based wake-to-record with configurable keyword and start-recording signal #152 — needs an unmuteWords field; it belongs in Preferences, not Profile
• [docs] Update Coder docs for runner-node picker, engines, and package paths #211-in-code — the Layout.tsx:20 comment cites "[docs] Update Coder docs for runner-node picker, engines, and package paths #211" for the Preferences page, but [docs] Update Coder docs for runner-node picker, engines, and package paths #211 is a Coder docs issue. The reference is stale; fix the comment while nearby.

[serge-ivo]

Shipped — but note the commit it landed in: 5365774, whose message ("fix(behaviour): five bugs in yesterday's behaviour work") does not describe this work. A concurrent session staged the whole working tree and swept these four files in before I committed them. The code is correct and pushed; the history is just mislabelled, and I did not rewrite a pushed commit to fix that.

What shipped:

• The voice block is gone from Profile. Preferences → Voice is the single home. A pointer sits where the block was.
• The profile's voice* fields are KEPT server-side as a read fallback and marked deprecated, so a user whose words only ever existed there does not lose them — read path, no write path. Migrating them into users.preferences.voice and deleting the fallback is still open if you want it fully gone.
• workAuthorization and salaryExpectation moved to a new job group alongside the existing job preferences. The whole job block is gated on the user having an apply-surface instance, resolved from /v1/instances/my/instances — the same capability gate the instance UI uses, applied at user level. The gate fails closed: a failed lookup shows fewer fields rather than job PII to someone with no use for it.
• "Candidate Profile" → "Personal details"; "Save Candidate Profile" → "Save Profile" (subsumes Profile page: rename 'Save Candidate Profile' button to 'Save Profile' #174).
• SettingsTab.tsx:904 kept its apply gate, retitled to match the section it points at. Two stale "Profile → Hands-free voice commands" pointers now say Preferences → Voice.

Tabs were not added, per the reasoning in this issue: once the duplicate block was gone the page was no longer long enough to need them.

[serge-ivo]

Finished in 00cf6b0 — the fallback is now gone, not just the UI.

Migration 0075 promotes user_profile.custom.voice* into users.preferences.voice (the home the runtime actually reads, via effectiveVoice), only where the preferences side is unset so a winning Preferences value is never clobbered. Originals renamed to voice*Legacy, per 0071's precedent.

Two things the SQL had to get right, verified against real SQLite 3.50 across the five shapes that exist in prod ('' default, 0071's voice:null, a populated object, an empty array, no profile row):

• $.voice must be forced to an object first — 0071 leaves it as JSON null for anyone with nothing to promote, and json_set can't create a key under a null parent, so the writes would have been silent no-ops for exactly those users.
• The JSON-subtype trap 0071 documents does not apply: these are scalar strings, so json_set binds them as proper JSON strings and parseVoiceWords splits them. Re-running the whole migration is a no-op.

The client-side fallback in voice/config.ts is deleted (it was what made a second writable home possible, and cost a /v1/profile round-trip on every voice-config load), and the voice group is dropped from PROFILE_FIELDS so the API offers no second write path.

Verified live after deploy: /v1/profile returns groups identity | job | preferences and no voice fields; the words are in /v1/preferences.