Each transition has one concrete action:

The reviewer recommends exactly one next step. Not a roadmap. Not a refactoring plan. One action to reach the next level.

Does the code follow its own implied contract? Are there inputs that produce nonsensical output? Does the calculation match the domain, not just run without error?

Are trust boundaries respected? Can external input reach calculations without validation? Are there side effects where pure computation was expected?

Would this produce the same output given the same input tomorrow? Can you audit what happened after the fact? Are there implicit dependencies on environment, ordering, or state?

Could a small team deploy and run this? If something breaks in production, how would anyone know? What would an operator observe?

If the project is already deployed and accessible, a stricter lens applies: unauthenticated public endpoints are more urgent than missing tests.

Does the agent know things the application should only know? Are there leaked secrets, exposed internals, or business logic that exists only in agent instructions rather than in code? If you change the most-called function, what breaks?

An advertising spend pacing tool. Calculates daily budgets, tracks ROAS, and projects campaign end dates.

Dashboard: $16,750 budget across 4 campaigns (Meta, Google, TikTok), $0 spent on Day 2, pacing check showing -$1,196 underspent. Auth is present (dev@localhost) but the structural tells remain.

The anomaly scan reveals structural tells before looking at any business logic:

• Package name mismatch. package.json declares "name": "rest-express" — the scaffolding template was never renamed.
• Phantom auth. passport and passport-local appear in package.json dependencies but are never imported anywhere. Authentication was intended but never wired up.
• Test infrastructure without tests. React components have data-testid attributes suggesting integration testing was planned. No test runner is configured. No tests/ directory exists.
• 30+ unused UI packages. A full shadcn/ui install rather than selective component addition. Characteristic of agent-generated scaffolding.

The reviewer asks: "Your pacing calculation divides budget by days remaining using float division. A $10,000 campaign over 30 days accumulates rounding errors. What happens to the last $0.03?"

Next step: Add authentication — the app handles advertising budgets on a public URL.

A sports betting bankroll tracker. Records bets, calculates ROI, tracks exposure as a percentage of bankroll.

Dashboard showing $5,110 bankroll, +28.3% ROI, 50% win rate (1W-1L), and $475 exposure (9.3% of bankroll). Three pending bets at $475 risk.

The numbers are immediately interesting from a review perspective:

• ROI calculation. +28.3% ROI on 5 total bets with 1 win and 1 loss. The calculation includes unrealized gains from 3 pending bets — bets that haven't settled yet are counted as profit. "Is that how you want ROI calculated, or should pending bets be excluded?"
• Exposure tracking. $475 exposure is 9.3% of a $5,110 bankroll. But the bankroll itself includes an +$85 unrealized gain. If the pending bets lose, the real exposure is higher than displayed. "What's the exposure if all pending bets lose?"
• No bet validation. The "New Bet" form has no constraints on stake amount. A user can bet more than their bankroll. "Should the app prevent bets that exceed available bankroll minus existing exposure?"

Next step: Write two tests: one for the ROI calculation (should pending bets count?) and one for bankroll balance after a loss. These pin down the rules before the next agent session changes them.

An options wheel strategy tracker. Monitors 16 contracts across multiple tickers, validates positions against portfolio rules, and fires alerts when invariants are violated.

Dashboard: $84,500 portfolio, $6,230 in collected premiums, 10 active alerts (4 critical), 15 of 17 contracts passing with 2 failed invariants. Critical alerts show earnings collisions on AMD, GOOGL, PLTR and a concentration limit breach on MSFT (31.1% vs 25% max).

This is the most mature of the three. It has tests, schema validators, and a contract monitoring system that actively checks invariants. The dashboard itself reveals the review's starting points:

• The system is catching violations. 2 of 17 contract checks are failing and 4 critical alerts are firing. The monitoring infrastructure works — but what happens when an alert fires? There's no alert history or acknowledgment flow. "If you dismiss a critical alert, is that recorded anywhere?"
• Concentration limit. MSFT at 31.1% exceeds the 25% portfolio limit. The system detects it but doesn't prevent new positions that would worsen it. "Is the 25% limit a warning or a hard block? Can you still sell a new MSFT put while over the limit?"
• Float precision. All money values — strike, premium, cost basis — use real (float32). The annualized return formula (premium/strike) × (365/DTE) × 100 amplifies rounding errors. "A $0.01 error on a $50 strike becomes $7.30 annualized. Is that within your tolerance?"
• Schema gap. One PATCH endpoint passes req.body directly to the database without Zod validation. Every other mutation endpoint validates. "Is this intentional or left over from an earlier iteration?"

Next step: Write a property test for the annualized return invariant (the 15% minimum threshold rule) to move toward Level 3.

All three are live on public URLs with no authentication. The review doesn't start with "add tests" — it starts with "who can reach this right now?" Operational and security findings take priority over engineering findings when the project is deployed.

The hardening ladder matters after the operational risk is mitigated.

The gap: building tools produce code fast, examination tools verify it slowly. The elenctic process bridges this by using whatever tools are available and asking questions when they surface violations.