block / block/coplan

[Bug] Plan type cannot be corrected after creation through the API

Open
#164 0 comments 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.