Skip to content

Commands

Every command of ReqSeq, grouped as in its catalog. Each page shows the input, the output and the call in the app, the command line, the API and MCP.

What the codes of problems and errors mean, and what to do about them: Problem and error codes.

  • Initialise workspace: Create a workspace with the standard model in an existing folder.
  • Show workspace status: Repositories of the workspace, which are available, where the metamodel comes from, read-only state.
  • Check workspace: Check the whole workspace against the metamodel: files, required and unknown properties, statuses outside the type and missing statuses, requirements with a statement but no text (a warning), missing targets, cycles, requirements without a parent (a warning, SR-022 AK6), duplicate IDs, outdated relations, evidence records that cannot be read or name an unknown element, a repository that is a workspace of its own whose metamodel counts other properties to the version. ok is false, and the CLI exits 1, on findings at or above failOn (default error).
  • Show last agent access: The element read or changed last through the local API or the MCP server on this working copy: which access, command and effect, when, and the element (UUID, repository); null when none is recorded.
  • List recent workspaces: The workspaces the app opened last, the most recent first (at most 20): the root of each, when it was opened, and whether the root still holds reqseq-workspace.yaml. The list belongs to the user, not to a workspace, so every access gives the same list from any folder.
  • Show metamodel: The effective metamodel: types with inherited properties and statuses, properties with whether they count to the version, relation kinds, statuses, meanings.
  • Create element: Create an element with a new random UUID. Only title, text and required properties are needed; empty required properties give a hint (SR-064). New elements always get the initial status of the metamodel (D-030); when their type lacks it or it is marked invalid, the first status of the type in metamodel order that is not marked invalid, and no status for a type without status or with only invalid statuses (#306, #344).
  • Get element: One element with text, properties, relations, version (and on request its date), hints, and which variants replace or exclude it.
  • Resolve reference: Resolve a reference from another tool (UUID, short ID or identifier, optional version) and tell whether the version is current.
  • List all elements: Elements of a selection, sorted; optionally as derivation tree.
  • Show facets: Types, statuses and property values of the elements of a selection, with counts, to choose a filter from.
  • Update element: Change title, text or properties of one element. Unknown properties are kept; status changes only via element.setStatus, and the origin of an imported element only via reqif.import (SR-057).
  • Set status: Set or remove the status of elements on explicit request of the caller. Only a status of each element’s type is taken (statuses of the type in metamodel.get, #306); an element of a type without status gets none. status: null removes the status line where the type’s status is optional (#343). The only command besides element.supersede that changes a status; no command changes a status on its own (D-030, SR-087).
  • Supersede element: Supersede an element: set an invalid status of its type and optionally name a successor (relation with meaning succession, written into the successor’s file). There is no delete (D-045).
  • Bulk update elements: Set, add to or remove one property for all elements of a selection. Without confirm only previews: the number of affected elements and the skipped ones, whose type does not have the property. With confirm writes only that property’s lines (SR-102). Never id, type or status (element.setStatus takes several refs).
  • Add attachment: Copy an image into the folder named like the element file, next to it, and return the Markdown that embeds it relatively; once the text embeds it, the image counts to the version (SR-097, D-057). Never replaces a file.
  • Search elements: Full-text search over title, text, properties and IDs of the elements of a selection, typo tolerant, in any case, the best first.
  • Show relation options: Relation kinds the metamodel allows from an element, each with the types its target may have (SR-067); search a target with element.search and selection.where: { type: targetTypes }.
  • Create relation: Add a relation; stores target UUID and current version, plus the title only within the same repository.
  • Remove relation: Remove a relation from the source file.
  • Show trace chain: Chain up to the top parents and down to evidence, with depth, gaps (also a requirement without a parent) and cycles; one page of nodes at a time, total counts all.
  • Show related elements: All children of a set of parents, or all parents of a set of requirements, each once, optionally up to a depth; one page at a time, total counts all.
  • Show affected elements: Elements affected by a change of one element, with path and distance.
  • Show neighbourhood: The surroundings of one element over every relation kind and inline reference, up and down to a depth; each edge says whether it repeats an element and whether it is outdated. One page of nodes at a time.
  • Show traceability matrix: Traceability matrix of a selection: one row per element in list order, one column per relation kind and direction that occurs, each cell the elements at the other end with outdated and missing marks; per column how many rows have a link. One page of rows at a time. With evidence locations also each requirement’s test cases and verification status, and the degree.
  • Show graph: The graph of one element: what its links lead to above it and what links to it below, to a depth, over the chosen kinds. Each element is one node with its level and marks, and each link between two nodes is one edge. At most limit nodes, nearest levels first.
  • List hints: Open hints of the workspace, filterable by kind, type, package or variant.
  • Confirm hints: Confirm hints, by ID (hintIds) or all of one element (ref, target): writes the current target version into the relation or inline reference (in the text or in a property marked markdown, SR-127; relation.outdated) or into the replaces item (variant.core-changed, SR-045), and nothing else but the current titles of the file’s same-repository targets (D-042); an ID no open hint has gives a warning, for example one confirmed already.
  • List saved filters: Saved filters of the workspace, with their definitions.
  • Save filter: Save a named filter as YAML in the repository; an existing name replaces that filter.
  • List evidence: Evidence records of an element with version, item, date, result, evidence location and baselines that contain the version.
  • Record evidence: Write a manual verification or validation record (Markdown, evidence-record.schema.json) into an evidence folder of the workspace; the element’s UUID and current version are filled in. A verification names a requirement, a validation a need or a requirement (D-012). Never replaces a file: a name that is taken gets -2, -3, …
  • Enrich JUnit file: Add UUID, version, item and date, and the variant’s UUID when there is one, to every test case of a JUnit XML file that names an element by short ID, UUID or identifier, or by a short ID in another form that a name pattern finds. Test cases with an unknown reference, or whose variant does not fit, stay unchanged and are listed; the CLI exits 1. The output counts the test cases that name no element.
  • Show evidence status: Verification status of a selection per view, from the evidence records (SR-031) and, without own record, from the children with the children that are missing (SR-034); validation status from the validation records (SR-038).
  • Show evidence coverage: Coverage of a selection per level: how many have children, how many have evidence; with the element lists.
  • Show verification degree: Verification degree of a selection in one view: the share of the requirements verified or indirect, and the count per verification status (SR-037).
  • List requirements without passed/no test: Every requirement without a passed test execution in one view (SR-120): no verification record with method test and result passed, of any version, holds there (spec question #532). Each with its verification status.
  • Export data: Data of the current state as JSON for external evaluation, or, from the command line and the API, as JSON Lines with one element per line: every element unless a selection is given, so an evaluation selects by filter, package, baseline or variant instead of exporting everything; no paging. With data store the only commands so far that take selection.baseline: the elements the baseline lists, as they are now. data store writes a whole state to a file.
  • Store data: Write the data of the current state (as data export gives it) as JSON Lines, one element per line, to <commit>.jsonl in a folder; -dirty with uncommitted ReqSeq files, replaces the file of the same commit; an old <commit>.json stays as it is. Many such files load as one table, grouped by commit and dirty. One folder per selection: the name is the same for every selection. Takes selection.baseline as data export does.
  • Create baseline: Write a baseline file for a selection (SR-050, ADR-0018): name, date, the HEAD commit of every repository involved, ID and version of every element. Refused while files of the selection are not committed. Never commits, never replaces a baseline.
  • List baselines: Baseline files of the workspace, with name, date, view and number of elements (ADR-0018).
  • Show baseline: Elements of a baseline with their version then and its date, marked changed, superseded, removed or added since (SR-051); with withEvidence the verification status of each requirement per view and the validation status at its version in the baseline, with the records dated after it named (SR-094).
  • Compare baseline: The two commits and the Git command that show the difference of an element since a baseline (SR-051 AK4). Runs nothing.
  • Analyse ReqIF file: Preview the import of a ReqIF file: types, attributes and values without mapping; for a repeated delivery the new, changed and dropped requirements and the conflicts with local changes; the losses. Writes nothing.
  • Import ReqIF file: Import a ReqIF 1.2 file through a saved mapping, all or nothing: creates an element per object and reports losses. Each element keeps its origin (source, source IDENTIFIER, import date, delivery, import version), which no other command writes. A repeated delivery of the same source updates the elements of the earlier one in place (matched by source and source IDENTIFIER) and only lists the dropped ones; an element changed locally and in the delivery is a conflict that needs take or keep, else the import is refused (reqif.conflict).
  • Save ReqIF mapping: Save or change the mapping of a source to the own metamodel, in the mapping folder (default reqif).
  • Export ReqIF: Export a selection or a saved export profile, or with statements the elements of the mapping’s source, as ReqIF 1.2: IDENTIFIER _ plus the UUID (the source IDENTIFIER for statements), text as XHTML and as reqseq-markdown, relations as SPEC-RELATIONs, targets outside the export as stubs.