Run the pipeline

Every document is produced by running a step on the project's agent. This page covers starting a step, following it live, stopping it, and reading what a failed step is telling you.

Before a step can run

• An agent is bound to the project (Settings › Agent). Without one the composer shows No Alara agent bound and an Open Project Settings link.
• You have Projects › Run. Without it the composer shows "Needs Projects › Run › create" and explains who can add it.
• The step is unlocked. Locked steps show a lock in the step rail with the reason under their name: "Run System Design Spec first" or "Approve Project Scope to unlock this".
• Nothing else is running in the project. One step runs at a time per project.

Start a step

SDLC Studio has three parts: the step rail on the left, the conversation in the middle with the composer at its foot, and the document you open on the right. Below the lg breakpoint the rail opens from the Steps button above the conversation.

The step rail lists every step in pipeline order — the documents (RFP, Scope, SRS, SDS, STS, Proposal), then the steps that work from them (Traceability, Compliance, Tasks). Each row shows:

• Its state — a check when approved, an eye when it is Awaiting your review, a spinner while it runs, a dashed circle when it is ready, a lock when it is waiting (with the reason under its name), and a warning when it is approved but upstream changed.
• Its document version (v2) once it has produced one.
• A play button on a ready step, and a re-run button on an approved one.

At the top of the rail is the version the project's documents are on (see Start a new version). While a version is open it reads, for example, Version 2.0 · In progress with how many of its documents are revised.

Collapse the rail

When you open a document beside the conversation, the rail collapses to a strip of step icons so the document gets the width. Each icon still shows the step's state; hover it for the step's name and state (or what it is waiting for). Expand the steps (the panel button at the top of the strip) opens the full rail again, and Collapse the steps shrinks it by hand at any time. Your choice holds until you open another document or close this one; the rail opens again by itself when the document closes.

The composer keeps a line of guidance: "Next: /sds — System Design Spec", or "/srs is waiting on your review above." when a document needs your decision first.

Three ways to start:

1. Press the step's play button in the rail.
2. Press the round button with the message box empty. It runs the next available step in pipeline order; its label reads "Run /sds" (or "Nothing to run").
3. Type the command — /sds on its own — and press Enter. See Talk to the agent for the rules.

The run appears at the bottom of the conversation as a new turn: a request bubble on the right with the command, its name and the time, and the agent's side below it.

Follow it live

While a step runs, its turn shows Working with a pulsing dot, then:

• A progress bar that advances as stages finish.
• The list of stages, each marked done, running, failed or skipped, sometimes with a detail in brackets. "Starting…" shows until the first stage reports.
• A live panel with what the agent is producing.

The stages of each step

A stage a run skips still counts toward the bar, so the bar always reaches the end.

Summary and Raw

The live panel has two views, switched at its top right:

• Summary (the default) — the document taking shape: sections as the step completes them (requirements, components, test cases, each as an "id — title" line where it has one), the values the agent is writing grouped by the part of the document they belong to, and under Document the Markdown itself rendered as it arrives. Long previews are cut with "…continued in the document."
• Raw — the untouched text the agent is sending, in a terminal-style pane. Useful when you want to see exactly what came back. A step that reports progress without streaming text says so.

The panel follows the output while you are at the bottom; scroll up to read and it stops following until you scroll back down. Hide details collapses it.

Stop a run

Press Stop on the running turn, or the square button in the composer. The composer reads "Stopping /sds…" while Alara Code tells the agent to stop, and the run ends as Cancelled. Nothing is produced, and the step can be run again.

Stopping needs the Projects › Abort permission. Anyone who can open the project and has that permission can stop a run someone else started.

One run per project

Only one step runs in a project at a time. Starting another while one is running is refused with Another command is running. While a run is going:

• the composer shows the running status and Stop, and the step rail's run buttons are disabled;
• approving, uploading an RFP, changing the agent and deleting the project are all unavailable;
• you can keep chatting with the agent — the message box stays open.

Your organization may also cap how many agents run at once across all its projects. At the cap, a new run is refused with Organization limit reached and a message such as "Your organization already has 3 of 3 agents running." Wait for one to finish.

If you reload the page or open the project in another tab, the running step reattaches and its output replays from the start.

When a step finishes

• Reviewed steps (RFP, Scope, SRS, SDS, STS, Proposal) finish as Awaiting your review with a document card, Approve and Request changes. See Review, approve, request changes.
• Tasks, Compliance and Traceability finish as Approved — there is nothing to review — and the next steps unlock at once.

A finished turn collapses to its outcome and document. Show run output reopens the live panel for the most recent run, so you can still read what the agent streamed.

When a step fails

A failed turn shows Failed and a summary card: what happened, the reason in plain words where there is one, and what to do. Details reveals the exact message. The same message is kept in Run History.

Two further failures are worth knowing:

• "Command /x finished but did not produce a new version — the artifact is unchanged since the last approval, so there is nothing to review." — a re-run of an approved step produced exactly the same document. There is nothing new to approve.
• "Command /tasks did not produce a ticket manifest …" — /tasks stopped at a precondition, typically design components without implementation units. Re-run /sds, then /tasks.

Refusals before a run starts

Some problems stop a step from starting at all. They appear as a notification rather than a failed turn:

Corrections, retries and time limits

Before you ever see a document, Alara Code checks it: required headings, the ids the step owns, closed and valid Mermaid diagrams, size, and the data schemas the later steps read. A reply that fails a check, or is not valid JSON, goes back to the agent as a correction: its own reply, plus each problem with where it is, what was expected, what was found and how to fix it. The agent edits that reply rather than writing a new one. In /rfp, /scope, /srs, /sds, /sts, /compliance and /proposal, each agent call gets up to three attempts (an administrator can set 1–5), and the best reply so far is kept.

When the attempts run out, what happens depends on the problem:

• Document problems — a missing section, an id not cited, too few diagrams, a banned phrase. The document is saved as a draft with the unresolved checks listed above Approve, so you decide whether to approve it or request changes.
• Data problems — requirements, test cases, the design's components or compliance findings that break their schema, or a document that is empty. A later step would break on that data, so the step stops and lists exactly which checks were still failing.

A run has a time budget of 25 minutes by default. A run that reaches it is stopped and recorded as aborted, with the budget named as the reason. Because a step runs as you, Alara Code also checks when it starts that your sign-in will last longer than that budget — if not, it asks you to sign in again first.

A run, end to end

Drawing diagram…

Under the hood

A run is started with POST /api/projects/:id/commands/:cmd and followed over server-sent events at GET /api/commands/runs/:runId/stream; Stop posts POST /api/commands/runs/:runId/cancel. Stage events carry an index, total and percent from each command's fixed plan. See Run lifecycle and streaming and Document checks and versioning.