Using the workspace

How to find your way around the workspace at /app: the sidebar, the overview, the requirement tree, the filters, Go to, and what happens when two windows edit the same thing. Shortcuts are given for a Mac; elsewhere use Ctrl for ⌘. They are all in one table under Keys.

Layout

• The sidebar has Go to at the top, then Overview, your lists under Requirements and your verifications under Verifications. Each list shows how many requirements it has and a bar of their statuses; each verification's cite shows its result. The + beside a heading makes a new list or verification. Drag a list or a verification to change its place.
• Collapsed, the sidebar is a column of icons and ids. An id too long for the column is shown without the part its group shares, PWR for VERIF-PWR, or as a plain mark if that is still too long or would read the same as another id. Hover to see the whole id and name. The browser remembers which you chose.
• Every place has its own address: a list, a requirement, a verification, a run, and each edit form. Reload and Back work as on any website, and a bookmark opens the same place again.

Overview

The workspace on one page, and where /app opens.

• Requirements: a bar for every requirement in the workspace, then a row per list with its status, how many requirements it has, how many fail, and how many need review.
• Needs attention: what to look at next, in groups. Requirements whose own verifications failed (a parent that fails only because of a child is not listed; the child is). Results that need review. Runs in progress. Verifications waiting for a run: never run, or a new version not yet run. Verifications that cannot be run yet, because they have no committed version or nothing is mapped to them. Requirements with no coverage. Empty groups are left out.
• Verifications: each one's latest completed run and its result, how many requirements are mapped to it, and its latest version. When the latest completed run used an older version, it says which.

A workspace with no lists shows Start with a list instead, with New list and New verification.

Requirements pages

There are two, and both show the tree on the left and the selected requirement on the right.

The tree

• Click a row to select it. ↑ and ↓ move through the rows shown, and on All requirements they carry on into the next list.
• As you scroll, the parents of the rows in view stay pinned at the top of the tree as single lines, so you can see which branch you are in. Click one to go to it. Past four levels, the middle ones fold into a … line.

Adding requirements

While the form is open, a dashed line labelled New requirement goes here marks the spot in the tree, and Where it goes in the form says it in words: At the top level, after HW-4, or Under HW-1 Power supply, last. Drag the line, use In and Out, or the keys, to put it somewhere else. After you create one, the form stays open just below it, ready for the next, with the cursor back in Title.

On an empty list the form is already open. New requirement then puts the cursor back in it.

Moving requirements

Drag a row to where you want it. Up and down chooses the gap; sideways chooses the level, one level per rail. The line shows where the row will land, and its tag says so in words:

• Release to move, or press Esc to cancel. The row's children move with it.
• With a row selected, → or Tab moves it in a level, to become the last child of the row above. ← or ⇧Tab moves it out, to just after its parent. The pane's ⋯ menu has the same two moves, named for where the row goes: Nest under HW-3, Move out of HW-1. A move that cannot be made is shown greyed, with the reason under it.
• A requirement cannot be moved to another list.
• While a filter is on, dragging, moving in and out, the buttons at the end of a row and moving the new-requirement line are all turned off, because hidden rows could sit between the rows you can see. Add a child requirement in the pane's menu still works.

The requirement pane

Select a row and the pane shows it. From top to bottom:

• Title and statement, with Edit and the ⋯ menu: Add a child requirement, the two moves, and Delete requirement.
• Body, with Edit body, or Add body when it has none.
• Status. The status, and one sentence on why. A requirement with children also shows the sum behind it: Own verifications Pass + Children Partial pass = Status Partial pass. Status explains these.
• Verifications. Each mapped verification, its outcome for this requirement and the run it came from, or the review that replaced it (Reviewed Oct 12, 2026 by sam@example.com, against RUN-3). Map a verification adds one. Each mapping's ⋯ menu has its notes and Close mapping, and a mapping marked Needs review has Review (see Reviewing a result).
• Cited in, if anything cites it.
• Children.
• History, closed until you click Show history.

Edit changes the title, the statement and the body: Add body in the form adds one. If a run has passed or failed the requirement, saving a changed statement or body asks whether the change affects what it requires; your text stays in the form while you answer (see Needs review). Delete requirement, in the menu and at the foot of the edit form, is turned off while it has children.

The body

A requirement's body holds what its statement depends on and cannot hold itself: a table of limits, a register layout, sub-clauses. It is part of the requirement, as binding as the statement (see Requirements). Edit body or Add body in the pane opens it on its own, with the statement above it for reference. Edit and the new-requirement form have it too, under the statement. In the pane the body is drawn in a field of its own, with its headings, lists, code and maths (see Blocks in a body).

• Size. Up to 16 KiB. From 12 KiB the size shows under the field (14.2 of 16 KiB), and past the limit Save body is turned off.
• Meaning. If a run has passed or failed the requirement, saving a changed body asks whether the change affects what it requires, as a changed statement does.
• Unsaved text. Reloading or closing the tab asks first. Cancel asks before it throws your changes away. Clicking elsewhere in the workspace keeps your text until you close the tab: open the body again and it is there, with Discard it to go back to the saved body.
• Saved meanwhile. If someone else changed the body after you opened it, your text stays in the field and the differences from theirs show under it. Save mine instead saves yours over it; theirs stays in the history. Use the saved body puts theirs in the field instead. If they changed only the title or statement, your body saves as usual.
• The tree's text filter does not search bodies.

History

Every saved change to a requirement's title, statement or body is kept. Show history at the foot of the pane shows what changed, newest first. It compares the text as it was typed, so formatting marks and cites show as written.

• Changes are grouped. Saves by one person in a row show as one change. Its header says which fields it changed, when, and who made it. A group ends where more than 12 hours pass between two saves, and where a run recorded a result or a review assessed the text. The saves themselves are all kept; the grouping is only how they are shown. The newest group is open; click another to open it.
• Words that changed are marked in place: removed words are struck through on a red tint, added words are underlined on a green tint.
• A line that was rewritten, keeping fewer than half its words, shows as the old line marked − and the new line marked +.
• Spacing. Re-aligning a table, by padding its cells or its --- row, is not a change, and nor is white space at the end of a line or blank lines at the end of the text. Elsewhere, a line whose only change is spacing is marked spacing changed. A field whose only change was of the first kind reads Only spacing changed.
• Answers. After a group's summary, Affects meaning or Same requirement shows how the question about the change was answered. Nothing shows where nobody was asked. A save that was asked ends its group.
• What changed since a result. See what changed on a run page, and Changed since on a completed one, open the history with one diff at the top: from the revision the result was recorded against to the current text. The groups inside that range have a rule down their left edge. The range is in the address (history=2, or history=2..6), so the link can be shared.
• Runs. A line such as VERIF-PWR:RUN-3 passed it at revision 5 sits above the change that produced revision 5: the run's result for this requirement was set while that text was current. A run still in progress moves up when its result for this requirement is set again. Click the run to open it.
• Reviews. A line such as sam@example.com reviewed VERIF-PWR:RUN-3's pass on 12 Oct 2026: now fails. sits above the change it assessed, with the review's note and See what changed, which opens the diff the reviewer was shown. A review whose run was deleted stays, and says who deleted the run and that the review no longer counts.
• Changes shows the changed lines with two lines either side; a longer stretch of unchanged lines folds to a button that shows them. Whole text shows every field in full, with the changes marked. The choice is remembered in this browser.
• The group that holds the requirement's first revision, at the bottom of the list, is marked Created and shows the text as it stood at the end of that group.

Filtering by text

On a requirements page, type in the field above the tree, or press ⌘F to go to it. The tree then shows only requirements whose cite, title or statement match (not the body), with their parents for context. Parents that do not match are drawn faint, with their cites in grey, and matched characters are bold. The header counts what is shown: 12 of 214 shown. Emptying the field shows every row again.

• A match must fall inside one field, and formatting marks are ignored.
• The filter is not kept in the address; another list starts without it.
• A row you edit stays shown, even if it stops matching, until you change the filter.

Filtering by status

The bar in the header counts the requirements shown by status, and its legend is the filter. Click a status to show only that status. Click others to add them, or click one that is shown to hide it again. Show all, at the end of the bar, clears the filter. Here Fail and No coverage are shown:

5 Pass1 Partial pass3 Fail2 Untested2 No coverage

• The bar and the counts stay the same while the filter is on, so you can see what is hidden.
• A requirement matches on the status its cite shows. A parent fails when a child fails, so with only Fail shown the parent is shown too (example). A row that does not match but leads to one that does is shown greyed.
• After the statuses, Needs review shows only requirements with a result of their own that needs review, with their parents for context. It is a switch of its own and combines with the statuses. Its count does not include parents marked only because of a change below them.
• The status filter is kept in the address, so reload and Back keep it. Needs review is kept there too, as review=1.
• With the text filter on as well, a row must match both.

Go to

Press # anywhere outside a text field, or click Go to at the top of the sidebar, then type a cite to jump to any list, requirement, verification or run. With nothing typed, it lists the places you visited most recently.

Runs come last unless you type one exactly. Go to does not search the text of requirements; the text filter does that.

Keys

Editing in more than one window

The workspace does not update by itself. With it open in two windows, or on two computers, each shows what it last loaded until you act, move to another page, or reload. Saving over a change you have not seen is refused:

Your text stays in the field. Copy it, reload, and make the change again on top of the other one. A move that still makes sense when it arrives is simply carried out.