Projects

Linked tasks

Let an agent file a task in a project it depends on, and wait for it, instead of working around a bug in someone else's code.

When part of a fix belongs in a project this one links to, such as a bug in a shared library, the agent can file a task there with the create_linked_task tool. By default its own task then waits until the linked task is done, and SI Fabrik picks it up again.

Before you begin#

  • The filing project must link to the receiving one under links: (a source package or a project service). See Project links.
  • The receiving project must accept tasks from it.

Accept tasks from another project#

In the receiving project's WORKFLOW.md:

shared-lib/WORKFLOW.md
accept_tasks_from: [shop-storefront]   # whose agents may file tasks here
linked_tasks_state: Backlog                     # where they land (default)

Or set Accept tasks from and Their tasks land in under Workflow → Settings → Links.

accept_tasks_from is separate from share_with on purpose: letting another project's agents file work that your agents run with your secrets is a bigger permission than letting them read your code.

Keep Backlog unless you mean it

Linked tasks land in Backlog by default, so a person approves each one before an agent runs it with this project's secrets. If you set linked_tasks_state to an active state, tasks written by another project's agent run here without review. The form warns you when you do.

How it works#

  1. The agent files the task

    The tool is only offered when at least one linked project accepts tasks from this one. The agent passes project, title, a Markdown description (what to change, where, and how to verify) and optionally wait. A task can file at most 3 linked tasks.

  2. The task lands in the other project

    It's created in the receiving project's tracker in linked_tasks_state, labelled linked-task, with a header saying which project and task it came from, that the original task waits for it, and to check the request against the project's code before acting on it.

  3. The filing task waits

    With wait: true (the default), the filing task stops after its current turn and isn't dispatched again. Its card shows waits on <project> <task>.

  4. SI Fabrik picks it up again

    When the linked task reaches one of its project's terminal states, SI Fabrik comments on the waiting task and dispatches it again.

With wait: false, the filing task carries on. If it hands off while the linked task is still open, its pull request is opened as a draft and says what it depends on.

The agent can check on what it filed with the linked_tasks tool, which lists the linked tasks this task filed and their current state.

Stop waiting by hand#

Right-click the waiting card and choose Stop Waiting on Linked Tasks, or press Stop waiting in the task's Linked tasks section. The task becomes eligible again right away.

On a server, the same action is POST /api/v1/projects/<p>/issues/<id>/release-waits (operator role).

Where it's stored#

Linked tasks and what waits on them are kept in linked-tasks.json (mode 0600) in SI Fabrik's data folder, so waits survive restarts.

See also#