Compose 0.2.0 feedback after using it as the source-of-truth for a real project

[john-derose]

Wanted to share feedback after spending a session using Compose 0.2.0 as the projects-as-code source of truth for a real, non-flat project, in case it's useful for prioritization.

Context. The project I tested with: 31 work items, 11 grouping units (modules), 5 phased time windows (cycles, with overlapping dates), ~17 dependency relations across them, 7 custom states. Probably representative of any moderately structured operational playbook -- release planning, customer onboarding, deal pipelines, marketing campaigns, etc. The kind of thing where the structure is the artifact and items get filled in over time.

The headline I was hoping to write was: Plane is the only modern PM tool that treats project structure as infrastructure. After working through Compose end-to-end, here's what I found.

What works well

• plane clone <uuid> is fast and ergonomic. ~6 seconds for a 31-item project. Directory layout (plane.yaml, schema/, work/, .plane/remote/) is intuitive.
• plane schema push for additive changes is great. Validate, diff, dry-run, push. Each step is informative, idempotent, and the plan output reads cleanly. Adding a new state took under a minute and produced a 3-line, semantically obvious git diff.
• plane auth login is straightforward and credentials live in the right place (~/.config/plane-compose/credentials).
• The schema vocabulary that exists (states, labels, types, custom fields) maps cleanly to YAML -- exactly the kind of thing teams would happily PR-review.

Where the projects-as-code story breaks down

These are scope gaps, not bugs. Listed roughly in order of impact:

1. Modules don't appear in the YAML at all. All 11 of my grouping units were silently dropped on plane clone. Modules aren't in schema/, and per-item module membership doesn't appear on work items either. Since modules express what part of the project an item belongs to, losing them flattens the structural model entirely.
2. Cycles also aren't represented. Same shape -- cycle definitions (with date ranges) and per-item cycle memberships both drop on clone. Especially costly when cycles have overlapping date windows: that's a Plane differentiator that becomes invisible in the YAML.
3. Dependency relations (blocked_by, relates_to, etc.) aren't in the YAML. The 17 dependency edges form the critical path of the project. None survive a clone. (Acknowledged: root cause is the open issue [feature]: issue-relation support in API #6236 -- the v1 API itself doesn't expose relations. Worth flagging here that this gap propagates straight into the projects-as-code story.)

For a project where modules + cycles + relations together describe the structure, the projects-as-code abstraction currently applies only to states / labels / types / custom fields -- i.e., the workflow primitives that most other PM tools also expose in some form. The structural primitives that make Plane's data model genuinely richer don't make it into the YAML.

Smaller, more tractable gaps

These felt like things on the way to being implemented:

4. Work items are create-only via plane push. Putting an item with id: PLOC-7 in work/inbox.yaml and pushing creates a duplicate PLOC-32 rather than updating PLOC-7 -- the id field is silently ignored. There's no documented way to take ownership of a cloned item and push edits back.
5. Two documented commands are missing from the CLI in 0.2.0. Auto-generated inbox.yaml references a plane import command -- No such command 'import'. The PyPI README references plane apply -- No such command 'apply'. Either implement them or remove the references; today they create false expectations about supported workflows.
6. Schema deletion is not implemented end-to-end. Tracked upstream at API DELETE /states/ returns 204 but does not delete custom states #8783 and friends (API DELETE /states/ returns 204 without deleting). Means once a schema element is pushed, it can't be removed via the CLI. I added a state to test the round-trip and now can't roll it back.

Cosmetics worth fixing

• plane --version reports 0.1.0 even when pipx install plane-compose installs 0.2.0. Pin the version string at build time.
• plane clone's schema/workflows.yaml includes terminal: [done, cancelled] referencing group names that don't appear in the state list (no state has group done; the closed state has group completed). Either an alias system that should be documented, or output drift.
• The PyPI metadata for plane-compose points to github.com/makeplane/compose for source and docs, which 404s. Either point at a real location, or open the Compose repo for issues / roadmap visibility -- feedback like this currently has nowhere natural to land.

What would unlock the projects-as-code thesis

In rough priority order:

1. Modules in schema/ and as a field on work items. Single biggest gap.
2. Cycles in schema/ (with date ranges) and as a field on work items. Bonus: a date-shift parameter at clone time (plane clone <uuid> --shift-dates +6mo) would unlock template reuse for projects that recur on a calendar.
3. Work item dependency relations in YAML (downstream of [feature]: issue-relation support in API #6236).
4. Update path for existing work items -- whether plane import to take ownership, or id-aware push semantics.
5. Delete operations for schema rollback, downstream of API DELETE /states/ returns 204 but does not delete custom states #8783.

Even in its current state, Compose's direction is something none of the competitor tools can match. Writing this in the hope it's useful for prioritization.

-- John