Knowledge Base

Spec Checks

Let DevStride's AI write an As Built for each finished spec-linked work item, compare it with the spec, track every difference until someone decides on it, and tell the spec's people. Off until an admin switches it on.

What spec checks do

A spec says what to build; a linked work item tracks the building. Spec checks close the loop once the work is done. When a work item linked to a spec finishes, DevStride's AI:

reads what was actually built: the item's description, comments and history, and the code changes on its linked GitHub pull requests;
writes an As Built for the item, a plain account of what was delivered, kept with every earlier version;
compares that with the part of each linked spec the item covers, and records each meaningful difference;
tells the spec's people, so someone decides whether the work or the spec is right.

When the last work item linked to a spec finishes, a whole-spec check also looks for requirements that nothing delivered.

Spec checks are for your team only. Your clients see nothing of them: not the As Built, not the differences and not the notifications. See What your clients see.

Switching spec checks on

Spec checks are off in every workspace until an admin switches them on.

Open Configure Settings → Knowledge Base → Specs.
Switch on Check finished work against its spec.
Under Model, choose the AI model the checks use.

Read the note under the switch before you turn it on. With checks on, each time a spec-linked item is finished, DevStride sends the linked spec's text, the item's description, comments and history, and the code changes on its linked GitHub pull requests to the chosen model's provider. Switching checks on is enough to let DevStride read the code on linked pull requests, even when the AI Assistant's GitHub context switch is off.

Every check counts toward your workspace's monthly AI budget. Paid models are listed once they are allowed under Settings > AI Assistants. If the model chosen earlier is no longer available, the page says so, and checks do not run until you choose another.

You need Manage Knowledge Base Settings to open this page. See Who can do what.

Only work finished after checks are on is checked

A check runs when an item finishes. Items that finished before you switched checks on, or before they were linked to a spec, are not checked afterwards.

The As Built on a work item

A work item linked to a spec has an As Built button beside Description above its description. Click it to see what was built; click Description to go back.

Until the item is done, it says Written automatically when this item is done.
While the AI is working, it says DevStride AI is writing the As Built. It appears by itself when it is ready.
Each As Built says when it was written and what it was written from: from pull requests, or from comments and history only when the item has no readable pull request.
When not everything could be read (a very long code change, say), it says Not everything could be read when this was written, so it may be incomplete.

Every version is kept. If an item is reopened, worked on and finished again, a new As Built is written and the earlier ones stay. Finishing it again with nothing new to read (no new pull request, comment or change) does not run another check. Pick one from the version list (Version 1 of 2), and click Compare with previous to see what changed between that version and the one before it.

If no As Built was written, the pane says why: for example, checks were switched off when the item finished, the monthly AI budget was reached, or the chosen model was no longer allowed.

The comment on the item

When what was built differs materially from the plan, or the compare found differences from a linked spec, DevStride leaves one internal comment on the item. It lists how the result differs from the plan and says how many spec differences were found, with a pointer to review them. It gives only the number of spec differences, never their words, because anyone who can read the item sees the comment and some of them may not be allowed to read the spec.

Differences from the spec

Each difference a check finds is recorded with:

its kind: Left out, Control left out, Endpoint left out, Works differently, Not in the spec (something built that the spec never mentions), or Not delivered (from the whole-spec check);
a short subject and an explanation;
what the spec says: the passage it is about, quoted when it was found word for word in the spec. When it was not, it is shown as The spec says, roughly: followed by the AI's reading, with the note This passage was not found word for word in the spec.;
any reason found in the work, when the item's comments or history explain why it was built that way;
the date it was found.

Where differences show

On the work item, under Differences from the spec in its As Built pane. Each one links to its spec.
On the spec, in the Spec checks section of the editor's right-hand column. Each one links to its work item. The same section lists every check run on the spec, with its date, a short summary and a score (85% as specified). A check that did not run, or only partly ran, says why.
In an items table, the Spec Sync column shows Spec differences with the number still open, beside the as-built sync state.

Open differences are listed first. Resolved ones are folded away under a button that shows them.

Deciding on a difference

A difference stays Open until a person decides on it. If you can edit the spec, each open difference offers two buttons:

Accept: the work is right as built and the spec does not need to change. You must answer Why is this difference acceptable?; your reason is kept with your name and the date.
Spec updated: you have changed the spec to match what was built.

If you cannot edit the spec, the difference says An editor of this spec can accept it or mark the spec updated. A decision made on the item shows on the spec straight away, and the other way round.

A later check can also close a difference. If the item is finished again and the new check no longer finds it, it is marked No longer found.

The whole-spec check

When the last work item linked to a spec finishes, DevStride checks the spec as a whole against everything that was delivered. It catches requirements that no item delivered, and records each as Not delivered. A Cancelled item counts as finished for this purpose, but as not delivered: what it was meant to build is checked as missing.

Who is told

When a check finds new differences on a spec, DevStride sends one in-app notification per spec: Finished work differs from a specification: open the spec to review the differences. It goes to:

the spec's author,
the people who approved or reviewed a version of it, and
everyone watching the spec or its category.

Only people who can read the spec are told. A check that finds nothing new, or only finds again what was already open, tells nobody. Clicking the notification opens the spec.

What your clients see

Nothing. The As Built pane, the item comment (it is internal), the differences, the checks and the notifications are all staff-only. Spec checks never change the spec's text, so a client reading the spec on the portal sees exactly what they saw before. To change the spec itself, edit it, or record an as-built change, which does write into the spec.

Spec checks and as-built changes are different things

An as-built change is something a person records by hand: it replaces the item's description and writes a note into every linked spec, which clients can read. A spec check is DevStride's AI reading the finished work: it writes the As Built beside the description, never into the spec, and only staff see what it finds.

Who can do what

To	You need
Switch spec checks on or off, and choose the model	Manage Knowledge Base Settings
See a work item's As Built	Permission to read the work item
See a difference	Permission to read the work item and access to the spec. Differences on specs you cannot see are counted, not shown
See a spec's Spec checks section	Access to the spec. A check about a work item you cannot read shows only its date
Accept a difference or mark the spec updated	Edit access to the spec

See Knowledge Base permissions.

Specs and work items: link a spec to its work items, and record as-built changes by hand.
Watching articles and categories: get told when a spec you care about changes.
Knowledge Base permissions: who can write, publish and set up the Knowledge Base.

Specs and Work Items

Link a spec to the work items built from it, create those items straight from the spec, be offered them when a spec reaches a stage, find specs that still have none, let an automation create them for you, and write back what was actually built.

Overview

The AI Assistant answers how-to questions from this documentation, looks up your own workspace, and makes changes you approve. Where it is, what it can do, and where every other AI feature in DevStride lives.