Staging Workflow & Status Mapping

Overview

The Staging tab is a review queue between AI-generated tests (from Chat) and the permanent Inventory. Tests land in staging, users review/edit them, then promote accepted tests to inventory.

Staging review statuses

Configurable in config.yaml:

staging:
  review_statuses:
    - Pending
    - Needs Review
    - Accepted
    - Rejected
  promotion_status: Approved  # inventory test_status set on promote

These are internal to TestIntel and do not sync to external systems. The default statuses are:

• Pending — newly staged, awaiting review
• Needs Review — flagged for additional review (e.g. by a manager or lead)
• Accepted — approved for promotion to inventory
• Rejected — will not be promoted

Teams can add custom statuses (e.g. "Needs Review - Manager", "Needs Review - QA Lead") by editing the review_statuses list.

Promotion to inventory

When tests are promoted from staging:

1. User selects target project from dropdown (if multiple projects exist)

1. test_status is set to the configured promotion_status (default: "Approved")

1. Tests go through inventory's add_batch with duplicate detection

1. If the test has a Zephyr external key, the status is synced to Zephyr Scale

1. Staging always reads from the default project; inventory targets the selected project

Inventory lifecycle statuses

Inventory test_status values come from the integration's schema:

• Zephyr Scale: Draft, Approved, Deprecated (discovered via testintel discover)
• Xray/Jira: No native lifecycle status — defaults to Draft/Approved/Deprecated
• Manual/AI-generated: Draft by default, Approved on staging promote

Editable fields in staging

When you expand a staged test, the following fields are editable:

• Name — text input
• Steps — textarea (BDD, numbered, plain text — all in one block)
• Expected Result — textarea
• Tags — comma-separated text input
• Type — dropdown (from configured types list)
• Priority — dropdown (P1, P2, P3)
• Review Status — dropdown (from configured review statuses)

Changes are saved explicitly via the Save button (PUT /staging/{index}).

Rejection behavior

When tests are rejected (removed) from staging, their signature (name + steps) is recorded in a blocklist (staging_rejected.json). This prevents the same tests from being re-added to staging if the AI regenerates them in a subsequent chat response.

How it works:

• Clicking "Reject Selected" removes the tests and records their signatures
• On the next "Add to Staging" from chat, any tests matching a rejected signature are automatically skipped
• The button will show how many were skipped (e.g. "3 tests staged — 2 previously rejected skipped")
• Matching is case-insensitive and based on exact name + steps content
• The blocklist is capped at 200 entries (oldest entries are dropped when the limit is reached)

If tests aren't being added to staging: Check whether they were previously rejected. The blocklist only matches tests with the exact same name and steps — editing either field in the AI prompt will produce a test that passes the filter.

Clearing the rejection history: Delete the staging_rejected.json file from the project's storage directory (or the root testintel_data/ for unscoped staging) to reset the blocklist.

Future enhancements

Status mapping (planned)

A full status mapping system would allow teams to configure how staging statuses map to inventory statuses, and how inventory statuses map to external system statuses:

# Future: schema.yaml or config.yaml
status_mapping:
  staging_statuses:
    - Pending
    - Needs Review
    - Needs Review - Manager
    - Accepted
    - Rejected

  inventory_statuses:
    - Draft
    - Approved
    - Deprecated

  promotion_map:
    Accepted: Approved
    default: Draft

  zephyr_map:
    Draft: Draft
    Approved: Approved
    Deprecated: Deprecated

  xray_map: {}  # no native status

The testintel discover command would auto-populate inventory_statuses and zephyr_map from the Zephyr Scale API. Users would configure staging_statuses and promotion_map to fit their workflow.

Jira workflow transitions (planned)

For Xray (where tests are Jira issues), status changes could trigger Jira workflow transitions. This requires:

• Discovering available transitions via GET /rest/api/3/issue/{key}/transitions
• Mapping inventory statuses to transition IDs
• Configuring per-project: xray.approval_field: customfield_10055 or xray.approval_transition: 31

Custom approval fields (planned)

Some teams use custom Jira fields for test approval (e.g. a "Test Status" select field). Support would include:

• Configuring the field ID in config.yaml
• Reading the field on pull to set test_status
• Writing the field on status change

Settings UI for status mapping (planned)

A Settings section where admins can:

• View discovered statuses from Zephyr/Xray/Jira
• Configure staging review statuses
• Map staging → inventory → external statuses
• Test the mapping with a dry-run