Preferences
Configure voice mode, deliverable formats, dispatch settings, and automation.
Settings that change the work
Preferences tell Pulse AI how the workspace wants work produced. They affect output format, narration, automation behavior, dispatch limits, platform targeting, and other closeout expectations.
Treat preferences as part of the work contract. If a setting changes what evidence is required, agents and reviewers need to account for it before calling a task complete.
Agent-facing preferences
Some preferences directly affect agent behavior:
- Voice settings determine when narration must be generated.
- Deliverable settings determine whether Markdown, HTML, presentations, or multiple formats are required.
- Dispatch settings define concurrency and workday behavior.
- Platform settings determine which editor or install target validation should use.
- Automation settings determine whether follow-ups, reviews, or summaries are expected.
When a preference is agent-facing, it should be read before output is produced. Skipping that step can make an otherwise good task fail closeout.
Runtime-only settings
Not every visible setting belongs in an agent prompt. Some settings are runtime UI choices or product behavior flags. Those should be respected by the app, but they should not be repeated into every task unless they change what the agent must do.
This distinction matters because prompts get noisy when runtime-only settings are treated like instructions. Use preferences only where they change the work, the validation, or the user-facing output.
Before closeout
Before marking preference-sensitive work complete, verify:
- The output format matches the configured deliverable requirements.
- Voice behavior matches the current voice toggles.
- Dispatch behavior respects the configured concurrency and workday mode.
- Installation or packaging proof targets the configured IDE.
- Any setting mentioned in public copy is visible or source-backed today.
If a task changes preference behavior, include proof from the relevant source, settings surface, or validation script. Do not rely on a summary that says the setting was handled.
Drift checks
Preference drift happens when the UI, .pulse/config/preferences.json, schema files, generated guidance, and runtime consumers stop agreeing.
When drift appears, compare the visible setting, the stored preference, and the code path that consumes it. Fix the source of truth first, then update docs and guidance.
Source of truth
The workspace preference file is .pulse/config/preferences.json. Schema and consumer checks should align with it. Public docs should describe the current user-facing contract, not internal assumptions or stale defaults.