Skip to content

Analyst pages

This reference covers the main analyst workspaces from specification planning to Requirement and Use Case refinement. Use it when you already know the analyst flow and need quick page-level guidance: what the page is for, why you would open it, which actions matter, and which modals you should expect. You only need normal access to the product, and most lookups here take a minute or two.

Specification workspace page

Purpose

Use the Specification workspace as the simplified cockpit for one specification. It summarizes what exists, what needs review, coverage health, readiness for implementation handoff, and one recommended next action. For newer users, it is the preferred first page for preparing a specification because it presents the path as Start, Draft, Review, Connect, Validate, and Handoff.

Its Start here section now uses the same familiar contract as the AI, Implementation, and Feature workspaces: compact KPIs, the numbered preparation path, and a slim recommended-action strip aligned with the highlighted stage. The stages and recommendations remain specific to specification work. A thin amber line on the left edge of the matching section below repeats the current recommendation.

Main actions

  • review the Start here summary and recommended next action, including the active Test Cases count when Test Cases are enabled and compact Ubiquitous Language term and finding signals when available
  • open Work on the specification document to edit Requirements, Use Cases, and Test Cases in SmartDoc
  • inspect draft, bookmarked, running, or failed items under Needs your review
  • review open Ubiquitous Language findings under Needs your review when Ubiquitous Language is enabled
  • review Coverage and gaps for Requirement coverage by Use Cases and Use Case coverage by Test Cases
  • check Handoff readiness, which separates specification readiness from implementation handoff readiness
  • use AI-assisted actions to open existing enhancement, Use Case generation, terminology, link suggestion, and gap-analysis workflows
  • use Detailed tools to jump to the Epics, Epic, Requirement, Use Case, Test Case, Ubiquitous Language, and Gap analysis pages when the guided workspace points you there

Notes

The workspace does not replace the advanced pages. It links into them so that traceability, detailed review, and artifact-specific actions remain available. Legacy Test Cases with status obsolete are ignored in workspace counts, coverage, review lists, and recent-work shortcuts.

Workspace terminology matches the detailed pages: Epic, Requirement, Use Case, Test Case, and Ubiquitous Language.

Project Demo page

Purpose

Use Project Demo to prepare and run a sequence of stakeholder meetings for one Specification. A Demo Series defines the intended Ubiquitous Language and artifact scope. It can contain multiple Demo Sessions, allowing the same Specification to be covered over several meetings or selected content to be revisited.

In Series, create the master scope and monitor covered, remaining, and changed-since-demo items. Any accepted UL term type can drive the scope. The fullscreen Series dialog retains the former Project Demo workspace: filter terms by keyword, show up to four type lanes, drag lanes to reorder them, and select term cards. Enter the Series objective directly in its editable field. The associated-artifact area shows only the intersection explicitly referenced by every selected term, supports RQ/UC/TC filters, and provides a list/detail inspection view. Text matches are not recommendations. Scope resolution subsequently includes explicit UL artifact references and authoritative RQ–UC–TC lineage.

In Preparation, narrow the next Session, choose its language, resolve source warnings, and generate or edit the six-part cited narrative. Expand Edit sources beneath a section to correct its typed UL and artifact citations. Scope and source associations use selectable cards, while RQ/UC/TC references are displayed as compact typed pills throughout the demo screens. When localized artifact text is unavailable, acknowledge the use of canonical English. Start Demo freezes the exact definitions, artifact excerpts, statuses, narrative, citations, locale sources, and source versions used for the meeting.

Run Mode is the screen-shared customer view. It contains only the prepared narrative, its referenced frozen UL definitions, simplified frozen artifacts, navigation, and meeting Notes. Saved Notes scroll within a list that fills the remaining Notes panel height. Finalize Session is separated from the Previous/Next presentation controls in the same navigation row. Press N outside an input to focus Note entry, or Ctrl+Enter to save. A saved Note appears immediately and is linked to the current presentation context.

After Finalize Session, use Review for demonstrated scope, chronological and grouped Notes, decisions, questions, follow-ups, candidate terminology, and an AI recap. Filter Chronological Notes by keyword or note type without changing the outcome counts or recap input. Notes remain editable with revision history; editing a Note marks recaps that cite it stale. The edit dialog can also correct the speaker, follow-up flag, and frozen UL/artifact associations. Use the typed artifact pills to open RQ, UC, or TC editors without leaving the review, and mark addressed Notes as resolved or reopen them directly from the chronological list. Completing a Series with remaining scope requires an explicit acknowledgement and preserves the remaining list.

Generated recaps open with a category summary and visually separate demonstrated content, customer statements, agreements, unresolved items, follow-ups, and candidate terminology. The latest version is expanded by default, older versions remain collapsible, and each recap item shows its supporting source count. Demonstrated content is hidden by default and can be toggled from its category pill. When a Series still has undemonstrated scope, completion uses the standard selection control for the required acknowledgement.

Notes

The Analyst facilitates the meeting in one shared window. There is no separate audience account or confirmation state. Candidate terminology is an outcome to incorporate later; the demo does not create or mutate UL terms or specification artifacts. Persisted Project Demo summaries remain API-compatible, but the Series dialog does not use them.

SmartDoc page

Purpose

Use the SmartDoc page to review and edit one Epic as a ProseMirror structured document. It keeps each block mapped to its underlying Requirement, Use Case, or Test Case record, so edits still flow through the normal API and advanced detail pages.

AIKOZO SmartDoc lets users work with Requirements, Use Cases, and Test Cases in one continuous, document-like editor while preserving each artifact as a structured, traceable record.

Main actions

  • open the page from Specification workspace -> Work on the specification document, from the Open SmartDoc button on the Epic page, or from an artifact row's SmartDoc button, which opens that item with the cursor in its editable SmartDoc field
  • switch between Requirements, Use Cases, and Test Cases
  • edit canonical and localized text inline as separate structured fields
  • in bilingual projects, use Show Canonical EN / Hide Canonical EN to reveal or collapse the read-only canonical English field above localized text
  • in Use Cases mode, edit only the title and canonical text in the document; use Advanced detail for deeper Use Case controls
  • in Test Cases mode, edit the title, canonical text, and localized text; use Advanced detail for traceability and scenario-specific fields
  • let draft edits autosave, or use Save draft and Finalize explicitly
  • review inline Validation Blockers on affected artifacts for missing canonical final text, non-final source artifacts, and format validation findings
  • use Finalize to run AI format checks against the active Requirement, Use Case, and Test Case format presets; backend blockers are shown inside the affected SmartDoc item
  • use Add block or Ctrl+Enter to create a new draft Requirement, Use Case, or Test Case record after the current cursor position
  • delete record-backed Requirement, Use Case, and Test Case blocks from the block controls
  • when deleting a Requirement, its references are removed from surviving Use Cases and Test Cases; when deleting a Use Case, linked Test Cases are preserved and their Use Case reference is cleared
  • run AI enhancement, review the inline diff-style preview, then explicitly apply or discard it
  • use semantic search, when enabled, to highlight matching blocks in the document
  • when Ubiquitous Language is enabled, review subtle SmartDoc finding markers and block badges on affected Requirement, Use Case, and Test Case text
  • open Advanced detail for full traceability and artifact-specific controls

Safe limits

Final Epics are read-only on this page. Requirement split is record-aware: the current Requirement is patched and a new draft Requirement record is created for the second part. Requirement merge keeps the previous Requirement as the surviving record, combines text into it, and marks the merged-away source Requirement deferred; it does not delete the source record. AI enhancement previews do not mutate committed text until Apply preview is selected. The page does not support drag reordering because Requirements, Use Cases, and Test Cases do not yet have an order field. SmartDoc finding markers are read-only review cues from Ubiquitous Language findings. If AIKOZO cannot safely match a finding to the visible artifact text, the block still shows a finding badge instead of placing an inline marker. In bilingual projects, inline finding markers are placed on localized text only. Repeated exact term matches are highlighted case-insensitively. Accept, Reject, and Defer on a SmartDoc finding update the finding review status; they do not rewrite the artifact text.

Finalization is API-enforced. Requirements, Use Cases, and Test Cases need canonical final text. When the project Format Enforcement setting is Enforce, artifacts must also pass the active format preset before they can move to final; when it is Warning Only, format issues appear as warnings and finalization can continue. New personal projects and existing projects that predate the setting default to Warning Only; new collaborative projects default to Enforce. Use Case finalization always requires linked Requirements to be final and have canonical final text. Test Case finalization always requires the source Use Case and linked Requirements to be final-ready. Epic finalization still enforces artifact status, canonical text, and format rules, but treats a reference to an artifact that has since been deleted as a warning instead of failing the entire Epic job.

Epics page

Purpose

Use the Epics page as the main analyst workspace for one specification. It combines Epic management, semantic search, Ubiquitous Language governance, and gap analysis.

Main actions

  • filter, sort, and open Epics; the compact control on the Epics tab cycles through oldest, newest, and key order and preserves the selection in the URL
  • create a new Epic manually
  • generate an Epic and starter Requirements from a business Requirement
  • run semantic search across Requirements, Use Cases, Test Cases, and accepted Ubiquitous Language terms when the related features are enabled
  • switch between Epics, Ubiquitous Language, and Gap analysis
  • when Spec Connections are enabled, switch to Spec Connections to configure JIRA, GitHub, or GitLab downstream destinations for the specification
  • review staged Ubiquitous Language candidates, accept terms, merge aliases, reject noise, and review semantic misalignment findings
  • run gap analysis, tune thresholds, and inspect coverage rows
  • open Use Case coverage details from gap-analysis results
  • manage Spec Connections without storing provider tokens on the connection; connection validation uses your Profile Security Tokens
  • import existing provider issues through a Spec Connection into a new Epic as Requirements or Use Cases

Pop-up modals

  • New Epic: create an Epic manually
  • Generate Epic with Requirements: provide the business Requirement and prompt choices for AI creation
  • New from issues: choose an active Spec Connection, load recent open provider issues, select rows, and import them into a new Epic as Requirements or Use Cases
  • Spec Connection details: add, edit, validate, activate, deactivate, or delete a JIRA, GitHub, or GitLab connection for this specification
  • Coverage map: inspect detailed Requirement coverage behind the selected gap analysis report and see accepted as-is or Requirement-created decisions from earlier reviews; step badges use U for user/external actor, S for system/service/platform, and X when the actor is unclear

The Ubiquitous Language tab is the governed semantic baseline for the active specification and the default input for downstream architecture generation. AI analyzes Requirements and Use Cases Epic by Epic, then consolidates the Epic-level outputs into one project-level review queue. Accepted terms change only when a user accepts, edits, merges, or rejects the staged work. Accepted terms are also indexed for semantic search and appear as Ubiquitous Language term results with an entity/process/policy style badge. Use the term-type toggles in Accepted terms to narrow the visible baseline by Role, Entity, Process, Policy, Value, or Event. Non-conforming term types remain visible so they can be reviewed and corrected instead of disappearing behind a filter.

Spec Connections

When Spec Connections are enabled, use the Spec Connections tab to define where specification artifacts should be synchronized downstream. The specification sync flow supports active JIRA, GitHub, and GitLab connections for Requirements and Use Cases.

For a JIRA Spec Connection, configure:

  • Connection URL: the base JIRA site URL, such as https://your-domain.atlassian.net for JIRA Cloud or your JIRA Data Center base URL
  • Project key: the visible JIRA project key, such as KEY; numeric Project ID is available under advanced identifiers only for unusual JIRA setups
  • Issue type: the JIRA issue type name to create; if omitted, AIKOZO uses Task. This value is the JIRA-side artifact type for every Requirement or Use Case issue created through this Spec Connection. Use the exact issue type name available in the target JIRA project, such as Story, Task, Bug, or Ticket; enter Story when synced AIKOZO artifacts should become JIRA Stories. Numeric Issue type ID is an advanced fallback when the instance does not accept the display name.
  • optional Parent issue key when created issues should sit under an existing JIRA parent; leave it empty when synced issues should not be placed in a JIRA hierarchy; numeric Parent issue ID is an advanced fallback
  • optional JIRA issue links when each synced issue should be linked to an existing JIRA issue; use an existing JIRA link label exactly as shown in Linked work items, and ensure the linked issue key is accessible during connection validation. For the implementation relationship, use implements when the synced AIKOZO issue should implement the linked issue key, for example synced issue ENG-42 implements KEY-21. Use is implemented by for the reverse direction, for example synced issue ENG-42 is implemented by KEY-21.
  • optional labels that should be added to every created and updated JIRA issue, useful for filtering or identifying AIKOZO-created items in JIRA
  • active or inactive status; only active Spec Connections appear in the sync modal

For a GitHub Spec Connection, configure the repository as owner/repository. For a GitLab Spec Connection, configure either the GitLab project ID or repository path, such as group/project. GitHub and GitLab connections synchronize issue title, body or description, and labels.

Spec Connections do not store provider secrets. Store a named provider token in Profile > Security tokens first. New Spec Connections default to Personal visibility: they are visible only to you and use the selected token name from your profile. Shared Spec Connections are visible to authorized users who can access the project, but they always use the current user's provider token marked default rather than the creator's token. Use Validate connection to verify that your current profile token can reach the configured project or repository. Existing connections are treated as Shared.

Visibility and token use

Choose visibility when the Spec Connection is created. Visibility cannot be changed later.

  • Personal: the connection is listed only for the creating user, subject to the same project access checks. Provider calls use the selected named Profile Security Token from that user's profile. Use this when the routing itself is private or when the connection should use a specific named token.
  • Shared: the connection is listed for users who pass project and Spec Connection RBAC. Provider calls do not use the creator's PAT. Each user must have their own Profile Security Token for the provider marked default. If the active user has no default token, AIKOZO disables load/import/sync actions in the UI and the API rejects the operation before a provider call or sync run starts.

Shared validation is also scoped to the active user. A successful validation for one user does not mean every other user can use the connection; each user still needs their own provider token and provider permissions. Personal validation can be shown as connection state because the connection belongs to one user.

From the Epics tab, New from issues reuses the selected active Spec Connection as an issue source. JIRA imports load recent open issues from the configured project and also apply the connection's issue type, parent, and issue link filters when configured. GitHub and GitLab imports load recent open issues from the configured repository or project. The import creates a new Epic, creates the selected issues as either Requirements or Use Cases in a background job. Once the import is queued, the modal closes and the Epic list refreshes while the job continues. Imported artifacts store provider issue text as original text using the project locale rules and adopt the remote issues as downstream mappings so later Sync SPEC updates the same source issues. For localized bilingual projects, the imported provider text is also translated into canonical English while the original provider text is preserved as the localized source.

Connections that are visible but missing the required token for the current user remain listed as unavailable. Add the required Profile Security Token before loading issues, importing issues, or starting Sync SPEC.

Working with JIRA

Use this flow when an analyst wants AIKOZO Requirements or Use Cases to create or update JIRA issues. Spec Connection sync from the Epic page handles Requirements and Use Cases; Test Cases are not synchronized from this flow.

  1. Create a JIRA token:
  2. For JIRA Cloud, create an Atlassian API token at https://id.atlassian.com/manage-profile/security/api-tokens. Store it in AIKOZO as <atlassian-email>:<api-token>, for example analyst@example.com:token.
  3. For JIRA Data Center or Server, create a Personal Access Token from your JIRA profile and store the raw PAT value in AIKOZO.
  4. The JIRA account behind the token must be able to browse the target project and create or edit issues there.
  5. Store the token in AIKOZO:
  6. Open Profile > Security tokens.
  7. Choose the JIRA provider.
  8. Save the token under a name such as sync_bot. Use Make default if this token should be used by shared JIRA Spec Connections. AIKOZO masks the value after save, so copy it from JIRA before closing the JIRA token page.
  9. Create the JIRA Spec Connection:
  10. Open the specification's Spec Connections tab.
  11. Add a JIRA connection.
  12. Choose Personal if only you should see the connection and it should use the selected named token. Choose Shared if authorized users should see the connection and each user should use their own default JIRA token.
  13. Set Connection URL to the base JIRA site URL, such as https://your-domain.atlassian.net.
  14. Set Project key to the JIRA project key that should receive synced issues.
  15. Set Issue type to the JIRA-side artifact type to create, such as Story, Task, Bug, or Ticket; use Story when AIKOZO artifacts should become JIRA Stories.
  16. Optionally set Parent issue key, labels, and JIRA issue links. For issue links, implements means the synced AIKOZO issue implements the configured linked issue, while is implemented by creates the reverse direction.
  17. Select the stored JIRA token name, validate the connection, and mark it active.
  18. Sync AIKOZO artifacts to JIRA:
  19. Open the Epic page and choose the Requirements or Use Cases tab.
  20. Use filters, search, sort, and bookmarked-only controls to define which artifacts should be processed.
  21. Select Sync SPEC, choose the active JIRA Spec Connection, review the filter summary, and start the sync.
  22. The sync runs in the background. The modal shows created, updated, unchanged, remote changes, conflict, and failed counts. For created JIRA issues, AIKOZO stores the downstream mapping so later syncs update the same JIRA issue.

As an alternative starting point, an analyst can create a whole Epic from JIRA: from the Epics tab, choose New from issues, select an active JIRA Spec Connection, load recent open JIRA issues, select the issues to import, and create them as Requirements or Use Cases in a new Epic. Imported artifacts keep their JIRA issue mappings, so later Sync SPEC updates those same source issues.

Epic page

Purpose

Use the Epic page to organize the analyst workload for one Epic across Requirements, Use Cases, Test Cases, and the optional dependency graph.

Main actions

  • switch between Requirements, Use Cases, Test Cases, and the optional Dependency graph
  • change Epic status between draft and final; finalization runs as a backend job, remains visible in Background jobs, and updates the page when complete
  • finalize individual Requirement, Use Case, and Test Case rows; blocked validation responses show a human-readable red Final text message on that row
  • when Epic finalization fails because an artifact's final text does not pass readiness validation, review the red Final text message on the affected row
  • filter Requirements, Use Cases, and Test Cases by search, lifecycle state, and bookmarked follow-up markers
  • create, import, and bulk-enhance Requirements
  • create, AI-generate, auto-generate, and bulk-enhance Use Cases
  • when Use Case or Test Case generation is blocked by non-final source artifacts or missing canonical final text, review the red blocker message directly below the generation modal title
  • when Spec Connections are enabled, sync filtered Requirements or Use Cases to an active Spec Connection; Test Cases are not synchronized from this flow
  • create manual Test Cases and update their review status
  • generate new Test Cases from selected, uncovered, or all Use Cases, with optional scenario type selection
  • bulk-enhance Test Cases that are still in new state with Enhance new
  • export reviewed and final Test Cases from the Test Cases tab with Export Xray when Xray export is enabled
  • open Requirement and Use Case details for deeper refinement
  • inspect traceability from Requirement to Use Case to Test Case in the layered dependency graph when graph capabilities are enabled
  • use SEM6 and LINKS superscripts on Requirement, Use Case, and Test Case rows to see whether semantic embeddings and graph relationships exist; blue means present and gray means missing
  • use the compact ULn superscript to identify rows with open Ubiquitous Language findings, then open the row directly in SmartDoc for review

Pop-up modals

  • New Requirement: create one Requirement manually
  • Import Requirements: bring in a Requirement list from external text
  • New Use Case: create one Use Case manually
  • Generate Use Case from Requirements: build a Use Case from selected Requirements; selected Requirements must be final and have canonical final text
  • Sync SPEC: choose an active usable Spec Connection, confirm the current filters, start an async sync, and review created, updated, unchanged, conflicted, or failed downstream issues
  • New Test Case: create one structured manual or logical Test Case linked to a Use Case and Requirements; when a Use Case is already selected, its linked Requirements are selected automatically
  • AI New: queue AI generation of new Test Case records; selected source Use Cases and linked Requirements must be final and have canonical final text. All user-selectable scenario types are selected by default, and users can limit generation to selected types such as happy_path, negative, or edge

Downstream specification sync

The downstream sync flow is started from the Requirements or Use Cases tab on the Epic page. It uses the active filters on the current tab, so the selected status, bookmarked-only toggle, search term, and sort order define which artifacts are processed.

The sync runs asynchronously through a background job. After you select an active usable Spec Connection and start the sync, the modal polls the run and shows counts for:

  • Created: AIKOZO created a new downstream issue and stored the link
  • Updated: AIKOZO updated an existing linked downstream issue
  • Unchanged: the current Requirement or Use Case already matches the last synchronized downstream issue state
  • Remote changes: importable remote fields changed downstream and can be imported back into AIKOZO after explicit confirmation when AIKOZO did not change the same item
  • Conflicts: AIKOZO refused to update because the stored downstream issue is missing, inaccessible, has no safe sync baseline, or changed remotely outside a safe import
  • Failed: the provider rejected the operation or the connection/token could not be used

The results table shows the same outcome in the Sync result column, with a message such as Issue updated. when AIKOZO pushed local changes downstream.

When creating a downstream issue, AIKOZO sends the canonical issue title, body or description, labels, and provider-specific routing fields through the selected Spec Connection. JIRA additionally sends project, issue type, optional parent, and configured issue links. For existing linked issues, AIKOZO manages only title/body/labels: JIRA summary, description, and labels; GitHub title, body, and labels; GitLab title, description, and labels. Before it updates an existing issue, it reads those fields from the provider and compares them with the last state AIKOZO wrote. The generated traceability block at the end of the remote body or description is ignored during this comparison. If someone edited only the remote body/description text, or edited the remote title for a Use Case while the AIKOZO Use Case stayed unchanged, the row is shown under Remote changes with a Confirm import action. Selecting it imports the remote body or description text, excluding the traceability block, and for Use Cases also imports the remote title as the Use Case name. Imports are confirmed one item at a time. If both AIKOZO and the remote item changed, the row is shown as a conflict and the remediation is to confirm Overwrite remote, keeping AIKOZO authoritative. Timeline entries created by confirmed imports are shown as the confirming user and marked with Downstream sync.

For Requirements, the downstream title is the Requirement human ID. For Use Cases, the downstream title is the Use Case name. The downstream body or description starts with the localized final text when available; if final text is missing, it uses the localized original text. Traceability is appended at the end and uses AIKOZO keys, such as project, specification, Epic, Requirement, and Use Case keys, instead of MongoDB IDs.

Test Cases are not synchronized from this flow.

Xray CSV export

When Xray export is enabled, Export Xray appears on the Test Cases tab. It exports reviewed and final Test Cases for the Epic as a semicolon-delimited CSV compatible with Xray Test Case Importer step mappings. Each Test Case step is exported as a separate row under the same Issue Id; preconditions, test data, and recorded gaps are included in the first row's test summary. The Test type column uses the Test Case scenario type, such as happy_path or negative. The downloaded file is named aikozo-{project-key}-{spec-key}-{epic-key}-tests.csv. Import the file in Jira/Xray through Xray Test Case Importer.

Current limits: the export creates new tests only, so Issue key is empty. It does not create Test Sets or Preconditions automatically, and only the step-based Test Case CSV format is exported.

Requirement page

Purpose

Use the Requirement page to refine one Requirement, maintain its final text, and review its enhancement and relationship history.

Main actions

  • review original text, saved final text, prompt template, and context; the final text editor is empty until final text is saved
  • bookmark the Requirement for later follow-up
  • move to the previous or next Requirement in the same Epic from the context tree
  • save edits, finalize, or defer the Requirement
  • when finalization fails, review the red Final text validation message next to the label
  • copy original text into final text with Use as final; this saves the change and sets the Requirement back to draft
  • run Enhance, optionally enter guidance for the AI enhancement, and inspect enhancement history
  • review similar Requirements in Semantics when enabled
  • suggest, approve, reject, create, and edit Requirement links
  • inspect, add, and remove Use Cases that cover the Requirement
  • inspect the timeline when available

Pop-up modals

  • Create link: add a new relationship to another Requirement
  • Edit link: change an existing Requirement relationship
  • Add Use Case: connect an additional Use Case to the Requirement

Use Case page

Purpose

Use the Use Case page to refine one Use Case, review coverage against Requirements, and maintain links to related Use Cases.

Main actions

  • review original text, final text, prompt template, and context
  • bookmark the Use Case for later follow-up
  • move to the previous or next Use Case in the same Epic from the context tree
  • generate a short Name from the Use Case text and covered Requirements
  • save edits, finalize, or defer the Use Case
  • when finalization fails, review the red Final text validation message next to the label
  • copy original text into final text with Use as final; this saves the change and sets the Use Case back to draft
  • run Enhance, optionally enter guidance for the AI enhancement, and inspect enhancement history
  • inspect covered Requirements and add or remove coverage links
  • inspect associated Test Cases in Test Cases when Test Case capabilities are enabled
  • suggest, approve, reject, and create Use Case links
  • review similar Use Cases in Semantics when enabled
  • inspect the timeline when available

Pop-up modals

  • Add Requirement: connect an additional Requirement to the Use Case
  • Create link: add a new relationship to another Use Case

Test Case page

Purpose

Use the Test Case page to refine one Test Case, inspect its source Use Case and linked Requirements, and review related Test Cases.

Main actions

  • review original text and final text in the same free-form Test Case body used by AI generation
  • bookmark the Test Case for later follow-up
  • move to the previous or next Test Case in the same Epic from the context tree
  • save final text or finalize the Test Case
  • when finalization fails, review the red Final text validation message next to the label
  • copy original text into final text with Use as final; this saves the change and sets the Test Case back to draft
  • inspect linked Requirements and the source Use Case in Requirements
  • suggest AI-classified Test Case links from semantic candidates in the Links tab, then approve or reject the proposed links before they become confirmed graph relationships
  • add confirmed Test Case links manually from the Links tab
  • review semantically similar Test Cases from the embeddings index in Semantics
  • run Enhance to optionally enter guidance and queue bilingual final text generation using the Test Case format, then review formatted enhancement history with prompt, model, and Use as final; generated text is copied into final text only after Use as final is selected
  • review recent Test Case events in Timeline, filter by human, AI, links, or status activity, and expand Details on each event when payload details are available