← Monorepo Cache Audit / API
Tokens

Drive Monorepo Cache Audit from your own code

The page reads one pasted Turborepo monorepo configuration in the browser for free — one or more files joined into one paste, each introduced by a # file: <path> line: the root turbo.json and package turbo.json files, the root and workspace package.json files, pnpm-workspace.yaml, the CI workflow that runs turbo and a committed .turbo/config.json — with its line numbers. It parses the JSON with comments allowed, keeping the line of every key, reads every task definition (dependsOn, outputs, inputs, env, cache, persistent), every package with its scripts and the framework it builds with, every turbo command in package scripts and CI lines with its tasks and flags, and every CI env entry. Then it runs 21 deterministic checks drawn from Turborepo practice (catalogue ids TR-01..TR-21, plus TR-22 for context): whether turbo accepts the configuration at all (the version, packageManager, Turborepo 1 syntax, package configurations, every task a command runs, credentials, the cache endpoint), whether tasks run in the right order (^build, persistent dependencies, dev servers, cacheable deploys), whether a cache hit restores what the next step needs (outputs, the framework’s build directory, caching switched off, --force), and whether the hash changes exactly when the result would (inputs, .env files, undeclared CI variables, loose env mode, per-commit or match-everything global inputs). Nothing is installed, hashed 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 configuration, the task graph, the outputs and the hash inputs, 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 task field: two lanes

task is the first field of every body. It 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 Turbokit.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 configuration the way a senior engineer reviews a Turborepo monorepo before trusting its cache: says what the monorepo builds, with which package manager and turbo version, and how its cache is shared (repo), rates the four areas (config, graph, outputs, hashing) 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 makes turbo refuse to run or leaks first (syntax, packageManager, package configurations, undefined tasks, credentials), then what makes a hit wrong, then what wastes the cache, then hygiene — with a plan that ends in turbo run build --dry=json and the CI command twice on a clean checkout.blocked | needs_work | readyBefore you turn on a shared remote cache or trust a green CI run: does turbo accept the configuration, is every hit correct, and what should change first.
"fix"Writes the fixed configuration: the whole of every pasted file it changes (never a new file), valid JSON, with every task key, package name and script kept — plus a changes list tied to the page flags (each naming the task key it is in, or (file)), the verify steps (--dry=json, the CI command twice, then the check that would have caught the worst problem), and what it left open for a fact or a decision only the engineer has (a packageManager version, a cache endpoint, which variables a task reads).fixed | partialWhen you want the files changed, not a list of findings: a configuration you already know is broken (a Turborepo 1 config after a turbo 2 bump), or what is left after an audit.

The model never invents a version, a packageManager value, an endpoint, a team or an environment variable name. When the note or the paste does not give one, the audit leaves the edit out and asks in questions, and the fix lane leaves the item open. It never copies a credential it finds in the paste.

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 Turborepo file was found. Paste turbo.json, the root package.json and the workspace package.json files, with a # file: <path> line above each.”, or “This does not read as a Turborepo configuration: no turbo.json, no package.json and no turbo command was found.”), and it warns before a run on a paste with no root turbo.json (“No root turbo.json was pasted: the task, output and hash checks need it.”) or no root package.json.

One worked example per lane follows, both examples the page ships (the example buttons on the app page; the full pastes are in /example.js, ids storefront and harbor), built exactly as the page builds them: Turbokit.buildInput(lane, Turbokit.analyze(text), note, null), with the saved model reply for each. The other two examples are audits that reach the other verdicts: larkline (needs_work, 3 flags (3 medium)) and fernpath (ready, no flag); the storefront audit also carries a saved fix run of its edited files (fixed). The request bodies cut the long code and facts strings with a visible ...; the replies are shown whole, pretty-printed, exactly as saved. The companies, hosts, tokens and packages are invented.

Worked example, task: "audit": a Next.js storefront whose deploy task is cacheable, whose build outputs miss .next, whose CI workflow holds the remote cache token and whose root script runs a task nothing defines

5 files: package.json, turbo.json, apps/web/package.json, packages/ui/package.json, .github/workflows/ci.yml. The page’s free check raises 9 flags (4 high, 4 medium, 1 low) (plus the TR-22 context flag); its own reading of the verdict is blocked. Running build-check.js on it (below) prints 5 file(s), 5 task(s), 3 package(s), 6 turbo command(s); 9 flags (4 high, 4 medium, 1 low); verdict_candidate blocked. The engineer’s note: “CI runs pnpm turbo run build test lint on every push and must keep writing the remote cache; deploys run from main through the root deploy script. The web build reads DATABASE_URL to pre-render product pages; the tests do not use it. test was set to cache: false after a flaky test once passed from cache; that test has since been fixed, so test can be cached again. GITHUB_SHA is only used to name the Sentry release in the build log. typecheck is tsc --noEmit in both packages. What do we fix first?”

The request body (POST /run or /run-stream), idempotency key monorepo-cache-audit:audit:b0361902-2997:a1:

{
  "task": "audit",
  "code": "# file: package.json\n{\n  \"name\": \"storefront\",\n  \"private\": true,\n  \"packageManager\": \"pnpm@9.12.0\",\n  \"scripts\": {\n    \"build\": \"turbo run build\",\n    \"dev\": \"turbo run dev\",\n    \"lint\": \"turbo run lint\",\n    \"typecheck\": \"turbo run typecheck\",\n    \"deploy\": ...",
  "facts": "{\"repo\":{\"turbo_version\":\"^2.3.3\",\"turbo_major\":2,\"package_manager\":\"pnpm@9.12.0\",\"root_turbo_json\":true,\"root_package_json\":true,\"files\":5,\"tasks\":5,\"packages\":3,\"turbo_commands\":6},\"files\":[{\"path\":\"package.json\",\"kind...",
  "note": "CI runs pnpm turbo run build test lint on every push and must keep writing the remote cache; deploys run from main through the root deploy script. The web build reads DATABASE_URL to pre-render product pages; the tests do not use it. test was set to cache: false after a flaky test once passed from cache; that test has since been fixed, so test can be cached again. GITHUB_SHA is only used to name the Sentry release in the build log. typecheck is tsc --noEmit in both packages. What do we fix first?"
}

The saved reply (output.output), verdict blocked, 9 findings, 8 edits:

{
  "task": "audit",
  "verdict": "blocked",
  "headline": "Turbo would refuse the typecheck script, restore an incomplete Next.js build from cache, replay a deploy that never ran, and leak a cache token, so this configuration is blocked until the four high findings are fixed.",
  "repo": "Storefront is a pnpm@9.12.0 / turbo ^2.3.3 monorepo building a Next.js storefront (apps/web) against a tsup component library (packages/ui), with lint and tsc typecheck in both, and a remote cache CI and laptops share through TURBO_TEAM/TURBO_TOKEN.",
  "areas": [
    {
      "area": "config",
      "status": "broken",
      "note": "An undefined typecheck task and a hardcoded TURBO_TOKEN mean turbo can refuse to run and the cache credential is exposed to every reader of the repo."
    },
    {
      "area": "graph",
      "status": "broken",
      "note": "deploy is cacheable so a hit can skip a real Vercel deploy, and dev is not marked persistent."
    },
    {
      "area": "outputs",
      "status": "broken",
      "note": "build's outputs miss .next/** for the Next.js app, and test was left uncached after the flaky failure that justified it was fixed."
    },
    {
      "area": "hashing",
      "status": "fragile",
      "note": "DATABASE_URL is undeclared and GITHUB_SHA sits in the hash, and .env files are not part of the build's hashed inputs."
    }
  ],
  "findings": [
    {
      "id": "TR-05",
      "flags": [
        "F1"
      ],
      "file": "turbo.json",
      "line": 27,
      "severity": "high",
      "area": "config",
      "title": "typecheck runs through turbo but turbo.json never defines it",
      "evidence": "    \"lint\": {},\n    \"test\": {",
      "why": "package.json's \"typecheck\" script runs `turbo run typecheck`, but turbo.json has no \"typecheck\" key in tasks: Turborepo 2 stops with a missing-task error on every machine (and any CI job) that runs `pnpm typecheck`. Both apps/web and packages/ui already have a typecheck script (`tsc --noEmit`); it just isn't registered.",
      "edits": [
        {
          "before": "    \"lint\": {},\n    \"test\": {",
          "after": "    \"lint\": {},\n    \"typecheck\": {\n      \"outputs\": []\n    },\n    \"test\": {"
        }
      ]
    },
    {
      "id": "TR-06",
      "flags": [
        "F4"
      ],
      "file": ".github/workflows/ci.yml",
      "line": 88,
      "severity": "high",
      "area": "config",
      "title": "TURBO_TOKEN is a literal credential in the workflow",
      "evidence": "TURBO_TEAM: storefront",
      "why": "The line right after this one hardcodes a real-looking TURBO_TOKEN value into a file every repository reader can see; anyone with read access can use it against the remote cache to download every cached artifact or upload poisoned ones that every machine then trusts as a hit. Rotate the token now and replace that line with `TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}` so CI reads it from the GitHub Actions secret store instead of the file.",
      "edits": []
    },
    {
      "id": "TR-14",
      "flags": [
        "F2"
      ],
      "file": "turbo.json",
      "line": 25,
      "severity": "high",
      "area": "outputs",
      "title": "build outputs miss .next/** for the Next.js app",
      "evidence": "      \"outputs\": [\"dist/**\"]",
      "why": "The shared build task's outputs list only dist/** (right for @storefront/ui's tsup build), so a cache hit on @storefront/web restores nothing: .next/** never lands on disk, and next start, the Vercel deploy, or a later dependent step then runs against a build directory that isn't there.",
      "edits": [
        {
          "before": "      \"outputs\": [\"dist/**\"]",
          "after": "      \"outputs\": [\"dist/**\", \".next/**\", \"!.next/cache/**\"]"
        }
      ]
    },
    {
      "id": "TR-11",
      "flags": [
        "F3"
      ],
      "file": "turbo.json",
      "line": 35,
      "severity": "high",
      "area": "graph",
      "title": "deploy is cacheable even though it ships to production",
      "evidence": "    \"deploy\": {\n      \"dependsOn\": [\"build\", \"test\"]\n    }",
      "why": "apps/web's deploy script runs `vercel deploy --prebuilt --prod`; without \"cache\": false, a replayed hit on unchanged inputs skips the command and just replays the old log, so `turbo run deploy --filter=@storefront/web` from main reports success without anything actually shipping.",
      "edits": [
        {
          "before": "    \"deploy\": {\n      \"dependsOn\": [\"build\", \"test\"]\n    }",
          "after": "    \"deploy\": {\n      \"dependsOn\": [\"build\", \"test\"],\n      \"cache\": false\n    }"
        }
      ]
    },
    {
      "id": "TR-19",
      "flags": [
        "F8"
      ],
      "file": "turbo.json",
      "line": 24,
      "severity": "medium",
      "area": "hashing",
      "title": "DATABASE_URL is not declared for the build that reads it",
      "evidence": "    \"build\": {\n      \"dependsOn\": [\"^build\"],\n      \"outputs\": [\"dist/**\"]",
      "why": "CI sets DATABASE_URL only on the build job, and the engineer confirms apps/web's build reads it to pre-render product pages, but no turbo.json task declares it, so Turborepo 2's strict env mode strips it from the task's environment and the pre-render fails or falls back silently. Declaring it in build's env also means a changed DATABASE_URL busts the cache, which is wanted since the pre-rendered output depends on it; tests don't use it, so it stays out of test's env.",
      "edits": [
        {
          "before": "      \"dependsOn\": [\"^build\"],",
          "after": "      \"dependsOn\": [\"^build\"],\n      \"env\": [\"DATABASE_URL\"],"
        }
      ]
    },
    {
      "id": "TR-16",
      "flags": [
        "F6"
      ],
      "file": "turbo.json",
      "line": 30,
      "severity": "medium",
      "area": "outputs",
      "title": "test is still forced uncached after the flaky test was fixed",
      "evidence": "    \"test\": {\n      \"dependsOn\": [\"build\"],\n      \"cache\": false",
      "why": "vitest run gives the same result for the same inputs, but \"cache\": false forces every machine to run the full suite on every commit; the engineer confirms the flaky test that justified this has since been fixed, so it should be cached again. The script is `vitest run` with no --coverage flag, so it writes no files: \"outputs\": [] is correct.",
      "edits": [
        {
          "before": "    \"test\": {\n      \"dependsOn\": [\"build\"],\n      \"cache\": false\n    },",
          "after": "    \"test\": {\n      \"dependsOn\": [\"build\"],\n      \"outputs\": []\n    },"
        }
      ]
    },
    {
      "id": "TR-21",
      "flags": [
        "F5"
      ],
      "file": "turbo.json",
      "line": 21,
      "severity": "medium",
      "area": "hashing",
      "title": "GITHUB_SHA in globalEnv changes every hash",
      "evidence": "  \"globalEnv\": [\"GITHUB_SHA\"],",
      "why": "GITHUB_SHA is new on every commit, and globalEnv hashes it into every task for every package, so no task in the monorepo can ever hit the cache twice. The engineer confirms it is only used to name the Sentry release in the build log, not to change what is built, so it belongs in globalPassThroughEnv: available to every task, but not hashed.",
      "edits": [
        {
          "before": "  \"globalEnv\": [\"GITHUB_SHA\"],",
          "after": "  \"globalPassThroughEnv\": [\"GITHUB_SHA\"],"
        }
      ]
    },
    {
      "id": "TR-10",
      "flags": [
        "F7"
      ],
      "file": "turbo.json",
      "line": 32,
      "severity": "medium",
      "area": "graph",
      "title": "dev is not marked persistent",
      "evidence": "    \"dev\": {\n      \"cache\": false\n    },",
      "why": "Both apps/web (`next dev --port 3000`) and packages/ui (`tsup ... --watch`) run their dev task forever; without \"persistent\": true, turbo treats it as a task that should finish, so a dependent task can hang waiting on it and nothing stops one being added.",
      "edits": [
        {
          "before": "    \"dev\": {\n      \"cache\": false\n    },",
          "after": "    \"dev\": {\n      \"cache\": false,\n      \"persistent\": true\n    },"
        }
      ]
    },
    {
      "id": "TR-18",
      "flags": [
        "F9"
      ],
      "file": "turbo.json",
      "line": 23,
      "severity": "low",
      "area": "hashing",
      "title": ".env files are not hashed for the Next.js build",
      "evidence": "    \"build\": {\n      \"dependsOn\": [\"^build\"],\n      \"outputs\": [\"dist/**\"]",
      "why": "Next.js reads .env files at build time, but Turborepo hashes only git-tracked files by default and .env files are usually git-ignored, so editing one keeps the old hash and the cache serves a build made with the old values. Adding \".env*\" after \"$TURBO_DEFAULT$\" in build's inputs keeps the default file set and adds .env files to it.",
      "edits": [
        {
          "before": "      \"outputs\": [\"dist/**\", \".next/**\", \"!.next/cache/**\"]",
          "after": "      \"outputs\": [\"dist/**\", \".next/**\", \"!.next/cache/**\"],\n      \"inputs\": [\"$TURBO_DEFAULT$\", \".env*\"]"
        }
      ]
    }
  ],
  "flag_answers": [
    {
      "flag": "F1",
      "status": "confirmed",
      "reason": "typecheck has no task key in turbo.json; adding one closes it."
    },
    {
      "flag": "F2",
      "status": "confirmed",
      "reason": "build's outputs list only dist/**, missing .next/** for @storefront/web."
    },
    {
      "flag": "F3",
      "status": "confirmed",
      "reason": "deploy runs `vercel deploy --prebuilt --prod` and had no cache:false."
    },
    {
      "flag": "F4",
      "status": "confirmed",
      "reason": "a literal TURBO_TOKEN value sits in ci.yml; must be rotated and read from secrets."
    },
    {
      "flag": "F5",
      "status": "confirmed",
      "reason": "GITHUB_SHA sits in globalEnv and is new on every commit/run."
    },
    {
      "flag": "F6",
      "status": "confirmed",
      "reason": "test still has cache:false though the flaky test behind it is fixed."
    },
    {
      "flag": "F7",
      "status": "confirmed",
      "reason": "dev runs next dev / tsup --watch forever but lacked persistent:true."
    },
    {
      "flag": "F8",
      "status": "confirmed",
      "reason": "DATABASE_URL is set in CI for the build job but no task declares it."
    },
    {
      "flag": "F9",
      "status": "confirmed",
      "reason": ".env files are outside the build task's hashed inputs."
    }
  ],
  "plan": [
    "Add a \"typecheck\" task to turbo.json (outputs: []) so `turbo run typecheck` stops hitting a missing-task error.",
    "Rotate the TURBO_TOKEN value now, and rewrite ci.yml to read it from `${{ secrets.TURBO_TOKEN }}`.",
    "Add \".next/**\" (and \"!.next/cache/**\") to build's outputs so a cache hit restores the Next.js app.",
    "Set \"cache\": false on deploy so a hit never replays a deploy that didn't run.",
    "Declare DATABASE_URL in build's env so the strict-mode CI build keeps seeing it and the hash reflects it.",
    "Drop test's \"cache\": false now that the flaky test is fixed, and give it outputs: [].",
    "Move GITHUB_SHA from globalEnv to globalPassThroughEnv so it stops busting every task's hash.",
    "Mark dev \"persistent\": true.",
    "Add \".env*\" to build's inputs (after $TURBO_DEFAULT$) so an edited .env file busts the cache.",
    "Verify: `turbo run build --dry=json` to check each task's hash inputs, then run the CI command twice on a clean checkout with the remote cache on - the second run should report every task cached, and the deploy step should still fire on a commit with no source change."
  ],
  "questions": [
    "Should typecheck depend on \"^build\" so apps/web is checked against packages/ui's built dist/index.d.ts rather than just its source?",
    "Is the shared remote cache (TURBO_TEAM/TURBO_TOKEN) reached over https, and will remoteCache.signature be turned on once the token is rotated?"
  ],
  "summary": "Fix the four high findings first, in this order: register typecheck in turbo.json, rotate the leaked TURBO_TOKEN into the CI secret store, add .next/** to build's outputs, and set deploy's cache to false - each one leaves turbo unable to run, a hit missing files, or a deploy that silently never fires. Then declare DATABASE_URL for build, re-enable caching on test now that its flaky failure is fixed, move GITHUB_SHA into globalPassThroughEnv, and mark dev persistent. None of this changes what CI runs (`pnpm turbo run build test lint`, then the root `deploy` script from main) or removes any task, package or script."
}

The credential finding carries no edit: it cannot be fixed without quoting the value, so the fix lane rewrites the line to read the CI secret. The page applies the other edits in order and re-checks: 8 edit(s) applied, 0 did not; with every edit in place the free check raises 1 high, 0 medium and 0 low flag(s).

Worked example, task: "fix": a design-system monorepo that bumped turbo to 2.1 but still has Turborepo 1 pipeline syntax, $NODE_ENV in dependsOn, outputMode, a package turbo.json without extends, no packageManager and a plaintext cache endpoint

5 files: package.json, turbo.json, packages/icons/turbo.json, packages/icons/package.json, packages/core/package.json. The free check raises 7 flags (6 high, 1 medium); build-check.js prints 5 file(s), 4 task(s), 3 package(s), 4 turbo command(s); 7 flags (6 high, 1 medium, 0 low); verdict_candidate blocked. The engineer’s note: “We bumped turbo to 2.1 and nothing runs any more. Fix what you can. We install with npm 10.9.0. NODE_ENV is only read by the builds. We do not know yet whether the self-hosted cache server can serve https - leave the endpoint for us.”

The request body, idempotency key monorepo-cache-audit:fix:7ca0d76b-1dd8:a1:

{
  "task": "fix",
  "code": "# file: package.json\n{\n  \"name\": \"harbor-kit\",\n  \"private\": true,\n  \"workspaces\": [\"packages/*\"],\n  \"scripts\": {\n    \"build\": \"turbo run build\",\n    \"dev\": \"turbo run dev\",\n    \"test\": \"turbo run test\",\n    \"release\": \"turbo run build --filter=./packages/* && ...",
  "facts": "{\"repo\":{\"turbo_version\":\"^2.1.0\",\"turbo_major\":2,\"package_manager\":null,\"root_turbo_json\":true,\"root_package_json\":true,\"files\":5,\"tasks\":4,\"packages\":3,\"turbo_commands\":4},\"files\":[{\"path\":\"package.json\",\"kind\":\"packag...",
  "note": "We bumped turbo to 2.1 and nothing runs any more. Fix what you can. We install with npm 10.9.0. NODE_ENV is only read by the builds. We do not know yet whether the self-hosted cache server can serve https - leave the endpoint for us."
}

The saved reply, verdict partial, 3 file(s), 6 change(s), 1 open item(s):

{
  "task": "fix",
  "verdict": "partial",
  "headline": "Fixed the six syntax and config errors blocking turbo 2 from running at all; the plaintext remote-cache endpoint is left open pending an https decision.",
  "files": [
    {
      "path": "package.json",
      "content": "{\n  \"name\": \"harbor-kit\",\n  \"private\": true,\n  \"packageManager\": \"npm@10.9.0\",\n  \"workspaces\": [\"packages/*\"],\n  \"scripts\": {\n    \"build\": \"turbo run build\",\n    \"dev\": \"turbo run dev\",\n    \"test\": \"turbo run test\",\n    \"release\": \"turbo run build --filter=./packages/* && changeset publish\"\n  },\n  \"devDependencies\": {\n    \"@changesets/cli\": \"^2.27.9\",\n    \"turbo\": \"^2.1.0\"\n  }\n}\n"
    },
    {
      "path": "turbo.json",
      "content": "{\n  \"$schema\": \"https://turbo.build/schema.json\",\n  \"globalDependencies\": [\".env\"],\n  \"tasks\": {\n    \"build\": {\n      \"dependsOn\": [\"^build\"],\n      \"outputs\": [\"dist/**\"],\n      \"outputLogs\": \"new-only\",\n      \"env\": [\"NODE_ENV\"]\n    },\n    \"test\": {\n      \"dependsOn\": [\"build\"],\n      \"outputs\": []\n    },\n    \"dev\": {\n      \"cache\": false,\n      \"persistent\": true\n    }\n  },\n  \"remoteCache\": {\n    \"apiUrl\": \"http://cache.harbor.internal:3000\"\n  }\n}\n"
    },
    {
      "path": "packages/icons/turbo.json",
      "content": "{\n  \"extends\": [\"//\"],\n  \"tasks\": {\n    \"build\": {\n      \"outputs\": [\"dist/**\", \"sprites/**\"]\n    }\n  }\n}\n"
    }
  ],
  "changes": [
    {
      "file": "package.json",
      "task": "(file)",
      "flags": [
        "F1"
      ],
      "change": "Added a packageManager field set to npm@10.9.0 to the root package.json.",
      "why": "Turborepo 2 refuses to run without packageManager to resolve the workspaces and lockfile."
    },
    {
      "file": "turbo.json",
      "task": "(file)",
      "flags": [
        "F2"
      ],
      "change": "Renamed the root turbo.json's top-level pipeline key to tasks.",
      "why": "Turborepo 2 rejects turbo.json until the Turborepo 1 pipeline key is renamed to tasks."
    },
    {
      "file": "turbo.json",
      "task": "build",
      "flags": [
        "F3"
      ],
      "change": "Removed $NODE_ENV from build's dependsOn and added an env list containing NODE_ENV to the build task.",
      "why": "Environment variables in dependsOn were removed in Turborepo 2; env hashes NODE_ENV correctly for the builds that read it, per your note."
    },
    {
      "file": "turbo.json",
      "task": "build",
      "flags": [
        "F4"
      ],
      "change": "Renamed build's outputMode key to outputLogs, keeping the value new-only.",
      "why": "outputMode was renamed to outputLogs in Turborepo 2; the old key is rejected."
    },
    {
      "file": "packages/icons/turbo.json",
      "task": "(file)",
      "flags": [
        "F5"
      ],
      "change": "Added an extends field pointing at the root (//) to packages/icons/turbo.json.",
      "why": "A package turbo.json without extends is rejected; extends makes it an override of the root's tasks instead of a competing global config."
    },
    {
      "file": "packages/icons/turbo.json",
      "task": "(file)",
      "flags": [
        "F6"
      ],
      "change": "Renamed pipeline to tasks in packages/icons/turbo.json.",
      "why": "Same Turborepo 2 rename as the root config; the old key is rejected."
    }
  ],
  "verify": [
    "Run turbo run build --dry=json and confirm turbo now accepts turbo.json (no pipeline/outputMode/$NODE_ENV/missing-packageManager errors) and that build's hash inputs list NODE_ENV under env.",
    "Run npm run build twice on a clean checkout with the remote cache reachable; the second run's summary should show build and test as cache hits for both packages.",
    "Change NODE_ENV between the two runs (e.g. development vs production) and confirm build's hash changes and it is no longer a cache hit, proving NODE_ENV is now tracked."
  ],
  "open": [
    {
      "item": "turbo.json's remoteCache.apiUrl is still http://cache.harbor.internal:3000 (plaintext).",
      "flags": [
        "F7"
      ],
      "reason": "You said you don't yet know whether the self-hosted cache server can serve https, so the endpoint (and whether to add remoteCache.signature) needs that answer before it can change."
    }
  ],
  "questions": [],
  "summary": "Turborepo 2 was rejecting the whole configuration: pipeline was renamed to tasks and outputMode to outputLogs in both turbo.json files, packages/icons/turbo.json now extends the root, the root package.json has packageManager set to npm@10.9.0, and NODE_ENV moved out of build's dependsOn into its env list since only the builds read it. The self-hosted remote cache still points at http://cache.harbor.internal:3000 over plain http, left as-is since you weren't yet sure whether the server can serve https; see the open item."
}

The fixes use only what the note gives (the package manager and its version, which builds read NODE_ENV); the cache endpoint the note asks to leave stays open, so the verdict is partial.

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 input fields

Every field is a string. The app declares this input schema; task, code and facts are required.

FieldTypeWhat it is
taskstring, required"audit" or "fix" (above).
codestring, requiredThe paste, verbatim: every file introduced by a # file: <path> line. Line 1 is its first line; every line number in facts and in the reply is a line of this string.
factsstring, requiredThe page’s analysis as a JSON string (below).
audit_handoffstring, optionalFix lane only: an audit handed on, as a JSON string (below).
notestring, optionalWhat the engineer says, cut to 2,000 characters: a goal, a constraint, facts the files cannot show (which variables a build reads, the package manager version CI installs). Context, never instructions, and never evidence about the files.
retry_notestring, optionalSent only on the page’s one automatic retry, when the first reply did not parse.

The code string

Paste the files one after another, each preceded by # file: <path> with the path from the repository root (# file: turbo.json, # file: apps/web/package.json, # file: .github/workflows/ci.yml). A marker’s path must look like a path (a dot or a slash); a line --- directly before a marker only separates files. A paste with no marker is one file, named by what it looks like. A file’s directory is its package, so apps/web/turbo.json configures the package of apps/web/package.json. The page reads up to 400,000 characters and 60 files, and sends at most 60,000 characters: over that it drops whole files from the end (files it does not check first, then .gitignore, pnpm-workspace.yaml and workspace package.json files — never the root ones) and ends code with a line # [monorepo-cache-audit: not sent: ...] naming them, and says so in facts.notes. The model is told never to quote what it was not sent.

The facts string

facts is produced by the page’s free check: Turbokit.analyze splits the paste into files, parses the JSON, reads the CI lines and runs the rules, and Turbokit.facts(A) turns that analysis into the object below (it does not depend on the lane). It is how the model knows which flags to answer, which paths and line ranges to name, and which tasks, packages and scripts must survive. Its top-level keys, in the order built:

KeyContents
repoturbo_version (the turbo dependency of the root package.json, or null), turbo_major, package_manager (the root packageManager, or null), root_turbo_json and root_package_json (whether each was pasted), and counts: files, tasks, packages, turbo_commands.
filesEvery file: path (use it verbatim), kind (turbo, package, workspace, ci, turbo_local, ignore, other), line and end_line (the paste lines of the file’s content, without its # file: line).
globalThe root turbo.json’s global_dependencies, global_env, global_pass_through_env, env_mode and tasks_key (tasks, or pipeline for Turborepo 1 syntax); null without a root turbo.json.
tasksEvery task definition (up to 200): key (build, @scope/web#build, //#format), file, line, and what it sets: depends_on, outputs, inputs, env, pass_through_env, cache, persistent.
packagesEvery package.json (up to 150): name, path, line, root, framework (next, nuxt, astro, sveltekit, vite, tsup ... or null), scripts (names), internal_deps (the pasted workspace packages it depends on).
commandsEvery turbo invocation (up to 120): file, line, source (script or ci), tasks, flags (a credential value shows as ***).
ci_envEvery CI env entry (up to 150): file, line, name, value (a secret reference as written; a credential or a secret-named value as ***).
unreadableFiles that did not parse: path, line, error.
flagsEvery flag the page raised: uid (F1, F2, ... in severity, file, then line order), id (TR-01..TR-22), sev (high | medium | low | info), file, line, text, detail, and lines (every line an aggregated flag covers, when there are several).
verdict_candidateThe audit verdict the flags point at: 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 catalogue:

IdFlagArea
TR-01turbo not pinned in the root package.jsonconfig
TR-02root package.json has no packageManager fieldconfig
TR-03Turborepo 1 syntax in turbo.jsonconfig
TR-04package turbo.json that does not extend the root, or sets root-only keysconfig
TR-05turbo runs a task that turbo.json does not defineconfig
TR-06credential literal in the configurationconfig
TR-07remote cache over a plaintext connectionconfig
TR-08build does not wait for the packages it depends ongraph
TR-09a task depends on a persistent taskgraph
TR-10long-running task not marked persistent, or cachedgraph
TR-11task with side effects is cacheablegraph
TR-12dependsOn names a task that turbo.json does not definegraph
TR-13build task with no outputsoutputs
TR-14outputs miss the framework's build directoryoutputs
TR-15outputs cache what they should notoutputs
TR-16caching switched off for a repeatable taskoutputs
TR-17inputs replace the default file sethashing
TR-18.env files the framework reads are not hashedhashing
TR-19environment variables CI sets are not declaredhashing
TR-20loose environment modehashing
TR-21global hash inputs that change on every commit or match everythinghashing
TR-22contextcontext

The simplest source is turbokit.js itself: the page loads it from /turbokit.js, and it also runs in Node (it sets module.exports). This script prints 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 storefront-paste.txt and redirect the output into storefront-check.json: 

// build-check.js -- run: node build-check.js storefront-paste.txt > storefront-check.json   (turbokit.js saved next to it)
const fs = require("fs");
const Turbokit = require("./turbokit.js");
const A = Turbokit.analyze(fs.readFileSync(process.argv[2], "utf8"));
if (!A.ok) { console.error(A.errors.join("\n")); process.exit(1); }
const inp = Turbokit.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");
console.error(A.files.length + " file(s), " + A.tasks.length + " task(s), " + A.packages.length + " package(s), " +
  A.commands.length + " turbo command(s); " + real.length + " flags (" + A.counts.high + " high, " +
  A.counts.medium + " medium, " + A.counts.low + " low); verdict_candidate " + A.candidate);

For the storefront example it reports 5 file(s), 5 task(s), 3 package(s), 6 turbo command(s); 9 flags (4 high, 4 medium, 1 low); verdict_candidate blocked; for the harbor example, 5 file(s), 4 task(s), 3 package(s), 4 turbo command(s); 7 flags (6 high, 1 medium, 0 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 "{}" works 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 and line ranges to name, with no turbo_version the model has to hedge every version-dependent edit (Turborepo 1 syntax, packageManager), and with no tasks and packages nothing says what must survive a fix. Build it with turbokit.js when you can.

The audit_handoff string

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

const run = Recon.applyFindings(A, res.findings, Turbokit);   // 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

Each finding’s edits there is the number of edits it carried. applyFindings applies every finding’s edits with Turbokit.applyEdits, in the order listed, to the finding’s file: each before must occur exactly once in that file as the earlier edits left it (blank lines at either end are tolerated, and a blank line written inside after is kept), or that edit is reported as failed and skipped — it is never guessed. This script does the whole step, in the same shape as build-check.js prints: 

// handoff.js -- run: node handoff.js storefront-paste.txt storefront-reply.txt > storefront-fix-check.json   (turbokit.js, recon.js next to it)
const fs = require("fs");
const Turbokit = require("./turbokit.js");
const Recon = require("./recon.js");
const A = Turbokit.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 = Turbokit.analyze(ho.text);                                            // facts recomputed from the edited paste
const inp = Turbokit.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");

For the storefront audit above it reports 8 edit(s) applied, 0 did not apply; the edited paste raises 1 high, 0 medium and 0 low flag(s), and the page sends that fix run with the audit’s note and the key monorepo-cache-audit:fix:9f1c5d2b-30af:a1. Its saved reply is fixed (1 file(s), 1 change(s), 0 open item(s)).

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 grounds everything in code: unpasted package.json, tsconfig and .env files, other CI jobs, the remote cache server and the machines are outside the paste, so they are asked about, never stated as facts. It never invents a version, a packageManager value, a URL, a host, a port, a team, an environment variable name or a task a package does not have; it never writes a secret value (a line that holds a credential is never copied into the reply — the value moves to the CI secret store, or to turbo login on a laptop); it keeps every JSON file valid; and it keeps the monorepo’s meaning: which task keys, packages and scripts exist and what the scripts run. Version-dependent advice follows facts.repo.turbo_version. Every page flag whose sev is not info is answered exactly once (audit lane: in flag_answers), and an info flag is never 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 TR7 become TR-07; flags keeps only F<n> values; repo may also arrive as workspace or monorepo, file as path, a change’s task as target and its change as what; questions is capped at 10, plan at 30 and verify at 20. An audit reply carries 9 sections (verdict, headline, repo, 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.

The page checks the reply against the files; 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 applies every edit or returned file to the paste, re-parses it and re-runs its own checks on the result. None of that happens in the API.

recon.js also runs in Node, so you can hold a reply to exactly the page’s standard. Save /turbokit.js and /recon.js next to this script: 

// recheck.js -- run: node recheck.js storefront-check.json storefront-reply.txt audit > storefront-edited.txt   (turbokit.js, recon.js next to it)
const fs = require("fs");
const Recon = require("./recon.js");                                            // loads ./turbokit.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 storefront audit reply it reports:

ok: The areas table rates the configuration, the task graph, the outputs and the hash inputs once each.
ok: Every one of the 9 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 9 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 task, package and script of the paste is still there after the edits (5 tasks, 3 packages, 15 scripts).
ok: The reply repeats no credential from the paste (1 found in it).
0 disagreement(s) in 8 statements checked
still raised: TR-06 high .github/workflows/ci.yml:96 a credential is written into .github/workflows/ci.yml (TURBO_TOKEN)

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

ok: 3 pasted files returned whole.
ok: Every returned JSON file parses.
ok: With the fixed files in place the free check raises no high or medium flag beyond the ones left open (0 low).
info: F7 left open by the reply.
ok: Every task, package and script is still there (4 tasks, 3 packages, 10 scripts).
ok: Every one of the 6 changes names a returned file, a task in the fixed turbo.json files (or the file itself) and real page flags.
ok: The verdict (partial) fits the open list.
ok: The reply repeats no credential from the paste.
0 disagreement(s) in 7 statements checked
still raised: TR-07 medium turbo.json:39 the remote cache is reached over http (http://cache.harbor.internal:3000)

The page does not run turbo. After that, run turbo run build --dry=json, then the CI command twice on a clean checkout and read the second run’s cache status (--summarize), plus whatever the reply’s plan or verify names.

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="${SKILLSAFE_TOKEN:-YOUR_TOKEN}"   # step 2

# 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
#   export SKILLSAFE_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":"monorepo-cache-audit"}' | 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 storefront example from storefront-check.json; step 6 reuses makeInput for the harbor (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. 

# storefront-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 "CI runs pnpm turbo run build test lint on every push and must keep writing the remote cache; deploys run from main through the root deploy script. The web build reads DATABASE_URL to pre-render product pages; the tests do not use it. test was set to cache: false after a flaky test once passed from cache; that test has since been fixed, so test can be cached again. GITHUB_SHA is only used to name the Sentry release in the build log. typecheck is tsc --noEmit in both packages. What do we fix first?" \
  '{task: "audit", code, facts: (.facts | tojson), note: $note}' storefront-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 monorepo-cache-audit:<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 monorepo-cache-audit:audit:b0361902-2997:a1 (storefront audit) and monorepo-cache-audit:fix:7ca0d76b-1dd8:a1 (harbor fix); the fix run of the storefront audit handed on (below) is monorepo-cache-audit:fix:9f1c5d2b-30af: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="monorepo-cache-audit: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 harbor 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 (task, 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 harbor-check.json: makeInput then carries its audit_handoff. 

# the fix worked example: harbor-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 "We bumped turbo to 2.1 and nothing runs any more. Fix what you can. We install with npm 10.9.0. NODE_ENV is only read by the builds. We do not know yet whether the self-hosted cache server can serve https - leave the endpoint for us." \
  '{task: "fix", code, facts: (.facts | tojson), note: $note} + (if .audit_handoff then {audit_handoff} else {} end)' \
  harbor-check.json)
FKEY="monorepo-cache-audit: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 // [])[] | {task, flags, change}], verify, open, questions}'

What the page does that you now do

Or skip all of this and use Monorepo Cache Audit in the browser: the check, the flags, the task, package and command inventories, putting an edit or the fixed files back into the paste, the changes as a unified .patch for git apply, and the Markdown, CSV and JSON exports are free.