[Feature]: Link project plan items to existing Roomote task execution and controls

[roomote-community]

Problem

Structured plan items are not connected to Roomote task execution, transcripts, follow-ups, or cancellation.

Proposed behavior

Launch one plan item manually as a normal Roomote task using the current integration SHA, persist project/milestone/item/plan-version context, and display linked attempts in the Work tab and task breadcrumbs.

Reuse standard task launch, existing task payload branch/description fields, task summaries/messages, live follow-up delivery, and cancellation. Do not introduce a new task workflow identity or autonomous dispatch.

Acceptance criteria

• Users can start one ready item and navigate between project and task.
• Checkout/base context uses the project integration branch.
• Follow-up and cancel controls work from project and task surfaces.
• Duplicate active attempts are prevented.
• Task completion updates execution state without accepting the item.

Dependencies

• [Feature]: Add the project planning domain model and authorization foundation #1037
• [Feature]: Add project integration branch configuration and preflight #1040

[roomote-community]

I've analyzed this issue and here's my proposed implementation plan:

1. Build on [Feature]: Add the project planning domain model and authorization foundation #1037's project-planning service rather than extending automation work_items: represent each launch as a durable project item attempt linked to the project, milestone, immutable plan version, plan item, ordinary taskId, and captured launch context. Keep attempt execution status separate from the item's acceptance state so a successful task never implicitly accepts the item.
2. Add a transaction-safe launchPlanItemAttempt operation to the server-only project-planning service (packages/db/src/lib/project-planning.ts, as introduced by [Feature]: Add the project planning domain model and authorization foundation #1037). In one transaction, authorize the actor, verify the item belongs to the current published plan and is ready, verify [Feature]: Add project integration branch configuration and preflight #1040's project-repository integration mapping/preflight is valid, and claim the item for launch. Enforce at most one active attempt per item with a database-backed partial unique constraint or equivalent lock plus constraint, not a UI-only check.
3. Launch through the existing standard task path instead of adding a workflow identity. Construct a StandardTask with workflow: 'standard', surface: 'web', and trigger: 'manual', reuse enqueueTask/the conventions in apps/web/src/trpc/commands/task-runs/index.ts, and populate the existing payload fields: the plan-item execution prompt as description, [Feature]: Add project integration branch configuration and preflight #1040's integration branch as branch, its current verified remote head as sha, and the project repository's configured environment/repository context. Finalize the attempt/task link only after enqueue succeeds; if enqueue fails, atomically release or fail the launch claim so the item can be retried.
4. Expose project-scoped tRPC commands/queries in the web application's project-planning router for launching an item and listing its attempt history. Return the normal task ID and route users to /task/[taskId]; include attempt status, task summary, timestamps, and active-run information in the Work-tab query while applying [Feature]: Add the project planning domain model and authorization foundation #1037's project permissions on every read and mutation.
5. Implement the project Work tab in the project page introduced by the dependent project UI work. Show ready/running/completed/failed/canceled attempt states, link each attempt to its ordinary task transcript, disable launch while an active attempt exists, and reuse the existing task follow-up and cancellation commands rather than introducing project-specific delivery or stop behavior. The project controls should target only the linked active task/attempt and refresh both project and task queries after actions.
6. Extend the task session query and apps/web/src/app/(sandbox)/task/[taskId]/Header.tsx to load an authorized project-task link and render breadcrumbs back to the project, milestone, and plan item. Unlinked tasks keep the current header unchanged; linked tasks remain ordinary task pages with the existing transcript, TaskPromptInput, summary/messages, live follow-up delivery, and cancel controls.
7. Synchronize attempt execution state from the shared task lifecycle. Add a small server-only helper called from the same terminal transaction boundary used by packages/sdk/src/server/lib/task-runs/finish-run.ts and the direct cancellation/dequeue paths so completed, failed, and canceled outcomes are recorded idempotently. Treat idle/resumable runs as active, derive status from the task's runs, and never mutate item acceptance when recording completion.
8. Add database/service tests for authorization, stale plan versions, non-ready items, branch/SHA capture, concurrent launch attempts, enqueue rollback/retry, attempt history, idempotent terminal synchronization, and completion remaining unaccepted. Add web command/component tests around Work-tab launch/cancel/follow-up behavior, disabled duplicate launch, task navigation, breadcrumbs, and unchanged rendering for unlinked tasks; extend packages/sdk/src/server/lib/task-runs/__tests__/finish-run.test.ts plus cancellation/dequeue tests for lifecycle synchronization.

This approach preserves one task model and all existing execution controls, while the project layer owns only readiness, launch context, attempt history, authorization, and execution-state projection. It should be implemented after #1037 and #1040 establish the named schema/service and integration-branch contracts.

Please tag @roomote if you'd like me to implement this, or reply with feedback on the plan.