[Bug] Plan type cannot be corrected after creation through the API
- Dominant language
- Ruby
- Stars
- 33
- Forks
- 12
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 34
Description
**Describe the bug**
A plan's type can be selected through `plan_type` when the plan is created, but the documented plan update API does not allow changing it afterward. A mistaken classification therefore appears permanent through the API even though plan content, title, tags, visibility, and references remain editable.
This is especially easy for agent-created plans: an agent may choose `General`, then recognize from the plan-type descriptions that the content should have been `Research`. The agent instructions correctly explain the distinction, but provide no supported correction workflow.
**To Reproduce:**
1. Create a plan with `POST /api/v1/plans` and `"plan_type": "general"`.
2. Determine that the plan should use the `Research` type.
3. Consult the agent instructions and `PATCH /api/v1/plans/:id` contract.
4. Observe that `plan_type` / `plan_type_id` is not an allowed update field and no dedicated type-change endpoint is documented.
**Expected behavior:**
Plan owners should be able to correct the type of an existing plan without deleting, archiving, or recreating it. Ideally:
- `PATCH /api/v1/plans/:id` accepts `plan_type` (name) or `plan_type_id`;
- the web UI exposes the same operation;
- the agent instructions document the correction workflow and any effect on default tags;
- the change is represented in plan history/audit metadata.
If plan types are intentionally immutable, creation should require explicit confirmation and the agent instructions should explain why recreation is the only option. However, mutability seems preferable because classification mistakes do not invalidate a plan's content or history.
**Supporting Material**
The current agent instructions say:
- “When creating a plan, pass `plan_type` to associate it with a type.”
- `plan_type` is optional on create.
- The update endpoint's allowed fields are `title`, `visibility`, `archived`, `tags`, and `references`.
No plan-type correction operation is documented.
**Environment:**
- API: CoPlan v1 REST API
- Client: `curl`/agent workflow
- Date observed: 2026-07-27
Contributor guide
Research direction
Start with the documented POST /api/v1/plans and PATCH /api/v1/plans/:id contracts, then read the agent instructions describing plan types and updates. Trace how plan type, default tags, and history or audit metadata are handled, including the web UI path. Done means the supported correction workflow and its effects are defined across the API, UI, and instructions, with coverage for changing an existing plan type.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- api, backend, documentation, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100