Mayz reviews

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.

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, 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	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. Mayz is in the rail when reviews are on for your account.

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#

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 Worker.

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.

Review and verification — how Code checks its own work.
Code in Ysra’s cloud — reviewing a repository or a cloud project.
Limits and costs — every cost in one place.
Commands — ysra mayz in the terminal.