---
title: Mayz reviews
description: "Get an independent review of a project with Mayz: a verdict and findings with evidence, made on its own copy without changing anything, then fix and review again."
new_in: "3.5"
---

**Mayz** is Ysra’s independent review: it reads a project and reports what is
wrong, how sure it is, and what to fix first, with evidence. Use it before
people rely on a project, or after Code has changed one. It works in its own
copy, so nothing in your project changes. This page covers starting a review,
what it costs, the verdicts and findings, and what to do when one doesn’t
finish; how Code checks its own work is on [Review and verification](review.md).

## The rule

A review reads; it never writes. Mayz works in its own copy, gets only the
tools that read from the services you connected in
[Plugins](../integrations/plugins.md), and runs with the desktop app’s
extensions off. Fixing what it found is a separate Code task that you start.

## Where a review runs

| Where | Start it from |
|---|---|
| A folder on your computer | The desktop app’s **Mayz** in the rail → **Start a review**; or Code’s start box, **What it does** → **Mayz review**; or `ysra mayz` in the CLI |
| A GitHub repository or a cloud project in [Ysra’s cloud](cloud.md) | Code’s start box, **What it does** → **Mayz review**, with the place under **Where** |
| Right after a Code task | **Review this with Mayz** under the finished task |

The start box asks “What should Mayz review?”. Under **Look at**, choose
**Everything**, **Security**, **Code quality** or **Design**, and tell Mayz
anything it should know, or just send. From the command line:
`ysra mayz <folder> --focus security`; see
[Review a project](../cli/commands.md#review-a-project). **Mayz** is in the
rail when reviews are on for your account.

<!-- media: mayz-report | A Mayz review from Start a review to the report, then Fix selected | Desktop → Mayz → Start a review → Look at: Everything → send → report with Needs work, 1 major → Choose what to fix… → tick F1 → Fix selected -->

## What it costs

| Review | Credits |
|---|---|
| A review on its own | Usually 100–300. It stops at 300. |
| To start one | At least 100 credits left; below that it doesn’t start |
| A check inside a Code thread | Counted in the thread's credits |

The report shows what the review used (“Used … credits”). Below the minimum, the
thread answers: “Your balance is too low for a review. One usually uses about
100–300 credits. Top up to continue; I didn't start.”

## Verdicts

| Verdict | When | What to do |
|---|---|---|
| **Ready** | No blocker or major finding. Minor findings may still be listed. “I found nothing that blocks it.” | Fix the minor ones if you like. |
| **Needs work** | At least one blocker or major finding. “It has problems worth fixing before people rely on it.” | Fix the blockers and majors, then review again. |
| **Unsafe** | At least one security finding of blocker severity. “It has a security problem that must be fixed first.” | Fix it before anyone uses the project. |
| **Not finished** | The review couldn’t read the code to the end, so there is no verdict; only the automatic checks’ findings are listed. | Top up if credits ran out, then **Review again**. |

While it works, the thread shows how the review is going, and a first verdict
can appear early, such as “First verdict: Needs work · 2 major, 1 minor ·
still checking…”.

## Findings

| Part | What it says |
|---|---|
| Number | F1, F2…: what “fix F2” names |
| Severity | **Blockers**, **Major** or **Minor** |
| What and why | What is wrong, and why it matters |
| Evidence | The file and line, or what it saw on a page |
| **Fix needed** | Marked on findings that need fixing |

**Security** findings are grouped: Secrets, Dependencies, Supply chain, Sign-in and access,
Other people’s data, Injection, Sessions and cookies, File uploads, CORS,
Security headers, Rate limits, Configuration and Code. **Not checked** lists
what Mayz couldn’t check, and why; when nothing is listed, “Everything in scope
was checked.” **Screenshots** shows “The pages Mayz looked at, in order”, up
to 30, when the project has pages.

## Supply chain { #supply-chain }

Every review checks the exact package versions the project’s lockfiles install
(npm, Yarn, pnpm, pip, Poetry, uv, Pipenv, Composer, Bundler, Go and Cargo)
against public advisories. The report’s **Supply chain** section lists how
many packages were checked, then:

| Line | What it says |
|---|---|
| Malicious or compromised | A release known to be malicious, hijacked or a typosquat. Installing it runs someone else’s code, so it is a **blocker**, whatever else is true. |
| Known vulnerabilities | By severity, with how many have a fixed version. |
| Each entry | Package, version, advisory, severity, the fixed version and a link. |

Mayz also searches the web for fresh incidents (a package compromised this
week, a new advisory) and cites the page in the finding. When the project has
no lockfile, the section says what wasn’t checked and why. To keep checking
between reviews, use a [Dependency watch](../workers/index.md#dependency-watch)
Worker.

<!-- media: mayz-supply-chain | A Mayz review's Supply chain section with a compromised package | Desktop → Mayz → Start a review on a project pinning a known-malicious release → report: Unsafe → Supply chain: "Malicious or compromised: 1" with the package, version, advisory link and fixed version -->

## Fixing and reviewing again

| Button | What happens |
|---|---|
| **Fix these** | A Code task starts on the findings worth fixing. |
| **Choose what to fix…** → **Fix selected** | A Code task starts on the findings you ticked. |
| **Review again** | A new review. Its report says, under **Since the last review**, which findings are **Fixed** and which are **Still there**. |

In the web app, a report on a folder on your computer is read-only: “Fix and
review again from the desktop app.” Past reviews are listed in **Mayz** under
**Past reviews**.

Save the report as a PDF or as a Markdown file (**Save as Markdown…**); the web
app can also copy it as Markdown (**Copy report**).

## If it doesn’t work

| Symptom | Why | What to do |
|---|---|---|
| “Your balance is too low for a review. …” | Fewer than 100 credits left. | Add credits, then ask again. |
| “Authorize this thread once to let me review the folder.” | Paid work in a thread needs one OK. | Give the OK on the card. |
| **Not finished**: “Your balance ran out before I could read the code, …” | Credits ran out during the review. | Add credits, then **Review again**. |
| **Not finished**: “I couldn't finish this review, …” | The review stopped for another reason. | **Review again**. |
| No **Fix selected** in the web app | The project is on your computer. | Open the report in the desktop app. |

## Related

- [Review and verification](review.md) — how Code checks its own work.
- [Code in Ysra’s cloud](cloud.md) — reviewing a repository or a cloud project.
- [Limits and costs](../workspace/limits.md) — every cost in one place.
- [Commands](../cli/commands.md#review-a-project) — `ysra mayz` in the terminal.