# Project Assistant: Proposals You Approve

> Ask the Project Assistant to run tests, fix a failing test, generate tests, link a requirement or schedule a report. It prepares a proposal card, and nothing changes until you accept it.

Source: https://totalshiftleft.ai/help-center/product-documentation/project-assistant-actions

> **Applies to:** All editions (each action keeps its own edition requirement) · Web app / Desktop app · Your normal permissions apply to every action · Requires an AI provider configured under **AI Settings**

## Overview

The Project Assistant in Shift-Left Studio can do more than answer questions. Ask it to run tests, fix a failing test, generate tests for a feature, link a requirement to an endpoint or schedule a report, and it prepares a **proposal**: a card in the conversation that says exactly what will happen, where, and to what.

Nothing happens until you press the button on the card. When you do, Studio carries out the action through the same path as the matching button elsewhere in the product. A run started from a conversation is the same run the **Run** button starts, with the same permissions, licence and edition checks, run limits and audit log entry.

## Key concepts

| Term | What it means |
|---|---|
| Proposal (offer) | A card describing one change, prepared before it is shown. If it cannot be done, you get a sentence explaining why instead of a card. |
| Preview | The part of the card that lists what will change: tests, environment, checks added (+) or removed (−), items created. |
| Promise line | The small line under the button saying what accepting does, for example "This runs the tests against the environment shown. It happens as soon as you accept." |
| Outcome | The result written under the card after you accept: success text, "Accepted — still running…", or "Nothing was changed." with the reason. |
| Background job | A long action (generation, document parsing, sign-in) that the card follows until it finishes. |

## Before you begin

- Read [Project Assistant: Ask Questions About Your Project](/help-center/product-documentation/project-assistant-overview) for opening the assistant.
- You need the permission for each action you accept. For example, accepting a run needs permission to run tests manually. If you lack it, the outcome says so and nothing changes.
- Edition limits still apply. For example, test packs, JSON-RPC and WebSocket-RPC testing, and performance testing are available only in the editions that include them.

## Step 1 — Ask for the change

Describe what you want in plain words. Be specific about *what*, *where* and *which environment*.

- "Run the checkout tests on QA."
- "Fix the three tests in this failure group."
- "Add a check that the response has an orderId."
- "Generate tests for the Payments feature."
- "Link REQ-E13E05F8 to POST /orders."

If something is missing, the assistant asks. If the change cannot be offered, it explains why and names the next step.

## Step 2 — Review the proposal card

Read the card before accepting. It shows:

1. **What** will happen, in words.
2. **Where**: the environment, project, feature or pack.
3. **The details**: which tests will run; checks marked **+** (added) and **−** (removed); tests that would be generated; the workflow's steps and any gaps.
4. **The promise line** under the button, stating what accepting does and what it leaves alone.

> **Important:** For actions that touch a real system (runs, a single call to an endpoint, load tests) the promise line says so. Pressing the button is the moment it happens.

## Step 3 — Accept, and read the outcome

1. Click the button on the card. Its label says what it does, for example "Run 12 tests on QA". While it works, the button reads **Working…**.
2. Read the outcome under the card:

| Outcome | Meaning |
|---|---|
| Green message | Done. The text comes from the product's own answer, for example "Applied, and re-ran in Development: it now passes." |
| "Accepted — still running. Reopen this thread to see how it ended." | A background job is under way. The card keeps following it. |
| "Waiting for you to sign in. Use the link below — this finishes on its own." | An authentication sign-in is waiting for you at your identity provider. |
| "Nothing was changed." followed by a reason | The action was refused. Nothing was written. The reason says why and, where possible, what to do. |

A proposal can be accepted **once**. After you accept, the button stays disabled, and the outcome stays with the card when you close and reopen the conversation. If the item changed after the card was prepared (for example someone edited the test), accepting is refused as stale; ask again for a fresh proposal.

**Fixes are verified.** When you accept a fix to a failing test in a non-production environment, Studio applies it and runs the test again, then tells you whether it now passes, still fails the same way, or fails differently.

## What the assistant can propose

### Running and analysing

| You ask | What the card does |
|---|---|
| "Run these tests on QA" | Runs the selected tests (by test, endpoint, tag or pack) against the named environment. |
| "Run the nightly pack" / "Stop the running pack" | Runs a pack, or asks a running pack to stop. Finished tests keep their results. |
| "Run the checkout workflow" | Runs a workflow against the named environment. |
| "Analyse that run" | Works out the failure causes of a run. Reads results and changes nothing. |
| "Call POST /orders once so we can see the response" | Calls the endpoint once, for real. A call that changes data is always its own decision. |

### Fixing and improving tests

| You ask | What the card does |
|---|---|
| "Fix these tests" (in a failure cause drawer) | Prepares repairs for you to review. Offered only when the cause is a test problem or a data problem. |
| "What else should this test check?" (validity finding) | Prepares extra checks for you to review, based on responses the product has actually seen. |
| "Make this negative test actually get rejected" | Prepares a new request the API must refuse, keeping every existing check. |
| "Add a check that status is 201 and orderId exists" | Changes the test as shown. It is recorded as your change and can be reverted. |
| "Reclassify this as an environment problem" | Changes what the run analysis says about the group, recorded as your decision. |
| "Run this test once per row of the Users sheet" | Binds the test to a data set. The column it names must exist. |

### Generating tests and working with requirements

| You ask | What the card does |
|---|---|
| "Generate tests for POST /orders" / "…for the Payments feature" / "…for the whole project" | Generates tests. For up to five endpoints the card shows a dry run listing what will be created. For more, it says what will be covered and marks the figure as an estimate. Generation runs in the background. |
| "Approve these requirements" | Records your review decision on the listed requirements. |
| "Link REQ-… to POST /orders" | Records which endpoint a requirement applies to. Asked without an endpoint, the assistant lists candidates with the evidence for each. |
| "Fill the coverage gaps" | Generates tests for uncovered requirements and says how many it *cannot* fill, and why. |
| "Resolve the disagreement on max quantity: use 100" | Records your choice for a rule two documents disagree on. It can be reopened on the Gaps tab. |
| "Re-read this document" / "Parse these documents" | Reads a document again, or queues several to be read one after another. |
| "Accept the detected spec change" | Decides a detected specification change. |

The assistant **never picks a side** in a disagreement between documents. Without your stated choice, it lists every value with the document it came from and asks you to choose.

### Organizing and configuring

| You ask | What the card does |
|---|---|
| "Create a smoke pack with these tests" | Creates or updates a pack. It does not run it. |
| "Tag these tests as smoke" | Labels tests. Packs that select by tag pick them up next time. |
| "Point Staging at https://staging.example.com" | Sets an environment's base URL. Credentials are never changed from here. |
| "Email the weekly report to the QA leads every Monday" | Schedules a report. "Send it now" sends it immediately. |
| "Alert me when the pass rate drops below 90%" | Creates an in-app alert. |
| "Leave a note on this test" / "Notify the team when the pack finishes" | Posts a comment under your name, or sets pack notifications. |
| "Create a mock for GET /products" / "Turn the mocks on" | Creates a mock (switched off), or switches mocks on or off. Switching on says how many other tests it affects. |

The assistant never invents a mock body. It builds one only from a response the product has already seen or a documented example; otherwise it refuses, because a made-up mock is something every test on that endpoint would then pass against.

### Workflows

| You ask | What the card does |
|---|---|
| "Fix the problems the workflow doctor found" | Adds the missing connectors or data extractions, and saves the workflow. Fixes only ever add; nothing is removed or repointed. |
| "Put a login step before Create Order" / "Step 3 should use the other test" | Changes an existing workflow using a limited set of edits: insert, append or move a step, change a step's test, add or rewire a data connector. |
| "Undo that change" | Restores the workflow exactly as it was before that change. |
| "Add a check that the whole workflow finishes in 5 seconds" | Adds a workflow-level assertion. |

Workflow edits are checked by the workflow doctor before they are offered. An edit that would leave new problems is refused with those problems named. Removing a step is offered only when you asked for it in so many words. Workflows with branches, loops or non-test steps are not edited from chat. Undo is refused if someone changed the workflow after the edit, so nobody's later work is thrown away.

### Performance testing (editions that include it)

The assistant can create a performance scenario, set a performance target, mark a baseline run, and start a load run against a **non-production** environment. The card says that a load run sends real traffic for the time shown. You can stop it from the Performance screen.

## Long-running actions and follow-through

Some actions start work that takes minutes: generating tests for a feature, reading a document, building a workflow after its tests are generated, or waiting for you to sign in.

- The card shows the action's own first answer at once (for example, a sign-in link).
- The outcome reads "Accepted — still running…" until the job actually finishes. The assistant never reports success when a job has only been queued.
- If the job fails, the outcome says so, even if it had started successfully.

**Continuation.** If your request had more than one step, for example "Generate the missing tests and then run them on QA", the assistant remembers the rest of the request. When the first job finishes, it picks the conversation back up and **proposes** the next step. It never accepts on your behalf, and it stops after a small number of follow-on steps.

## What the assistant will never do from a conversation

| Never | Why | Where to do it instead |
|---|---|---|
| Delete anything (projects, tests, endpoints, requirements, profiles…) | Deleting is permanent and should be done where the consequences are shown. | The item's own screen. |
| Store or show credentials (passwords, API keys, tokens, client secrets, cookies) | Anything typed into a conversation stays in its transcript. Credentials belong in the encrypted store. | The Authentication screen, **Authentication Profiles**, or the Data Sources screen. |
| Publish or share outside Studio (public dashboard links, embed tokens) | Publishing exposes data outside your team. | The dashboard's share controls. |
| Change where a production environment points | One wrong address sends a whole suite at the wrong live system. | The project's environment settings. |
| Run against production by default | See the production guard below. | The screen's own run controls. |
| Start a load test against production | Sending load to production needs an administrator's approval and a typed confirmation. | The Performance screen. |
| Repair a failure cause in a workflow run | Workflow run analysis explains causes only. | The flow editor and workflow doctor. |
| Patch a test to accept a suspected product bug or contract drift | A test "fixed" to accept a defect never reports it again. | Report the defect; the tests stay red until it is fixed. |
| Weaken a negative test into one that checks nothing | A negative test that accepts anything hides the problem it was written to catch. | Change the request so the API must refuse it. |

**The production guard.** An environment counts as production if an administrator marked it as production, or if its name reads as production (for example "prod", "production", "live", "PRD"). Either one is enough. The assistant refuses to run, call or load-test such an environment unless your server administrator has explicitly allowed assistant-driven production runs *and* the specific request asks for it. By default, that permission is off.

## Troubleshooting

| Symptom | Why it happens | What to do |
|---|---|---|
| You got a sentence instead of a card | The change cannot be done right now; the sentence says why | Follow the next step it names, for example run the test once first. |
| "Nothing was changed." after accepting | A permission, edition, run-slot or safety check refused it | Read the reason. Ask an administrator if it is a permission. |
| Accept refused as stale or "already accepted" | The item changed since the card was made, or the card was already used | Ask again for a fresh proposal. |
| Card still says "still running" | The background job has not finished | Reopen the thread later, or check the test execution screen. |
| "Fix these tests" is not offered | The cause is a product bug, an environment issue, or its repair was already rejected | Read the verdict. Fixes are offered only for test and data problems. |
| Mock proposal refused | No observed response or documented example exists | Run the endpoint once, or add an example to the specification. |

## Best practices

- Name the environment in every request that runs something.
- Read the **+** and **−** lines on a test change before accepting.
- Keep production runs on the screens designed for them.
- For multi-step requests, say the whole plan once; the assistant proposes each step as the previous one finishes.

## FAQ

**Is an accepted change logged?**
Yes. It goes through the same route as the equivalent button, so it gets the same audit log entry, under your name.

**Can I undo a change?**
Test changes are recorded as your change and can be reverted. Workflow edits made from a conversation can be undone by asking "Undo that change". Deletions are never made from chat.

## Related articles

- [Project Assistant: Ask Questions About Your Project](/help-center/product-documentation/project-assistant-overview)
- [Project Assistant: Create Projects, Endpoints, Tests and Workflows](/help-center/product-documentation/project-assistant-creating-content)
- [Teaching the Assistant: Feedback and Learned Notes](/help-center/product-documentation/project-assistant-learning)
- [Run analysis: failure causes and bulk repair](/help-center/product-documentation/run-triage-and-bulk-repair)
- [Test run](/help-center/product-documentation/test-run)

## For administrators (self-hosted installations)

| Setting | Default | What switching it does |
|---|---|---|
| `MCP_ALLOW_PRODUCTION_RUNS` | `false` | `true` allows assistant- and agent-driven runs against production environments, but only when each request also explicitly asks for it. |
| `ASSISTANT_CHAT_ENABLED` | `true` | `false` turns the assistant off entirely. |