The delivery board

The Board tab shows the tickets the Tasks step produces. Each card is one buildable piece of work drawn from the approved design, with its requirements, test cases, acceptance criteria and implementation steps attached.

The board is view-only. You do not create, edit or move tickets here:

• In an organization connected to Alara Plan, Plan owns the project's epics and tickets. People move tickets in Plan, and the board shows a read-only copy that follows Plan within seconds.
• A project that is not linked to Plan shows the Tasks step's output in four columns, as it comes from the manifest.

Where tickets come from

Tickets are produced by the Tasks step (/tasks in SDLC Studio). Tasks unlocks once the STS step has produced its test plan. For every design component in the SDS, the project agent writes the implementation work, and the bridge assembles it into a ticket manifest:

• Epics are the design components (DC-001, DC-002, ...).
• Tickets are the implementation units inside each design component.

When the Tasks run completes, the bridge fills the board from the new manifest. If the project is linked to Alara Plan, it then publishes the epics and tickets to Plan, as the person who ran Tasks. What Plan did — how many epics and tickets were created or updated, and any warnings — is shown when the run completes. The same run also writes the readable build plan, "Build Plan — Epics and Tickets", in the Artifacts tab.

Drawing diagram…

Ticket keys

In a project linked to Alara Plan, Plan numbers the tickets: each gets a key made of the project's key and a running number, such as AP-001, AP-002. The project key is chosen when the project is linked to Plan (see Linking to Alara Plan). Epics are numbered from the same sequence. The board shows Plan's key on every card.

Code also keeps its own key for each ticket — the design unit, such as T-DC-001-02 — which Plan uses to match a ticket when Tasks runs again. You see it next to Plan's key in the ticket's detail panel.

In a project that is not linked, cards show the manifest's story key (for example FO-001).

Epics first

The board always opens on the project's epics, one card each. A card shows:

• the epic's key (AP-001 in a linked project, DC-001 in one that is not) and its title;
• Plan's status for the epic, in a linked project;
• how many of its tickets are done, as a count, a percentage and a progress bar;
• how many tickets are in each category: to do, in progress, review and done.

Epics are listed in key order. Tickets that belong to no epic — usually ones made directly in Plan — are collected on a last card, No epic.

Click an epic to see only its tickets, in the columns described below. The bar above the columns names the epic and shows its progress; All epics takes you back to the list.

All tickets

The Epics | All tickets switch above the board shows every ticket at once, in the same columns, with each card naming its epic. It is useful for seeing everything in progress across epics. Switching back to Epics returns to the epic list.

Search

The search box narrows whatever you are looking at. It matches every word you type against a ticket's keys (Plan's key, the story key and Code's key), its title, its assignee and its epic.

• On the epic list, an epic stays when its key or title matches, or when one of its tickets does.
• In an epic, or in All tickets, only matching tickets stay in the columns. In an epic, the bar says how many of its tickets are shown.

When nothing matches, Clear search brings everything back.

The columns

In a linked project the board shows Plan's columns, in Plan's order — including any columns your Plan admins added, renamed or reordered, which reach the board within about a minute. Which columns a project starts with depends on the board type chosen when it was linked: a Scrum board has To Do, In Progress, Blocked, Application Integration, Ready for Deployment, QA and Done; a Kanban board has To Do, In Progress, Review and Done. Each column's dot is coloured by its category: to do, in progress, review or done.

In a project that is not linked, or before Plan's column setup has arrived, the board shows the four categories: To Do, In Progress, Review and Done.

Each column header shows a count of its tickets. An empty column reads "No tickets".

Reading a card

Each card shows:

• the ticket key (AP-004 in a linked project) and its priority, when Plan has one;
• the ticket title;
• the epic: its key and title (only in All tickets — inside an epic the bar above already names it);
• the assignee, or "Unassigned";
• the number of dependencies (for example 2 dep) and the estimated story points (for example 3 SP).

Badges call out the special cases:

Story points and assignees

Story points come from the design component's complexity in the SDS (simple 3, average 5, complex 8) and are shared out across the component's tickets. Assignees come from the project's team when Tasks runs; after that, Plan owns the assignee. See Members and permissions.

The header

In a linked project the board's header shows:

• Alara Plan AP · last synced 40 s ago — when the board last brought changes from Plan;
• Sync now — for people who may manage integrations; asks Plan for changes at once;
• Publish to Alara Plan — sends the latest Tasks manifest to Plan again (see below);
• Open in Alara Plan — the project's page in Plan.

How the board stays current

While the board is open it refreshes every five seconds, and each refresh lets the bridge ask Plan for what changed. However many people have boards open, Plan is asked at most once every 15 seconds per organization, and not at all when nobody is looking. A move made in Plan therefore shows on the board within about 20 seconds. The refresh pauses while the browser tab is hidden.

Banners

Open a ticket

Click a card to open its detail panel on the right. The panel is read-only. In a linked project, opening a ticket fetches its latest version from Plan, and Open in Alara Plan takes you to it there. Close the panel with the close button, by clicking outside it, or with Escape.

The panel shows, when the ticket has them:

If the ticket was deleted in Plan, opening it removes it from the board.

Refs

Requirements and test cases are stored on the ticket as ids only. The panel looks up their text in the project's current SRS and STS data. If an id is no longer in the current documents, the entry reads "Not in the current SRS" or "Not in the current STS" instead of the text.

Dependencies

Each entry under Depends On is a button that jumps to that ticket. A dependency shows Done only when that ticket is in a done column; otherwise Not done. If the dependency is not on the board at all, it is marked Missing.

Publish to Alara Plan

Publish to Alara Plan sends the latest Tasks manifest to Plan without running Tasks again — useful if publishing failed at the end of a run, or Plan was unreachable then. It is safe to press more than once: Plan matches tickets by Code's key, so nothing is duplicated.

Publishing never overwrites what happened in Plan: a ticket's column, assignee and order are set when Plan first creates it and are Plan's from then on. The title, contract, specification, criteria, steps, refs, dependencies and story points are refreshed from the manifest.

Re-running Tasks

Run Tasks again from SDLC Studio when the design or tests change:

• In a linked project the new manifest is published to Plan. Existing tickets keep their Plan key, column and assignee; their content is refreshed. New tickets are added. Tickets the new manifest no longer has are marked Not in latest /tasks, never deleted.
• Code matches tickets by their design unit, so a re-run updates the same Plan tickets even when the order of units changes.
• In a project that is not linked, existing tickets keep their column, their content is refreshed, and new tickets are added to To Do.

Who can do what

Empty board

Until Tasks has run, the board shows No tickets yet. Below it is Publish to Alara Plan in a linked project, or Sync from manifest in one that is not linked. Use it when Tasks has already run but the board is still empty. The result shows as a toast:

When Tasks produces no tickets

If the Tasks run fails before it writes the manifest, the board stays empty. The most common cause is a design with no implementation units: "Command /tasks did not produce a ticket manifest — it likely stopped at a precondition (e.g. design components are missing implementationUnits[]; re-run /sds, then /tasks)." Re-run SDS, then Tasks. See Troubleshooting.

Under the hood

• The local copy lives in board_tickets and board_epics, per project and organization. Plan's change feed is applied to it by Plan's key; see the data model.
• The bridge endpoints are GET /api/projects/:id/board/tickets, GET /api/projects/:id/board/tickets/:planKey, GET /api/projects/:id/board/refs, POST /api/projects/:id/board/publish and POST /api/projects/:id/board/ingest. See the API reference.
• You only see the board of a project you can open. See Members and permissions.
• For what the Tasks step does in detail, see Tasks.