Read and export documents

Every document the pipeline produces opens in the same reader: a page-like sheet with a contents panel, diagrams drawn in place, a switch to the Markdown source, and a Download menu that exports to PDF, Word, Excel, HTML or Markdown. This page covers where to find documents, how to read them, and what each export contains.

Where documents appear

• Beside the conversation. A step's turn in SDLC Studio carries a card for the document it produced; Read opens it in a panel next to the chat.
• The Artifacts tab. Every document of the project in one list, with the reader beside it.
• Artifacts in the sidebar. The same list across every project you can open, grouped by project.

The Artifacts tab

On the left, Documents lists everything the project has produced, with a count, in pipeline order: Request for Proposal, Project Scope, Software Requirements Specification, Software Design Specification, Software Test Specification, the build ticket manifest, the Compliance Report, the Traceability Matrix and the Client Proposal. Each row shows:

• an icon for the file format;
• the document's name, with a Draft badge while it is under review;
• the format (for example MD), the version (v2) and the date it last changed;
• a download button on hover.

Selecting a row opens it on the right. The address bar keeps the selection (?tab=artifacts&doc=srs), so you can send someone a link to a specific document. With nothing selected, the first readable document opens. A format the browser cannot display is a download link rather than a selection.

Before any step has run, the tab reads No documents yet and points you to SDLC Studio.

The reader

The header

The header identifies the document and holds its actions:

Then the actions: Edit (on a draft you can edit — see Edit a draft), a lock on an approved document ("Approved documents are read-only. To change it, start a new version once the pipeline is complete."), the Preview | Markdown switch, Show contents / Hide contents, Print, Download, and Close document when the reader is open beside the chat. Esc also closes it there.

The header fits the space the reader has, not the size of your window. Beside the chat, the title, version and close button share the first row with a one-line summary under the title, and the status and actions take a second row; in a wide reader everything sits on one row. When the reader is narrow the buttons show icons only — hover one for its name — and a long title is shortened, with the full title on hover.

Preview and Markdown

Every generated document is Markdown. Preview (the default) renders it: headings, lists, tables and diagrams. Markdown shows the source exactly as stored, for copying into another tool or checking what the agent wrote. The switch resets to Preview when you open another document.

The contents panel

On the left of the sheet, Contents lists the document's headings, indented by level. Click one to scroll to it; the heading you are reading is highlighted as you scroll. The panel hides itself when the reader is too narrow to spare the room (under about 760 pixels wide, as in a narrow side panel), and while you are viewing the Markdown source.

Diagrams

Diagrams are written in Mermaid inside the document and drawn in your browser as the document opens. "Drawing diagram…" shows while one renders. Diagrams follow the app's light or dark theme.

If a diagram's source is invalid, the reader shows "This diagram could not be drawn:" with the parser's message and the diagram's source, and the rest of the document is unaffected.

Tables

Wide tables — requirement catalogues, traceability matrices — scroll sideways inside the page rather than stretching it.

What every document contains

The agent writes the body. Alara Code adds, around it:

• A title block at the top: the document title and a table of Project, Client, Version (for example 2.0) and Date.
• Catalogue tables for the items the step owns, such as requirement, component or ticket lists.
• A Version History table at the end, with Version, Date, Author, Changes and Status — one row for each time the document was written, including each round of requested changes.

Edit a draft

A document Awaiting your review can be edited before you approve it. Press Edit in the reader's header, or Edit on the step's turn in SDLC Studio beside Approve and Request changes.

• The editor shows what the agent wrote as rich text: headings, lists, checklists, links, tables and code blocks. Mermaid diagrams are code blocks whose diagram is drawn live under the source as you edit it. The toolbar adds tables and diagrams; inside a table it adds and removes rows and columns.
• The toolbar and the save bar under it stay pinned under the reader's header while you scroll, so formatting and Save are always in reach, however long the document.
• The save bar says No changes yet or Unsaved changes, and reminds you that the draft stays under review until you approve it.
• The document's title block and the sections Alara Code maintains — the requirement, design-component and test-case catalogues, the traceability tables and the version history — are shown under the editor, locked, under "Maintained by Alara Code — built from the project data, not editable here." They are kept as they are when you save.
• Save (or Ctrl+S) keeps the draft's version number and leaves it Awaiting your review; a Draft saved notification confirms it. Approve it when it reads right; Approve records exactly what you saved.
• Cancel leaves the editor. With unsaved changes it asks first: "Discard your changes to this document?"
• If the document changed since you opened it (someone else saved, or the step ran again), the save is refused so nothing is overwritten. Reload it and edit again.

Approved documents are read-only. To change one, finish the current version and start a new one; see Start a new version. An uploaded RFP is changed by uploading a new file.

Your edits carry forward

When a later step runs, the agent receives the approved documents it builds on — as you edited them — and treats them as the authority where they differ from the project's structured data. For example, the SDS is written from the Scope and the SRS as you approved them, and in a new version each step works from the documents already revised and approved in that version.

Only an approved document is passed on; a draft still under review is not.

Editing needs the same permission as Request changes: Projects › Run › create.

Download and export

For a Markdown document, Download opens an Export as menu. The export happens in your browser, from the document's Markdown, and is saved under the document's own file name with the new extension (for example srs-v2.docx). The button reads Exporting… while it works; if an export fails, a notification says why.

In PDF, Word and HTML, a diagram that cannot be drawn is included as its Mermaid source instead of an image. In Excel, diagrams and code blocks appear as text rows on the Document sheet.

Print

Print prints the document sheet through your browser, without the app around it. Use your browser's "Save as PDF" if you prefer that to the PDF export.

Older documents

Projects created before documents became Markdown may still hold Word (.docx) and Excel (.xlsx) files. They still open in the reader:

• Word files are shown as formatted pages, with the contents panel built from their headings. If some embedded diagrams were too large to show, a notice says "Some diagrams were too large to display here." with a Download button.
• Spreadsheets are shown as tables, one per sheet; the header reads, for example, "2 sheets · 340 rows". Very large sheets are cut off in the preview.
• JSON and PDF files open in their own views; plain text files open as text.

These files have a single Download button that saves the original file; the export menu is for Markdown documents only. An uploaded RFP keeps the format you uploaded, so a PDF RFP opens in the browser's PDF viewer.

When a file cannot be shown, the reader says why and offers Download the file:

Under the hood

The list comes from GET /api/projects/:id/documents, a document's content from GET /api/projects/:id/documents/:kind, and the original file from GET /api/projects/:id/documents/:kind/file. Save in the editor sends PUT /api/projects/:id/documents/:kind/content with the edited body and the hash of the version you opened; the bridge answers 422 for an approved document and 409 when the document changed since you opened it. A draft under review is read from the project's working copy; an approved document from storage. Documents are stored as .sdlc/artifacts/<step>-vN.md. See Document checks and versioning.