[Feature] Workflow

[HCH-hash]

Summary

Replace (or heavily augment) the current “manually enroll every task card as a workflow node” model with attribute-based, inheritable automation rules that apply automatically to matching cards (by type, epic, labels, or other criteria).

The current design makes everyday automation effectively impossible at scale and diverges sharply from how mature tools (Jira, Linear, Asana, GitHub Projects) handle the same problem.

Problem

Today a workflow is a graph whose nodes are specific task cards. Rules only fire for cards that have been manually added as nodes. This creates several concrete, severe problems:

1. No real automation
   Every new task must be manually added to the relevant workflow(s). If you forget, the rules silently do nothing. There is no “set it and forget it.”

2. Does not scale
   A project with 200–300 tasks over 18 months forces you to keep hundreds of (mostly closed) cards as nodes inside the workflow graph just so the rules remain applicable. The graph becomes a dumping ground of historical cards.

3. No inheritance / genericity
   Workflows cannot be attached to a card type (Bug / Feature / Chore), an epic, or any other attribute. Every card must be enrolled individually. There is no way to say “all Bugs under Epic X automatically get this flow.”

4. Lifecycle ambiguity
   What happens when a card is closed or archived? Does it stay in the graph forever? Removing it breaks historical rule applicability; keeping it pollutes the workflow.

5. Multiple overlapping workflows with no conflict resolution
   A card can be a node in several active workflows at once, with undefined behavior when rules collide.

This model is closer to a one-off process instance than to a reusable automation system. For a project-management tool it is the wrong abstraction for the common case.

Proposed Direction

Introduce (or evolve the existing system toward) declarative, attribute-scoped automation rules that apply automatically:

• Attach a workflow / rule set to one or more of:

  • Card type (Bug, Feature, Chore, …)
  • Epic (or any parent)
  • Labels / custom fields
  • Project / board
  • Arbitrary filter (type + epic + status + …)

• New cards that match the criteria inherit the workflow immediately — no manual enrollment step.

• Closed / archived cards do not need to remain as explicit nodes; rules can still be evaluated against historical data if needed, or the system can keep a lightweight “was enrolled” record without polluting the visual graph.

• Clear conflict-resolution policy when a card matches multiple workflows (priority order, most-specific wins, explicit “exclusive” flag, etc.).

The existing visual graph can remain useful for complex, multi-path, AI-collaborative processes, but the default / everyday path should be the attribute + inheritance model.

We plan to explore implementing this as a plugin (leveraging Paca’s WASM plugin system) if core support is not prioritized, because the current model is unusable for our needs.

Scope

• Product behavior (primary)
• Architecture (workflow engine / rule evaluation)
• Developer experience (plugin APIs if the feature is exposed that way)
• Documentation

Additional Context

Comparison with mature tools:

• Jira – rules are project-scoped (or global), triggered by events, filtered by issue type / JQL / fields. No per-issue enrollment.
• Asana – rules live on a project; trigger + conditions + actions apply to all matching tasks.
• Linear – team-level status workflows + event/schedule-driven automations that match on issue attributes.
• GitHub Projects – filter-based auto-add and status updates; no manual node enrollment.

The current Paca design is closer to a BPMN-style process instance than to the attribute-driven automation model that users of those tools expect. For an AI-native Scrumban tool the explicit graph may still have value for complex agent hand-offs, but it should not be the only (or default) way to get basic “when status = Approved → assign to X” behavior.

Happy to discuss trade-offs, contribute a plugin prototype, or help refine the rule model.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[pikann]

Hi @HCH-hash , thanks for the detailed feedback

I'm planning to extract Status Assigning Rules into a standalone, project-wide feature with support for field filtering (task type, sprint, story point, etc.). Would this alignment cover your core use cases for automation?

[HCH-hash]

Hey, thanks for the quick reply.

Status Assigning Rules with filters would be nice for the simple “status → assign” cases. But it still leaves the main headache: One has to manually drop every new task into the workflow graph or nothing happens. Feels a bit like having to invite every guest to the party one by one instead of just saying “everyone on the list is in.”

What we really after is being able to attach a workflow to a type, an epic, or some filter so matching cards just join automatically. No manual enrollment, no growing pile of closed tasks cluttering the graph.

We’re actually already hacking on a plugin for this (started this morning) and hope to have something shareable by Monday. Happy to show you what we’ve got and treat the status rules as a first step toward the bigger idea if that works.

[pikann]

That sounds awesome, and I’d love to check out your plugin prototype or discuss the design behind it once it's ready!
Your insights will be super helpful for shaping Paca's core automation, and I’m really looking forward to learning from your approach.