Key concepts

These are the terms the rest of the documentation uses. Each one is described as you meet it in the app, with the mechanism in a sentence or two where it helps.

Organization

Everything in Alara Code belongs to an organization — the workspace you choose when you sign in. Projects, runs, documents, chat messages and the list of available agents are all scoped to it; nothing is shared across organizations.

Your organization role, assigned in PolyX, decides what you may do. Alara Code reads it as module permissions:

A control you lack the permission for is disabled and names what is missing when you hover it. See Members and permissions.

Project

A project is one engagement: a name, an optional client (printed as "Prepared for" on every document), a type — greenfield (a new system) or brownfield (a change to an existing one) — the teams who can open it, and the documents it produces. The project page has a left-hand menu: SDLC Studio, Board, Artifacts, Repository, Members, Run History and Settings.

The badge beside the project name shows the furthest approved phase (discovery, requirements, design, test-planning or proposal), or Running while a step is in progress.

Project agent

Every step, and every chat reply, runs on one Alara reasoning agent bound to the project. The agent lives in Alara; an Alara admin shares it with the Alara Code app for your organization, and you bind it in Settings › Agent. It runs as whoever starts the step, on that person's Alara identity. A project with no agent bound can be opened and read, but nothing can run.

Skill files

The agent's instructions come in eleven skill files, one per kind of work — sdlc-scope-analyst.md for the scope, sdlc-architect.md for the design, sdlc-project-assistant.md for the chat, and so on. They are added to the agent in Alara as reference files, and each message Alara Code sends names the one file that applies. Check agent asks the agent which of them it can see. See Set up the project agent.

Steps and commands

A step is one stage of the pipeline, started by its command:

/rfp → /scope → /srs → /sds → /sts → /tasks, /compliance, /traceability, /proposal

You start a step in SDLC Studio — its play button in the step rail, the round button in the composer, or by typing the command. Only one step runs at a time in a project.

Phase gates

Each step has a gate state, recalculated from the project's documents and approvals:

A step is stale when it is approved but a step it depends on has been produced again since. It stays approved; the label tells you it was built on an older version.

The gates: Scope needs an approved RFP; SRS an approved Scope; SDS an approved SRS; STS an approved SDS; Proposal needs Scope, SRS and SDS produced and an approved STS; Tasks and Compliance need the STS produced; Traceability needs the SDS produced.

A step's life

Drawing diagram…

Tasks, Compliance and Traceability go straight from running to complete: they have no review gate.

Documents and versions

Every step writes one document in Markdown, with Mermaid diagrams. Alara Code checks it, adds a title block (project, client, version, date), the catalogue tables it owns and a Version History table, and stores it. An uploaded RFP is kept as the file you uploaded.

A document is either a draft (shown as "Draft · under review" or "Draft, awaiting approval") or approved. Its version, vN, counts approved milestones:

• the first draft is v1;
• requesting changes to a draft rewrites it in place — it stays v1 until approved;
• re-running a step whose document is already approved produces the next version, v2, as a new draft.

You read documents in the Artifacts tab or beside the conversation, and export them. See Read and export documents.

Approvals and requested changes

Approve records who approved which version, stores the approved document, and unlocks the next step. Request changes sends a list of changes — one per line — to the agent, which revises only that document; it comes back for review. You can request changes only while a document is under review; to change an approved one, re-run its step. See Review, approve, request changes.

Runs

A run is one execution of a step. It is recorded with who started it, when, and how it ended:

Run History lists the last 20 runs of the project. See Run history and costs.

The chat

SDLC Studio holds one conversation: your messages to the agent, its replies, and the runs you started, in time order. The agent shapes your idea into an RFP and answers questions about the project; it cannot run, approve or change a step. See Talk to the agent.

Ids

Documents number their items so every later document can point back at them.

On the board, each design component becomes an epic and each implementation unit a ticket.