Changelog

Until this release the CLI moved in one direction. A specification was authored on the platform, pulled down, and checked against the working tree. Teams with an existing system had no entry point, and teams working in anything other than IEEE 830 found that publishing results back quietly damaged their document.

Release 4.2.0 closes that loop. The CLI now generates specifications from source, verifies requirements against it, and writes results back through a format-independent contract that every document type understands.

Specifications from an existing codebase

sra reverse documents a system that was built before it was specified. It reads the working tree through git ls-files, so .gitignore is honoured and nothing untracked leaks into the request, then reduces the repository to a bounded structural digest — dependency manifests, module layout, HTTP interface, data entities and exported symbols. That digest runs through the same multi-agent pipeline the web application uses, and each generated requirement group is matched back against the files that produced it.

Those matches are recorded as proposed, never verified. Promotion to verified requires sra check, which confirms the link independently. Heuristic evidence is labelled as such, so a reverse-engineered specification never overstates what it knows.

Generation is server-side by design. reverse builds the digest locally and posts it to the platform; it never calls a model itself, because under bring-your-own-key the provider credential lives on the platform, not on the developer's machine.

Run sra reverse --dry-run to inspect the digest locally before any of it leaves the machine.

Traceability that survives a change of format

Previously sync extracted requirements without regard to document format, and push wrote all of them back as IEEE 830's systemFeatures. On a Volere, ISO 29148 or Agile PRD document that injected a section the format does not define, flattened structured user stories into prose, and rendered nowhere in the workspace.

Two changes fix this permanently:

• sync now records the originating section of every requirement group, read from the platform's own format registry rather than inferred.
• push writes content back only into feature-shaped sections. For every other format it publishes to metadata.cliTraceability — a format-independent traceability record — and leaves the document structure untouched.

That record is rendered in the analysis workspace for every format, not only IEEE 830, by a new traceability panel. It is the supported contract between the CLI and the web application; future traceability data belongs in it rather than in new document keys.

Verification you can put in a pipeline

sra check gains three modes that make it useful as a gate rather than a report:

Five new commands

sra analyze starts a run from a file or standard input. sra status --watch, sra list, sra projects and sra formats cover the read paths that previously required the web interface. analyze, reverse and status --watch consume the platform's live progress channel — the same stream the web workspace uses — and fall back to polling automatically when it is unavailable.

Every read-only command accepts --json, with the payload on standard output and nothing else: the banner is suppressed, configuration loading is quieted, and human output is routed away. The CLI is scriptable without parsing decorated text.

The analysis pipeline was built against a single model provider, with the provider name threaded through the code as a string that only one branch ever checked. Selecting anything other than the default silently routed back to it. This release replaces that with a real provider abstraction and puts the choice — and the credential — in your hands.

One interface, four providers

Every model call now goes through a shared adapter contract covering content generation, streaming, token counting and error classification. Gemini, OpenAI, Claude and Grok each implement it, so the pipeline treats them identically and a fifth provider is an adapter rather than a rewrite.

Generation runs on your provider key. Keys are stored per user and per provider, encrypted with AES-256-GCM, and are never returned to the browser in plaintext — only a masked form for confirmation. Add them under Settings → AI Providers, and pick the provider and model per analysis when you start a run.

The platform's own credential funds exactly one thing: embeddings. Nothing about generation falls back to it, so a run either uses the key you chose or fails with a clear message naming the missing one. There is no silent substitution.

Embeddings stay on a single provider

Retrieval embeddings remain fixed to Gemini regardless of which provider generates your document. This is deliberate: the vector column backing semantic retrieval is dimensioned to that model, and mixing embedding providers within one index corrupts similarity scores in a way that degrades results without producing an error.

Progress you can watch

The workspace previously discovered progress by re-requesting the analysis every few seconds. A multi-minute, multi-stage pipeline reported through that channel looks identical to one that has stalled.

Progress is now published as the pipeline advances and streamed to the browser over a live connection, so each stage appears as it completes. Conversational refinement streams too: the reply arrives token by token, while the structured document edit is computed separately and only when an edit was actually requested — which keeps partial JSON off your screen.

A single interface

The web application and the marketing site were two codebases with two visual languages. They are now one: the landing page, authentication, projects, the full analysis workspace and settings share a single application and component library.

Documentation drifts more quietly than code. This release audits it against the running system rather than against itself.

• Setup, testing and operational guides now use the workspace commands the monorepo actually supports, replacing single-package instructions that no longer worked from the repository root.
• The Node.js prerequisite is stated once and enforced consistently, so a supported version is unambiguous before installation rather than discovered during it.
• Broken cross-references in the encryption, incident-response and infrastructure guides were repaired; a runbook that links nowhere is worse than one that is missing, because it is trusted.
• Every document targets the same release version, so no guide silently describes an older platform.

A specification stops being useful the moment nobody can tell whether the code still matches it. This release introduces the SRA command line interface so that question has an answer that lives with the code, in version control, next to the work.

Specification-to-code traceability

sra init links a working directory to an approved analysis. sra sync pulls the finalised specification down as a local file. sra check walks each requirement and confirms the source files it claims are present. sra push publishes those results back to the platform, where they appear against the requirement itself.

The check is deliberately modest about what it proves: it establishes that the files a requirement points at exist, which is a fast and honest signal, not an assertion that the requirement is correctly implemented. Overstating that would make the traceability record worse than having none.

Verification visible on both sides

Requirement displays in the web workspace reflect verification status synced from the CLI, and exported documents carry a full audit trail listing the implementing files for every requirement. The specification and the repository stop being two disconnected records of the same intent.

Built as a maintainable client

The CLI is structured as a layered application rather than a collection of scripts: a resilient API client with retry behaviour, layered configuration resolution, and command modules that stay thin over shared logic. Merging CLI verification data into a cloud-side analysis was made safe against concurrent edits, so publishing results cannot discard changes made in the browser.

Generating a full specification is not a request-response interaction; it is a sequence of long model calls where any one of them can be slow, rate-limited or truncated. This release makes that path survivable.

Failures that recover instead of ending the run

Every model call now runs under a six-minute ceiling with jittered exponential backoff on transient failures, so a rate limit or a slow response is retried on a schedule that does not amplify the problem. Requests that were previously abandoned now complete.

When a response cannot be parsed, the raw output is retained in full. Diagnosing a malformed generation previously meant reproducing it; now the evidence is already captured.

Faster first paint

Heavy components — diagram renderers, result tabs — are loaded on demand rather than in the initial bundle, so the workspace becomes interactive well before the parts of it you are not looking at have loaded.

A single model asked to produce an entire specification does every job at once: scoping, architecture and drafting. The result reads as one voice with no separation between commercial intent and technical design, and there is no point at which the work is reviewed before delivery.

This release restructures generation as a pipeline of specialists.

Specialist agents with distinct mandates

Each stage receives the previous stage's output as its input, so scope decisions are made before architecture, and architecture before drafting — the order in which the decisions actually depend on each other.

Quality measured, not assumed

Two independent evaluations run against every document.

A critic scores the draft on six dimensions — clarity, completeness, conciseness, consistency, correctness and context — and a retrieval evaluation measures faithfulness and answer relevancy against the source material the pipeline actually retrieved. A draft that fails either gate is refined rather than delivered.

Both scores are recorded with the analysis, so quality is a number you can compare across runs instead of an impression.

Consistent requirement identity

Prompt governance moved into a versioned registry, so the exact instructions that produced a given document are recoverable rather than lost to an edit. Requirement identifiers are project-prefixed and sequential, making them stable enough to cite in a change request or a test plan.

Serverless workloads open and discard database connections far more aggressively than long-lived servers, and the same connection string cannot serve both application queries and schema migrations correctly.

Connection strategy

Application queries run through the pooled connection; migrations and any operation requiring session state run through a direct one. Configuring both explicitly removes a class of failure that presents as intermittent timeouts under load and is easy to misread as a capacity problem.

The ORM was upgraded a major version and moved onto driver adapters, with configuration centralised so that connection behaviour is defined in one place rather than inferred from where the client happens to be constructed.

Supporting changes

• Infrastructure definitions and container builds were updated for the new runtime requirements, including non-root execution in the image.
• A supported Node.js version is now declared and enforced by the package manager, so an unsupported runtime fails at install rather than at run time.
• Transitive dependency advisories were resolved through targeted overrides.

Infrastructure configured by hand is understood only by whoever configured it, and recovering it after a loss depends on that person's memory. This release moves the platform's hosting configuration into code.

Reproducible environments

A complete Terraform configuration now defines the hosting projects for both the application and the API, with variables, outputs and a worked example separated so that standing up an environment is a parameter change rather than a rebuild.

The practical effects are the ones that matter during an incident: infrastructure changes go through review like any other change, the current state is described by something readable, and recovery is a command rather than a reconstruction.

Security practice, written down

Two operational documents were added and are maintained alongside the code:

• Encryption — what is encrypted, with which algorithm, and where the keys live.
• Incident response — severity classification from P0 to P3, with the procedure for each.

Row-level security policies on the database were confirmed active rather than assumed, and the content delivery and caching strategy was documented so that performance behaviour is intentional rather than emergent.

This release establishes the operational controls a system holding customer specifications is expected to have.

Backups that are encrypted and verified

Database backups run weekly, are encrypted with AES-256-GCM before they are stored, and carry a SHA-256 checksum so integrity can be confirmed rather than trusted. Retention is configurable and enforced automatically.

A command line tool covers the manual path — creating, listing, verifying and restoring a backup — so recovery does not depend on the scheduled job or on access to a dashboard.

An audit trail

Sensitive operations — creation, deletion, finalisation and export — are recorded with full metadata by middleware rather than by each handler, which is what makes the coverage complete. Real-time monitoring flags brute-force attempts, mass deletions and unusual access patterns.

Field-level encryption utilities were added for personally identifiable data.

Security checks on a schedule

Automated auditing runs daily: dependency vulnerability scanning, secret leak detection, permission checks and security header validation. Findings arrive on their own rather than waiting for someone to look.

Data fetching

Analysis views moved to declarative data fetching with caching and background revalidation, replacing hand-written polling timers. Roughly 150 lines of coordination code were removed, and stale views now refresh on their own.

The system-wide audit in 3.0.0 changed the shape of an API response that project initialisation depended on. The client continued to read the previous shape and treated a successful creation as a failure.

The mismatch is corrected and project creation succeeds again. No data was lost — projects created during the affected window exist and are reachable.

Growth had outpaced structure. This release is the result of auditing the whole system at once — interface, API, agent orchestration and deployment — and acting on what the audit found.

Consistent, authenticated API access

Every authenticated request now goes through a single client path that handles token attachment and cross-site request forgery protection. Previously each call site implemented its own approach, which meant a new call site could omit a protection without anything failing.

Cross-site request forgery protection is mandatory in production: the application refuses to start without its secret configured, rather than starting with the protection quietly disabled.

A workspace that scales with the document

The results view was decomposed into specialised, memoised components. A specification with many features previously re-rendered the entire view on any change; the sections are now independent, which is what keeps a large document responsive to edit.

Known follow-up

This release introduced a regression in project creation, corrected in 3.0.9 the following day.

Quality that depends on remembering to check it degrades as soon as the project gets busy. This release moves those checks into automation.

• Continuous integration runs linting and static security analysis on every change, and stale work is triaged automatically rather than accumulating indefinitely.
• Executable workflows cover setup, test and deployment, so those procedures are runnable definitions instead of prose someone has to follow correctly.
• Documentation — the overview, architecture and change history — was rewritten to a standard that lets a new contributor become productive without a walkthrough.

The frontend codebase reached a zero-warning state, which is what makes a warning meaningful again: from here, a new one is signal.

A diagram in a specification is read more often than the prose around it, and a diagram that fails to render takes the credibility of the document with it.

Explorable, exportable

Data flow diagrams are now interactive: pan, zoom and inspect rather than squint at a fixed image. Any diagram exports as a high-resolution image suitable for a document or a presentation, without a screenshot.

Diagrams that repair themselves

Generated diagram syntax occasionally contains errors that prevent rendering entirely. Diagrams are now checked before they are presented, and a malformed one is repaired automatically and re-rendered.

This matters beyond appearance: the quality evaluation scores what it is shown, so a diagram that failed to render used to depress the assessed quality of a document whose content was sound.

Progress worth watching

Loading sequences show the pipeline phase actually in progress, replacing an indeterminate spinner during a process that takes minutes.

The first release proved that a specification could be generated. This one makes the process defined, grounded and durable.

Five defined layers

Requirements engineering was formalised into five architectural layers, each with a stated input and output. A specification is now produced by a process that can be inspected and reasoned about at each stage, rather than by one opaque step whose behaviour can only be judged from its output.

Grounded in prior work

Requirements from previous analyses are stored as embeddings and retrieved by semantic similarity when a new analysis runs. Drafting is informed by the organisation's own accumulated specifications instead of starting from nothing every time — which is what makes terminology and structure consistent across documents produced months apart.

Work that outlives the request

Analysis moved onto a durable job queue. Generation takes minutes and no longer happens inside a request that a browser, proxy or platform timeout can end. A run survives a worker restart, and delivery is retried rather than lost.

The first public release of the Smart Requirements Analyzer.

It does one thing: takes unstructured stakeholder input and produces a structured requirements specification following IEEE 830, saved against an authenticated account so the work persists between sessions.

Everything that followed — the multi-agent pipeline, semantic retrieval, multiple document formats, the command line interface — is built on this shape: raw intent in, a reviewable specification out.