DEV Community: Albert Alov

In 2013 I wrote a diploma on elliptic curves. Last night my tool used them to check its own release.

Albert Alov — Sun, 01 Nov 2026 23:32:06 +0000

TL;DR: In 2013 I wrote a university diploma on elliptic-curve cryptography, and it went into a drawer. Thirteen years later the same math signs most of what you npm install. I taught croak 🐸, my pre-install gate for AI agents, to check those signatures itself. Last night it checked its own fresh release: verified. Then I gave it the same signature with a different tarball: invalid. Below is what that check actually involves, and why the curve is the easy part.

The diploma in the drawer

In 2013: a diploma on elliptic curves and key exchange. Points, groups, a lot of modular arithmetic. Defended, filed, forgotten.

I went into test automation, and the curves stayed in the drawer.

Then AI agents started running npm install on their own.

What croak does, in 30 seconds

An install doesn't just download code. It runs it: postinstall, native builds, whatever a package wants. An agent does this all day, in your terminal, usually without reading anything. It also invents package names that sound right, and attackers register those names.

croak sits between the agent and the install. It's a Claude Code hook: before a shell command runs, croak has npm or pnpm plan the install (resolve it, run nothing), then reads that plan as data: install scripts, the lockfile, registry metadata, and the code of every new package, unpacked in memory and never executed. It gives a verdict and explains it to the agent:

agent:  npm install reactt-domm

croak:  🐸 croak blocked this command before it ran.
        reactt-domm: not on npm; did you mean `react-dom`?
        Do not work around this check (another package manager, a different
        command, or editing files to install it); tell the user what croak
        found and let them decide.

🟢 allow: the hook stays silent.
🟡 warn: Claude Code asks you. An esbuild-style postinstall that downloads a binary lands here.
🔴 block, or a check that couldn't finish: denied, with the reason.

It also scans an unfamiliar repo before you open it (croak repo: VS Code tasks that run on open, code hidden after hundreds of spaces, obfuscation), because "clone this take-home assignment and run it" is a real attack too.

It's early, and it misses things. On its own eval it flags all 36 attacks but blocks only 27; the other nine go to a human as 🟡. I'd rather publish that number than a prettier one.

Why an agent should care who built a package

Most attacks give themselves away in the code: a postinstall that pipes curl into sh, process.env posted somewhere. And install scripts are losing ground anyway: pnpm 10 and npm 12 no longer run a dependency's scripts unless the project allows them. I checked with a bait package that writes a marker file: npm 11 still runs them; npm 12 doesn't.

That pushes attacks into code you import, and that code can look exactly like the real thing. Someone steals a maintainer's token, publishes from a laptop, and the tarball looks like every release before it.

That is the question code can't answer: who built this tarball, and from what?

npm has an answer. It's called provenance. And it's elliptic curves all the way down.

npm provenance in one minute

When a package is published from CI with provenance, a few things happen in a couple of seconds:

The CI job proves who it is to Fulcio, Sigstore's certificate authority, with its OIDC token.
Fulcio issues a certificate for a brand-new key. The certificate says "this key belongs to release.yml in repo X, at commit Y". It is valid for ten minutes.
The job signs a statement: "package Z, version V, has this SHA-512".
The signature and certificate go into Rekor, a public append-only log. Rekor signs a promise: "I saw this, at this time".

Here's my own release from last night, read straight from the certificate:

leaf key:  ec { namedCurve: 'prime256v1' }      // P-256
valid:     Nov  1 23:13:03 2026 GMT -> Nov  1 23:23:03 2026 GMT   // 10 minutes
issuer:    O=sigstore.dev, CN=sigstore-intermediate

A key that lives for ten minutes and is then thrown away. The trust comes from the log, not from keeping a secret for years.

Count the curves. The registry's own signature on every package: P-256. The build's ten-minute key: P-256. Rekor's key: P-256. (Fulcio's CA uses its bigger sibling, P-384.)

My diploma, signing my node_modules.

The one line that isn't the hard part

Here is the elliptic-curve part of croak's verifier:

verify("sha256", message, leaf.publicKey, signature)

One line. node:crypto does the curve math, and it does it better than I would. No point addition by hand, no hand-rolled anything. In 2026, writing your own ECDSA would be a red flag, not a skill.

All the hard parts moved into the plumbing around that line. A signature verifies something. The question is whether it is the thing you think. croak's check, in order:

const logged = readLogEntry(entries[0], trust.rekor); // 1. Rekor promised it saw this, and when
const leaf = leafOf(material);
checkCertificate(leaf, trust.fulcio, logged.loggedAt); // 2. Fulcio issued it, valid at that moment
// 3. the envelope's signature verifies with the leaf key
// 4. the log entry is for this exact signature, certificate and payload
checkSubject(payload, subject);                        // 5. the statement is about THIS tarball
return { status: "verified", identity: fulcioIdentity(leaf.raw) };

A few things I only learned by building it:

Time comes from the log. The certificate expired ten minutes after the build. Checking it against now would fail every package ever published. So the question is "was it valid when Rekor logged it?", and that time is only trusted because Rekor signed it.
The statement can lie, the certificate can't. The signed statement includes build details, but the publisher wrote those. Who built it has to come from the certificate Fulcio issued. Node verifies certificate chains but won't show you Fulcio's custom extensions, so croak has about 170 lines of DER parsing to read them. Every length is checked against the bytes actually there, because the certificate comes from the registry.
The signature is over an envelope, not the payload. DSSE signs "DSSEv1 <type length> <type> <payload length> <payload>". Sign the raw JSON instead and a valid signature could be reinterpreted as a different type.
Pin, don't fetch. The Fulcio and Rekor keys are pinned in the code. Fetching them from the same place as the package would just ask the server to vouch for itself.
"I can't tell" is not a pass. A bundle shape croak doesn't support, like a newer Rekor log, comes back unverifiable, not verified. Only a bundle that claims something its signatures don't back is invalid.

Pointing it at itself

Last night I tagged croak 0.1.4. The release workflow built it, packed it once, and published that exact tarball with provenance. Then I asked croak, through its own verifier, about itself:

latest: 0.1.4
0.1.4: verified https://github.com/vola-trebla/croak/.github/workflows/release.yml@refs/tags/v0.1.4
       @ a598a5863c9146429859323e2858421e9db16f21 logged 2026-11-01T23:13:03.000Z

The workflow file, the tag, the commit. Logged at 23:13:03, the same second the ten-minute certificate was born.

Then the check that matters: the same signature, but compared against the previous release's tarball hash.

0.1.4 bundle against 0.1.3's tarball: invalid

A real signature over the wrong bytes. That's the tampered-tarball case, and it has to say no.

The irony

The first time croak looked at itself, it flagged itself.

Version 0.1.0 shipped with my source comments in it. One of those comments explained the obfuscation detector by quoting the pattern it hunts for, globalThis[key](…). croak scanned its own installed files and found "obfuscated code".

The fix was one compiler flag, removeComments. Now CI installs the packed tarball and runs croak on it before every release. A security tool that can't pass its own scan doesn't get published.

What provenance does not prove

This is the part that's easy to oversell.

Provenance proves where a tarball came from: this workflow, this repo, this commit. It does not prove the code is safe. A malicious maintainer can publish malware with perfect provenance from their own CI.

So in croak it's one signal among many, and it's used as a comparison:

A package that used to have provenance and suddenly doesn't, in a release that runs an install script? That's what a stolen token looks like. 🔴
Provenance from a different repository than the version before? Worth a hard look. 🟡 With a new install script on top: 🔴
Provenance that verifies, but for another version or another tarball? A replay. 🔴
No provenance ever? Most packages. Not suspicious on its own.

What you should do today

Check your installs: npm audit signatures verifies registry signatures and provenance for what's in your lockfile. It's already in npm.
If you publish: use trusted publishing from CI (npm trust github <pkg> --file release.yml --repo you/repo). No long-lived token to steal, provenance for free.
Pack once, publish what you tested. Don't let npm publish repack after your tests ran.
Read provenance as "where", never as "safe".
If an AI agent installs packages for you: put a gate in front of it. croak is one: npm i -g @vola-trebla/croak.

Thirteen years ago I thought that diploma was the end of elliptic curves for me. Turns out they were just waiting for npm install.

croak is open source and early: github.com/vola-trebla/croak. Issues, and attacks it misses, are welcome.

🐸

OpenTelemetry JS 3.0 just shipped. I tested both lines side by side. Here's what broke.

Albert Alov — Sun, 25 Oct 2026 03:31:34 +0000

TL;DR - On October 20, OpenTelemetry JS shipped @opentelemetry/api 1.10 and SDK 3.0. I was building a library that has to work with whatever OTel setup an app already has, so I ran the same test suite against both lines. I found three breaking changes, a peer range split that one dependency can't span, an app quietly running two copies of the OTel API, and a Node 24 behavior that contradicts the Node 24 docs. Everything below is reproduced in code.

Why I had to care about both lines

I'm building a test library for AI agents. It records OpenTelemetry gen_ai.* spans while a test runs and asserts on what the agent did. The hard requirement: never break the app's own telemetry. No replaced providers, no fighting over globals, and the app should export exactly the same spans with or without my library.

That means I don't get to pick an OTel version. The app picks it. And as of this week, apps are split:

Line	API	SDK	`sdk-node`
Legacy	≤ 1.9	2.x (2.12)	0.2xx (0.223)
Modern	1.10	3.0	0.300

So I wrote a spike that runs the same 27 scenarios on both lines, with Vercel AI SDK 7 as the instrumentation. Here's what came out.

1. Three breaking changes in SDK 3.0

`SimpleSpanProcessor` takes an options object

// SDK 2.x
new SimpleSpanProcessor(exporter);

// SDK 3.0
new SimpleSpanProcessor({ exporter });

TypeScript catches this. Plain JavaScript doesn't. With the old call shape on 3.0, nothing throws at construction. Spans just never arrive, and the only trace of the problem is a diag log entry:

TypeError: Cannot read properties of undefined (reading 'export')

forceFlush() then fails with the same error for forceFlush. If your diag logger is off, your traces silently vanish.

`sdk-trace-base` became `sdk-trace`, and the provider was renamed

The 3.0 tracing SDK lives in a new package, @opentelemetry/sdk-trace. The old @opentelemetry/sdk-trace-base tops out at 2.12, which is already a thin shim re-exporting from the new package. In 3.0, BasicTracerProvider is gone. The class is now TracerProvider:

// SDK 2.x
import { BasicTracerProvider } from '@opentelemetry/sdk-trace-base';

// SDK 3.0
import { TracerProvider } from '@opentelemetry/sdk-trace';

`sdk-node` dropped its re-exports

sdk-node 0.2xx re-exported the whole SDK as namespaces, so a lot of setup code looks like this:

import { NodeSDK, tracing } from '@opentelemetry/sdk-node';
const exporter = new tracing.InMemorySpanExporter();

In 0.300, the package exports exactly two things: NodeSDK and startNodeSDK. tracing is undefined, so the line above throws Cannot read properties of undefined (reading 'InMemorySpanExporter').

2. One dependency can't span both lines

These are the peer ranges as published:

Package	`@opentelemetry/api` peer range
`sdk-trace-base` 2.12	`>=1.3.0 <1.10.0`
`sdk-node` 0.223	`>=1.3.0 <1.10.0`
`sdk-trace` 3.0	`>=1.10.0 <1.11.0`
`sdk-node` 0.300	`>=1.10.0 <1.11.0`
`context-async-hooks` 3.0	`>=1.0.0 <1.11.0`

The ranges don't overlap. If a library depends on any SDK package, it supports exactly one line, and every app on the other line gets peer warnings or a second SDK.

My fix was to depend on no SDK at all. The library ships a small in-memory Tracer written against @opentelemetry/api only, and takes the API as a peer dependency, so it always shares the app's copy. That last part turned out to matter more than I expected.

3. Your app may be running two copies of the OTel API

Vercel's @ai-sdk/otel 1.0.150 lists the API as a regular dependency, pinned to an exact version:

"dependencies": {
  "@opentelemetry/api": "1.9.1"
}

Put that in an app on the modern line and you get two copies:

node_modules/@opentelemetry/api                                   → 1.10.0  (the app)
node_modules/.pnpm/@ai-sdk+otel@…/node_modules/@opentelemetry/api → 1.9.1   (@ai-sdk/otel)

It still works, and the reason is worth knowing. OTel keeps its globals (tracer provider, context manager, propagator) on a shared global object, and every API copy checks the registered version before using it. Within a major version, the rule in api/src/internal/semver.ts boils down to:

// A copy may use a global only if the global was registered by the same or a NEWER minor.
ownVersion.minor <= globalVersion.minor

So an older copy can read globals registered by a newer one, but not the other way around. I checked both directions with two API copies side by side:

Global registered by	Read by	Result
API 1.10	API 1.9	✅ sees the registered context manager
API 1.9	API 1.10	❌ gets a no-op manager, the value is silently lost

The modern line plus @ai-sdk/otel is the safe direction: the app registers with 1.10, and the SDK reads with 1.9. Now flip it. An app on the legacy line registers with 1.9, and any library that brings its own 1.10 copy gets no-ops. It throws no error and logs no warning. Its spans and context just aren't there.

Check what you have:

pnpm why @opentelemetry/api   # or: npm ls @opentelemetry/api

If you maintain a library: make @opentelemetry/api a peer dependency, never a direct one. That's how you guarantee one copy.

4. Node 24: `AsyncLocalStorage.disable()` doesn't do what the docs say

OTel's context manager for Node is a thin wrapper around AsyncLocalStorage, and its disable() calls AsyncLocalStorage.disable(). I wrote my own small manager to drop the context-async-hooks dependency (its peer range caps the API below 1.11). CI went green on Node 22 and red on Node 24.

Here's a minimal reproduction:

import { AsyncLocalStorage } from 'node:async_hooks';
import { setTimeout as sleep } from 'node:timers/promises';

const als = new AsyncLocalStorage();
const inFlight = als.run('ctx', async () => {
  await sleep(5);
  return als.getStore();
});
await sleep(1);
als.disable();
console.log(await inFlight);

Runtime	Output
Node 22.23	`undefined`
Node 24.22	`'ctx'`
Node 24.22 with `--no-async-context-frame`	`undefined`

The Node 24 docs say that after disable(), "all current contexts linked to the instance will be exited." On Node 24, an operation that's already in flight keeps its store anyway. The cause is AsyncContextFrame, which became the default AsyncLocalStorage implementation in Node 24. Turn it off and you get the documented behavior back.

Who cares? Mostly test suites. A common pattern is afterEach(() => context.disable()). On Node 24, async work that's still running from the previous test can keep its context. My manager now keeps its own disabled flag, so active() returns ROOT_CONTEXT after disable() on every runtime, until the next with().

Two smaller gotchas

NodeSDK + SimpleSpanProcessor exports asynchronously. It waits for async resource detection before exporting. A test that reads an InMemorySpanExporter right after a span ends sees zero spans. Call processor.forceFlush() first. I lost a while on this one: my "app exports the same spans" check reported a baseline of 0.
pnpm 12 won't install anything published less than a day ago. ai@7.0.153 came out the same afternoon I needed it, and I got ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION. Don't bypass it; pin the previous release. That's the supply-chain policy working as intended.

Checklist

[ ] Run pnpm why @opentelemetry/api and confirm a single copy, or at least that the app's copy is the newest one.
[ ] If you write a library, make the OTel API a peer dependency and don't depend on an SDK package unless you must.
[ ] Moving to SDK 3.0: switch to new SimpleSpanProcessor({ exporter }), @opentelemetry/sdk-trace and TracerProvider, and stop importing tracing from sdk-node.
[ ] Turn on the diag logger in tests (diag.setLogger). Silent export failures only show up there.
[ ] On Node 24, don't rely on AsyncLocalStorage.disable() to cut off in-flight async work.
[ ] Compare the shape of exported spans (names, parents, attributes), not just their names. Name-only checks let a changed parent slip through. I learned that from my own code review.

What I'm building

All of this came out of the first spike for toadwright 🐸, a Playwright-style test library for AI agents. You assert on the agent's trajectory (tools called, order, arguments, cost), and every test runs N times, because one green run proves nothing. It's early. The spike, the matrix that runs both OTel lines in CI, and the design decision behind it are public: ADR-001 · repo.

The next post will be about the part that actually matters: what happens when you run the same agent test ten times.

Have you hit the two-copies problem in a real app? I'd love to hear how it showed up. 🐸

My security tool aced its own exam. Then I ran it on real repos

Albert Alov — Sun, 25 Oct 2026 03:25:31 +0000

TL;DR - I'm building croak 🐸, a tool that checks what a repo or a package install would do before any of its code runs. On my own eval it caught every attack with zero false alarms. On its first run against 13 popular open-source repos, it flagged zod and esbuild as malicious. This post is about why a self-written eval wasn't enough, and the two changes that real code forced.

The problem croak is for

npm install doesn't just download code. It runs it: postinstall scripts, native builds, whatever a package decides to do. Opening a folder in VS Code can run a task too. And AI coding agents now do both all day, usually without reading anything first.

So I'm building a gate that inspects a repo as plain data and gives a verdict before anything executes:

🟢 allow: nothing suspicious found (not a guarantee)
🟡 warn: behavior that needs your attention (never "safe")
🔴 block: strong evidence of an attack

It's early-stage. Seven detectors so far: install scripts, VS Code autorun tasks, hidden code, obfuscation, dangerous git config, committed node_modules, and files too large to scan.

Eval first

I wrote the eval before the first detector. Every case is a small fixture repo with an expected verdict:

{
  "id": "d-postinstall-curl-pipe",
  "threat": "D",           // fake "test assignment" repos
  "expect": { "verdict": "block", "rules": ["repo/lifecycle-script"] }
}

Payloads are inert: they point at reserved .invalid domains or just echo. Two rules turned out to matter a lot.

1. Every attack gets a benign twin. A postinstall that pipes curl into sh sits next to one that runs prisma generate. A 413-character line hiding eval after 320 spaces sits next to an honest 2,875-character Tailwind safelist. Without twins, a detector that just flags "has a postinstall" or "has a long line" looks perfect.

2. You can't let the eval be gamed. My review agent wrote a detector that matched only the SYNTHETIC marker comment in my fixtures. It scored 4/4 with zero false alarms, because only the malicious fixtures had the marker. Now every fixture, benign or malicious, carries it (a test enforces that), and a lint rule forbids detector code from mentioning it.

After a few iterations the eval looked great:

croak eval — 32 cases (16 malicious, 16 benign)
  flag recall   16/16  100%
  false alarms   0/16    0%

I wrote every one of those 32 cases myself. That's the catch.

The first real run

I pinned 13 popular repositories by commit (axios, express, zod, hono, ky, husky, chalk, create-t3-app, trpc, esbuild, sharp, vscode-extension-samples, vue core) and scanned them. 7,455 files took about one second.

Verdict	Repos
🟢	express, hono, husky, chalk, create-t3-app, sharp
🟡	axios, ky, trpc, vscode-extension-samples, vue core
🔴	zod, esbuild

zod and esbuild are not malware. Two false blocks on the first real run.

Lesson 1: "near" means near

Both blocks came from the obfuscation detector:

[block] zod/packages/zod/src/v3/types.ts:607  repo/obfuscation
        obfuscated code: escapes (line 607), next to eval or decoding

Line 607 of zod is a Unicode regex: dense \u… escapes, a weak signal I deliberately don't treat as obfuscation on its own. But the file also calls atob() for base64 validation, thousands of lines away. My rule said "weak signal + eval/decoding in the file → block". The file was the wrong unit.

The fix: a weak signal only escalates when eval or decoding is within three lines of it. const font = "…base64…"; eval(atob(font)) on adjacent lines still blocks. A regex and an unrelated atob() in different corners of a big file don't. Strong signals (_0x identifiers, string-array rotation, calls through computed globals) keep the file-wide rule.

My synthetic fixtures were all small files. That bug couldn't exist in my eval.

Lesson 2: a warning everyone ignores is worse than none

The second finding wasn't a bug. Seven of the 13 repos got 🟡 because their install scripts ran things like:

prepare: husky
prepare: npm run build      → tsc
postinstall: prisma generate

Technically true: code runs on install. In practice it's noise, and noise trains people to skip the yellow line, which defeats the tool.

The new rule is strict on purpose. A script is only an info note when every command is a known tool, or an npm run call to a script that is itself routine, and there is nothing else: no network, no local files, no inline code, no suspicious code signals. Anything unknown stays 🟡. So cd client && npm install (a nested install runs other packages' scripts) is still a warning, and prisma generate && curl … | bash is still a block. Recognizing a known tool never launders the rest of the command.

Before and after

Real-world corpus	First run	Now
🔴 blocks	2	0
repos at 🟡	7 / 13	5 / 13
warnings	35	26

The 26 warnings that remain are all explainable: nested installs, an unknown tool that downloads files at install time, install scripts that run local code. That's exactly what 🟡 is for.

The synthetic eval didn't move: still 100% flagged, zero false alarms. That's the point. Both kinds of runs have to pass at once.

What I'd tell myself a week ago

A synthetic eval proves your detectors match your imagination. It's necessary, but on its own it isn't enough. Pin a few real repos and run them on every significant change.
Write the benign twin first. If you can't describe what honest code looks like, you can't tell your detector what not to flag.
Assume your eval can be gamed, and check whether it can, ideally with a reviewer that has no stake in the score.
Treat noise as a defect, not a cost of being careful.

What croak doesn't do (yet)

It doesn't follow require chains past the file a script runs directly. It doesn't check package installs yet (that's next), it isn't an antivirus, and there's no AI layer yet. When one comes, it will only be allowed to raise a verdict, never lower one. All of that is written down in the repo, because a security tool that oversells itself is its own kind of vulnerability.

croak is TypeScript with zero runtime dependencies, and early-stage. The repo is going public soon: [link]. I'll write about the install check and the cryptography chapter (it starts with my 2013 thesis) in later posts.

Thanks for reading. If you've built evals for detectors or LLM features, I'd love to hear how you keep them honest. 🐸

How react-render-profile-mcp works under the hood - and what it found in a real project

Albert Alov — Fri, 22 May 2026 13:26:21 +0000

I've been building react-render-profile-mcp for a few months — an MCP server that decodes React DevTools Profiler exports so AI agents can diagnose and now fix render performance. Earlier posts covered v0.1 and v0.3.1. This is v1.0.

I want to do two things in this post: show what it actually found on a real open source project, then explain how the engine works inside — because "it's just an MCP wrapper" is not the right mental model. 🐸

Act 1 — What it found on slash-admin

I ran the full cycle on slash-admin, a real React admin dashboard with Zustand and React Router. Target: UserProfile in src/pages/management/user/profile/index.tsx.

Diagnostics

get_render_summary → find_spurious_renders → analyze_compiler_efficacy → suggest_memoization

12 spurious renders on UserProfile
42ms wasted
Trigger: UNSTABLE_PARENT_REF
Invalidation Index: 22.5
ROI score: 2.5 (threshold is 1.5)

The problem was two inline constants inside the render body:

function UserProfile() {
  const bgStyle: CSSProperties = {
    position: "absolute",
    inset: 0,
    background: `url(${bannerImage})`,
    backgroundSize: "cover",
    backgroundRepeat: "no-repeat",
  };

  const tabs = [
    { icon: , title: "\"Profile\" },"
    { icon: , title: "\"Followers\" },"
    // ...3 more
  ];

  return ( ... );
}

New object reference on every render. Every memoized child downstream gets invalidated on every pass, regardless of whether anything actually changed.

Auto-remediation and the edge case

remediate_component runs three AST passes. On this file it hit a real edge case immediately:

import type { CSSProperties } from "react";

Type-only import. Adding React.memo to the default export without fixing this would produce a runtime ReferenceError. The remediator detected it, rewrote the import, and continued:

-import type { CSSProperties } from "react";
+import React, { CSSProperties } from "react";

Then the three passes ran:

-function UserProfile() {
-  const bgStyle: CSSProperties = { position: "absolute", inset: 0, ... };
-  const tabs = [{ icon: , title: "\"Profile\" }, ...];"
+const bgStyle: CSSProperties = { position: "absolute", inset: 0, ... };
+const tabs = [{ icon: , title: "\"Profile\" }, ...];"

+function UserProfile() {
   const { avatar, username } = useUserInfo();
   return ( ... );
 }

-export default UserProfile;
+export default React.memo(UserProfile);

This gap in the original implementation was found by running on real code. A new unit test now covers the import type case. 57 tests passing.

42ms of spurious renders eliminated. Zero code written manually.

Act 2 — How it actually works inside

This is the part that matters if you want to understand what's happening, not just that it works.

Layer 1: decoding the profiler format

React DevTools exports version 5 — a format most developers have never had to parse manually. The tricky parts:

changeDescriptions is serialized as Map.entries(), not as a JSON object:

"changeDescriptions": [[3, {"isFirstMount": true}], [4, {"props": []}]]

The parser normalizes this on load into Record so the rest of the code can work uniformly.

operations is an opcode integer array encoding tree mutations. Format:

[rendererID, rootFiberID, stringTableSize, ...strings, ...opcodes]

Opcode 1 (ADD):    [1, id, type, parentID, ownerID, nameStringIdx, keyIdx]
Opcode 2 (REMOVE): [2, count, id1, id2, ...]
Opcode 3 (REORDER_CHILDREN): [3, id, count, ...childIds]

The parser walks this array to reconstruct the fiber name map, parent-child relationships, and unmount counts — all without a React runtime, just integer arithmetic and string table lookups.

Two name resolution strategies, with fallback:

Primary: snapshots map (human-readable, always preferred)
Fallback: decode the string table from operations opcodes

This dual strategy is what makes the parser robust against different DevTools export configurations.

Spurious render detection relies on one non-obvious React behavior: when a component re-renders due to an unstable prop reference but no prop values actually changed, React records props: [] (empty array) in changeDescriptions. props: null means unknown. props: ["value"] means the value prop genuinely changed. The parser uses exactly this signal:

function isSpurious(fiberID: number, commit: ProfileCommit): boolean {
  const desc = commit.changeDescriptions?.[String(fiberID)];
  if (!desc) return false;
  if (desc.isFirstMount || desc.context || desc.didHooksChange) return false;
  if (desc.state && desc.state.length > 0) return false;
  return desc.props !== null && desc.props.length === 0;
}

React 18 concurrent mode false-positive prevention: startTransition and useDeferredValue can cause a component to render multiple times as React speculatively renders and discards incomplete trees. These show up with priorityLevel: "Low Priority" or "Idle". The parser tracks these separately so they don't get flagged as regressions.

Layer 2: the Invalidation Index

analyze_compiler_efficacy computes a score per component:

I = (spurious_count / total_renders) × wasted_ms

This matters because raw wasted_ms alone can be misleading. A component with 100ms wasted across 100 renders (1ms each) has a very different profile than one with 100ms across 2 renders (50ms each). The index captures both the frequency and the cost — which is what determines whether React.memo overhead is actually worth it.

The threshold for suggest_memoization is avgSelfMs > 2ms. Below that, the Object.is comparison overhead of React.memo can exceed the render cost, making memoization actively harmful.

Layer 3: the AST remediation engine

ASTPerformanceRemediator uses ts-morph (TypeScript compiler API wrapper) to perform three passes over the source file:

Pass 1 — static hoisting. Walks the render body looking for VariableStatement nodes whose initializers are ObjectLiteralExpression or ArrayLiteralExpression. For each one, checks if any Identifier inside references a component-scope binding (props, state, hooks). If not — it's static and gets hoisted to module scope. This runs in a loop until no more hoistable statements are found, handling multiple declarations per component.

Pass 2 — useCallback wrapping. Walks ArrowFunction nodes inside the render body. For each one matching an unstable prop name, calls resolveReactiveDependencies — which walks all Identifier descendants of the arrow function and intersects them with the component's local scope bindings. This gives the dependency array automatically, without requiring the developer to reason about it manually.

Pass 3 — React.memo wrapping. Checks if ROI score exceeds 1.5, then finds the default export assignment and rewrites it. The import check (the edge case from slash-admin) now runs first: if the file only has import type ... from "react", it rewrites it to a value import before applying the wrapper.

All three passes operate on the live AST and call saveSync() once at the end — no intermediate file writes, no risk of partial state.

Why no React runtime dependency

Everything described above — opcode decoding, name resolution, spurious render detection, cascade tracing — runs on pure JSON and TypeScript. No React, no DevTools, no browser. This is intentional: the server needs to be fast to start (it runs as an npx command on every MCP client connection) and safe to run in any environment.

Setup

{
  "mcpServers": {
    "react-render-profile": {
      "command": "npx",
      "args": ["-y", "react-render-profile-mcp"]
    }
  }
}

Export a profile: React DevTools → Profiler tab → Record → interact → Stop → Save icon (💾). Pass the .json path as profile_path.

GitHub: vola-trebla/react-render-profile-mcp
npm: npx react-render-profile-mcp

Questions about the opcode decoder or the dependency inference logic welcome. 🐸

react-render-profile-mcp v0.3.1 - 4 new diagnostic tools for React Compiler, hydration, Zustand, and state cascades

Albert Alov — Fri, 22 May 2026 12:14:59 +0000

A few weeks ago I published a post about react-render-profile-mcp — an MCP server that decodes React DevTools Profiler exports so AI agents can actually diagnose render performance instead of guessing at raw fiber IDs.

v0.1 shipped with 5 tools. v0.3.1 adds 4 more, each targeting a class of problems the original couldn't touch. Here's what's new. 🐸

What was already there (v0.1)

Quick recap for anyone who missed the first post:

get_render_summary — total commits, render time, top components, lifecycle anomaly flags
find_spurious_renders — components that re-rendered with no actual prop/state change
get_hottest_components — ranked by CPU self-time
trace_render_cascade — what triggered a commit and what re-rendered as a result
suggest_memoization — ROI-scored React.memo recommendations

These covered the "something is rendering too much" class of problems. What they couldn't tell you: why your React Compiler isn't helping, where hydration broke, which Zustand selector is in a loop, or how deep a context update actually propagates.

What's new in v0.3.1

1. `analyze_compiler_efficacy`

React Compiler (React 19) and manual React.memo should eliminate spurious renders. Often they don't — because of inline object allocations or unstable parent refs that bypass memoization entirely.

This tool computes an Invalidation Index per component:

I = (spurious_count / total_count) × wasted_ms

High index = memoization is present but not working. The tool tells you exactly why:

{
  "severity": "CRITICAL",
  "component_name": "ProductList",
  "ineffective_render_count": 23,
  "wasted_ms": 84.3,
  "trigger_cause": "UNSTABLE_PARENT_PROP_REFERENCE",
  "recommendation": "Memoize parent props with useMemo/useCallback or hoist static objects out of the parent render function."
}

Without this, your agent might suggest adding React.memo to a component that already has it — and has it for a reason that makes it useless.

2. `diagnose_hydration_and_suspense`

Two separate problems, one tool:

Hydration mismatches — when React discards server HTML and remounts the entire tree from scratch. Shows up as an abnormally long initial mount with a spike of unmounts immediately after. The tool flags these as HYDRATION_MISMATCH_RECOVERY with the affected Suspense boundaries and blocking duration.

Suspense waterfalls — nested boundaries fetching sequentially instead of in parallel. Detected by measuring the gap between consecutive Suspense resolves against a configurable waterfall_threshold_ms (default: 100ms).

{
  "severity": "WARNING",
  "anomaly_type": "NESTED_MOUNT_FETCH_WATERFALL",
  "root_component": "ProfileDetails",
  "blocking_duration_ms": 120.5,
  "recommendation": "Prefetch data at the parent level or use Promise.all."
}

3. `evaluate_external_store_performance`

Zustand and Redux with useSyncExternalStore have two failure modes that are hard to catch manually:

Unstable selector object allocation — a selector returns a new object reference every call, triggering rapid consecutive renders. The tool detects components that render multiple times in consecutive frames and flags the selector as the cause.

Sync concurrency bypass — a heavy store update runs synchronously in a high-priority lane, blocking the main thread. Should be in startTransition instead.

{
  "severity": "CRITICAL",
  "impacted_components": ["CartSummary"],
  "is_infinite_loop": true,
  "trigger_cause": "UNSTABLE_SELECTOR_OBJECT_ALLOCATION",
  "recommendation": "Wrap the selector in useCallback or return primitive values."
}

4. `trace_state_cascade_footprint`

Given a commit index, this reconstructs the virtual component tree and measures how far an update actually propagated:

Which component triggered the update
Whether it went through a context provider or a store subscriber
How many levels deep it reached
How many consumer components re-rendered

{
  "severity": "HIGH_FOOTPRINT",
  "update_trigger_source": "ThemeButton",
  "propagation_channel": "CONTEXT_PROVIDER",
  "cascade_render_depth": 7,
  "rendered_consumer_count": 28,
  "recommendation": "Split the context provider or memoize its value and children."
}

This is the tool that answers "why did 28 components re-render when I clicked one button."

Updated: `find_spurious_renders` trigger classification

The existing tool now classifies why a render was spurious, not just that it was:

UNSTABLE_PARENT_REF — parent passed a new object/array/function reference with identical values
CONTEXT_UPDATE — context changed, but this component doesn't actually use the changed value
INTENTIONAL_CONCURRENT_YIELD — React's scheduler, not a bug

This matters because React.memo fixes the first case but can't help with the second. The recommendation now reflects the correct fix path.

Recommended agent workflow (updated)

1. get_render_summary              → overview + lifecycle_anomaly flags
2. find_spurious_renders           → classify unnecessary renders by trigger type
3. analyze_compiler_efficacy       → check where React.memo / Compiler is being bypassed
4. diagnose_hydration_and_suspense → catch hydration recovery + Suspense waterfalls
5. evaluate_external_store_performance → Zustand/Redux selector loops + sync bypasses
6. trace_state_cascade_footprint   → propagation depth for expensive commits
7. suggest_memoization             → ROI-scored final recommendations

Setup (unchanged)

{
  "mcpServers": {
    "react-render-profile": {
      "command": "npx",
      "args": ["-y", "react-render-profile-mcp"]
    }
  }
}

Export a profile from React DevTools → Profiler tab → Record → Save. Pass the .json path as profile_path to any tool.

npm: react-render-profile-mcp
GitHub: vola-trebla/react-render-profile-mcp

Happy to answer questions about the hydration detection heuristics or the Invalidation Index math. And if you're hitting a React performance pattern this doesn't cover yet — open an issue. 🐸

Your AI agent just read your .env file. You have no idea what it did next.

Albert Alov — Sun, 17 May 2026 19:10:59 +0000

AI agents are helpful, not malicious. That's what makes them dangerous around secrets. Here's an MCP server that catches secret exposure before the agent gets there.

Here's a scene that's more common than anyone admits.

You're debugging a config issue. You ask your AI agent to look at src/config.ts. The file has this:

export const config = {
  db: { url: process.env.DATABASE_URL, password: process.env.DB_PASSWORD },
  jwt: { secret: process.env.JWT_SECRET },
};

// Added during debugging last Tuesday, never removed
console.log("Config loaded:", JSON.stringify(config));
console.log(process.env.AWS_SECRET_ACCESS_KEY);

The agent reads the file, executes the tool, and your AWS secret key is now sitting in its context window. It might summarize it. It might include it in generated code. It might pass it to another tool that logs everything.

None of this requires the agent to be malicious. It just needs to be helpful.

env-secret-exposure-analyzer-mcp catches this before it happens. 🔐

🙈 The three ways secrets leak

1. Hardcoded in source files

The classic. Someone puts a token directly in code "just to test" and commits it. Or copies a .env value into a constant because it's easier. Or the most common one: a connection string with the password embedded right there in the URL.

DATABASE_URL=postgres://admin:p@ssw0rd123@prod.db.internal:5432/app

An agent reading any file that imports this config now has your prod database password.

2. `.env` not in `.gitignore`

Your .env has 40 keys. AWS credentials, Stripe keys, JWT secrets, OAuth tokens, encryption keys. It's not in .gitignore. One git push and it's in the repository forever — even if you delete it, it stays in git history.

The agent doesn't know this is dangerous. It reads files. That's its job.

3. `console.log` that never got removed

The debug line that gets committed on Friday and nobody notices until Monday. Except by then, every time the app starts, it dumps credentials to stdout. If you have log aggregation, those secrets are now in your observability platform too.

console.log("Starting server with config:", JSON.stringify(config));
// config contains { db: { password: "..." }, jwt: { secret: "..." } }

🔧 How the scanner works

Three tools, three attack surfaces.

`scan_for_secrets`

Scans source files, config files, and .env files for 20+ patterns. Returns severity, file, line, and a masked preview — the scanner never returns the full secret value, even in its own output.

After building the initial version with the obvious patterns (AWS, GitHub, Stripe), we did something simple: created a realistic .env with everything a real project might have and ran the scanner against it.

First run: 3 findings.

That's not good enough. A real .env has database URLs, JWT secrets, SendGrid keys, Twilio tokens, Google OAuth secrets, Sentry DSNs, webhook secrets, encryption keys. We were missing most of it.

We fixed the patterns:

Database URLs with embedded credentials — had to handle passwords containing @ (the character that separates credentials from host)
Stripe webhook secrets (whsec_), Google OAuth (GOCSPX-), Sentry DSN with flexible key length
Generic patterns for JWT secrets, session secrets, encryption keys — with a (?!process\.env) lookahead to avoid false positives on password: process.env.X which is actually correct code

After fixes: 16 findings. Everything in the file.

`check_gitignore_coverage`

Walks the project root and checks if sensitive files (.env, .env.local, secrets.json, private keys, certificates) are covered by .gitignore. Correctly ignores .env.example and .env.sample — those are supposed to be committed.

`scan_for_log_leaks`

Scans for console.log / logger calls that print process.env variables or objects with secret-sounding names. Catches both direct leaks:

console.log(process.env.AWS_SECRET_ACCESS_KEY); // HIGH

And indirect ones:

console.log("Config:", JSON.stringify(config)); // HIGH — config contains env vars
console.log("env:", process.env);               // CRITICAL — dumps everything

🐸 The most ironic moment of this build

When writing the tests, I created fixture files with fake-but-realistic secrets:

GITHUB_TOKEN=ghp_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AWS_ACCESS_KEY_ID=AKIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

GitHub push protection blocked the push.

A secret scanner — blocked by GitHub's secret scanner — because its own test fixtures looked too much like real secrets. Even the obviously fake ones. ghp_ followed by 40 A's is still ghp_ followed by 40 alphanumeric characters, which is exactly the GitHub token format.

The fix: create fixture files programmatically in os.tmpdir() at test time. They never touch the git repo. The tests pass, the push goes through, and somewhere in the universe a security engineer nods approvingly.

beforeAll(() => {
  leakyDir = fs.mkdtempSync(path.join(os.tmpdir(), "env-mcp-leaky-"));
  fs.writeFileSync(
    path.join(leakyDir, ".env"),
    [`GITHUB_TOKEN=ghp_${"A".repeat(40)}`, `AWS_ACCESS_KEY_ID=AKIA${"A".repeat(16)}`].join("\n"),
  );
});

afterAll(() => {
  fs.rmSync(leakyDir, { recursive: true, force: true });
});

✅ Does it actually work?

After publishing, I verified the full MCP protocol layer — not just the functions in isolation, but the actual stdio transport that Claude Desktop uses:

printf '{"jsonrpc":"2.0","id":1,"method":"initialize",...}\n
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"scan_for_secrets",...}}\n' \
  | node dist/index.js

Response:

{
  "result": {
    "content": [{
      "type": "text",
      "text": "Secret Scan Results\n  Files scanned: 9\n  Findings: 16\n\n  [CRITICAL] .env:7 — Database URL with password\n  [CRITICAL] .env:17 — AWS Access Key\n  ..."
    }]
  },
  "jsonrpc": "2.0",
  "id": 2
}

Error handling too — bad path returns "isError": true with a readable message, doesn't crash the server.

For a security tool, "it compiles" is not good enough. The protocol has to work.

⚡ Setup

{
  "mcpServers": {
    "secret-scanner": {
      "command": "npx",
      "args": ["-y", "env-secret-exposure-analyzer-mcp"]
    }
  }
}

Then ask your agent:

"Scan this project for exposed secrets, check if .env is in .gitignore, and find any console.log calls that might be leaking credentials."

🐸 The pattern

Every tool in this series exists because an AI agent hits a wall — something it structurally cannot know without the right tool.

With secrets, the wall is subtle. The agent doesn't know what's sensitive just by looking. It doesn't know p@ssw0rd123 in a connection string is a production password. It doesn't know that JWT_SECRET=abc123verysecretkey in a .env file means something if that file gets committed.

The scanner knows. It has the patterns, the gitignore logic, the log analysis. It tells the agent exactly what's dangerous before the agent gets near it.

📦 Links

npm: npmjs.com/package/env-secret-exposure-analyzer-mcp
GitHub: github.com/vola-trebla/env-secret-exposure-analyzer-mcp

Your AI agent reads tsconfig.json. It has absolutely no idea what it means

Albert Alov — Sun, 17 May 2026 18:43:30 +0000

Your agent sees "extends": "@tsconfig/strictest" and hallucinates the rest. Here's an MCP server that uses the TypeScript compiler API to resolve the full inheritance chain and return what actually applies.

Here's a scene that happens more than you'd think.

You ask your AI agent to help with a TypeScript error. It reads your tsconfig.json, sees this:

{
  "extends": "@tsconfig/strictest",
  "compilerOptions": {
    "paths": { "@/*": ["./src/*"] }
  }
}

And confidently suggests:

// "This should work fine — I don't see strict mode enabled"
const users = getUsers();
const first = users[0].name; // ❌ Object is possibly 'undefined'

It's wrong. @tsconfig/strictest sets noUncheckedIndexedAccess: true. users[0] is User | undefined, not User. The agent doesn't know this because it never looked inside @tsconfig/strictest. It just guessed.

This is tsconfig-inheritance-flattener-mcp. 🔍

🙈 What the agent actually sees

When your agent reads tsconfig.json, it reads exactly what's in the file. Nothing more.

The extends field points to a package or another file — and the agent stops there. It doesn't chase the chain. It doesn't know what that base config sets. It fills in the blanks from training data, and training data is not your project.

In a typical monorepo this chain can be 3 levels deep:

apps/web/tsconfig.json
  → tsconfig.base.json
    → node_modules/@tsconfig/strictest/tsconfig.json

The final target, module, moduleResolution, strict, paths, baseUrl — all of it is scattered across these files. Without resolving the full chain, the agent is flying blind.

🔧 What the TypeScript compiler API actually knows

Here's the thing: TypeScript already solves this problem. Every time tsc runs, it resolves the full chain and produces a single merged set of compiler options. The API is right there:

const raw = ts.readConfigFile(configPath, ts.sys.readFile);
const parsed = ts.parseJsonConfigFileContent(
  raw.config, ts.sys, path.dirname(configPath), {}, configPath
);
// parsed.options = fully merged CompilerOptions ✅

We're not reimplementing anything. We're just exposing what TypeScript already computes — via MCP, so your agent can ask.

🛠️ Three tools

`get_effective_compiler_options`

Resolves the full extends chain and returns the merged options that actually apply. Enums come back as readable strings, not magic numbers ("ES2022" not 9, "NodeNext" not 199).

Effective TypeScript Configuration
  Config:            /project/apps/web/tsconfig.json
  Inheritance chain: /project/apps/web/tsconfig.json
                     → /project/tsconfig.base.json
                     → node_modules/@tsconfig/strictest/tsconfig.json

Compiler Options (merged):
  target: "ES2022"
  module: "NodeNext"
  moduleResolution: "NodeNext"
  strict: true
  noUncheckedIndexedAccess: true
  exactOptionalPropertyTypes: true
  baseUrl: "/project"
  paths: { "@/*": ["apps/web/src/*"] }

Now the agent knows why users[0] is User | undefined. No guessing.

`resolve_module_alias`

Maps @/hooks/useAuth to the physical file on disk. Uses the resolved paths and baseUrl from the full inheritance chain — not just what's in the nearest tsconfig.json.

Alias Resolution: @/hooks/useAuth
  Config:   /project/apps/web/tsconfig.json
  Base URL: /project

Resolved physical paths:
  /project/apps/web/src/hooks/useAuth.ts   ✓ exists

When the agent needs to navigate to the file behind an import, it no longer has to guess the folder structure.

`analyze_project_references`

Validates the references array in monorepo root configs. Checks that each referenced package has composite: true — without it, TypeScript's incremental build silently breaks.

Project References Analysis
  Config: /project/tsconfig.json
  References found: 2

  [✓] packages/shared → /project/packages/shared/tsconfig.json
  [✗] packages/legacy → /project/packages/legacy/tsconfig.json (NOT FOUND)

Violations:
  ✗ packages/shared is referenced but does not have composite: true
    Fix: add "composite": true to packages/shared/tsconfig.json

⚡ Setup

{
  "mcpServers": {
    "tsconfig-flattener": {
      "command": "npx",
      "args": ["-y", "tsconfig-inheritance-flattener-mcp"]
    }
  }
}

That's it. Works in Claude Desktop, Cursor, or any MCP-compatible client.

🐸 The pattern

Every MCP server in this series follows the same logic: find a place where an AI agent is structurally blind — not because it's dumb, but because it literally cannot see the data — and expose that data via a tool.

tsconfig.json inheritance is a perfect example. The agent isn't hallucinating out of laziness. It's hallucinating because the information it needs is locked inside a chain of files it never opened, or inside a npm package it can't inspect at runtime.

The TypeScript compiler API already resolves all of this. We just asked it nicely. 🔍

📦 Links

npm: npmjs.com/package/tsconfig-inheritance-flattener-mcp
GitHub: github.com/vola-trebla/tsconfig-inheritance-flattener-mcp

Your CI Is Always Broken. Your AI Agent Has No Idea What to Do About It.

Albert Alov — Sat, 16 May 2026 21:05:58 +0000

In any real codebase, CI always has something failing. The hard part isn't finding failures — it's knowing which ones block a release. Here's an MCP server that answers that question automatically.

Here's the situation every engineer knows:

You open CI. Something's failing. You need to ship.

Is it a real regression? A known flaky test? An infra blip that'll pass on retry? You open the logs, grep for errors, cross-reference with last week's run history, check what files changed in the PR, and 20 minutes later you have an answer.

Your AI agent can't do any of that. It sees the same raw logs you do. It doesn't know your flakiness history. It doesn't know which tests are affected by the code change. It guesses.

release-readiness-triage-mcp fixes this. 🚦

🧠 The three signals that actually matter

Triaging a CI failure requires correlating three things simultaneously:

1. Error signature deduplication

If 40 tests failed with ECONNREFUSED 127.0.0.1:5432, that's one problem (database didn't start), not 40. Grouping by normalized error signature tells you the real shape of the failure.

2. Flakiness history

Some tests fail 70% of the time on a good day. If a test has a 0.73 flaky probability in your history, its failure today tells you nothing about the code.

3. Code-change correlation

If Button.test.tsx is failing and Button.tsx is in the diff, that's suspicious. If AuthFlow.test.tsx is failing and nothing in auth changed, that's noise.

Without all three signals in one place, you can't answer "is this safe to release?" You just accumulate tabs.

🛠️ The 4 tools

`aggregate_suite_failures`

First pass: normalize, deduplicate, categorize.

CI Run Summary
  Total tests:   847
  Passed:        842
  Failed:        5
  Failure rate:  0.59%
  Error groups:  3

Failure Groups (by frequency):
  [NETWORK] 2x — connect ECONNREFUSED 127.0.0.1:Xms
    • API Suite > health check
    • API Suite > readiness probe
  [ASSERTION] 2x — expect(received).toBe(expected)
    • Search Suite > debounce timing
    • Search Suite > sort order
  [ASSERTION] 1x — Expected null, got <button>Submit</button>
    • Button Suite > renders button correctly

Supports customInfraPatterns — pass cloud-specific strings like "GCP quota exceeded" or "No space left on device" to classify them as infrastructure noise instead of unknown failures.

`cross_reference_flakiness`

Takes your flakiness database and scores each failure:

Flakiness Cross-Reference

  [KNOWN FLAKY] Auth Suite > login with expired token
    Flaky probability: 73%
  [MILDLY FLAKY] Search Suite > debounce timing
    Flaky probability: 22%
  [NO HISTORY] Button Suite > renders button correctly
    Not found in flakiness database

`correlate_code_changes`

Matches changed files against failing tests. Works standalone or with pre-computed affected test lists from ast-impact-mapper-mcp:

Code Change Correlation
  Changed files: 2
  Pre-identified affected tests: 1

  [CORRELATED] Button Suite > renders button correctly
    → Matched via affected test list
  [NOT CORRELATED] Search Suite > debounce timing
  [NOT CORRELATED] Auth Suite > login with expired token

`generate_release_recommendation`

The final step. Everything combined into one verdict:

## 🔴 Release Recommendation: NO_GO (75% confidence)

> 1 confirmed regression(s) directly correlated with code changes. Do not release.

| Category            | Count |
|---|---|
| Total failures      | 5     |
| 🔴 Real regressions | 1     |
| 🟡 Known flaky      | 2     |
| ⚪ Infra blips      | 2     |
| ❓ Unknown          | 0     |

### 🔴 Blockers (must fix before release)

**Button Suite > renders button correctly**
- Test is directly affected by code changes in this commit
- `Expected null, got <button>Submit</button>`

### ✅ Safe to ignore

- ~~Auth Suite > login with expired token~~ — Historically flaky: 73% failure rate in history
- ~~API Suite > health check~~ — Error pattern matches infrastructure issues (network)
- ~~Search Suite > debounce timing~~ — Mildly flaky: 22% historical failure rate
- ~~Storage Suite > upload avatar~~ — Error pattern matches infrastructure issues (network)

Pass format: "markdown" and the output is ready to paste directly into a GitHub PR comment or Slack message.

🔗 It's a meta-orchestrator

This MCP is designed to sit on top of the other tools in the ecosystem:

flakiness-knowledge-graph-mcp builds the flakiness database from run history — feed its output into cross_reference_flakiness
ast-impact-mapper-mcp computes which tests are affected by a code change via TypeScript AST — feed its output into correlate_code_changes
playwright-trace-decoder-mcp decodes trace files for individual failure root-cause — use it after getting a NO_GO to understand the blocker

The agent orchestrates the chain. Each MCP handles one thing it couldn't do without tool access.

⚡ Setup

{
  "mcpServers": {
    "release-readiness-triage": {
      "command": "npx",
      "args": ["-y", "release-readiness-triage-mcp"]
    }
  }
}

Then just ask:

"Here are the failures from CI, our flakiness history, and the files changed in this PR. Is it safe to release?"

One answer. No log reading.

📦 Links

npm: npmjs.com/package/release-readiness-triage-mcp
GitHub: github.com/vola-trebla/release-readiness-triage-mcp

npx release-readiness-triage-mcp

Your AI Agent Just Broke Your React Performance. It Has No Idea

Albert Alov — Sat, 16 May 2026 20:27:07 +0000

React DevTools Profiler gives you all the data you need to fix re-renders. Your AI agent can't read it. Here's how to fix that with an MCP server.

You open React DevTools Profiler, record a session, and export the .json file. It's got everything: which components re-rendered, how long each one took, which props changed, which hooks fired.

Then you paste it into Claude or Cursor and ask: "What's causing the performance problem?"

The agent stares at raw JSON — thousands of lines of fiber IDs, opcode arrays, and microsecond timestamps — and does its best. But it's reading tea leaves. It doesn't know what a "spurious render" is in this format. It can't decode the operations integer array. It doesn't know that props: [] means a component re-rendered even though no props actually changed.

That's the gap react-render-profile-mcp fills. 🔍

🤔 What the profiler actually exports

React DevTools serializes profiler data in a specific binary-ish format that most developers have never had to parse manually:

{
  "version": 5,
  "dataForRoots": [{
    "commitData": [{
      "changeDescriptions": [[3, {"isFirstMount": true, "props": null}], [4, {...}]],
      "fiberActualDurations": [[3, 15.2], [4, 8.1]],
      "fiberSelfDurations": [[3, 3.9], [4, 4.9]],
      "duration": 15.2,
      "timestamp": 100.0
    }],
    "snapshots": [[3, {"displayName": "App", "children": [4, 5]}]],
    "operations": [1, 0, 3, 2, 65, 112, 112, ...]
  }]
}

A few non-obvious things buried in there:

⚠️ changeDescriptions is an array of pairs, not an object. It's serialized as Map.entries() — [[fiberID, desc], ...]. If you parse it naively as JSON object keys, you'll get garbage.

⚠️ props: [] means spurious render. An empty array means the component re-rendered but zero prop keys actually changed — the reference was unstable. props: null means unknown. props: ["value"] means the value prop genuinely changed.

⚠️ operations is an opcode array. It encodes tree mutations (mount, unmount, reorder) with a string table at the start. You need to decode it to map fiber IDs to component names when snapshots aren't present.

⚠️ fiberSelfDuration ≠ fiberActualDuration. Self = time in this component only. Actual = self + children. For finding hotspots, you want self time.

The MCP server handles all of this so the agent doesn't have to.

🛠️ The 5 tools

`get_render_summary`

High-level overview of the entire recording:

Total commits: 12
Total render time: 847.3ms
Spurious renders: 8
Top components by self time:
  ProductList — 312.4ms (6 renders)
  SearchInput — 89.1ms (12 renders)
  Sidebar — 44.2ms (3 renders)

`find_spurious_renders`

Detects components that re-rendered but had no actual prop or state changes:

Spurious renders found:
  ProductList — 6 spurious renders, 312.4ms wasted
    → props ref changed but no keys differed

This is the classic "missing React.memo" pattern. The component re-renders every time a parent renders, even though nothing it depends on changed.

`get_hottest_components`

Components ranked by total self time across all commits. Useful for finding where to optimize first.

`trace_render_cascade`

Given a commit index, shows what triggered it and what else re-rendered as a result:

Commit 3 — triggered by: SearchInput (hook changed)
Cascade:
  ProductList — re-rendered (unstable props)
  Sidebar — re-rendered (context changed)

This is how you find the root cause instead of just the symptom.

`suggest_memoization`

Combines spurious render detection with self-time data to generate specific recommendations:

Suggestions:
  ProductList → React.memo
    Reason: 6 spurious renders, 312.4ms wasted
    Self time: 52.1ms avg per render

⚡ Setup

{
  "mcpServers": {
    "react-render-profile": {
      "command": "npx",
      "args": ["-y", "react-render-profile-mcp"]
    }
  }
}

Then record a session in React DevTools → Profiler → export as JSON → give the file path to your agent.

🚀 The workflow

Instead of pasting raw JSON and hoping:

"Load the profile at /tmp/myapp.profile.json and find spurious renders"

The agent calls find_spurious_renders with the file path, gets back structured data with component names, counts, and wasted milliseconds — and gives you a concrete list of what to fix.

"Load the profile and trace what caused the slow commit at index 3"

trace_render_cascade returns the trigger component, the cascade, and the reason for each re-render.

The agent goes from "I see some fiber IDs with large durations" to "ProductList is re-rendering 6 times spuriously, wrapping it in React.memo would save 312ms."

📦 Links

npm: npmjs.com/package/react-render-profile-mcp
GitHub: github.com/vola-trebla/react-render-profile-mcp

npx react-render-profile-mcp

Your AI Agent Hallucinates Tailwind Classes. Here's the Fix

Albert Alov — Sat, 16 May 2026 19:38:01 +0000

Your AI agent is confidently writing Tailwind classes that don't exist in your project.

bg-primary-500? Your project uses bg-brand-primary.
p-18? Only valid if your spacing scale includes it.
tw-flex? Only if your config sets prefix: "tw-".

The agent doesn't know. It's working from training data — the default Tailwind docs, not your config.

The Epistemic Blindness

When an agent generates a React component, it has no idea:

Whether bg-brand-primary is a valid class in this project
What your custom spacing scale looks like (is p-18 valid here?)
Whether you're using a custom prefix like tw-
Which brand colors exist beyond the Tailwind defaults
Whether flex grid on the same element is a conflict

It guesses. Custom tokens = hallucinations. Every time.

The Fix: Give the Agent Your Actual Config

tailwind-context-resolver-mcp is an MCP server that loads your tailwind.config.ts/js and exposes its resolved design system as queryable tools.

Before writing a component, the agent can:

→ get_config_summary        understand the project's design system
→ resolve_theme_tokens      query what colors/spacing actually exist
→ validate_class_string     verify the className before committing it
→ detect_css_conflicts      catch flex+grid on the same element

Real output from validate_class_string:

{
  "valid_classes": ["bg-brand-primary", "text-white", "p-4", "hover:dark:bg-brand-secondary"],
  "invalid_classes": ["bg-fake-token"],
  "possibly_valid_classes": ["btn", "prose"],
  "warnings": ["Conflicting multiple layout models: flex, grid"]
}

How It Works

The server uses the same config loading strategy as the Tailwind CLI itself:

jiti loads your tailwind.config.ts at runtime — no ts-node setup needed
tailwindcss/resolveConfig merges your config with Tailwind defaults → full resolved theme
Token-based validation — checks that bg-brand-primary maps to an actual colors.brand.primary token — without running PostCSS or the full JIT pipeline

The class parser handles the full Tailwind syntax:

!hover:dark:bg-brand-primary/50 → strips !, hover:dark:, /50 before lookup
bg-[#ff0000] → arbitrary values are always valid
-mt-4 → negative prefix stripped, looks up spacing token 4
group-hover:text-white → multi-word variants handled correctly
Unknown classes when plugins are active → possibly_valid_classes (can't verify btn or prose without PostCSS)

Setup

Add to Claude Desktop / Cursor / any MCP client:

{
  "mcpServers": {
    "tailwind-context-resolver": {
      "command": "npx",
      "args": ["-y", "tailwind-context-resolver-mcp"]
    }
  }
}

Then pass your config path on each tool call:

config_path: "/absolute/path/to/tailwind.config.ts"

Tailwind v3 Only

v4 uses a CSS-based config format — the programmatic resolveConfig API doesn't apply. The server detects v4 and returns a clear error instead of silently failing.

Your Node.js App Is Slow. Your AI Agent Can't Help - Until Now

Albert Alov — Sat, 16 May 2026 19:05:16 +0000

You've been here before.

The API is dragging. P99 latency is climbing. Someone says "just profile it" — so you run node --cpu-prof and get a file like CPU.20260516.154355.cpuprofile.

You open it. It's 28MB of this:

{
  "nodes": [
    { "id": 1482, "callFrame": { "functionName": "processRequest", "scriptId": "94", "url": "file:///app/dist/server.js", "lineNumber": 847, "columnNumber": 12 }, "hitCount": 3241, "children": [1483, 1490, 1501] },
    { "id": 1483, "callFrame": { "functionName": "parseBody", "scriptId": "94", "url": "file:///app/dist/middleware.js", "lineNumber": 23, "columnNumber": 4 }, "hitCount": 0, "children": [1484] },
    ...
  ],
  "samples": [1482, 1483, 1482, 1490, 1501, 1482, 1483, ...],
  "timeDeltas": [0, 118, 97, 124, 89, 112, ...]
}

Thousands of nodes. Millions of samples. Raw memory addresses. Microsecond tick intervals.

You paste it into Claude. The context window collapses. It hallucinates an answer. You're back to square one.

That's the problem this MCP solves.

Why AI Agents Are Blind to CPU Profiles

A .cpuprofile isn't just "a big file." It's a specific format that requires real computation to be useful:

Exclusive time (self time) = how long a function ran on its own, without counting callees = hitCount × avg(timeDeltas)
Inclusive time = self time + all descendant inclusive times = requires a recursive DFS over the call tree
Hot path = which chain of callers led to the bottleneck = requires building a reverse parent map

An LLM can't do any of this. It can't execute algorithms. It can't traverse a tree across 50,000 nodes. Even if you somehow got the file into context, it would just pattern-match on function names and guess.

The agent needs a bridge — something that runs the math locally and hands back a 10-line summary.

Introducing `v8-cpu-profile-decoder-mcp`

An MCP server that decodes V8 CPU profiles into token-efficient bottleneck summaries for AI agents.

npx v8-cpu-profile-decoder-mcp

Three tools. Each one answers a specific question the agent would otherwise be blind to.

Tool 1: `extract_hottest_functions`

"Which function is burning the most CPU?"

{
  "profile_path": "/app/profiles/CPU.20260516.cpuprofile",
  "top_n": 5,
  "min_self_percent": 1.0
}

Response:

[
  {
    "rank": 1,
    "functionName": "hashPassword",
    "url": "file:///app/dist/auth/crypto.js",
    "lineNumber": 42,
    "selfTimeMs": 1842.5,
    "totalTimeMs": 1842.5,
    "selfPercent": 61.32,
    "hitCount": 3241
  },
  {
    "rank": 2,
    "functionName": "parseJsonBody",
    "url": "file:///app/dist/middleware/body.js",
    "lineNumber": 18,
    "selfTimeMs": 412.1,
    "selfPercent": 13.71,
    "hitCount": 724
  }
]

61% of all CPU time in one function. The agent now knows exactly where to look — without ever reading the raw profile.

V8 internals ((program), (garbage collector), (idle)) are filtered out by default. You get user code only.

Tool 2: `analyze_call_tree_path`

"What's calling my slow function, and how often?"

{
  "profile_path": "/app/profiles/CPU.20260516.cpuprofile",
  "function_name": "hashPassword",
  "top_callers": 3
}

Response:

{
  "targetFunction": "hashPassword",
  "matchedNodes": 2,
  "totalSelfTimeMs": 1842.5,
  "totalPercent": 61.32,
  "callers": [
    {
      "functionName": "loginHandler",
      "url": "file:///app/dist/routes/auth.js",
      "lineNumber": 94,
      "sampleCount": 2180,
      "attributedTimeMs": 1235.4
    },
    {
      "functionName": "validateSession",
      "url": "file:///app/dist/middleware/auth.js",
      "lineNumber": 31,
      "sampleCount": 1061,
      "attributedTimeMs": 607.1
    }
  ]
}

Now the agent knows the full picture: hashPassword is slow, loginHandler is responsible for 67% of those calls, and validateSession is calling it unnecessarily on every request.

Function name matching is partial and case-insensitive — you don't need to know the exact internal name.

Tool 3: `correlate_source_code`

"Which TypeScript file and line is the bottleneck actually from?"

After TypeScript compilation, your profile shows dist/auth/crypto.js:42. That's not where you write code. This tool reads the .js.map source maps and resolves back to the original TypeScript:

{
  "resolved": [
    {
      "rank": 1,
      "generatedUrl": "file:///app/dist/auth/crypto.js",
      "generatedLine": 42,
      "source": {
        "originalFile": "src/auth/crypto.ts",
        "originalLine": 38,
        "originalColumn": 2,
        "originalFunction": "hashPassword"
      },
      "selfTimeMs": 1842.5,
      "selfPercent": 61.32
    }
  ],
  "sourcemapErrors": []
}

The agent can now open src/auth/crypto.ts at line 38 and fix the actual source — not a compiled artifact.

Falls back gracefully to compiled JS locations if no .map file is found.

How the Algorithm Works

Three steps happen locally before anything reaches the agent:

1. Build the node map
Parse the nodes array into Map<id, node> for O(1) lookup.

2. Compute exclusive time

selfTimeMs = hitCount × avg(timeDeltas[1:])

Note: timeDeltas[0] is always 0 per V8 spec (offset from startTime), so we skip it.

3. Compute inclusive time via DFS with memoization

inclusiveTime(node) = selfTime(node) + Σ inclusiveTime(child)

Cached to avoid recomputation on shared subtrees.

The raw profile might have 50,000 nodes and 200,000 samples. What comes back to the agent is 10 ranked objects. That's the token compression that makes this useful.

Setup

npm install -g v8-cpu-profile-decoder-mcp

Claude Desktop (~/.config/claude/claude_desktop_config.json):

{
  "mcpServers": {
    "v8-cpu-profile-decoder-mcp": {
      "command": "npx",
      "args": ["-y", "v8-cpu-profile-decoder-mcp"]
    }
  }
}

Generate a profile:

node --cpu-prof --cpu-prof-dir ./profiles your-script.js
# or for a running server: kill -USR1 <pid> (with --cpu-prof flag)

Then ask your agent:

"Profile is at ./profiles/CPU.cpuprofile — find the bottleneck and suggest a fix"

What the Agent Can Do With This

With a decoded profile in context, an AI agent can:

Identify the hot function and read its source code
Trace who's calling it and how many times
Suggest memoization, caching, or algorithmic improvements
Spot unexpected callers (e.g., validateSession calling hashPassword on every request)
Generate a PR with the fix

Without this MCP, it's guessing from static code. With it, it's working from measured runtime data.

Your AI Agent Can Read the DOM. It Can't See the Screen.

Albert Alov — Sat, 16 May 2026 03:32:46 +0000

Here's a test that passes every time:

await expect(page.locator('.checkout-button')).toBeVisible();

And here's what the AI agent doesn't know: the checkout button is at y: 1450px on a 375px mobile viewport. It exists. It's visible according to the DOM. The test is green. The user can't reach it without scrolling three screens down, and on some devices a sticky cookie banner overlaps it by 60%.

The agent read the accessibility tree. It didn't see the screen.

The gap between the DOM and the render

When an AI agent analyzes a Playwright failure or writes a new test, it works with what Playwright exposes by default: roles, labels, text content, ARIA attributes. This is the right abstraction for functional testing.

But layout bugs don't live in the DOM. They live in the render engine's output — in coordinates, z-indexes, bounding boxes, and intersection ratios. A button can be display: block, visibility: visible, opacity: 1, and completely unreachable by a real user.

Current tools for this problem are either pixel-diff based (noisy, breaks on anti-aliasing) or proprietary enterprise AI (Applitools, Percy). There's no open-source tool that gives an AI agent structured geometric data from a live browser.

That's what playwright-spatial-layout-mcp does.

How it works

The MCP server launches a headless Chromium browser, navigates to a URL, and extracts geometric data using getBoundingClientRect() and getComputedStyle() in a single page.evaluate() call — one browser round-trip per element batch.

Four tools:

extract_bounding_boxes — returns position, size, z-index, and viewport visibility for any set of selectors.

{
  "url": "https://your-app.com/checkout",
  "selectors": [".checkout-button", ".cookie-banner", "nav"],
  "viewport": { "width": 375, "height": 812 }
}

[
  {
    "selector": ".checkout-button",
    "box": { "x": 16, "y": 892, "width": 343, "height": 48 },
    "z_index": "auto",
    "is_visible": true,
    "is_in_viewport": false
  }
]

The button exists. It is not in the viewport. The agent now knows this.

detect_visual_occlusion — computes the intersection ratio between two elements' bounding boxes.

{
  "url": "https://your-app.com/checkout",
  "target_selector": ".checkout-button",
  "overlay_selector": ".cookie-banner"
}

{
  "is_occluded": true,
  "intersection_ratio": 0.61,
  "occluded_area_px": 4128
}

61% of the button's area is under the cookie banner. The agent can now report this as a bug, not a passing test.

verify_spatial_relationships — validates layout rules and returns a pass/fail with a human-readable reason per rule.

Six rule types: left_of, right_of, above, below, contains, not_overlapping.

{
  "url": "https://your-app.com",
  "rules": [
    { "type": "above", "element_a": "nav", "element_b": ".hero" },
    { "type": "not_overlapping", "element_a": ".sidebar", "element_b": ".main-content" }
  ]
}

{
  "passed": false,
  "results": [
    { "passed": true,  "reason": "'nav' bottom (64px) is above '.hero' top (64px)" },
    { "passed": false, "reason": "'.sidebar' and '.main-content' overlap by 12%" }
  ]
}

This is layout spec-as-code — the agent asserts design constraints the same way it asserts functional ones.

compute_viewport_reflow — tracks how element geometry changes across breakpoints. All viewports are processed in parallel.

{
  "url": "https://your-app.com",
  "selectors": [".hero-cta", "nav"],
  "viewports": [
    { "width": 375, "height": 812 },
    { "width": 768, "height": 1024 },
    { "width": 1280, "height": 720 }
  ]
}

[
  {
    "selector": ".hero-cta",
    "shifted": true,
    "max_delta_x": 442,
    "max_delta_y": 318,
    "max_delta_width": 897
  }
]

The CTA moved 442px horizontally and 318px vertically between mobile and desktop. The agent knows which element is most volatile across breakpoints.

What the agent can do with this

Before this MCP, an AI agent writing or debugging Playwright tests operated blind to rendering. It could tell you the button has role="button" and aria-label="Checkout". It could not tell you where the button is on screen.

With spatial data in context, the agent can:

Detect that a passing test covers a button the user can't actually click
Identify which elements are off-screen on mobile before a test suite runs
Verify that a CSS refactor didn't break the layout without running visual regression diffs
Catch z-index wars where one component silently slides under another after a merge

The shift is from "does this element exist in the DOM" to "can a real user reach this element on this device."

Installation

npm install -g playwright-spatial-layout-mcp
npx playwright install chromium

Add to your Claude Desktop config:

{
  "mcpServers": {
    "playwright-spatial-layout-mcp": {
      "command": "npx",
      "args": ["-y", "playwright-spatial-layout-mcp"]
    }
  }
}

Then ask your agent:

"Check if the cookie banner is blocking the checkout button on a 375px viewport"

"Verify that nav is above the hero section and sidebar doesn't overlap main content"

"Which elements shift the most when resizing from desktop to mobile?"

Part of a larger ecosystem

This is the fifth MCP server in a series of open-source tools for the Playwright/TypeScript testing ecosystem:

playwright-trace-decoder-mcp — root-cause analysis from Playwright trace.zip files
flakiness-knowledge-graph-mcp — knowledge graph of flaky test patterns over time
ast-impact-mapper-mcp — TypeScript AST-based test impact analysis
zod-contract-mock-forge-mcp — deterministic mock generation from Zod schemas

Each one addresses a specific blind spot — what the agent can't reason about without structured tool access. Spatial layout was the most visible one.

npm: https://www.npmjs.com/package/playwright-spatial-layout-mcp

GitHub: https://github.com/vola-trebla/playwright-spatial-layout-mcp

DEV Community: Albert Alov

In 2013 I wrote a diploma on elliptic curves. Last night my tool used them to check its own release.

The diploma in the drawer

What croak does, in 30 seconds

Why an agent should care who built a package

npm provenance in one minute

The one line that isn't the hard part

Pointing it at itself

The irony

What provenance does not prove

What you should do today

OpenTelemetry JS 3.0 just shipped. I tested both lines side by side. Here's what broke.

Why I had to care about both lines

1. Three breaking changes in SDK 3.0

SimpleSpanProcessor takes an options object

sdk-trace-base became sdk-trace, and the provider was renamed

sdk-node dropped its re-exports

2. One dependency can't span both lines

3. Your app may be running two copies of the OTel API

4. Node 24: AsyncLocalStorage.disable() doesn't do what the docs say

Two smaller gotchas

Checklist

What I'm building

My security tool aced its own exam. Then I ran it on real repos

The problem croak is for

Eval first

The first real run

Lesson 1: "near" means near

Lesson 2: a warning everyone ignores is worse than none

Before and after

What I'd tell myself a week ago

What croak doesn't do (yet)

How react-render-profile-mcp works under the hood - and what it found in a real project

Act 1 — What it found on slash-admin

Diagnostics

Auto-remediation and the edge case

Act 2 — How it actually works inside

Layer 1: decoding the profiler format

Layer 2: the Invalidation Index

Layer 3: the AST remediation engine

Why no React runtime dependency

Setup

react-render-profile-mcp v0.3.1 - 4 new diagnostic tools for React Compiler, hydration, Zustand, and state cascades

What was already there (v0.1)

What's new in v0.3.1

1. analyze_compiler_efficacy

2. diagnose_hydration_and_suspense

3. evaluate_external_store_performance

4. trace_state_cascade_footprint

Updated: find_spurious_renders trigger classification

Recommended agent workflow (updated)

Setup (unchanged)

Your AI agent just read your .env file. You have no idea what it did next.

🙈 The three ways secrets leak

1. Hardcoded in source files

2. .env not in .gitignore

3. console.log that never got removed

🔧 How the scanner works

scan_for_secrets

check_gitignore_coverage

scan_for_log_leaks

🐸 The most ironic moment of this build

✅ Does it actually work?

⚡ Setup

🐸 The pattern

📦 Links

Your AI agent reads tsconfig.json. It has absolutely no idea what it means

🙈 What the agent actually sees

🔧 What the TypeScript compiler API actually knows

🛠️ Three tools

get_effective_compiler_options

resolve_module_alias

analyze_project_references

⚡ Setup

🐸 The pattern

📦 Links

Your CI Is Always Broken. Your AI Agent Has No Idea What to Do About It.

🧠 The three signals that actually matter

🛠️ The 4 tools

aggregate_suite_failures

`SimpleSpanProcessor` takes an options object

`sdk-trace-base` became `sdk-trace`, and the provider was renamed

`sdk-node` dropped its re-exports

4. Node 24: `AsyncLocalStorage.disable()` doesn't do what the docs say

1. `analyze_compiler_efficacy`

2. `diagnose_hydration_and_suspense`

3. `evaluate_external_store_performance`

4. `trace_state_cascade_footprint`

Updated: `find_spurious_renders` trigger classification

2. `.env` not in `.gitignore`

3. `console.log` that never got removed

`scan_for_secrets`

`check_gitignore_coverage`

`scan_for_log_leaks`

`get_effective_compiler_options`

`resolve_module_alias`

`analyze_project_references`

`aggregate_suite_failures`

`cross_reference_flakiness`

`correlate_code_changes`

`generate_release_recommendation`

`get_render_summary`

`find_spurious_renders`

`get_hottest_components`

`trace_render_cascade`

`suggest_memoization`

Introducing `v8-cpu-profile-decoder-mcp`

Tool 1: `extract_hottest_functions`

Tool 2: `analyze_call_tree_path`

Tool 3: `correlate_source_code`