[Feature]: Create structured project plans from existing Roomote plan artifacts

[roomote-community]

Problem

Roomote plans are durable Markdown artifacts, but they cannot drive milestone dependencies, acceptance, or project progress.

Proposed behavior

Define a structured plan contract and add Create project from plan to existing plan artifacts. Import milestones, items, dependencies, and acceptance criteria into an immutable draft/approved plan version while preserving the exact source artifact and task.

Reuse current create_plan versioning, artifact authorization, the artifact viewer, and the existing Build this path. Keep Build this unchanged for one-task execution.

Acceptance criteria

• Import is previewable, correctable, deterministic, and idempotent per artifact version.
• Approved plan versions are immutable; edits create a new draft.
• Structured plans and source artifacts link in both directions.
• Existing plan artifacts remain valid without conversion.

Dependencies

• [Feature]: Add the project planning domain model and authorization foundation #1037
• [Feature]: Add the Projects dashboard and manual project setup #1038

[roomote-community]

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

1. Land this after [Feature]: Add the project planning domain model and authorization foundation #1037 and [Feature]: Add the Projects dashboard and manual project setup #1038, and extend the shared project-planning vocabulary introduced by [Feature]: Add the project planning domain model and authorization foundation #1037 with a versioned import contract in packages/types/src/project-planning.ts. Define normalized project metadata, milestones, ordered items, dependency references, acceptance criteria, source locations, validation diagnostics, and a contract version; leave packages/types/src/task-artifacts.ts and the existing plan artifact type backward compatible.
2. Implement a pure, deterministic Markdown-to-contract parser alongside that shared contract. Recognize documented headings, ordered/checklist items, stable labels, dependencies, and acceptance sections; preserve unrecognized Markdown as descriptions rather than dropping it; derive stable preview keys from the artifact version and document position; and return actionable diagnostics for ambiguous or invalid references. The same artifact bytes and contract version must always produce the same normalized preview.
3. Extend the project-planning schema/service from [Feature]: Add the project planning domain model and authorization foundation #1037 in packages/db/src/schema.ts and packages/db/src/lib/project-planning.ts with an artifact-import/source relation keyed uniquely by the exact task_artifacts version row. Record the source task, artifact ID/path/version, content digest, parser-contract version, and resulting project/plan version so repeated imports return the existing result instead of creating duplicates. Retain captured source metadata when task/artifact cleanup removes the live row, following [Feature]: Add the project planning domain model and authorization foundation #1037's history-preservation model.
4. Add authorized project import commands under a focused apps/web/src/trpc/commands/projects/ module and expose them through apps/web/src/trpc/routers/_app.ts. The preview command should fetch the exact artifact version through apps/web/src/lib/server/artifacts.ts, require an uploaded Markdown plan artifact, reuse existing task/artifact visibility checks plus [Feature]: Add the project planning domain model and authorization foundation #1037 project grants, parse and validate without writing, and return the normalized editable preview with diagnostics.
5. Add a transactional confirm command that accepts the artifact ID/version plus the corrected preview, re-fetches and re-hashes the source to prevent stale confirmation, validates milestone/item/dependency references and cycle constraints through the [Feature]: Add the project planning domain model and authorization foundation #1037 service, then creates the project and immutable draft plan version atomically. Enforce idempotency with the database uniqueness constraint and resolve concurrent duplicate submissions by returning the already-linked project/version.
6. Add Create project from plan beside the existing toolbar action in apps/web/src/components/tasks/ArtifactViewerContent.tsx, limited to exact-version plan artifacts with fetched content and project-create permission. Keep buildArtifactPlanDescription, BuildArtifactConfirmDialog.tsx, and the current Build this task-launch mutation unchanged so one-task execution remains behaviorally separate.
7. Build a multi-step import dialog under apps/web/src/components/projects/ using the project form patterns from [Feature]: Add the Projects dashboard and manual project setup #1038: preview source identity, edit project/milestone/item fields, resolve parser diagnostics and dependencies, review acceptance criteria, and confirm. After import, route to the new project's Plan tab; subsequent visits for the same artifact version should offer View project rather than another import.
8. Show provenance in both directions. The project Plan version UI from [Feature]: Add the Projects dashboard and manual project setup #1038 should link to /task/[taskId]/artifacts/[...path]?v=[version] and display the immutable source identity/digest, while the artifact viewer should query its import relation and link back to the project and exact plan version. If a live task/artifact has later been removed, retain the captured provenance and present it as unavailable rather than silently losing history.
9. Apply [Feature]: Add the project planning domain model and authorization foundation #1037's version rules at every edit boundary: confirmation creates a draft; approval freezes that version; editing an approved import clones its structured contents into a new draft instead of mutating it; and the original source link remains attached to the imported version. A user-authored correction can be recorded as corrected structured data without rewriting the Markdown artifact.
10. Add contract/parser unit tests in packages/types, real-Postgres service tests in packages/db for exact-version identity, concurrent idempotency, source retention, authorization, cycles, draft cloning, and approved-version immutability, plus tRPC/component tests for preview diagnostics, stale-source rejection, correction/confirmation, View project, and coexistence with the unchanged Build this action. Update apps/docs/ with the supported Markdown structure, correction workflow, provenance behavior, and the fact that existing plan artifacts remain usable without conversion.

This approach makes import deterministic by using a versioned pure parser, makes correction explicit before any write, and anchors idempotency to the existing task_artifacts version identity (taskId, path, version) while relying on #1037 for immutable plan versions/authorization and #1038 for the project workspace. It also avoids repurposing automation work_items or coupling project creation to the existing single-task Build this path.

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