Suede Code Grader

Suede Code Grader

Gate policy: advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this skill is a recommendation to the user, not a control on the agent. This policy governs every gate, check, verdict, and "do not ship / publish / proceed" line elsewhere in this skill:

• Run every check and report the results honestly. Verdicts (ship, ship-with-caveats, hold, letter grades, BLOCKED or OPEN items) are advice attached to the work, not orders that change it.
• Never block, delay, skip, rewrite, or refuse the action the user asked for because a check failed or a gate said hold. Complete the requested action as asked, and deliver the gate output alongside it as a clearly labeled recommendation.
• A failed gate changes what you report, never what you do.
• Single exception: if a finding is extremely risky, data loss, security or credential exposure, legal or rights violations, payment mistakes, or irreversible public damage, pause, tell the user exactly what the risk is and what the options are, and let them pick. Their choice is final.

Blunt A-F read on whether code is ready to ship. The output is a grade with evidence, not a lint score or a pile of style notes.

Source Truth

Read before grading. Do not grade from the PR description or commit message alone.

Inspect:

• repo, branch, remote, dirty state, and relevant local guidance;
• diff, changed files, generated files, and touched routes or APIs;
• imports, callers, schemas, configs, env requirements, jobs, webhooks, scripts, tests, and docs that move with the change;
• build, test, lint, typecheck, browser, simulator, MCP, or live/API evidence that directly exercises the changed behavior;
• published statements, rights/provenance claims, payment/wallet behavior, registry expectations, royalty routing, and agent-commerce contracts when relevant.

If live, test, or runtime checks are not practical, grade the source and mark those lanes as unverified.

Gate evidence is a command, not an impression. Run what the repo already ships and cite the command and its exit status: the typecheck, the configured linter on changed files, the test suite, and, for a release grade, the production build. For per-stack syntax (web/Node, MCP server, iOS/Swift, generic API), use the Gate Commands by Stack table in suede-code-review rather than inventing a command. Detect what exists and run only that; never introduce a tool the repo does not use, and never report a gate result you did not execute.

Instant-F Triggers

Check these before scoring any lane. Any single match is an automatic F, no other lanes matter until it is fixed. This list mirrors suede-code's canonical Step 1 list, change both together.

Secrets and credentials: hardcoded API key/secret/token/password in committed source; private key or certificate committed; OAuth/signing secret outside a secret manager. Injection: SQL built by string concatenation with user input; shell command from user input via exec/spawn/eval; template rendered with unescaped user input where XSS is reachable. Auth bypass: auth middleware with a path that skips it (early return, swallowed exception, always-true condition); permission check bypassable via request param; JWT accepting alg: none or a hardcoded secret. Payment and wallet: payment handler swallowing errors silently; webhook with no signature verification; amount or recipient from untrusted input without server-side validation. Data destruction: migration with DROP/destructive ALTER, no rollback, no tested restore; bulk delete/update with no WHERE or user-controlled WHERE; cache invalidation that clears production stores with no restore path. Plaintext sensitive data: password stored or logged in plaintext; PII to an unencrypted log/analytics pipeline; SSN/payment card/health data in a non-encrypted field.

If any Instant-F pattern is present: stop, report it, mark the grade F, list the specific file and line, and do not grade remaining lanes. The grade cannot be raised by other lane performance.

Grade Lanes

Score each lane A-F, then give one overall grade. When grading non-Suede work, substitute "domain truth" for "Suede truth": use whatever domain invariants apply (API contract truth, published-statement accuracy, data model truth).

• Correctness: intended behavior, edge cases, error paths, async behavior, routing, data flow, and regression risk.
• Security and permissions: auth, secrets, payment, wallet, injection, path, SSRF, permission, and data exposure risks fail closed.
• Data and state: schemas, migrations, caches, jobs, queues, webhooks, retries, idempotency, and state transitions stay consistent.
• Suede truth: public copy, rights, provenance, registry-backed media, royalty routing, licensing, agent-commerce, and product claims match the implementation.
• UX and release behavior: loading, empty, error, success, mobile/native, screenshot, metadata, route, and user-visible states hold together.
• Tests and verification: changed behavior has meaningful tests, builds, screenshots, simulator runs, MCP checks, live/API readbacks, or named caveats.
• Deploy readiness: env vars, feature flags, configs, migrations, rollback notes, install paths, docs, and release sequencing are clear.

Grade Meaning

• A: All lanes pass. Behavior is verified at runtime. No known follow-ups. Example: new feature with unit + integration tests, live readback confirmed, env vars documented, rollback is trivial.
• B: No blockers. One or more lanes have named, bounded follow-ups that do not affect correctness or safety in the current release. Example: happy-path tested but edge-case coverage is thin; or migration is forward-only but rollback risk is low and documented.
• C: At least one lane has a real defect or unverified risk that could surface in production but is not immediately catastrophic. Hold until that lane is fixed and rechecked. Example: auth path not fully tested; or a data migration with no rollback plan on a low-traffic table; or a God object in a payment module that obscures correctness.
• D: A serious defect exists that is likely to cause data loss, auth bypass, broken payments, or a user-visible production failure. Recommend not shipping until the defect is fixed and verified, and because these are extreme-risk categories, pause and put the choice to the user before any ship step. Example: missing auth check on a state-changing endpoint; migration with no tested rollback on a high-traffic table; payment flow that silently swallows errors.
• F: Strongly recommend against shipping. The change breaks core behavior, introduces an Instant-F pattern, or verification evidence is absent for a critical surface. Example: hardcoded API key in source, SQL injection via string concatenation, auth middleware that can be bypassed, or a payment handler with zero test coverage and no live readback.