← Routelarch / API
Tokens

Drive Routelarch from your own code

The page reads the files behind one Express or Fastify API service in the browser for free — one or more .js, .ts, .mjs or .cjs files joined into one paste, each introduced by a // file: <path> line, plus package.json for the Express or Fastify version — with its line numbers. It lexes strings, template literals, regex literals and comments out first (so a string that mentions req.body is never a finding), resolves require() and import between the pasted files, finds every express(), Router() and fastify() instance, and maps every route with its method, its full path through its mount (app.use("/api/orders", router)), its middleware chain and its handler (inline, or found by name in another pasted file), every use() registration in order with what each argument is (body parser, auth, rate limit, CORS, helmet, router, error handler), the error handlers, and what each handler reads from the request. Then it runs 17 deterministic checks drawn from Node.js backend practice (catalogue ids EX-01..EX-17, plus EX-18 for context): async handlers whose rejection never reaches the error handler on Express 4, an error handler that is missing, registered too early or without four parameters, stack traces or raw errors sent to the client, req.body read with no body parser in front, SQL or NoSQL built from request input, a whole request body written to the database, credential literals, jwt.decode() used as verification, CORS that admits any origin with credentials, a branch that sends and falls through to send again, login routes with no rate limit, blocking sync calls in a handler, request input in a redirect, a file path or a shell command, write routes with no authentication, APIs and path syntax Express 5 removed, missing helmet and graceful shutdown, and Fastify routes with no schema. Nothing is installed or run: every flag is a reading of the text. Its two paid steps are available over HTTP. You send one JSON object with task set to "audit" or "fix", the paste as code and the page’s check as a facts string, and the model replies with one JSON object: an audit that rates the four areas, answers every flag and gives exact before/after edits per finding, or the whole fixed file(s) with a list of every change tied to the page’s flags.

Base URL: https://api.skillsafe.ai/v1/app-api. Every call sends Content-Type: application/json and, once you have a token, Authorization: Bearer <token>. The paths below (/guest, /me, /estimate, /run, /jobs/{job_id}, /run-stream) are relative to it, exactly as sdk.js calls them. A plain-text summary of the app for agents is at /llms.txt. Both lanes run on the gpt-terra model with a 10% publisher markup. A run needs a signed-in (user) token and is metered: the platform places a hold on your credits when the run starts and then charges only what the run used. /estimate is free.

The response envelope

Responses are JSON of the form {"ok": ..., "data": ..., "error": {...}}. The page’s SDK (sdk.js) decides success from the HTTP status, not from ok: on a 2xx it returns data; otherwise it raises an error whose message is error.message (or the HTTP status text when the body carries none), with status, code (error.code) and details (error.details) attached. A body that is not JSON is treated as {}.

{ "ok": true,  "data": { ... } }
{ "ok": false, "error": { "code": "...", "message": "...", "details": { ... } } }

Error codes

Branch on the HTTP status and error.code, show error.message. The page handles 401 and 402 by name; the rest reach it as a generic failure (“The run failed: ...”).

HTTPerror.codeWhat it means / what to do
400VALIDATION_ERRORThe body is not a JSON object, a required field (task, code, facts) is missing, or a declared field has the wrong type. Every field is a string; sending facts or audit_handoff as an object is the usual cause.
401UNAUTHORIZEDNo token, or one that expired or was revoked. The page forgets the signed-in user and says “Your session expired - sign in again.” Get a new token.
402INSUFFICIENT_CREDITSThe balance cannot cover the run. The page says “Not enough credits for this run.” with a top-up link, and tries never to submit into a 402: it disables the run button when the /me balance is below the estimate’s min_credits.
404NOT_FOUNDA wrong path, or a job id that does not belong to this token.
409CONFLICTAn Idempotency-Key replayed with a different body. Send the original body, or use a new key (the page bumps its :a<attempt> suffix for a retry).
429RATE_LIMITEDToo many requests. Back off with a delay; do not tight-loop, and never resend a metered run without its original Idempotency-Key.

Failures that do not arrive as an HTTP status:

WhatWhat happens
event: error on /run-streamThe SDK raises an error carrying the event’s message, code and job_id.
Job status: "failed"Polling stops; the job’s error field says why.
Polling past 180 sThe SDK’s own client-side limit (waitForJob, 1 s interval, 180 000 ms default): it throws “job timed out”. The job itself is not cancelled.

The task field: two lanes

task routes the run, and it takes exactly two values: "audit" and "fix". Each lane has its own reply contract, and a reply never mixes them. The skill’s instructions tell the model to do the audit lane when task is missing or anything else (and the page’s own Expresskit.buildInput turns any lane that is not "fix" into "audit"), so a typo silently gets you an audit: always send one of the two values.

taskWhat it doesverdictUse it when
"audit"Reviews the service the way a senior Node.js engineer reviews an API before it goes to production: follows each request through its middleware chain to its handler and asks what happens when a query throws, what reaches the client when it does, what the handler does with each thing it reads from the request, who may call it and what it trusts, and what can block or crash the process on this version. It says what the service exposes and how a request flows through it, rates the four areas (errors, input, security, operations) as sound, fragile or broken, confirms or dismisses every page flag, adds what text rules cannot see, and gives the verbatim evidence and exact before/after edits for each finding, listed in the order to apply them — what fails requests or crashes the process first (async errors on Express 4, body parser order, removed Express 5 APIs), then what can be exploited (injection, paths, shell, tokens, missing authentication, CORS, secrets, rate limits), then what leaks or misbehaves (stack traces, double responses, mass assignment, sync calls), then hygiene — with a plan that ends in running the test suite, starting the service and calling each changed route, and npm audit.blocked | needs_work | readyBefore shipping: will an async handler hang the request and crash the process, is the body parser in front of the routes, is SQL built from request input, what reaches the client when something throws, who can call the write routes, is the token really verified, and what should change first.
"fix"Writes the fixed version of the pasted code: the whole of every file it changes (and at most two new files next to them, such as a small asyncHandler helper or a validation schema, never a second package.json), with async errors routed to the error handler, the body parser and the error handler in the right place, parameterised queries, only named and validated fields written, tokens verified, CORS read from a configured list, credentials moved into configuration, and a return after every early response — plus a changes list tied to the page flags, the verify steps (the test suite, starting the service and the request that would have caught the worst problem), and what it left open. Every route keeps its method and full path and every export its name unless the note asks for it, and no package the paste does not already use is added unless the note allows it.fixed | partialWhen you want the code changed, not a list of findings: a service you already know is broken, or what is left after an audit.

The page chains the two: after an audit, “Apply every edit and fix the rest” puts every audit edit into the paste, switches to the fix lane on that edited paste and adds an audit_handoff string (below) with the audit’s verdict, headline and findings. Over the API that is a second run with task: "fix", the edited paste as code, facts recomputed from the edited paste, and that string. The page drops the handoff as soon as the paste is edited again.

Guards the page applies before a run and the API does not: it refuses to price or run a paste it cannot read (“Nothing was pasted.”, “No JavaScript or TypeScript file was found. Paste the service's .js/.ts files, with a // file: server.js line above each file.”, or “This does not read as JavaScript or TypeScript source: no import, require, export or function was found.”), and it warns before a run on a paste that may not be an API service (“No Express or Fastify import and no route was found: this may not be an API service. Paste the file that creates the app and the route files (// file: server.js, // file: routes/users.js).”) or has no route at all (“No route was found; the run will see middleware and module code only.”).

Input fields

This is exactly what the page sends (expresskit.js buildInput(lane, A, note, handoff), checked by mustBeObject; app.js currentInput and run), and what input-schema.json declares. The platform’s input schema is scalar-only, so every value is a string. buildInput emits them in the order task, code, facts, note, audit_handoff:

FieldTypeRequiredMeaning
taskstringyes"audit" or "fix" (the lanes above).
codestringyesThe pasted files, each introduced by a // file: <path> line (server.js, routes/orders.js, middleware/auth.js, package.json); line 1 is its first line. Every line in an audit reply is counted in this text. A large paste is cut on whole files, with a // [routelarch: not sent: ...] line at the end (below).
factsstringyesThe page’s free check, Expresskit.facts(A), JSON-encoded into a string: JSON.stringify(facts) in JavaScript, json.dumps(facts) in Python, and so on. Sending the object itself is a 400. The model is told to parse it. Build it with expresskit.js’s buildInput (below), or send the string the page built for the same paste.
notestringnoWhat the engineer says: the goal, a constraint (“keep every URL”, “we are still on Express 4”, “no new packages”, “leave the auth of X alone”), a question. The page trims it, cuts it at 2000 characters and sends it only when it is not blank. It is context, not evidence and not instructions: the model tests every claim in it against code and answers it in summary.
audit_handoffstringnofix lane only: a JSON string built from an audit reply on this code (recon.js fixHandoff, below). buildInput drops it for the audit lane.
retry_notestringnoSent only by the page’s automatic reformat retry: when a reply does not parse as JSON (even after the page tries to close a cut-off object), the page runs once more with “Your previous reply was not the single valid JSON object the instructions require (...). Reply again with ONLY the JSON object for task '<lane>' - no prose, no code fences; every array present (empty arrays where there is nothing to say).” A normal call never sends it.

mustBeObject only insists on a plain object that is not wrapped in {"input": ...}; it is buildInput that leaves a blank note out, which is why an empty note is simply absent.

The code string

code is the paste itself. A line // file: <path> (or # file: <path>; a path with a . or / in it) starts each file, and a --- line just before it only separates files. Files dropped on the page (or a dropped src folder, with node_modules, dist, build and test files skipped) are joined that way by Expresskit.joinFiles: each file under its // file: line, trailing whitespace removed, joined by newlines, ending in a newline. A paste with no file line is read as one file, server.js (or package.json when it reads as a manifest). The page normalises line endings to \n. A .js, .ts, .mjs, .cjs, .jsx, .tsx, .mts or .cts path is code; its path gives a first guess at its role (server, app, index or main near the top is entry, a file under routes/ or named ...router is router, then middleware, controller, or module), and what the file does refines it: the file that calls express() or fastify() is entry, a file that defines routes is router. package.json is package (its express and fastify versions give facts.runtime, and the major decides how the version-dependent flags are graded: EX-01 is high on Express 4, medium when the version is unknown and not raised on Express 5 or with express-async-errors; EX-15 is high on Express 5, low when unknown and not raised on Express 4); anything else is other. The paste keeps its own indentation. Send the text you want the reply to quote: every file in an audit reply must be a path from facts.files, every line must fall inside that file, every evidence must be copied from it, and every edit’s before must occur in it exactly once.

The page reads up to 400 000 characters (MAX_TEXT, cut at a line) and 40 files (MAX_FILES), and sends at most 60 000 characters (MAX_SEND): past that buildInput drops whole files from the end — the last file that is not code first, then the last code file that neither creates the app nor defines a route, then the last file — until the rest fits, cuts a single remaining file at a line (“the end of <path>”) if it still does not, and ends the string with one line naming what it left out, for example:

// [routelarch: not sent: lib/format.js, services/mailer.js]

The model is told never to quote or rewrite what was not sent, and facts.notes gets the sentence “Not sent (the paste is over 60,000 characters): ... The page checked them; the run did not see them.” facts is still computed from the whole paste. The worked examples below are small, so their code is the paste unchanged.

The facts string

facts is optional to compute but required to send. It is produced by the page’s free check: Expresskit.analyze splits the paste into files, lexes them, finds their functions, exports, requires and imports, resolves them between the files, maps every app, router, mount, route, middleware chain and handler, and runs the rules, and Expresskit.facts(A) turns that analysis into the object below (it does not depend on the lane: an audit and a fix run of the same paste carry the same facts). It is how the model knows which flags to answer, which file paths and line ranges to name, which routes and exports must survive, and which framework version it is reading. Its top-level keys, in the order built:

KeyContents
runtimeframework (Express, Fastify, or a note that neither import was found), express and fastify (the version range in a pasted package.json, or null), express_major and fastify_major (4, 5, ... or null when unknown), node (engines.node), package_json_pasted, dependencies (the package names, up to 60), and code_files, routes (counts) and entry_pasted (whether the file that creates the app was pasted).
filesEvery file: path (use it verbatim), kind (code, package, other), line and end_line (the paste lines of the file’s content, without its // file: line), and for code a role (entry, router, middleware, controller, module).
exportsEvery export (up to 200): name (default for module.exports = x or a default export), file, line, kind (function, const, module.exports, export default).
functionsEvery named function (up to 200): name, file, line, async, params.
routesEvery route (up to 150): method, path, full_path (with its mount prefix), label ("POST /api/orders"), file, line, kind (express or fastify), handler (inline, a name with the file it was found in, or <name> (not pasted)), async, wrapped (inside an asyncHandler-style call), middleware (the chain before the handler: {name, kind} with kind body_parser, auth, rate_limit, cors, helmet, router, middleware, error_handler ...), reads (body, params, query, headers, cookies), and for a Fastify route with an options object, options.
middlewareEvery use() in registration order (up to 120): file, line, on (the app or router variable), path (the mount path or null), args ({name, kind} as above).
error_handlersWhere error-handling middleware (four parameters) or setErrorHandler is registered (up to 20): file, line, on.
flagsEvery flag the page raised: uid (F1, F2, ... in severity, file, then line order), id (EX-01..EX-18), sev (high | medium | low | info), file, line, text, detail, and lines (every line an aggregated flag covers, only when it covers more than one). An audit must answer every non-info flag by its uid; a fix must close every high and medium flag or name it in open.
verdict_candidateThe audit verdict the flags point at (the page’s own reading): blocked with any high flag, needs_work with any medium, otherwise ready.
notesPlain sentences about what was not read or not sent (empty for a paste that fits).

The simplest source is expresskit.js itself: the page loads it from /expresskit.js, and it also runs in Node (it sets module.exports). Its buildInput is the function the page calls, so this script prints exactly what the page would send as code and facts (with the 60 000-character cut applied), with the facts decoded so you can read them; the step 4 samples compact them back into the page’s string byte for byte. Save the paste as orders-paste.txt and redirect the output into orders-check.json:

// build-check.js -- run: node build-check.js orders-paste.txt > orders-check.json   (expresskit.js saved next to it)
const fs = require("fs");
const Expresskit = require("./expresskit.js");
const A = Expresskit.analyze(fs.readFileSync(process.argv[2], "utf8"));
if (!A.ok) { console.error(A.errors.join("\n")); process.exit(1); }
const inp = Expresskit.buildInput("audit", A, "", null);     // code and facts do not depend on the lane
console.log(JSON.stringify({ code: inp.code, facts: JSON.parse(inp.facts) }, null, 2));
const real = A.flags.filter((f) => f.sev !== "info");
const codeFiles = A.files.filter((f) => f.kind === "code").length;
console.error(codeFiles + " code file(s), " + A.routes.length + " route(s), " + A.middleware.length + " use() registration(s); " +
  real.length + " flags (" + A.counts.high + " high, " + A.counts.medium + " medium, " + A.counts.low + " low); verdict_candidate " + A.candidate);

For the orders example it reports 3 code file(s), 3 route(s), 4 use() registration(s); 10 flags (5 high, 3 medium, 2 low); verdict_candidate blocked; for the tasks example, 3 code file(s), 3 route(s), 0 use() registration(s); 7 flags (2 high, 2 medium, 3 low); verdict_candidate blocked. For both worked examples its code and facts are exactly what the page sends.

Without the page’s check. The platform only checks that facts is a string, so a minimal object works — "{}", or a hand-built one such as {"flags": [], "notes": ["No page check was run; read the code directly."]} — and the model still reads code. But you lose what the check adds: with no flags there is nothing to confirm, dismiss or close, with no files there are no paths, line ranges or roles to name, with no routes and middleware the model has to rebuild every mount and chain itself, with no runtime it does not know the Express major (and so whether an async handler needs a wrapper), and with no exports nothing says what must survive a fix. Build it with expresskit.js as above when you can.

The audit_handoff string

Only for task: "fix", and only for the code the audit was about with every audit edit applied. The page builds both from the normalised audit reply res (recon.js normalize, below) and the analysis A of the audited paste, in recon.js fixHandoff:

const run = Recon.applyFindings(A, res.findings, Expresskit);   // every finding's edits, in order, each on top of the last
JSON.stringify({ verdict: res.verdict, headline: res.headline,
  findings: res.findings.map(f => ({ id: f.id, severity: f.severity, file: f.file, line: f.line, title: f.title, why: f.why, edits: f.edits.length })),
  applied: /* edits that applied */, failed: /* edits that did not */ })
// run.A.text is the edited paste: it becomes code, and facts is recomputed from it

That is {"verdict", "headline", "findings": [{id, severity, file, line, title, why, edits}], "applied", "failed"}, where each finding’s edits is the number of edits it carried. applyFindings applies every finding’s edits with Expresskit.applyEdits, in the order listed: each before must occur exactly once in its file as the earlier edits left it (leading and trailing blank lines ignored), or that edit is reported as failed and skipped — it is never guessed. The handoff is a previous reply, not evidence: the model checks it against code and fixes what is left. This script does the whole step — the edited paste, its recomputed facts and the handoff string, in the same shape as build-check.js prints, so the samples read it the same way:

// handoff.js -- run: node handoff.js orders-paste.txt orders-reply.txt > orders-fix-check.json   (expresskit.js, recon.js next to it)
const fs = require("fs");
const Expresskit = require("./expresskit.js");
const Recon = require("./recon.js");
const A = Expresskit.analyze(fs.readFileSync(process.argv[2], "utf8"));        // the audited paste
const res = Recon.normalize(Recon.parseResult(fs.readFileSync(process.argv[3], "utf8")), "audit");
const ho = Recon.fixHandoff(A, res);                                            // every edit, in order
const B = Expresskit.analyze(ho.text);                                          // facts recomputed from the edited paste
const inp = Expresskit.buildInput("fix", B, "", ho.handoff);
console.log(JSON.stringify({ code: inp.code, facts: JSON.parse(inp.facts), audit_handoff: inp.audit_handoff }, null, 2));
console.error(ho.applied + " edit(s) applied, " + ho.failed + " did not apply");

Save the audit’s output.output as orders-reply.txt; for the orders audit below it reports 8 edit(s) applied, 0 did not apply. The edited paste then reads 3 code file(s), 3 route(s), 4 use() registration(s); 3 flags (0 high, 2 medium, 1 low); verdict_candidate needs_work: what is left is the CORS origin list (EX-09), authentication in front of POST /api/orders (EX-14) and helmet (EX-16) — the three decisions the audit’s own questions ask about. The page sends that fix run with the audit’s note and the key routelarch:fix:5b65685f-2c1f:a1.

The output contracts

The model is instructed (SKILL.md) to reply with one JSON object and nothing else — no prose, no code fences — with every array of its lane present ([] when empty). The run’s output text is that object. In both lanes it must ground everything in code: a middleware, a helper (db, User, requireAuth, a config module ...), a database schema, a proxy or the deployment that is not in the paste is never claimed to do anything — it goes into questions, and a handler or middleware that was not pasted is written about conditionally (“if requireAuth checks the token ...”). It must never write a secret value: a line that holds a literal credential is never copied into the reply (not in evidence, not in an edit, not in a file), and no credential, real hostname or endpoint is invented. A new setting is read the way the paste already reads settings (through its config module). It must never change what the service offers its clients: every route keeps its method and full path, every export keeps its name, and every response keeps its shape and status on success, unless the note asks for it (adding a 400/401/403/404 answer for a request that must be refused is allowed). It uses an API only when it is sure the API exists with that name in that package and version, says which advice depends on the version when the version is unknown, and never adds a package the paste does not already use unless the note allows it (a small asyncHandler helper is preferred to a new package). Every page flag whose sev is not info is answered exactly once (audit lane: in flag_answers), and an info flag is never reported as a finding.

task: "audit"

task: "fix"

How the page reads a reply (recon.js parseResult and normalize): it strips a code fence and parses from the first { to the last }. A reply is read as the lane that was asked for, unless it names the other lane and carries that lane’s body (a files array for fix, a findings array for audit). An unknown verdict shows as needs_work or partial and counts as a disagreement; an unknown severity becomes medium; ids like EX7 or ex 7 become EX-07; flags keeps only F<n> values; findings with no file, evidence and title are dropped; service may also arrive as route or api, file as path, a change’s function as func and its change as what, and an open item as path; questions is capped at 10, plan at 30 and verify at 20. An audit reply carries 9 sections (verdict, headline, service, areas, findings, flag_answers, plan, questions, summary) and a fix reply 8 (verdict, headline, files, changes, verify, open, questions, summary), which is what the page counts when it recovers a partial reply.

Worked examples

Both are examples the page ships (the example buttons on the app page; the full pastes are in /example.js, ids orders and tasks, and the replies in /example-result.js), built exactly as the page builds them: Expresskit.buildInput(lane, Expresskit.analyze(text), note, null), with the real model reply the page replays for each. The request bodies cut the long code and facts strings with a visible ..., and the replies are pretty-printed excerpts, with ... where entries were left out. Every value shown is copied from the input or the reply. The services and their values are invented; the tasks paste holds a (made-up) database password in a connection string, which is why that line is not shown here and why the reply never repeats it.

Audit: an orders API on Express 4 whose async handlers never reach the error handler, whose body parser comes after the router, and which builds SQL from the query string

Four files: package.json (express ^4.19.2, pg and cors), server.js, db.js and routes/orders.js: a small orders service. server.js registers cors({ origin: true, credentials: true }), mounts the orders router on /api/orders and only then registers express.json(), and its error handler sends err.message and err.stack to the client. The three route handlers are async with no try/catch and no wrapper, GET /api/orders interpolates req.query.status into its SQL, and POST /api/orders has no authentication in front of it. The page’s free check raises 10 flags (5 high, 3 medium, 2 low) (plus the EX-18 context flag); its own reading of the verdict is blocked. The engineer’s note: “Since we moved the handlers to async/await the API sometimes hangs, and twice the whole process died. What else should we fix before the launch on Monday?”

The code string, whole: 1,679 characters, 66 lines ending in a newline. Save it as orders-paste.txt and run node build-check.js orders-paste.txt > orders-check.json:

// file: package.json
{
  "name": "pinvarra-orders-api",
  "private": true,
  "main": "server.js",
  "dependencies": {
    "cors": "^2.8.5",
    "express": "^4.19.2",
    "pg": "^8.11.3"
  }
}
// file: server.js
const express = require("express");
const cors = require("cors");
const ordersRouter = require("./routes/orders");

const app = express();

app.use(cors({ origin: true, credentials: true }));
app.use("/api/orders", ordersRouter);
app.use(express.json());

app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: err.message, stack: err.stack });
});

app.listen(3000, () => {
  console.log("orders api listening");
});
// file: db.js
const { Pool } = require("pg");

const pool = new Pool({ max: 10 });

module.exports = pool;
// file: routes/orders.js
const { Router } = require("express");
const db = require("../db");

const router = Router();

router.get("/", async (req, res) => {
  const { status } = req.query;
  const result = await db.query(`SELECT id, sku, qty, status FROM orders WHERE status = '${status}' ORDER BY id DESC`);
  res.json(result.rows);
});

router.get("/:id", async (req, res) => {
  const result = await db.query("SELECT id, sku, qty, status FROM orders WHERE id = $1", [req.params.id]);
  if (!result.rows.length) {
    return res.status(404).json({ error: "order not found" });
  }
  res.json(result.rows[0]);
});

router.post("/", async (req, res) => {
  const { sku, qty } = req.body;
  const result = await db.query(
    "INSERT INTO orders (sku, qty, status) VALUES ($1, $2, 'open') RETURNING id",
    [sku, qty]
  );
  res.status(201).json({ id: result.rows[0].id });
});

module.exports = router;

Its facts, decoded, as an excerpt: the runtime block, the files, the first route and the first three use() registrations, the error handler, and every flag without its detail sentence (the full object also lists the other two routes, the fourth registration — the error handler — and the two exports, the module.exports of db.js and of routes/orders.js; the request carries it as one compact JSON string):

{
  "runtime": {
    "framework": "Express",
    "express": "^4.19.2",
    "express_major": 4,
    "fastify": null,
    "fastify_major": null,
    "node": null,
    "package_json_pasted": true,
    "dependencies": [
      "cors",
      "express",
      "pg"
    ],
    "code_files": 3,
    "routes": 3,
    "entry_pasted": true
  },
  "files": [
    {"path":"package.json","kind":"package","line":2,"end_line":11},
    {"path":"server.js","kind":"code","line":13,"end_line":30,"role":"entry"},
    {"path":"db.js","kind":"code","line":32,"end_line":36,"role":"module"},
    {"path":"routes/orders.js","kind":"code","line":38,"end_line":66,"role":"router"}
  ],
  "routes": [
    {
      "method": "GET",
      "path": "/",
      "full_path": "/api/orders",
      "label": "GET /api/orders",
      "file": "routes/orders.js",
      "line": 43,
      "kind": "express",
      "handler": "inline",
      "async": true,
      "wrapped": false,
      "middleware": [],
      "reads": [
        "query"
      ]
    },
    ...
  ],
  "middleware": [
    {"file":"server.js","line":19,"on":"app","path":null,"args":[{"name":"cors({ origin: true, credentials: tru...","kind":"cors"}]},
    {"file":"server.js","line":20,"on":"app","path":"/api/orders","args":[{"name":"ordersRouter","kind":"router"}]},
    {"file":"server.js","line":21,"on":"app","path":null,"args":[{"name":"express.json()","kind":"body_parser"}]},
    ...
  ],
  "error_handlers": [
    {
      "file": "server.js",
      "line": 23,
      "on": "app"
    }
  ],
  "flags": [
    {"uid":"F1","id":"EX-01","sev":"high","file":"routes/orders.js","line":45,"text":"async handler for GET /api/orders: a rejected await never reaches the error handler"},
    {"uid":"F2","id":"EX-05","sev":"high","file":"routes/orders.js","line":45,"text":"SQL built from request input in GET /api/orders"},
    {"uid":"F3","id":"EX-01","sev":"high","file":"routes/orders.js","line":50,"text":"async handler for GET /api/orders/:id: a rejected await never reaches the error handler"},
    {"uid":"F4","id":"EX-04","sev":"high","file":"routes/orders.js","line":58,"text":"req.body is read by a route registered before the body parser (POST /api/orders)"},
    {"uid":"F5","id":"EX-01","sev":"high","file":"routes/orders.js","line":59,"text":"async handler for POST /api/orders: a rejected await never reaches the error handler"},
    {"uid":"F6","id":"EX-09","sev":"medium","file":"server.js","line":19,"text":"CORS reflects any origin and allows credentials"},
    {"uid":"F7","id":"EX-03","sev":"medium","file":"server.js","line":25,"text":"the stack trace of err is sent to the client"},
    {"uid":"F8","id":"EX-14","sev":"medium","file":"routes/orders.js","line":57,"text":"no authentication in front of POST /api/orders"},
    {"uid":"F9","id":"EX-16","sev":"low","file":"server.js","line":17,"text":"no helmet() on app"},
    {"uid":"F10","id":"EX-16","sev":"low","file":"server.js","line":28,"text":"no graceful shutdown: SIGTERM is never handled"},
    {"uid":"F11","id":"EX-18","sev":"info","file":"server.js","line":13,"text":"context: Express, 3 code files, 3 routes, 4 use() registrations, express ^4.19.2"}
  ],
  "verdict_candidate": "blocked",
  "notes": []
}

Note what the chain says on its own: use() on line 20 mounts the router and line 21 registers the body parser, so every route inside the router reads req.body before it is parsed (F4). The request body (POST /estimate, then POST /run or /run-stream with Idempotency-Key: routelarch:audit:e299aa89-260e:a1 as the page sends it):

{
  "task": "audit",
  "code": "// file: package.json\n{\n  \"name\": \"pinvarra-orders-api\",\n  \"private\": true,\n  \"main\": \"server.js\",\n  \"dependencies\": {\n    \"cors\": \"^2.8.5\",\n    \"express\": \"^4.19.2\",\n    \"pg\": \"^8.11.3\"\n  }\n}\n// file: server.js\nconst express = require(\"express\");\nconst cors = require(\"cors\");\n...",
  "facts": "{\"runtime\":{\"framework\":\"Express\",\"express\":\"^4.19.2\",\"express_major\":4,\"fastify\":null,\"fastify_major\":null,\"node\":null,\"package_json_pasted\":true,\"dependencies\":[\"cors\",\"express\",\"pg\"],\"code_files\":3,\"routes\":3,\"entry_pasted\":true},\"files\":[{\"path\":\"package.json\",\"kind\":\"package\",\"line\":2,\"end_line\":11},{\"path\":\"server.js\",\"kin...",
  "note": "Since we moved the handlers to async/await the API sometimes hangs, and twice the whole process died. What else should we fix before the launch on Monday?"
}

The reply (output.output), an excerpt: the verdict, the headline, the service, the four areas, the finding that answers “why does it hang and crash” (the unwrapped async handler that also builds SQL from the query string) with its edits, the body parser finding, the first two flag answers, the last two plan steps, the first question and the summary:

{
  "task": "audit",
  "verdict": "blocked",
  "headline": "Unparameterised SQL, unhandled async rejections on Express 4, and a body parser registered after the router can each hang or crash this orders API before Monday's launch.",
  "service": "This Express 4 service exposes three JSON routes under /api/orders (list by status, fetch by id, create) backed directly by a pg Pool; a request passes through CORS, then the orders router, and only afterward a JSON body parser and a single catch-all error handler.",
  "areas": [
    {
      "area": "errors",
      "status": "broken",
      "note": "All three route handlers are async with no try/catch, no asyncHandler wrapper and no express-async-errors, so a rejected query hangs the request and can crash the process on Node 15+; the error handler itself also sends err.stack and err.message to the client."
    },
    {
      "area": "input",
      "status": "broken",
      "note": "express.json() is registered after the orders router, so req.body is undefined on every POST /api/orders; GET /api/orders also builds its SQL by interpolating req.query.status directly into the query text."
    },
    {
      "area": "security",
      "status": "fragile",
      "note": "POST /api/orders has no authentication in its chain, and CORS reflects any Origin while allowing credentials, so a page on any other site could call it using a signed-in user's cookies."
    },
    {
      "area": "operations",
      "status": "sound",
      "note": "No helmet() and no SIGTERM handling were the only gaps found here, both low severity; nothing blocks the event loop and no Express 5 API is used."
    }
  ],
  "findings": [
    {
      "id": "EX-01",
      "flags": [
        "F1",
        "F2"
      ],
      "file": "routes/orders.js",
      "line": 45,
      "severity": "high",
      "area": "errors",
      "title": "GET /api/orders builds SQL from request input and can hang the process on failure",
      "evidence": "  const { status } = req.query;\n  const result = await db.query(`SELECT id, sku, qty, status FROM orders WHERE status = '${status}' ORDER BY id DESC`);",
      "why": "req.query.status is spliced straight into the query text, so a value like ' OR '1'='1 changes the WHERE clause and a value with a quote can run a second statement (SQL injection). Separately this is an async handler with no try/catch and no wrapper: on Express 4 a rejected db.query() (a bad connection, a syntax error) never reaches the error handler, the request just hangs, and on Node 15+ the unhandled rejection can crash the whole process - matching the hangs and crashes reported before launch.",
      "edits": [
        {
          "before": "const db = require(\"../db\");",
          "after": "const db = require(\"../db\");\nconst asyncHandler = (fn) => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next);"
        },
        {
          "before": "router.get(\"/\", async (req, res) => {\n  const { status } = req.query;\n  const result = await db.query(`SELECT id, sku, qty, status FROM orders WHERE status = '${status}' ORDER BY id DESC`);\n  res.json(result.rows);\n});",
          "after": "router.get(\"/\", asyncHandler(async (req, res) => {\n  const { status } = req.query;\n  const result = await db.query(\n    \"SELECT id, sku, qty, status FROM orders WHERE status = $1 ORDER BY id DESC\",\n    [status]\n  );\n  res.json(result.rows);\n}));"
        }
      ]
    },
    {
      "id": "EX-04",
      "flags": [
        "F4"
      ],
      "file": "server.js",
      "line": 20,
      "severity": "high",
      "area": "input",
      "title": "The JSON body parser is registered after the orders router",
      "evidence": "app.use(\"/api/orders\", ordersRouter);\napp.use(express.json());",
      "why": "Express runs middleware in registration order: a request to /api/orders reaches the router before express.json() ever parses the body, so req.body is undefined for POST /api/orders. Destructuring `const { sku, qty } = req.body;` then throws inside an async handler, which becomes an unhandled rejection under EX-01 - every POST request fails this way today.",
      "edits": [
        {
          "before": "app.use(\"/api/orders\", ordersRouter);\napp.use(express.json());",
          "after": "app.use(express.json());\napp.use(\"/api/orders\", ordersRouter);"
        }
      ]
    },
    ...
  ],
  "flag_answers": [
    {
      "flag": "F1",
      "status": "confirmed",
      "reason": "Async handler with no try/catch or wrapper at routes/orders.js line 45."
    },
    {
      "flag": "F2",
      "status": "confirmed",
      "reason": "req.query.status is interpolated into the SQL text at routes/orders.js line 45."
    },
    ...
  ],
  "plan": [
    ...,
    "Run the test suite, start the service, then call each route: GET /api/orders?status=' OR '1'='1 (expect a normal result, not an error), POST /api/orders with a normal body (expect 201, no crash), a request that makes the database throw (expect a JSON 500 with no stack), and POST /api/orders without a token once auth is added (expect 401).",
    "Run npm audit."
  ],
  "questions": [
    "What authentication should protect POST /api/orders, and should the GET routes stay public? No auth code is pasted.",
    ...
  ],
  "summary": "The hangs and crashes reported trace to two compounding Express 4 bugs: express.json() is registered after the orders router, so every POST /api/orders reads req.body as undefined and throws, and none of the three handlers catch a rejected promise, so that throw (or any database error) becomes an unhandled rejection that Express 4 can't route to the error handler and Node can turn into a process crash. GET /api/orders also builds its SQL by string interpolation, a SQL injection alongside the crash risk. The body-parser order, all three handlers and the parameterised query are fixed with edits here; POST /api/orders still needs authentication, CORS needs a real origin allow-list, and the error handler still needs to stop returning err.stack before Monday's launch."
}

The reply has 8 findings and confirms all 10 flags, with 8 edits in all. The first finding (EX-01, carrying F1 and F2) adds a one-line asyncHandler next to the db require and wraps GET /api/orders in it with a $1 placeholder; the second (EX-01, F3 and F5) wraps GET /api/orders/:id and POST /api/orders the same way; the EX-04 finding shown above moves express.json() in front of the router (F4); the EX-03 finding stops sending err.stack (F7); and the low EX-16 finding for F10 adds a SIGTERM handler that closes the server and the pool. Three findings carry no edit because they need a decision the paste cannot make: authentication for POST /api/orders (EX-14, F8), the CORS origin list (EX-09, F6) and helmet, which is not yet a dependency (EX-16, F9) — which is why its questions ask about exactly those three, and why the re-check below still raises them.

Fix: a Fastify task API that decodes tokens without verifying them, builds ORDER BY from the query string, keeps its database password in the source and reflects any origin with credentials

Four files: package.json (fastify ^4.28.1, @fastify/cors, jsonwebtoken and mysql2), server.js, config.js and routes/tasks.js. server.js creates the MySQL pool from a literal connection string that carries a password, registers @fastify/cors with origin: true, credentials: true, and authenticates every request in an onRequest hook that calls jwt.decode() and never jwt.verify(); routes/tasks.js puts request.query.sort into ORDER BY. The free check raises 7 flags (2 high, 2 medium, 3 low); its reading of the verdict is blocked. This example has no audit before it, so it carries no audit_handoff. The engineer’s note: “Pen test found that any made-up token is accepted. Fix every high and medium problem the check found; keep every route URL, and do not add packages.”

The code string is 2,227 characters, 78 lines ending in a newline; the whole paste is the tasks entry of /example.js. Save it as tasks-paste.txt and run node build-check.js tasks-paste.txt > tasks-check.json. Two excerpts: the hook F1 points at, and the routes file, whole:

// file: server.js (lines 26-33)
app.addHook("onRequest", async (request, reply) => {
  const auth = request.headers.authorization || "";
  const claims = jwt.decode(auth.replace(/^Bearer /, ""));
  if (!claims) {
    return reply.code(401).send({ error: "sign in first" });
  }
  request.user = claims;
});
// file: routes/tasks.js
module.exports = async function tasksRoutes(fastify) {
  fastify.get("/", async (request) => {
    const sort = request.query.sort || "created_at";
    const [rows] = await fastify.db.query(
      `SELECT id, title, done FROM tasks WHERE owner_id = ? ORDER BY ${sort}`,
      [request.user.sub]
    );
    return rows;
  });

  fastify.post(
    "/",
    {
      schema: {
        body: {
          type: "object",
          required: ["title"],
          properties: { title: { type: "string", minLength: 1, maxLength: 200 } },
        },
      },
    },
    async (request, reply) => {
      const [result] = await fastify.db.execute("INSERT INTO tasks (owner_id, title) VALUES (?, ?)", [request.user.sub, request.body.title]);
      reply.code(201);
      return { id: result.insertId };
    }
  );

  fastify.patch("/:id", async (request) => {
    await fastify.db.execute("UPDATE tasks SET done = ? WHERE id = ? AND owner_id = ?", [request.body.done ? 1 : 0, request.params.id, request.user.sub]);
    return { ok: true };
  });
};

Its facts, decoded, cut to runtime, files, the flags (without their detail) and verdict_candidate (the full object also carries the 3 exports — port and jwtKey of config.js, the module.exports of routes/tasks.js —, the function tasksRoutes and the three routes GET /tasks, POST /tasks and PATCH /tasks/:id; Fastify has no use() chain here, so middleware and error_handlers are empty):

{
  "runtime": {
    "framework": "Fastify",
    "express": null,
    "express_major": null,
    "fastify": "^4.28.1",
    "fastify_major": 4,
    "node": null,
    "package_json_pasted": true,
    "dependencies": [
      "@fastify/cors",
      "fastify",
      "jsonwebtoken",
      "mysql2"
    ],
    "code_files": 3,
    "routes": 3,
    "entry_pasted": true
  },
  "files": [
    {"path":"package.json","kind":"package","line":2,"end_line":11},
    {"path":"server.js","kind":"code","line":13,"end_line":37,"role":"entry"},
    {"path":"config.js","kind":"code","line":39,"end_line":44,"role":"module"},
    {"path":"routes/tasks.js","kind":"code","line":46,"end_line":78,"role":"router"}
  ],
  "flags": [
    {"uid":"F1","id":"EX-08","sev":"high","file":"server.js","line":28,"text":"jwt.decode() used without jwt.verify()"},
    {"uid":"F2","id":"EX-05","sev":"high","file":"routes/tasks.js","line":49,"text":"SQL built from request input in GET /tasks"},
    {"uid":"F3","id":"EX-07","sev":"medium","file":"server.js","line":20,"text":"credential literal in a connection string"},
    {"uid":"F4","id":"EX-09","sev":"medium","file":"server.js","line":22,"text":"CORS reflects any origin and allows credentials"},
    {"uid":"F5","id":"EX-16","sev":"low","file":"server.js","line":37,"text":"no graceful shutdown: SIGTERM is never handled"},
    {"uid":"F6","id":"EX-17","sev":"low","file":"routes/tasks.js","line":47,"text":"GET /tasks reads request.query with no schema"},
    {"uid":"F7","id":"EX-17","sev":"low","file":"routes/tasks.js","line":74,"text":"PATCH /tasks/:id reads request.body with no schema"},
    {"uid":"F8","id":"EX-18","sev":"info","file":"server.js","line":13,"text":"context: Fastify, 3 code files, 3 routes, 0 use() registrations, fastify ^4.28.1"}
  ],
  "verdict_candidate": "blocked"
}

The request body (Idempotency-Key: routelarch:fix:601c1dd2-1fbb:a1):

{
  "task": "fix",
  "code": "// file: package.json\n{\n  \"name\": \"ferlowen-tasks\",\n  \"private\": true,\n  \"dependencies\": {\n    \"@fastify/cors\": \"^9.0.1\",\n    \"fastify\": \"^4.28.1\",\n    \"jsonwebtoken\": \"^9.0.2\",\n    \"mysql2\": \"^3.11.0\"\n  }\n}\n// file: server.js\nconst Fastify = require(\"fastify\");\nconst cors = require(\"@fastify/cors\");\nconst jwt = require(\"jsonwebtoken\");\nconst mysql = require(\"mysql2/promise\");\nconst config = require(\"./config\");\n...",
  "facts": "{\"runtime\":{\"framework\":\"Fastify\",\"express\":null,\"express_major\":null,\"fastify\":\"^4.28.1\",\"fastify_major\":4,\"node\":null,\"package_json_pasted\":true,\"dependencies\":[\"@fastify/cors\",\"fastify\",\"jsonwebtoken\",\"mysql2\"],\"code_files\":3,\"routes\":3,\"entry_pasted\":true},\"files\":[{\"path\":\"package.json\",\"kind\":...",
  "note": "Pen test found that any made-up token is accepted. Fix every high and medium problem the check found; keep every route URL, and do not add packages."
}

The reply (output.output), an excerpt: the verdict, the headline, the first of the three returned files (server.js, whole, with the connection string replaced by config.databaseUrl), the change that closes the token hole and the one that closes the SQL injection, the first three verification steps, the (empty) open list and the summary:

{
  "task": "fix",
  "verdict": "fixed",
  "headline": "Tokens are now verified, the sort column is allow-listed, the DB credential moved to config, and CORS is restricted to a configured origin list.",
  "files": [
    {
      "path": "server.js",
      "content": "const Fastify = require(\"fastify\");\nconst cors = require(\"@fastify/cors\");\nconst jwt = require(\"jsonwebtoken\");\nconst mysql = require(\"mysql2/promise\");\nconst config = require(\"./config\");\n\nconst app = Fastify({ logger: true });\nconst db = mysql.createPool(config.databaseUrl);\n\napp.register(cors, { origin: config.corsOrigins, credentials: true });\n\napp.decorate(\"db\", db);\n\napp.addHook(\"onRequest\", async (request, reply) => {\n  const auth = request.headers.authorization || \"\";\n  const token = auth.replace(/^Bearer /, \"\");\n  let claims;\n  try {\n    claims = jwt.verify(token, config.jwtKey, { algorithms: [\"HS256\"] });\n  } catch (err) {\n    return reply.code(401).send({ error: \"sign in first\" });\n  }\n  request.user = claims;\n});\n\napp.register(require(\"./routes/tasks\"), { prefix: \"/tasks\" });\n\napp.listen({ port: config.port, host: \"0.0.0.0\" });\n"
    },
    ...
  ],
  "changes": [
    {
      "file": "server.js",
      "function": "(module)",
      "flags": [
        "F1"
      ],
      "change": "Verify the bearer token with jwt.verify(token, config.jwtKey, { algorithms: [\"HS256\"] }) inside a try/catch instead of jwt.decode(), answering 401 when verification throws",
      "why": "stops anyone from writing an unsigned or forged token and being treated as signed in"
    },
    {
      "file": "routes/tasks.js",
      "function": "GET /tasks",
      "flags": [
        "F2"
      ],
      "change": "Check request.query.sort against an allow-list of column names (created_at, title, done, id), falling back to created_at when it does not match, before it reaches the ORDER BY clause",
      "why": "prevents SQL injection through the sort query parameter"
    },
    ...
  ],
  "verify": [
    "Run the test suite if one exists.",
    "Set DATABASE_URL, JWT_KEY and CORS_ORIGINS and start the service (node server.js); confirm it now throws at startup when DATABASE_URL is unset instead of using a literal credential.",
    "Call GET /tasks with an Authorization header holding a base64-encoded but unsigned or wrongly-signed token (the pen test's made-up token) and expect 401, not a 200 with data.",
    ...
  ],
  "open": [],
  "questions": [],
  "summary": "Fixed both high findings: the onRequest hook now calls jwt.verify with the HS256 algorithm and config.jwtKey inside a try/catch, and GET /tasks checks its sort parameter against an allow-list before it reaches the SQL text. Fixed both medium findings by moving the database connection string and the CORS origin list into config.js, read from DATABASE_URL (failing fast if absent) and CORS_ORIGINS; server.js now uses config.databaseUrl and config.corsOrigins instead of a literal credential and origin: true. No package was added and every route keeps its method and path; the remaining low findings (no graceful shutdown, no Fastify schema on GET /tasks and PATCH /tasks/:id) were left alone since the note scoped this pass to high and medium problems. The rotated database password itself must still be changed out of band since it already appeared in the source."
}

The other two files are config.js, which now reads databaseUrl from a DATABASE_URL setting (failing at startup when it is missing) and builds corsOrigins by splitting a CORS_ORIGINS setting on commas, and routes/tasks.js, which checks request.query.sort against a SORTABLE_COLUMNS allow-list. The other three changes create the pool from config.databaseUrl (F3), register CORS with origin: config.corsOrigins (F4), and add the two settings to config.js (F3, F4). The verdict is fixed because every high and medium flag is closed and open is empty; the three low flags were left alone, as the note scoped the pass, and package.json needed no change, so it is not returned.

The page checks the reply against the code; the API does not

What comes back from the API is the model’s raw text in output.output. The page holds it to account in the browser before showing it (recon.js reconcile, with the facts, the code and the handoff it sent): it checks every quote against the paste, applies every edit or returned file to the paste and re-runs its own checks on the result. None of that happens in the API. A direct API caller gets the reply unchecked and must do the applying and re-checking itself.

recon.js also runs in Node, so you can hold a reply to exactly the page’s standard. Save /expresskit.js and /recon.js next to this script, pass the file you built the body from (build-check.js or handoff.js output), the reply text and the lane; it prints every statement, the count, and the paste with every edit (or file) put back:

// recheck.js -- run: node recheck.js orders-check.json orders-reply.txt audit > orders-edited.txt   (expresskit.js, recon.js next to it)
const fs = require("fs");
const Recon = require("./recon.js");                                            // loads ./expresskit.js itself
const sent = JSON.parse(fs.readFileSync(process.argv[2], "utf8"));             // code, facts (and audit_handoff) you sent
const lane = process.argv[4] || "audit";
const res = Recon.normalize(Recon.parseResult(fs.readFileSync(process.argv[3], "utf8")), lane);  // output.output
const r = Recon.reconcile(res, { facts: sent.facts, code: sent.code, handoff: sent.audit_handoff || null });
r.notes.forEach((n) => console.error(n.kind + ": " + n.text));
console.error(r.disagreements + " disagreement(s) in " + r.statements + " statements checked");
if (r.after) (r.after.flags || []).forEach((f) => console.error("still raised: " + f.id + " " + f.sev + " " + f.file + ":" + f.line + " " + f.text));
if (r.after && r.after.text) console.log(r.after.text.replace(/\n$/, ""));      // the paste with every edit (or file) put back

For the orders audit reply it reports:

ok: The areas table rates errors, input, security and operations once each.
warn: Finding 4 (EX-14) is medium and gives no edit; the page cannot check a fix for it - apply it by hand, or run the fix lane.
warn: Finding 5 (EX-09) is medium and gives no edit; the page cannot check a fix for it - apply it by hand, or run the fix lane.
ok: Every one of the 8 findings names a pasted file, a line inside it and evidence copied from it.
ok: The verdict (blocked) fits the worst finding.
ok: Every one of the page's 10 flags is answered once.
ok: All 8 edits applied in order, each before text found exactly once.
ok: Every confirmed flag a finding carries is gone once all edits are applied.
ok: Every export of the paste is still there after the edits.
ok: Every one of the 3 routes still answers at its method and path after the edits.
ok: The reply repeats no credential from the paste.
0 disagreement(s) in 11 statements checked
still raised: EX-09 medium server.js:20 CORS reflects any origin and allows credentials
still raised: EX-14 medium routes/orders.js:70 no authentication in front of POST /api/orders
still raised: EX-16 low server.js:18 no helmet() on app

The two warnings are the page doing its job: the audit left the CORS origin list and the authentication of POST /api/orders as decisions for the engineer, so the re-check still raises them (on their new lines, after the edits) and the handoff to the fix lane carries them into the next run.

and for the tasks fix reply (node recheck.js tasks-check.json tasks-reply.txt fix):

ok: 3 files returned whole.
ok: With the fixed files in place the free check raises no high or medium flag (3 low).
ok: Every one of the 3 exports is still there.
ok: Every one of the 3 routes still answers at its method and path.
ok: Every one of the 5 changes names a returned file, a function in the fixed code and real page flags.
ok: The verdict (fixed) fits the open list.
ok: The reply repeats no credential from the paste (1 found in it).
0 disagreement(s) in 7 statements checked
still raised: EX-16 low server.js:40 no graceful shutdown: SIGTERM is never handled
still raised: EX-17 low routes/tasks.js:61 GET /tasks reads request.query with no schema
still raised: EX-17 low routes/tasks.js:88 PATCH /tasks/:id reads request.body with no schema

The page does not install, build or run the code. After that, run the service’s test suite, start it and send the requests the reply’s plan or verify names (a bad request, an unauthenticated request, a request that makes the database throw), run npm audit, and rotate any credential that was ever in the source, before you ship anything.

Step 1 — a tiny client helper

One function per language that does what sdk.js does for every call: JSON in, bearer token if you have one, data out on a 2xx, an error carrying status, error.code and error.message otherwise. The later steps assume this helper is in the same file (for Go, Java and C#, the later snippets go inside main / the top-level statements; Java’s makeInput from step 4 goes in the class).

BASE="https://api.skillsafe.ai/v1/app-api"
TOKEN="YOUR_TOKEN"   # step 2: paste your token here

# api METHOD PATH [extra curl args...] -- prints the whole envelope; pipe to jq
api() {
  method="$1"; path="$2"; shift 2
  curl -sS -X "$method" "$BASE$path" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $TOKEN" "$@"
}
# success: jq '.data'      failure: jq '.error | {code, message}'

Step 2 — a token

Two kinds work:

# personal token (needed for a run): copy it from /tokens.html, then
#   put it in TOKEN (in place of YOUR_TOKEN) and skip the rest of this block
# guest token (enough for /me and /estimate): no Authorization header on this one call
TOKEN=$(curl -sS -X POST "$BASE/guest" \
  -H "Content-Type: application/json" \
  -d '{"slug":"routelarch"}' | jq -r '.data.token')
echo "guest token: ${TOKEN:0:12}..."

Step 3 — GET /me

Who the token belongs to and what it can spend. sdk.js documents the shape as {subject_type, subject_id, credits, profile?}. The page treats the caller as signed in only when subject_type is "user", shows credits as the balance (1 credit = $0.0001, so it divides by 10 000 for the dollar figure), and compares it with the estimate in step 4 before it lets you run.

api GET /me | jq '.data // .error'

Step 4 — build the input, then POST /estimate

First a small makeInput that does what buildInput does: task, then code as the paste the page would send, facts as a compact JSON string, the note when it is not blank, and — for the fix lane only — the audit_handoff string when the file carries one. It reads the file build-check.js (or handoff.js) printed. The samples build the audit input of the orders example from orders-check.json; step 6 reuses makeInput for the tasks (fix) example. Then price it. The body of /estimate is the same input you will send to /run; no job is created and nothing is charged — /estimate is free. From the response the page reads:

FieldMeaning
hold_creditsA reservation, not a price: the worst case the platform holds while the run is in flight. The page shows it as “reserves N credits ($...) for the audit run” and adds that you are charged only for what the run actually uses, usually far less. What you pay is the job’s charged_credits after settlement (step 5). A balance below the hold is allowed, but the page warns that the reply may be cut short (truncated: true).
min_creditsThe smallest balance that can start a run. Below it the page disables the run button and names the shortfall, because the call would be a 402.
sponsor_enabledWhen true, a caller who is not signed in may run; otherwise the page asks them to sign in.
warningsInput warnings. They do not refuse the call; the page shows them next to the price (“input warnings: ...”), so check them before you run.

The page re-prices whenever the paste, the note or the lane change. The amounts grow with the size of code and facts, so read them from the call rather than hard-coding them.

# orders-check.json: printed by build-check.js (see "The facts string").
# (.facts | tojson) turns the facts into ONE compact string, as JSON.stringify does.
BODY=$(jq -c --arg note "Since we moved the handlers to async/await the API sometimes hangs, and twice the whole process died. What else should we fix before the launch on Monday?" \
  '{task: "audit", code, facts: (.facts | tojson), note: $note}' orders-check.json)
# No page check at hand? facts: "{}" is accepted as a string, but the reply then has no page flags to answer.
# Fix lane after an audit: read handoff.js's output instead and add its string:
#   '{task: "fix", code, facts: (.facts | tojson), note: $note} + (if .audit_handoff then {audit_handoff} else {} end)'

api POST /estimate -d "$BODY" \
  | jq '.error // (.data | {hold_credits, min_credits, sponsor_enabled, warnings})'

Step 5 — POST /run, then poll the job (audit)

Send the same input to /run with an Idempotency-Key header, using a personal token. Its data carries a job_id. Poll GET /jobs/{job_id} the way sdk.js waitForJob does: every second until status is succeeded or failed, giving up on the client side after 180 seconds. On the finished job, read:

Idempotency key. Resending a request with the same key must not start a second paid run, so derive the key from the input, not from the clock — and include the lane, so an audit and a fix run of the same paste never share a key. The page uses routelarch:<lane>:<inputHash>:a<attempt> (app.js run), where <lane> is audit or fix, <inputHash> is a 32-bit djb2 hash of JSON.stringify(input) in hex, a dash, and the string’s length in hex (app.js inputHash, over the input without retry_note), and <attempt> is 1 for a normal run and 2 for the automatic reformat retry (which also adds retry_note). For the two worked examples that is routelarch:audit:e299aa89-260e:a1 (orders audit) and routelarch:fix:601c1dd2-1fbb:a1 (tasks fix); the fix run of the orders audit handed on (above) is routelarch:fix:5b65685f-2c1f:a1. The format is the page’s convention, not a requirement: any stable, unique string does. The samples below use the lane and a SHA-256 prefix.

The page itself uses /run-stream (step 6), not /run; both take the same body and header.

KEY="routelarch:audit:$(printf '%s' "$BODY" | shasum -a 256 | cut -c1-16):a1"

JOB=$(api POST /run -H "Idempotency-Key: $KEY" -d "$BODY" | jq -r '.data.job_id')

for i in $(seq 180); do                       # 1 s interval, 180 s client-side limit
  J=$(api GET "/jobs/$JOB")
  S=$(printf '%s' "$J" | jq -r '.data.status')
  if [ "$S" = "succeeded" ] || [ "$S" = "failed" ]; then break; fi
  sleep 1
done

printf '%s' "$J" | jq '.data | {status, truncated, charged_credits, error}'
printf '%s' "$J" | jq -r '.data.output.output' \
  | jq '{verdict, headline, areas: [(.areas // [])[] | {area, status}],
         findings: [(.findings // [])[] | {id, file, line, severity, edits: ((.edits // []) | length)}],
         flag_answers: [(.flag_answers // [])[] | {flag, status}]}'

Step 6 — POST /run-stream (Server-Sent Events, fix)

The alternative to step 5, and what the page uses: same kind of body, same Idempotency-Key header, one request. Run one or the other for a given input, not both. To show the second lane, the samples build the fix input of the tasks example (with its own key) and stream it; to stream the audit input instead, pass the step 4 input and key. The response is text/event-stream. sdk.js splits it into frames on a blank line, takes the event name from an event: line (default message) and concatenates the data: lines, skips frames with no data or with data that is not JSON, and handles these events:

EventDataWhat the SDK does
delta{text}Passes text to onDelta.
jobjob infoPasses it to onJob (the page uses it to advance its progress display).
donethe final payload: {job_id, status, charged_credits, output}Keeps it as the result.
pendinga payloadTreated exactly like done. If it carries a job_id and no output, poll that job as in step 5.
error{message, code, job_id}After the stream ends, raises an error with those fields.

If the response is not text/event-stream, it is an ordinary JSON envelope: the SDK returns its data (an idempotent replay returns this way) or raises the error on a non-2xx status. Handle both shapes.

From the final payload the page reads output.output (falling back to the concatenated delta text), truncated and charged_credits. Browsers receive progress ticks rather than deltas from this endpoint, so the page relies on the final payload; if the stream fails part-way, it tries to recover a partial reply from whatever delta text arrived. The samples print the verdict and headline, each returned file’s path and size, each change (function, flags and change), each verification step, each open item and each question. To put the files into the paste and re-check them the way the page’s “Put every file into the paste” does, keep the reply text and run recheck.js with the lane fix. To fix code you audited, read handoff.js’s output instead of tasks-check.json: makeInput then carries its audit_handoff.

# the fix worked example: tasks-check.json from build-check.js
# (for audited code, read handoff.js's output instead; the + (...) adds its audit_handoff)
FBODY=$(jq -c --arg note "Pen test found that any made-up token is accepted. Fix every high and medium problem the check found; keep every route URL, and do not add packages." \
  '{task: "fix", code, facts: (.facts | tojson), note: $note} + (if .audit_handoff then {audit_handoff} else {} end)' \
  tasks-check.json)
FKEY="routelarch:fix:$(printf '%s' "$FBODY" | shasum -a 256 | cut -c1-16):a1"

# -N turns off buffering; the whole stream lands in $STREAM
STREAM=$(api POST /run-stream -N -H "Idempotency-Key: $FKEY" -d "$FBODY")

# frames look like:
#   event: job
#   data: {...}
#
#   event: done
#   data: {"job_id":"...","status":"...","charged_credits":...,"output":{"output":"{\"task\":\"fix\",...}"}}

# the final reply text, from the done (or pending) frame:
REPLY=$(printf '%s\n' "$STREAM" \
  | awk '/^event:/{ev=$2} /^data:/ && (ev=="done" || ev=="pending"){sub(/^data: */,""); print}' \
  | jq -r '.output.output')
# an idempotent replay answers with a plain JSON envelope instead: REPLY=$(printf '%s' "$STREAM" | jq -r '.data.output.output')
printf '%s' "$REPLY" | jq '{verdict, headline,
  files: [(.files // [])[] | {path, characters: (.content | length)}],
  changes: [(.changes // [])[] | {function, flags, change}], verify, open, questions}'

What the page does that you now do

Or skip all of this and use Routelarch in the browser: the check, the flags, every route with its full path, middleware chain and handler, the use() registrations in order, putting an edit or the fixed files back into the paste, and the Markdown and CSV exports are free.