Look up a term

This page lets you look up any term that the rest of the docs use without defining it again. Each entry links to the page that explains the concept in full.

A

Acceptance criterion (AC) — A checkable statement stored on a requirement, with an id, a description, and a completed flag. PR verification grades a pull request against each criterion, and the web app refuses to move a requirement to In Review or Done while any criterion is incomplete. See Write acceptance criteria.

Ambiguity analysis — An AI pass that scores a requirement from 0 (clear) to 1 (very ambiguous) and lists vague phrases with concrete alternatives. Run it through the MCP tool spectrace_requirements_analyze_ambiguity; the result is stored on the requirement.

API key — A secret that starts with spc_k1_, created at Settings → Developers and shown once. It authenticates AI agents against the MCP server; the key's permissions are the org role of the user who created it. See Create an API key.

C

Check run — The GitHub check named Spectrace verification that PR verification opens on the pull request's head commit and concludes as success, failure, or neutral. Only a contradicted criterion produces failure. See Use check runs.

Contributor — A person listed on a requirement because they acted on it. Contributors are derived from the project audit log, not stored, so work done through the MCP server or the VS Code extension counts. See See who contributed.

D

Drift (spec drift) — A verification result where the pull request references one requirement but touches files linked to a different one. Spectrace adds a "Possible drift" line to the PR comment; nothing is stored. See Understand spec drift.

E

Enrichment — A background job that drafts the user story, acceptance criteria, and subtasks for a requirement created by quick-add, by Slack, by the VS Code extension's quick-add box, or by an inbound Jira, Linear, or GitHub Issues sync. Quick-add can also ask it to draft tests.

Evidence link — A link in the verified PR comment from a criterion to file:lines in the diff, pinned to the verified commit. It is how the comment shows what satisfied or broke a criterion. See Read a verification result.

Explicit reference — A reference number found in a pull request's branch name, title, or description. It is the first rung of the resolution ladder and decides which requirement is verified. See Link a PR to a requirement.

G

GitHub App installation — An installation of the Spectrace GitHub App on a GitHub organization or personal account, connected ("claimed") to exactly one Spectrace organization. The GitHub App verifies pull requests only on repositories covered by an active, claimed installation; a legacy per-repository webhook still verifies PRs it already has a registered requirement for. See Install the GitHub App.

H

Hosted MCP endpoint — The URL /api/mcp on a Spectrace host (https://spectrace.io/api/mcp on Spectrace Cloud) that speaks MCP over HTTP with a Authorization: Bearer <API key> header. Nothing to install and no database credentials. See Connect an agent.

I

Import run — The record behind the import wizard: a source (pasted text, documents, or URLs), its extraction status, and the drafts waiting for review. Runs are resumable. See Import requirements.

Inline verification — Calling the MCP tool spectrace_pr_verifications_create with mode: "inline" and a diff you supply. The verifier runs immediately and persists a result; no GitHub call is made. See Verify before you push.

M

MCP (Model Context Protocol) — An open protocol that lets AI assistants call tools and read resources from a server. The Spectrace MCP server exposes 36 tools, 6 resource templates, and 3 prompts. See Tool reference.

O

Organization — The top-level tenant that owns products, projects, integrations, and API keys. Some settings copy calls it a workspace. Org roles are owner, admin, and member. See Roles and permissions.

P

Per-criterion status — The verdict PR verification records for one acceptance criterion: satisfied, partial, not_found (no relevant change in this diff), contradicted (the diff breaks something the criterion requires), or unclear. See Read a verification result.

Product — A container that groups related projects inside an organization. Every project created in the web app belongs to a product. See Core concepts.

Project — The unit that holds requirements. A project has a key, a slug, and its own members and roles (owner, admin, qa, developer, viewer). A GitHub repository maps to at most one project. See Core concepts.

Project key — A short prefix (for example SSS), set on the project or derived from the first three letters of its name. The new-project wizard accepts up to four letters; the server, project settings and the MCP tools accept up to ten. Lower-cased, it is the first half of every reference number in that project.

Provenance — The record attached to every AI-generated artefact: provider, model, agent, prompt hash, safety version, and generation time. See Architecture.

R

Reference number (ref) — The per-project identifier of a requirement, formatted <project key>-<sequence> with the key lower-cased and the sequence zero-padded to three digits, for example sss-050. It appears in the requirement's URL and is what a branch name or PR title must contain to link the PR. The retired spelling RIP-SSS-050, in a URL or in PR text, still resolves to sss-050.

Register mode — The default mode of spectrace_pr_verifications_create. It links a pull request to a requirement so the next push is verified by the GitHub webhook; it does not verify anything by itself and returns no score.

Repository mapping — The link from a repository covered by the GitHub App installation to one project, set in Settings → Integrations. Pull requests on unmapped repositories are ignored. See Install the GitHub App.

Requirement — The core record: a title, description, type, priority, optional user story, acceptance criteria, workflow stage, and reference number, plus subtasks, test cases, and links to files. See Write a good requirement.

Resolution ladder — The order in which PR verification decides which requirement to verify a pull request against: an explicit reference first, file traceability second, and unmatched when neither names exactly one requirement. See How PR verification works.

S

Subtask — A checklist item on a requirement with status todo, in_progress, or done. Subtask status drives the requirement's progress percentage.

T

Test case — A Gherkin (Given/When/Then) scenario attached to a requirement, generated by AI or written by hand, with a status and a review state (pending, approved, rejected).

Traceability link — A stored link from a requirement to a code file path (or to a test case, PR, or issue). File links come from the VS Code extension, the MCP tool spectrace_requirements_link_file, or the REST route the extension uses; PR verification reads them as the second rung of the ladder and to detect drift.

U

Unmatched — The verification outcome when no single requirement can be resolved for a pull request. The reasons are no_reference, reference_not_found, ambiguous_reference, and ambiguous_traceability; Spectrace posts a comment explaining which one and concludes the check neutral. See Troubleshooting.

User story — The As a … I want … so that … triple stored on a requirement, alongside its acceptance criteria.

V

Verification (PR verification) — The job that runs when a pull request is opened, pushed to, or reopened on a mapped repository: it resolves the requirement, grades the diff against each acceptance criterion, posts one comment, and concludes the check run. See How PR verification works.

W

Workflow stage — Where a requirement sits in its lifecycle. The web app shows four stages: Backlog (draft), In Dev (in_development), In Review (qa_verification), and Done (done). The MCP transition tool also passes through qa_review between draft and in_development. See Workflow and approvals.