Feature: cross-project workflow rules (status sync between linked issues)

[ahmadoqsrawi]

Problem

Many teams run two or more linked projects where a status change on one side implies a status change on another. For example: a Marketing project tracks a campaign through Pitch -> Approved -> Running -> Reported, and a parallel Creative project tracks the asset for that campaign through Requested -> In Progress -> Delivered -> Approved -> Archived. The team wants: when the campaign moves to Running, the creative becomes In Progress; when the creative is Delivered, the campaign moves back to Review on the marketing side. Any pair of projects with a handoff shape has this need (QA pipeline linked to a Dev backlog, Procurement linked to Vendor Onboarding, Content Calendar linked to a Design queue, etc.).

Today the only paths are:

• Manual: whoever updates one side also updates the other. Easy to forget.
• External: a long-running script with the API client, polling or re-querying.

Both are fragile and project-specific.

Ask

A first-class workflow rule that lives on a Project (or on a ProjectType, inherited by all Projects of that type) and declares the status mapping to a counterpart issue in another Project. The server enforces it on every status Tx.

Suggested data model

A new domain class under tracker or a reusable workflow plugin:

interface WorkflowRule extends Doc {
  space: Ref<Project>              // the project this rule belongs to
  linkedProject: Ref<Project>      // the counterpart project
  linkKind: 'subissue' | 'parent' | 'relation'  // how the two issues are linked
  // Status map, both directions. Empty string = "no action".
  mapForward: Record<Ref<IssueStatus>, Ref<IssueStatus>>   // this -> linked
  mapBackward: Record<Ref<IssueStatus>, Ref<IssueStatus>>  // linked -> this
  // Loop-back permissions (deliberate regressions). Each entry is "if current = X and target = Y, allow".
  allowedLoops: Array<{ from: Ref<IssueStatus>, to: Ref<IssueStatus> }>
  // Auto-create behaviour.
  autoCreateOn?: Ref<IssueStatus>[] // when this-project issue hits one of these statuses, create a counterpart if missing
  // Field inheritance when auto-creating.
  inheritFields?: ('title' | 'description' | 'dueDate' | 'priority' | 'assignee')[]
}

Enforcement lives in a Tx middleware/hook on IssueStatus changes:

1. On TxUpdateDoc(Issue, { status }), resolve the linked issue via linkKind + the rule's linkedProject.
2. Resolve the target status via mapForward[newStatus] (or mapBackward if the rule fires on the counterpart side).
3. Compute whether the target would be a regression. Define category rank on IssueStatus (UnStarted=0, ToDo=1, Active=2, Won=3, Lost=99) and refuse regressions unless the (currentStatus, targetStatus) pair is in allowedLoops.
4. Emit a TxUpdateDoc on the counterpart issue with status = target. Tag the Tx so a listener on the counterpart does NOT echo back (loop prevention).

UI

In a Project's settings, a new tab Workflow rules. For each rule:

• Pick linked Project (dropdown of workspace projects)
• Pick linkKind (subissue / parent / relation)
• A matrix editor: rows = this project's statuses, cols = linked project's statuses. Click a cell to set forward or backward mapping. Blank cell = "no action".
• An "Allowed loops back" sub-list: pairs of (current, target) that bypass the regression guard. Default-populate common loops (Review -> Design for revisions, etc.).
• Auto-create section: tick the statuses that should spawn a counterpart issue if one does not exist, and tick which fields to copy.

Behaviour expectations

• A status change on either side within 1s updates the other side via the server-side Tx.
• Last-write-wins when both sides change in the same Tx batch; the later Tx is authoritative.
• Loops are prevented by tagging daemon-written Tx with an origin marker; the mirror side ignores Txes with its own origin.
• A rule can be paused (archived: true on the WorkflowRule doc) without being deleted, so teams can snapshot a mapping before iterating.
• allowedLoops means a Done issue cannot be dragged back to Todo by accident; a stray click on an older issue is a no-op if the rule denies the move.

Why native, not integration

The link primitive is already in Huly (attachedTo + attachedToClass on Issue). This proposal adds the policy layer that server-enforces the handoff, instead of each team re-implementing it per-project. Enables richer sub-issue hierarchies to actually drive workflow, not just visual grouping.