← GitOps Repo Audit / API
Tokens

Drive GitOps Repo Audit from your own code

The page reads the manifests of a Flux CD GitOps repository in the browser for free — several files joined into one paste, each introduced by a # file: <path> comment — with their line numbers, names every document Kind/name, and runs 31 deterministic checks drawn from the Flux maintainers’ repo audit (catalogue ids FX-01..FX-32; FX-32 is context only): Flux APIs that Flux 2.7 and 2.8 removed, fields the CRDs require, sourceRef kinds an applier cannot use, dependsOn cycles, plaintext Secrets and credentials in Git, insecure sources, cluster-admin for tenants, cross-namespace sources, prune: false, missing wait, unpinned charts, image automation that pushes to the branch it reconciles, and more. Its two paid steps are available over HTTP. You send one JSON object with task set to "audit" or "fix", the paste as manifests and the page’s check as a facts string, and the model replies with one JSON object: an audit with the corrected document per finding, an answer for every flag and what each applier reconciles, or the corrected documents themselves, with what changed, what was kept and the commands to run outside Git.

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.

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 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. 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 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 repository the way the Flux maintainers’ repo audit does: classifies it (repo pattern, how Flux is installed, clusters, tenancy), confirms or dismisses each page flag, adds what text rules cannot see, gives the verbatim evidence and the whole corrected document for each finding, says what each Kustomization, HelmRelease and ResourceSet reconciles, gives the flux migrate steps when removed APIs are in the paste, and orders the fixes into a plan.unsafe | needs_work | readyBefore merging: will Flux reconcile this, is it safe, and what should change first.
"fix"Returns the corrected documents for what the page (and, with a handoff, the audit) found — each the whole document, replacing the pasted one it names, or a new one; lists each change with the flags it fixes, the flags it keeps with a reason, the documents it removes, and the commands to run outside Git (flux migrate, rotating a credential, sops --encrypt).ready | partialWhen you want documents to commit rather than a list of findings.

The page chains the two: after an audit, “Fix the manifests from this audit” switches to the fix lane on the same paste and adds an audit_handoff string (below) with the audit’s verdict, headline, findings and dismissed flags. Over the API that is a second run with task: "fix", the same manifests and facts, and that string. The page drops the handoff as soon as the paste is edited.

Two guards the page applies before a fix and the API does not: it refuses to run the fix lane when the paste was too large to send whole (“the fix cannot correct documents it was not sent”), and it warns when the free check raises nothing but info flags (there is nothing for the fix lane to change; the audit can still look for what rules cannot see).

Input fields

This is exactly what the page sends (fluxkit.js buildInput, passed through mustBeObject; app.js run), and what input-schema.json declares. The platform’s input schema is scalar-only, so every value is a string, in this order:

FieldTypeRequiredMeaning
taskstringyes"audit" or "fix" (the lanes above).
manifestsstringyesThe pasted Flux manifests, verbatim; line 1 is its first line. Every line in the reply is counted in this text. A large paste is cut on whole documents (below).
factsstringyesThe page’s free check, Fluxkit.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.
notestringnoWhat the engineer says: the goal, a constraint (“we are still on Flux 2.6”), 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 manifests and answers it in summary.
audit_handoffstringnofix lane only: a JSON string built from an audit reply on the same paste (app.js auditHandoff, 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 turns the input into a flat object of strings and drops empty values, which is why facts and audit_handoff travel as strings and why an empty note is simply absent.

The manifests string

manifests is the paste itself. Documents are separated by --- lines; a # file: <path> comment above a document names the file it came from (dropped files are joined that way). The page normalises line endings to \n and also reads a JSON paste. Send the text you want the reply to quote: every resource in an audit reply must be a ref from facts.source.resources, every line must fall inside that document, and every evidence must be copied from it. The page reads up to 400 000 characters and 400 documents, and sends at most 60 000 characters: past that it keeps whole documents from the start (the cluster entry points usually come first) and from the end (apps usually come last), and replaces the middle with one comment, 

# [gitops-repo-audit: lines X-Y (N documents) not sent]

(the model is told never to quote or rewrite what was not sent), with a sentence in facts.notes. facts is still computed from the whole paste. Both worked examples below are small, so their manifests 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: Fluxkit.analyze parses the paste and runs the rules, and Fluxkit.facts(A) turns that analysis into the object below (it does not depend on the lane: an audit and a fix of the same paste carry the same facts). It is how the model knows which flags to answer, which resource refs to name, and which appliers to describe. Its top-level keys, in the order built:

KeyContents
sourcelines, format (yaml | json), files[] (the # file: paths), namespaces[], resources[] (every document: ref — Kind/name, or Kind/namespace/name when a name is reused, or kustomization.yaml (<file>) for a Kustomize build file — kind, api_version, name, namespace ((not set) when the document has none), file, line, end_line, flux (true for Flux CRDs), and generated: true on gotk-components and CRDs) and up to ten parse_errors.
install, layoutHow Flux is installed (Flux Operator (FluxInstance ...), flux bootstrap (gotk-sync) or not in the paste) and the top-level directories the file names show.
tenancymulti_tenant, fluxinstance_multitenant (the FluxInstance cluster.multitenant value, or null), tenant_namespaces[], appliers_with_service_account[].
sourcesEvery source: ref, kind, namespace, url, type, revision, interval, provider, secret_ref, verify, insecure.
appliersEvery Kustomization, HelmRelease and ResourceSet: ref, kind, namespace, source, what (the path or the chart and version), interval, prune, wait, depends_on, target_namespace, service_account, timeout, retry_interval.
secretsEvery Secret document: ref and encrypted (SOPS).
flagsEvery flag the page raised: uid (F1, F2, ...), id (FX-01..FX-32), sev (high | medium | low | info), resource (a ref), resources (only on a flag that aggregates several resources: every ref it covers), line, text and detail. The reply must answer every non-info flag by its uid.
verdict_candidateThe audit verdict the flags point at (the page’s own reading).
notesPlain sentences about what was not read or not sent.

The simplest source is fluxkit.js itself: the page loads it from /fluxkit.js, and it also runs in Node (it sets module.exports). This script writes the two files the samples read, <stem>-manifests.yaml and <stem>-facts.json; for both worked examples it reproduces the page’s manifests and facts exactly (the samples compact the facts file back into the page’s string byte for byte): 

// build-facts.js -- run: node build-facts.js paste.yaml platform   (fluxkit.js saved next to it)
const fs = require("fs");
const Fluxkit = require("./fluxkit.js");
const [paste, stem] = process.argv.slice(2);
const A = Fluxkit.analyze(fs.readFileSync(paste, "utf8"));
if (!A.ok) { console.error(A.errors.join("\n")); process.exit(1); }
fs.writeFileSync(stem + "-manifests.yaml", Fluxkit.sentConfig(A).text);             // what the page sends as manifests
fs.writeFileSync(stem + "-facts.json", JSON.stringify(Fluxkit.facts(A), null, 2));  // what it sends, compacted, as facts
console.log(A.flags.length + " flags; verdict_candidate " + A.candidate);

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 manifests directly."]} — and the model still reads manifests. But you lose what the check adds: with no flags there is nothing to confirm, dismiss, fix or keep, with no source.resources there are no refs to name documents by, and with no appliers the audit has no list of appliers to describe. Build it with fluxkit.js as above when you can.

The audit_handoff string

Only for task: "fix", and only for the paste the audit was about. The page builds it from the normalised audit reply r (recon.js normalize, below): 

JSON.stringify({ from: "audit", verdict: r.verdict, headline: r.headline,
  findings: r.findings.map(f => ({ id: f.id, resource: f.resource, severity: f.severity, title: f.title, flags: f.flags })),
  dismissed: r.flag_answers.filter(a => a.status === "dismissed").map(a => ({ flag: a.flag, reason: a.reason })) })

That is {"from": "audit", "verdict", "headline", "findings": [{id, resource, severity, title, flags}], "dismissed": [{flag, reason}]}. The fix is then expected to change or keep every finding it lists, and to say in summary which of the audit’s fixes were applied as written and which were done differently. It is a previous reply, not evidence: the model checks it against manifests.

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 never write a secret value: when the paste holds a credential it says to rotate it, quotes the key with *** for the value, and refers to a Secret by name. Every page flag whose sev is not info is answered exactly once — in the audit lane in flag_answers, in the fix lane in changes or kept — and an info flag is never reported as a finding. A flag that lists several resources is one flag, fixed only when every resource it lists is fixed.

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 documents array for fix, an appliers array for audit). An unknown verdict shows as needs_work or partial and counts as a disagreement; an unknown severity becomes medium and counts as one too; ids like FX3 become FX-03; flags keeps only F<n> values; findings with no resource, evidence and title are dropped; questions is capped at 6, plan at 14, migration and commands at 12. An audit reply carries 10 sections (verdict, headline, classification, findings, flag_answers, appliers, migration, plan, questions, summary) and a fix reply 9 (verdict, headline, documents, changes, kept, removed, commands, 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 platform and helm), built exactly as the page builds them: Fluxkit.mustBeObject(Fluxkit.buildInput(lane, Fluxkit.analyze(text), note)), with a real model reply for each. Long values are trimmed for display, and each excerpt says what it leaves out; what is shown is verbatim. Neither paste holds a secret.

Audit: a Flux Operator platform repo onboarding its first tenant

Five files, 12 documents: a FluxInstance, the tenants Kustomization, the team-checkout namespace, service account and RoleBinding, its GitRepository and Kustomization, image automation against ECR, and a Redis HelmRelease from a type: oci HelmRepository. The page’s free check raises 8 flags (6 medium, 1 low, 1 info); its own reading of the verdict is needs_work. The engineer’s note: “First tenant on the staging cluster. Is the tenancy set up the way Flux recommends before we add more teams?”

The manifests string, an excerpt: the first 45 of its 191 lines (the first two documents); the whole string is 3,863 characters ending in a newline. Save the full platform paste as platform.yaml and run node build-facts.js platform.yaml platform: 

# file: clusters/staging/flux-system/flux-instance.yaml
apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
  name: flux
  namespace: flux-system
spec:
  distribution:
    version: "2.8.x"
    registry: "ghcr.io/fluxcd"
  components:
    - source-controller
    - kustomize-controller
    - helm-controller
    - notification-controller
    - image-reflector-controller
    - image-automation-controller
  cluster:
    type: kubernetes
    size: medium
    multitenant: false
    networkPolicy: true
  sync:
    kind: GitRepository
    url: https://github.com/vandrel-labs/platform.git
    ref: refs/heads/main
    path: clusters/staging
    pullSecret: flux-system
---
# file: clusters/staging/tenants.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: tenants
  namespace: flux-system
spec:
  interval: 30m
  retryInterval: 2m
  timeout: 5m
  wait: true
  path: ./tenants/staging
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system
...

The facts object, decoded — an excerpt: 2 of the 12 resources, 1 of the 2 sources, 1 of the 3 appliers and 3 of the 8 flags (F3..F7 — FX-19, FX-22, FX-18, FX-20 and FX-26 — are left out). The full string is 7,530 characters; build it with build-facts.js (it lands in platform-facts.json): 

{
  "source": {
    "lines": 192,
    "format": "yaml",
    "files": [
      "clusters/staging/flux-system/flux-instance.yaml",
      "clusters/staging/tenants.yaml",
      "tenants/staging/team-checkout.yaml",
      "tenants/staging/image-automation.yaml",
      "tenants/staging/redis.yaml"
    ],
    "namespaces": [
      "flux-system",
      "team-checkout"
    ],
    "resources": [
      {
        "ref": "FluxInstance/flux",
        "kind": "FluxInstance",
        "api_version": "fluxcd.controlplane.io/v1",
        "name": "flux",
        "namespace": "flux-system",
        "file": "clusters/staging/flux-system/flux-instance.yaml",
        "line": 2,
        "end_line": 28,
        "flux": true
      },
      {
        "ref": "Kustomization/checkout",
        "kind": "Kustomization",
        "api_version": "kustomize.toolkit.fluxcd.io/v1",
        "name": "checkout",
        "namespace": "team-checkout",
        "file": "tenants/staging/team-checkout.yaml",
        "line": 88,
        "end_line": 101,
        "flux": true
      }
    ],
    "parse_errors": []
  },
  "install": "Flux Operator (FluxInstance FluxInstance/flux)",
  "layout": "top-level clusters/, tenants/",
  "tenancy": {
    "multi_tenant": true,
    "fluxinstance_multitenant": false,
    "tenant_namespaces": [
      "team-checkout"
    ],
    "appliers_with_service_account": []
  },
  "sources": [
    {
      "ref": "GitRepository/checkout",
      "kind": "GitRepository",
      "namespace": "team-checkout",
      "url": "https://github.com/vandrel-labs/checkout-deploy",
      "type": "",
      "revision": "branch=main",
      "interval": "5m",
      "provider": "",
      "secret_ref": "checkout-git",
      "verify": "",
      "insecure": false
    }
  ],
  "appliers": [
    {
      "ref": "Kustomization/checkout",
      "kind": "Kustomization",
      "namespace": "team-checkout",
      "source": "GitRepository/checkout",
      "what": "path ./deploy/staging",
      "interval": "10m",
      "prune": "true",
      "wait": "(not set)",
      "depends_on": [],
      "target_namespace": "",
      "service_account": "",
      "timeout": "5m",
      "retry_interval": "2m"
    }
  ],
  "secrets": [],
  "flags": [
    {
      "uid": "F1",
      "id": "FX-21",
      "sev": "medium",
      "resource": "FluxInstance/flux",
      "line": 21,
      "text": "FluxInstance/flux does not enable cluster.multitenant, but the paste labels tenant namespaces (team-checkout)",
      "detail": "multitenant: true enforces service-account impersonation, disables cross-namespace references and sets a default service account on all controllers."
    },
    {
      "uid": "F2",
      "id": "FX-20",
      "sev": "medium",
      "resource": "Kustomization/checkout",
      "line": 88,
      "text": "Kustomization/checkout (tenant namespace team-checkout) sets no serviceAccountName",
      "detail": "In a multi-tenant repo each tenant's appliers should impersonate a tenant service account with namespace-scoped RBAC; without it they run with the controller's own cluster-wide permissions."
    },
    {
      "uid": "F8",
      "id": "FX-32",
      "sev": "info",
      "resource": "Kustomization/tenants",
      "line": 31,
      "text": "No Alert or Provider in the paste",
      "detail": "Production clusters should send at least error-severity events to a Provider (Slack, Teams, ...), if that is not configured elsewhere."
    }
  ],
  "verdict_candidate": "needs_work",
  "notes": []
}

The request body the page sends, trimmed for display: the full body is 12,618 characters of compact JSON, and the two long strings are cut here after their first 160 characters, with the cut marked inside the string. The step 4 samples build the untrimmed body from the two saved files. 

{
  "task": "audit",
  "manifests": "# file: clusters/staging/flux-system/flux-instance.yaml\napiVersion: fluxcd.controlplane.io/v1\nkind: FluxInstance\nmetadata:\n  name: flux\n  namespace: flux-system ... [trimmed for display: 160 of 3,863 characters shown]",
  "facts": "{\"source\":{\"lines\":192,\"format\":\"yaml\",\"files\":[\"clusters/staging/flux-system/flux-instance.yaml\",\"clusters/staging/tenants.yaml\",\"tenants/staging/team-checkout ... [trimmed for display: 160 of 7,530 characters shown]",
  "note": "First tenant on the staging cluster. Is the tenancy set up the way Flux recommends before we add more teams?"
}

The page sends it with Idempotency-Key: gitops-repo-audit:audit:80389222-314a:a1 (see step 5). The reply, an excerpt: 2 of the 7 findings (the others are FX-21 on FluxInstance/flux, FX-19, FX-22, FX-20 on HelmRelease/redis and FX-26), 2 of the 7 flag answers (all 7 are confirmed; F8 is info and needs none), 1 of the 3 appliers, 2 of the 6 plan steps and 1 of the 2 questions: 

{
  "task": "audit",
  "verdict": "needs_work",
  "headline": "The repo is fully on current Flux 2.8 APIs and reconciles cleanly, but the first tenant (team-checkout) is not yet isolated the way Flux recommends before more teams are added.",
  "classification": "Directory-driven, single-cluster (staging) repo installed via the Flux Operator (FluxInstance/flux): clusters/staging drives Kustomization/tenants into tenants/staging, which onboards team-checkout as its own namespace, RBAC, Git source, Kustomization, image automation and a Helm-deployed Redis. The layout is multi-tenant by directory and labeling (toolkit.fluxcd.io/tenant), but FluxInstance.spec.cluster.multitenant is still false and no tenant applier impersonates a service account yet.",
  "findings": [
    {
      "id": "FX-20",
      "flags": [
        "F2"
      ],
      "resource": "Kustomization/checkout",
      "line": 88,
      "severity": "medium",
      "title": "Kustomization/checkout has no serviceAccountName",
      "evidence": "namespace: team-checkout\nsourceRef:",
      "why": "team-checkout already has ServiceAccount/team-checkout and a namespace-scoped RoleBinding to ClusterRole admin (tenants/staging/team-checkout.yaml), but Kustomization/checkout never impersonates it, so kustomize-controller applies ./deploy/staging with its own controller-wide permissions instead of the tenant's namespace-scoped RBAC.",
      "fix": "apiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n  name: checkout\n  namespace: team-checkout\nspec:\n  interval: 10m\n  retryInterval: 2m\n  timeout: 5m\n  path: ./deploy/staging\n  prune: true\n  serviceAccountName: team-checkout\n  sourceRef:\n    kind: GitRepository\n    name: checkout\n"
    },
    {
      "id": "FX-18",
      "flags": [
        "F5"
      ],
      "resource": "HelmRepository/bitnami",
      "line": 161,
      "severity": "medium",
      "title": "HelmRepository/bitnami uses the legacy type: oci mode",
      "evidence": "type: oci\nurl: oci://registry-1.docker.io/bitnamicharts",
      "why": "type: oci HelmRepository is the deprecated way to pull OCI Helm charts: it cannot be referenced by chartRef, cannot use cosign verification, and has no tag/layer selection. HelmRelease/redis pulls redis from oci://registry-1.docker.io/bitnamicharts through it today, with none of those newer supply-chain controls available.",
      "fix": "apiVersion: source.toolkit.fluxcd.io/v1\nkind: OCIRepository\nmetadata:\n  name: redis\n  namespace: team-checkout\nspec:\n  interval: 1h\n  url: oci://registry-1.docker.io/bitnamicharts/redis\n  ref:\n    semver: \"20.x\"\n---\napiVersion: helm.toolkit.fluxcd.io/v2\nkind: HelmRelease\nmetadata:\n  name: redis\n  namespace: team-checkout\nspec:\n  interval: 30m\n  timeout: 10m\n  serviceAccountName: team-checkout\n  chartRef:\n    kind: OCIRepository\n    name: redis\n  install:\n    strategy:\n      name: RetryOnFailure\n  upgrade:\n    strategy:\n      name: RetryOnFailure\n  driftDetection:\n    mode: enabled\n  values:\n    architecture: standalone\n    auth:\n      existingSecret: redis-auth\n"
    }
  ],
  "flag_answers": [
    {
      "flag": "F2",
      "status": "confirmed",
      "reason": "Kustomization/checkout's spec (lines 93-101: interval, retryInterval, timeout, path, prune, sourceRef) has no serviceAccountName field."
    },
    {
      "flag": "F5",
      "status": "confirmed",
      "reason": "HelmRepository/bitnami line 161 sets type: oci."
    }
  ],
  "appliers": [
    {
      "resource": "Kustomization/checkout",
      "does": "Reconciles ./deploy/staging from GitRepository/checkout (branch main) every 10m with prune: true. FX-20 (F2): it runs with kustomize-controller's own permissions instead of impersonating ServiceAccount/team-checkout."
    }
  ],
  "migration": [],
  "plan": [
    "Add serviceAccountName: team-checkout to Kustomization/checkout and HelmRelease/redis so both impersonate the namespace-scoped RBAC already created for the tenant (F2, F6).",
    "Set FluxInstance/flux spec.cluster.multitenant: true now that the tenant's appliers impersonate, so the operator enforces impersonation and blocks cross-namespace references for this and every future tenant (F1)."
  ],
  "questions": [
    "Is AWS Workload Identity (IRSA) already set up for this staging cluster, so ImageRepository/checkout-api can move to spec.provider: aws instead of secretRef ecr-credentials?"
  ],
  "summary": "Not yet: FluxInstance/flux still has cluster.multitenant: false, and neither Kustomization/checkout nor HelmRelease/redis impersonate the ServiceAccount/team-checkout and RoleBinding already created for the tenant, so team-checkout's appliers currently run with the controllers' own cluster-wide permissions rather than the tenant's namespace-scoped RBAC - add serviceAccountName to both, then flip multitenant: true, before onboarding a second team. The rest of the repo is solid: every document is already on current Flux 2.8 APIs (no flux migrate needed) and HelmRelease/redis already uses the modern RetryOnFailure remediation with drift detection on; the remaining gaps - the legacy oci HelmRepository, ECR static credentials, image updates pushed straight to main, and no retryInterval on redis - are medium/low hygiene items, not blockers."
}

Held to the page’s own reconciliation (recon.js reconcile, on this exact body and the full reply), this reply has 1 disagreement in 18 statements checked, and it is in the excerpt: the FX-18 fix adds OCIRepository/redis and moves HelmRelease/redis to chartRef, but leaves remove empty, so with the fix put back HelmRepository/bitnami is still there and the page still raises FX-18 on it. The fix needed "remove": ["HelmRepository/bitnami"]. (The page also notes, as information, that the FX-21 evidence quotes a line from outside FluxInstance/flux.) This is why the page re-runs every fix, and why you should too.

What the step 5 samples print for the full reply (the Python form; charged is whatever the run cost):

truncated: False charged: ...
needs_work - The repo is fully on current Flux 2.8 APIs and reconciles cleanly, but the first tenant (team-checkout) is not yet isolated the way Flux recommends before more teams are added.
FX-21 FluxInstance/flux 21 medium
FX-20 Kustomization/checkout 88 medium
FX-19 ImageRepository/checkout-api 110 medium
FX-22 ImageUpdateAutomation/checkout 148 medium
FX-18 HelmRepository/bitnami 161 medium
FX-20 HelmRelease/redis 165 medium
FX-26 HelmRelease/redis 171 low
applier Kustomization/tenants
applier Kustomization/checkout
applier HelmRelease/redis

Had you pressed “Fix the manifests from this audit” after this reply, the page would send the fix lane on the same paste (the same manifests, facts and note) with this audit_handoff, shown decoded and trimmed to 3 of its 7 findings; in the body it is the compact JSON.stringify of it (1,306 characters). That body is 14,097 characters and its key would be gitops-repo-audit:fix:4ef41696-3711:a1: 

{
  "from": "audit",
  "verdict": "needs_work",
  "headline": "The repo is fully on current Flux 2.8 APIs and reconciles cleanly, but the first tenant (team-checkout) is not yet isolated the way Flux recommends before more teams are added.",
  "findings": [
    {
      "id": "FX-21",
      "resource": "FluxInstance/flux",
      "severity": "medium",
      "title": "FluxInstance does not enforce multi-tenant impersonation",
      "flags": [
        "F1"
      ]
    },
    {
      "id": "FX-20",
      "resource": "Kustomization/checkout",
      "severity": "medium",
      "title": "Kustomization/checkout has no serviceAccountName",
      "flags": [
        "F2"
      ]
    },
    {
      "id": "FX-19",
      "resource": "ImageRepository/checkout-api",
      "severity": "medium",
      "title": "ImageRepository/checkout-api authenticates to ECR with a static Secret",
      "flags": [
        "F3"
      ]
    }
  ],
  "dismissed": []
}

Fix: two HelmReleases on helm v2beta2 with charts on * and latest

Four files, 4 documents: HelmRelease/podinfo and HelmRelease/redis on helm.toolkit.fluxcd.io/v2beta2, their two HelmRepositories on source.toolkit.fluxcd.io/v1beta2, chart versions "*" and "latest", and the legacy remediation blocks. The free check raises 8 flags (4 medium, 3 low, 1 info). This example has no audit before it, so it carries no audit_handoff. The engineer’s note: “Bring these up to Flux 2.8 practice. podinfo 6.x and redis 20.x are the lines we run.”

The manifests string, whole: 1,539 characters ending in a newline — save it as helm.yaml and run node build-facts.js helm.yaml podinfo:

# file: apps/base/podinfo/release.yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: podinfo
  namespace: podinfo
spec:
  interval: 10m
  targetNamespace: podinfo
  chart:
    spec:
      chart: podinfo
      version: "*"
      sourceRef:
        kind: HelmRepository
        name: podinfo
  install:
    createNamespace: true
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
      remediateLastFailure: true
  values:
    replicaCount: 2
    ingress:
      enabled: true
      hosts:
        - host: podinfo.staging.lumorra-retail.example
          paths:
            - path: /
              pathType: Prefix
---
# file: apps/base/podinfo/repository.yaml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: podinfo
  namespace: podinfo
spec:
  interval: 1h
  url: https://stefanprodan.github.io/podinfo
---
# file: apps/base/redis/release.yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: redis
  namespace: podinfo
spec:
  interval: 10m
  chart:
    spec:
      chart: redis
      version: "latest"
      sourceRef:
        kind: HelmRepository
        name: bitnami
  install:
    remediation:
      retries: 3
  values:
    architecture: standalone
    auth:
      existingSecret: redis-auth
---
# file: apps/base/redis/repository.yaml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: bitnami
  namespace: podinfo
spec:
  interval: 1h
  url: https://charts.bitnami.com/bitnami

The facts object, decoded — an excerpt: 1 of the 4 resources, 1 of the 2 sources, 1 of the 2 appliers and 3 of the 8 flags (F2..F4, F6 and F7 — FX-17, FX-01, FX-17, FX-26 and FX-25 — are left out). Note how F1 and F5 each cover two resources. The full string is 5,607 characters (podinfo-facts.json): 

{
  "source": {
    "lines": 77,
    "format": "yaml",
    "files": [
      "apps/base/podinfo/release.yaml",
      "apps/base/podinfo/repository.yaml",
      "apps/base/redis/release.yaml",
      "apps/base/redis/repository.yaml"
    ],
    "namespaces": [
      "podinfo"
    ],
    "resources": [
      {
        "ref": "HelmRelease/podinfo",
        "kind": "HelmRelease",
        "api_version": "helm.toolkit.fluxcd.io/v2beta2",
        "name": "podinfo",
        "namespace": "podinfo",
        "file": "apps/base/podinfo/release.yaml",
        "line": 2,
        "end_line": 33,
        "flux": true
      }
    ],
    "parse_errors": []
  },
  "install": "not in the paste",
  "layout": "top-level apps/",
  "tenancy": {
    "multi_tenant": false,
    "fluxinstance_multitenant": null,
    "tenant_namespaces": [],
    "appliers_with_service_account": []
  },
  "sources": [
    {
      "ref": "HelmRepository/podinfo",
      "kind": "HelmRepository",
      "namespace": "podinfo",
      "url": "https://stefanprodan.github.io/podinfo",
      "type": "",
      "revision": "(none)",
      "interval": "1h",
      "provider": "",
      "secret_ref": "",
      "verify": "",
      "insecure": false
    }
  ],
  "appliers": [
    {
      "ref": "HelmRelease/podinfo",
      "kind": "HelmRelease",
      "namespace": "podinfo",
      "source": "HelmRepository/podinfo",
      "what": "chart podinfo *",
      "interval": "10m",
      "prune": "(not set)",
      "wait": "(not set)",
      "depends_on": [],
      "target_namespace": "podinfo",
      "service_account": "",
      "timeout": "",
      "retry_interval": ""
    }
  ],
  "secrets": [],
  "flags": [
    {
      "uid": "F1",
      "id": "FX-01",
      "sev": "medium",
      "resource": "HelmRelease/podinfo",
      "resources": [
        "HelmRelease/podinfo",
        "HelmRelease/redis"
      ],
      "line": 2,
      "text": "2 resources on helm.toolkit.fluxcd.io/v2beta2 (removed in Flux v2.8)",
      "detail": "Current: helm.toolkit.fluxcd.io/v2. Flux v2.8 and later refuse these resources. Run flux migrate -f . --dry-run, then flux migrate -f . and commit; then migrate the cluster objects (flux migrate) before upgrading. Affected: HelmRelease/podinfo, HelmRelease/redis."
    },
    {
      "uid": "F5",
      "id": "FX-27",
      "sev": "low",
      "resource": "HelmRelease/podinfo",
      "resources": [
        "HelmRelease/podinfo",
        "HelmRelease/redis"
      ],
      "line": 2,
      "text": "2 appliers have namespace or drift hygiene gaps (HelmRelease/podinfo, HelmRelease/redis)",
      "detail": "HelmRelease/podinfo: targetNamespace without storageNamespace, install.createNamespace, no driftDetection.mode: enabled; HelmRelease/redis: no driftDetection.mode: enabled. Namespaces belong to the parent Kustomization, Helm storage beside the release, and production releases should detect drift."
    },
    {
      "uid": "F8",
      "id": "FX-32",
      "sev": "info",
      "resource": "HelmRelease/podinfo",
      "line": 2,
      "text": "No Alert or Provider in the paste",
      "detail": "Production clusters should send at least error-severity events to a Provider (Slack, Teams, ...), if that is not configured elsewhere."
    }
  ],
  "verdict_candidate": "needs_work",
  "notes": []
}

The request body, trimmed the same way (the full body is 7,961 characters):

{
  "task": "fix",
  "manifests": "# file: apps/base/podinfo/release.yaml\napiVersion: helm.toolkit.fluxcd.io/v2beta2\nkind: HelmRelease\nmetadata:\n  name: podinfo\n  namespace: podinfo\nspec:\n  inter ... [trimmed for display: 160 of 1,539 characters shown]",
  "facts": "{\"source\":{\"lines\":77,\"format\":\"yaml\",\"files\":[\"apps/base/podinfo/release.yaml\",\"apps/base/podinfo/repository.yaml\",\"apps/base/redis/release.yaml\",\"apps/base/re ... [trimmed for display: 160 of 5,607 characters shown]",
  "note": "Bring these up to Flux 2.8 practice. podinfo 6.x and redis 20.x are the lines we run."
}

The page sends it with Idempotency-Key: gitops-repo-audit:fix:20a13c99-1f19:a1. The reply, an excerpt: 2 of the 4 documents (HelmRelease/podinfo is shown decoded below; HelmRepository/podinfo is left out) and 3 of the 7 changes (every flag F1..F7 is fixed by one change; kept and removed are empty): 

{
  "task": "fix",
  "verdict": "ready",
  "headline": "Migrated all four documents to Flux 2.8 APIs, pinned the podinfo/redis chart versions to the 6.x/20.x lines, and modernized remediation, drift detection and timeouts on both HelmReleases.",
  "documents": [
    {
      "resource": "HelmRelease/redis",
      "yaml": "apiVersion: helm.toolkit.fluxcd.io/v2\nkind: HelmRelease\nmetadata:\n  name: redis\n  namespace: podinfo\nspec:\n  interval: 10m\n  timeout: 5m\n  retryInterval: 2m\n  driftDetection:\n    mode: enabled\n  chart:\n    spec:\n      chart: redis\n      version: \"20.x\"\n      sourceRef:\n        kind: HelmRepository\n        name: bitnami\n  install:\n    strategy:\n      name: RetryOnFailure\n  values:\n    architecture: standalone\n    auth:\n      existingSecret: redis-auth\n"
    },
    {
      "resource": "HelmRepository/bitnami",
      "yaml": "apiVersion: source.toolkit.fluxcd.io/v1\nkind: HelmRepository\nmetadata:\n  name: bitnami\n  namespace: podinfo\nspec:\n  interval: 1h\n  url: https://charts.bitnami.com/bitnami\n"
    }
  ],
  "changes": [
    {
      "flags": [
        "F4"
      ],
      "id": "FX-17",
      "resource": "HelmRelease/redis",
      "what": "Pinned chart.spec.version from \"latest\" to \"20.x\" on HelmRelease/redis.",
      "why": "The note confirms redis 20.x is the line run in production; 'latest' is not a pinned semver constraint and would resolve differently on every reconcile, including a breaking major."
    },
    {
      "flags": [
        "F5"
      ],
      "id": "FX-27",
      "resource": "HelmRelease/podinfo",
      "what": "Added spec.storageNamespace: podinfo and spec.driftDetection.mode: enabled to HelmRelease/podinfo; added spec.driftDetection.mode: enabled to HelmRelease/redis.",
      "why": "podinfo set targetNamespace without a matching storageNamespace, which scatters the Helm release's storage secret from the workload namespace; neither release detected manual drift in the cluster."
    },
    {
      "flags": [
        "F7"
      ],
      "id": "FX-25",
      "resource": "HelmRelease/podinfo",
      "what": "Replaced install.remediation/upgrade.remediation on HelmRelease/podinfo with install.strategy.name: RetryOnFailure and upgrade.strategy.name: RetryOnFailure; replaced install.remediation on HelmRelease/redis with install.strategy.name: RetryOnFailure (redis had no upgrade.remediation block to replace).",
      "why": "install/upgrade.remediation is the legacy HelmRelease remediation API; strategy.name: RetryOnFailure is the current field."
    }
  ],
  "kept": [],
  "removed": [],
  "commands": [
    "flux migrate -f . --dry-run",
    "flux migrate"
  ],
  "questions": [],
  "summary": "Per the note, chart versions are pinned to the 6.x (podinfo) and 20.x (redis) lines actually run, and all four documents move off the v2beta2/v1beta2 APIs Flux 2.7/2.8 removed onto helm.toolkit.fluxcd.io/v2 and source.toolkit.fluxcd.io/v1. Both HelmReleases also gained storageNamespace (podinfo) and driftDetection.mode: enabled, a timeout and retryInterval, and the modern install/upgrade.strategy.name: RetryOnFailure remediation in place of the legacy remediation blocks. No secrets are present in this paste, so nothing needed rotation; run flux migrate --dry-run against the full repo (this paste is only two of its apps) before committing and flux migrate against the cluster to convert already-applied objects before upgrading to Flux 2.8."
}

The HelmRelease/podinfo document of the reply, decoded:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: podinfo
  namespace: podinfo
spec:
  interval: 10m
  timeout: 5m
  retryInterval: 2m
  targetNamespace: podinfo
  storageNamespace: podinfo
  driftDetection:
    mode: enabled
  chart:
    spec:
      chart: podinfo
      version: "6.x"
      sourceRef:
        kind: HelmRepository
        name: podinfo
  install:
    createNamespace: true
    strategy:
      name: RetryOnFailure
  upgrade:
    strategy:
      name: RetryOnFailure
  values:
    replicaCount: 2
    ingress:
      enabled: true
      hosts:
        - host: podinfo.staging.lumorra-retail.example
          paths:
            - path: /
              pathType: Prefix

Held to the page’s reconciliation, this reply has 1 disagreement in 17 statements checked: F5 (FX-27) is listed as fixed, but with the documents put back the free check still raises it on HelmRelease/podinfo — the flag’s detail names three gaps there (no storageNamespace, install.createNamespace, no drift detection) and the reply closed two; createNamespace: true is still in the document. Everything else checks out: every resource is still there, no new high flag, and the verdict fits.

To see that for yourself — what the page’s “Check the fixed manifests” does — put the documents back into the paste with fluxkit.js and run the free check on the result. Save the parsed reply as fix-reply.json: 

// apply-fix.js -- run: node apply-fix.js helm.yaml fix-reply.json > fixed-paste.yaml   (fluxkit.js next to it)
const fs = require("fs");
const Fluxkit = require("./fluxkit.js");
const A = Fluxkit.analyze(fs.readFileSync(process.argv[2], "utf8"));
const r = JSON.parse(fs.readFileSync(process.argv[3], "utf8"));           // the parsed fix reply
const out = Fluxkit.applyDocs(A,
  (r.documents || []).map((d) => ({ yaml: d.yaml, ref: d.resource === "new" ? null : d.resource })),
  (r.removed || []).map((x) => x.resource));
if (!out) { console.error("a document does not read as Kubernetes YAML"); process.exit(1); }
process.stdout.write(out.text);                                           // the paste with the documents in place
const B = Fluxkit.analyze(out.text);                                      // the free check, run again
console.error(B.flags.filter((f) => f.sev !== "info").map((f) => f.id + " " + f.sev + " " + f.text).join("\n") || "no flags left");

For this reply it writes the 84-line repaired paste and reports the one flag left:

FX-27 low 1 applier has namespace or drift hygiene gaps (HelmRelease/podinfo)

The same function checks one audit finding: pass [{ yaml: f.fix, ref: f.resource }] and f.remove instead.

What the step 6 samples print for the full reply (the Python form):

truncated: False charged: ...
ready - Migrated all four documents to Flux 2.8 APIs, pinned the podinfo/redis chart versions to the 6.x/20.x lines, and modernized remediation, drift detection and timeouts on both HelmReleases.
change F1 FX-01 HelmRelease/podinfo
change F2 FX-17 HelmRelease/podinfo
change F3 FX-01 HelmRepository/podinfo
change F4 FX-17 HelmRelease/redis
change F5 FX-27 HelmRelease/podinfo
change F6 FX-26 HelmRelease/podinfo
change F7 FX-25 HelmRelease/podinfo
command flux migrate -f . --dry-run
command flux migrate

The page checks the reply against the manifests; 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 manifests and the handoff it sent). These checks are client-side: a direct API caller gets none of them.

If you call the API directly, apply your own checks — the evidence against your manifests, every flag answered, each fix or document put back and re-checked (apply-fix.js above, then flux-schema, kustomize build or a dry-run against the cluster) — before you merge 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="${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":"gitops-repo-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 manifests as the pasted YAML text, facts as a compact JSON string, the note when it is not blank, and — for the fix lane only — the audit_handoff string when you have one. The samples build the audit input of the platform example from the two files build-facts.js wrote; step 6 reuses makeInput for the 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. What you pay is the job’s charged_credits after settlement (step 5), normally less. A balance below the hold is allowed but 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, 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, 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 manifests and facts, so read them from the call rather than hard-coding them. 

# platform-manifests.yaml and platform-facts.json: written by build-facts.js (see "The facts string").
# --rawfile keeps the YAML byte for byte (jq 1.6+); jq -c turns the facts into ONE compact string.
BODY=$(jq -n --rawfile manifests platform-manifests.yaml --arg facts "$(jq -c . platform-facts.json)" \
  --arg note "First tenant on the staging cluster. Is the tenancy set up the way Flux recommends before we add more teams?" \
  '{task: "audit", manifests: $manifests, facts: $facts, note: $note}')
# No page check at hand? --arg facts '{}' is accepted as a string, but the reply then has no page flags to answer.
# Fix lane after an audit of the SAME paste: task: "fix", plus
#   --arg handoff "$(jq -c . handoff.json)"  and  audit_handoff: $handoff  in the object.

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 of the same paste never share a key. The page uses gitops-repo-audit:<lane>:<inputHash>:a<attempt>, 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 gitops-repo-audit:audit:80389222-314a:a1 and gitops-repo-audit:fix:20a13c99-1f19: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="gitops-repo-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, findings: [(.findings // [])[] | {id, resource, line, severity}], appliers: [(.appliers // [])[] | .resource]}'

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 podinfo 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 change’s flags, id and resource, each kept flag, each removed resource and each command to run outside Git, and write every corrected document to fixed-documents.yaml (joined by ---, the way the page’s “copy all documents” does). Those documents replace the pasted ones they name; to get the whole repaired paste, put them back with apply-fix.js (under “Worked examples”) — what the page’s “Check the fixed manifests” does — and paste the result into the app page to run the free check on it. To fix a paste you audited, pass the handoff string as makeInput’s last argument. 

# the fix worked example: podinfo-manifests.yaml and podinfo-facts.json from build-facts.js
FBODY=$(jq -n --rawfile manifests podinfo-manifests.yaml --arg facts "$(jq -c . podinfo-facts.json)" \
  --arg note "Bring these up to Flux 2.8 practice. podinfo 6.x and redis 20.x are the lines we run." \
  '{task: "fix", manifests: $manifests, facts: $facts, note: $note}')
FKEY="gitops-repo-audit:fix:$(printf '%s' "$FBODY" | shasum -a 256 | cut -c1-16):a1"

# -N turns off buffering so frames print as they arrive; tee keeps them for the next lines
api POST /run-stream -N -H "Idempotency-Key: $FKEY" -d "$FBODY" | tee stream.txt

# 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=$(awk '/^event:/{ev=$2} /^data:/ && (ev=="done" || ev=="pending"){sub(/^data: */,""); print}' stream.txt \
  | jq -r '.output.output')
# an idempotent replay answers with a plain JSON envelope instead: REPLY=$(jq -r '.data.output.output' stream.txt)
printf '%s' "$REPLY" | jq '{verdict, headline, changes: [(.changes // [])[] | {flags, id, resource}], kept, removed, commands}'
printf '%s' "$REPLY" | jq -r '[(.documents // [])[] | .yaml | sub("\\s+$"; "")] | join("\n---\n")' > fixed-documents.yaml

What the page does that you now do

Or skip all of this and use GitOps Repo Audit in the browser: the check, the flags, putting a fix back into the paste, and the Markdown and CSV exports are free.