kandev/docs/plans/standard-task-create-hidden-workflow-context/plan.md

spec, created, status

spec	created	status
docs/specs/workspaces/requirements/improve-kandev.md	2026-07-29	implemented

Implementation Plan: Standard Task Creation From Hidden Workflow Context

Overview

The task-detail boot payload correctly exposes the current task's hidden workflow so the task can render, but standard New Task entry points pass that context straight into the shared task-create dialog. The dialog treats it as an explicit selection, so a task created while viewing an Improve Kandev task can silently inherit the hidden Improve workflow.

Normalize the workflow context at the shared task-create boundary: ordinary task creation must discard a hidden contextual workflow and fall back to the workspace's visible workflows, while a feature wrapper with a locked workflow continues to preserve its explicit hidden workflow. Fetch the visible workflow's steps when the normalized fallback differs from the caller-provided context, then prove the behavior through unit and desktop/mobile E2E coverage.

Frontend

Shared workflow-context normalization

• Add a pure workflow-context resolver in apps/web/components/task-create-dialog-defaults.ts.
• When the caller-provided workflow is hidden and lockedFields.workflow !== true, clear the provided workflow and default step before initializing, resetting, or submitting the dialog. This lets the existing visible-only single-workflow fallback choose the workspace's Kanban workflow.
• Preserve visible workflows and preserve explicitly locked hidden workflows, including the Improve Kandev wrapper.
• Apply the normalized workflow/default-step context consistently in apps/web/components/task-create-dialog.tsx; do not change the task-detail boot state because it still needs the hidden workflow to render the task.

Fallback step loading

• Extend the workflow-step effect in apps/web/components/task-create-dialog-effects.ts to load steps for the computed effective workflow when it differs from the normalized caller-provided workflow.
• Update the default-step resolver in apps/web/components/task-create-dialog-defaults.ts so fetched steps for the effective fallback supply its start/first step. Do not reuse the hidden workflow's step ID.
• Keep the existing explicit workflow-switch behavior unchanged.

Mobile design contract

• Desktop entry point remains the app-sidebar New Task action.
• Mobile entry point remains the New action in apps/web/components/task/mobile/session-task-switcher-sheet.tsx, the nearest shipped mobile exemplar.
• The existing task drawer, task-create dialog, hierarchy, scroll ownership, safe-area behavior, and touch targets do not change. Desktop and mobile share the same workflow normalization and step-loading logic.
• Mobile Playwright coverage creates a task from the existing task drawer while viewing a hidden-workflow task and verifies the visible workflow receives it.

Tests

• What: an unlocked hidden contextual workflow is removed, while a locked hidden workflow and an ordinary visible workflow are preserved. File: apps/web/components/task-create-dialog-defaults.test.ts. How: table-driven pure-function tests.
• What: a visible fallback workflow that differs from the provided context fetches its steps and resolves the visible start step. Files: apps/web/components/task-create-dialog-effects.test.ts and apps/web/components/task-create-dialog-defaults.test.ts. How: focused hook and pure-function tests that fail against the current selected-workflow-only loading rule.

E2E Tests

• Scenario: GIVEN a task in a hidden workflow, WHEN the user opens the desktop sidebar New Task dialog and creates a task, THEN the created task's workflow step belongs to the visible Kanban workflow. File: apps/web/e2e/tests/task/create-task.spec.ts. What to verify: seed a hidden workflow and task, navigate directly to the task, create without an agent through the sidebar, and query the created task to compare workflow_step_id with the visible workflow's start step.
• Scenario: GIVEN the same hidden task on a phone viewport, WHEN the user opens the mobile task drawer, taps New, and creates a task, THEN the task uses the visible workflow. File: apps/web/e2e/tests/task/mobile-hidden-workflow-task-create.spec.ts. What to verify: drive the existing drawer and dialog with touch-oriented interactions, then assert the created task's workflow step and absence of document horizontal overflow.

Implementation Task

• task-01-normalize-task-create-workflow — done

The task performs unit and desktop/mobile E2E RED runs before changing production code, then implements and reruns the same focused checks GREEN. After the targeted checks pass, run the workflow-requested repository gates in order (make fmt, then make typecheck test lint) and commit with a Conventional Commit message.

Risks And Out Of Scope

• Hidden workflows remain stored in SQLite and present in task-detail boot state; they are not database corruption.
• This fix does not change workflow visibility APIs, migrations, workflow persistence, or the Improve Kandev bootstrap contract.
• The linked task ID is absent from the current database, so its original request cannot be reconstructed from persisted rows; the current task and task-detail boot payload reproduce the same failure path.