Add Tasks Planner settings and field mapping controls #113

New issue

Closed

opened 2026-05-27 09:14:09 +00:00 by steve · 0 comments

steve commented

2026-05-27 09:14:09 +00:00

Owner

Add user-facing settings for the planner workflow after the core planner metadata and UI prove stable.

Problem

Planner metadata should remain mapped and configurable like the rest of the Tasks schema, but adding settings too early would lock in fields and grouping options before the workflow is validated.

Goal

Expose minimal planner settings and mapped field controls once the planner model, view, and scheduling actions exist.

Scope

Add planner settings such as default open view, due-today behavior, Today grouping, week start, and Someday review threshold.
Expose mapped field roles for planner metadata such as when, areas, order fields, and reviewed as they ship.
Keep default behavior opinionated and compatible with existing task settings.
Add settings persistence tests and settings-tab coverage where practical.
Document settings defaults in the Tasks spec.

Non-goals

No large settings redesign.
No declarative app-configuration migration unless required by surrounding Tasks settings work.
No NLP or calendar-provider settings.

Acceptance Criteria

Planner settings persist through plugin data and survive reload.
Existing Tasks settings continue to load when planner settings are absent.
Field mapping controls do not break existing custom field mappings.
The planner reacts to relevant settings changes after save/rebuild.
Defaults keep due dates and scheduled dates semantically distinct.

Implementation Notes

The current settings tab does not expose generic field mapping controls; decide whether to add planner-specific controls or a broader field-mapping section.
Ensure mergeTasksSettings() handles older saved settings without planner keys.
Avoid expanding the first planner UI slice with too many settings.

Suggested Files or Specs To Inspect

packages/plugins/plugin-tasks/src/core/settings.ts
packages/plugins/plugin-tasks/src/core/settings-tab.ts
packages/plugins/plugin-tasks/src/core/settings.test.ts
packages/plugins/plugin-tasks/src/planner/
spec/src/30-cross-package-contracts/configuration-and-settings.md
spec/src/20-packages/plugins/tasks/index.md

Validation Commands

pnpm --filter @lapis-notes/tasks test
pnpm --filter @lapis-notes/tasks check
make spec-lint
pnpm test:smoke

Follow-up Tasks

TASK-PLUGIN-063

Implementation Summary

Added planner settings for default planner behavior, review thresholds, and mapped field controls for planner metadata.

Add user-facing settings for the planner workflow after the core planner metadata and UI prove stable. ## Problem Planner metadata should remain mapped and configurable like the rest of the Tasks schema, but adding settings too early would lock in fields and grouping options before the workflow is validated. ## Goal Expose minimal planner settings and mapped field controls once the planner model, view, and scheduling actions exist. ## Scope - Add planner settings such as default open view, due-today behavior, Today grouping, week start, and Someday review threshold. - Expose mapped field roles for planner metadata such as `when`, `areas`, order fields, and `reviewed` as they ship. - Keep default behavior opinionated and compatible with existing task settings. - Add settings persistence tests and settings-tab coverage where practical. - Document settings defaults in the Tasks spec. ## Non-goals - No large settings redesign. - No declarative app-configuration migration unless required by surrounding Tasks settings work. - No NLP or calendar-provider settings. ## Acceptance Criteria - Planner settings persist through plugin data and survive reload. - Existing Tasks settings continue to load when planner settings are absent. - Field mapping controls do not break existing custom field mappings. - The planner reacts to relevant settings changes after save/rebuild. - Defaults keep due dates and scheduled dates semantically distinct. ## Implementation Notes - The current settings tab does not expose generic field mapping controls; decide whether to add planner-specific controls or a broader field-mapping section. - Ensure `mergeTasksSettings()` handles older saved settings without planner keys. - Avoid expanding the first planner UI slice with too many settings. ## Suggested Files or Specs To Inspect - `packages/plugins/plugin-tasks/src/core/settings.ts` - `packages/plugins/plugin-tasks/src/core/settings-tab.ts` - `packages/plugins/plugin-tasks/src/core/settings.test.ts` - `packages/plugins/plugin-tasks/src/planner/` - `spec/src/30-cross-package-contracts/configuration-and-settings.md` - `spec/src/20-packages/plugins/tasks/index.md` ## Validation Commands - `pnpm --filter @lapis-notes/tasks test` - `pnpm --filter @lapis-notes/tasks check` - `make spec-lint` - `pnpm test:smoke` ## Follow-up Tasks - TASK-PLUGIN-063 ## Implementation Summary Added planner settings for default planner behavior, review thresholds, and mapped field controls for planner metadata.

steve

2026-05-27 09:14:09 +00:00