@runcofactor/cli 0.52.0 → 0.53.0

package/dist/{chunk-I5RHTCPY.js → chunk-EL6KJ4PO.js}

@@ -1,15 +1,15 @@
 import { createRequire as __cr } from "module"; import { fileURLToPath as __fup } from "url"; import { dirname as __dn } from "path"; const require = __cr(import.meta.url); const __filename = __fup(import.meta.url); const __dirname = __dn(__filename);
 import {
   apiRequest
-} from "./chunk-LL6TSQWV.js";
+} from "./chunk-VKZOHJCE.js";
 import {
   getArgValue,
   hasFlag,
   resolveConfig
-} from "./chunk-3HI6QC4V.js";
+} from "./chunk-WRBU6TX7.js";
 import {
   writeRawOutput
-} from "./chunk-UEJ2HTKU.js";
+} from "./chunk-MJVUMVLO.js";
 
 // src/tag.ts
 import process from "process";
@@ -438,4 +438,4 @@ export {
   updateEntityTags,
   runTag
 };
-//# sourceMappingURL=chunk-I5RHTCPY.js.map
+//# sourceMappingURL=chunk-EL6KJ4PO.js.map

package/dist/{chunk-ZL4O6C42.js → chunk-HXBK3AGD.js}

@@ -9,7 +9,7 @@ import {
   slugifySeedName,
   validateMacroReferences,
   validateWorkflowInputExpressions
-} from "./chunk-76Z6E7XX.js";
+} from "./chunk-4UZN6TVT.js";
 
 // ../canary-spec/src/parse.ts
 import yaml2 from "yaml";
@@ -3256,4 +3256,4 @@ export {
   writeWorkflowId,
   writeNodeIds
 };
-//# sourceMappingURL=chunk-ZL4O6C42.js.map
+//# sourceMappingURL=chunk-HXBK3AGD.js.map

package/dist/{chunk-PRERH4DN.js → chunk-I2SOHQ2C.js}

@@ -1,10 +1,10 @@
 import { createRequire as __cr } from "module"; import { fileURLToPath as __fup } from "url"; import { dirname as __dn } from "path"; const require = __cr(import.meta.url); const __filename = __fup(import.meta.url); const __dirname = __dn(__filename);
 import {
   clearUpdateCache
-} from "./chunk-QCYSONXI.js";
+} from "./chunk-CRYHWO4M.js";
 import {
   packageName
-} from "./chunk-UEJ2HTKU.js";
+} from "./chunk-MJVUMVLO.js";
 
 // src/upgrade.ts
 import fs from "fs";
@@ -68,4 +68,4 @@ export {
   installCommandLine,
   runUpgrade
 };
-//# sourceMappingURL=chunk-PRERH4DN.js.map
+//# sourceMappingURL=chunk-I2SOHQ2C.js.map

package/dist/{chunk-CYSPCGO6.js → chunk-JEHHEMUL.js}

@@ -2,22 +2,22 @@ import { createRequire as __cr } from "module"; import { fileURLToPath as __fup
 import {
   ENV_VAR_NAME,
   updateEnvVarDefinitions
-} from "./chunk-775FI436.js";
+} from "./chunk-RVD6J6IZ.js";
 import {
   UUID_RE,
   apiRequest,
   fetchProperties,
   readStdin,
   stripOneTrailingNewline
-} from "./chunk-LL6TSQWV.js";
+} from "./chunk-VKZOHJCE.js";
 import {
   getArgValue,
   hasFlag,
   resolveConfig
-} from "./chunk-3HI6QC4V.js";
+} from "./chunk-WRBU6TX7.js";
 import {
   writeRawOutput
-} from "./chunk-UEJ2HTKU.js";
+} from "./chunk-MJVUMVLO.js";
 
 // src/environment.ts
 import process from "process";
@@ -405,4 +405,4 @@ export {
   handleSetVar,
   runEnvironment
 };
-//# sourceMappingURL=chunk-CYSPCGO6.js.map
+//# sourceMappingURL=chunk-JEHHEMUL.js.map

package/dist/{chunk-LIEADTEF.js → chunk-LJFVRJCA.js}

@@ -1,7 +1,7 @@
 import { createRequire as __cr } from "module"; import { fileURLToPath as __fup } from "url"; import { dirname as __dn } from "path"; const require = __cr(import.meta.url); const __filename = __fup(import.meta.url); const __dirname = __dn(__filename);
 import {
   apiRequest
-} from "./chunk-LL6TSQWV.js";
+} from "./chunk-VKZOHJCE.js";
 
 // src/teams-channels.ts
 import process from "process";
@@ -22,4 +22,4 @@ async function loadTeamsChannels(apiUrl, token) {
 export {
   loadTeamsChannels
 };
-//# sourceMappingURL=chunk-LIEADTEF.js.map
+//# sourceMappingURL=chunk-LJFVRJCA.js.map

package/dist/{chunk-UEJ2HTKU.js → chunk-MJVUMVLO.js}

@@ -1700,6 +1700,22 @@ var ISSUES_GUIDE_SECTIONS = [
   { title: "Hand an issue off for a fix", slug: "handoff", content: handoff_default }
 ];
 
+// ../content/src/proofs-guide/overview.txt
+var overview_default3 = 'PROVE A CHANGE WITH TESTS\n\nUse this guide for a pull request that changes user-visible behavior. The pull\nrequest connects numbered acceptance criteria to passing Workflow evidence.\nPass `--org <org>` on every write to select the organization.\n\nCHOOSING PROOFS\n\nPick the proof that fits the change; one change can need several.\n\n- Functional change: a Workflow run that passes at the pushed commit. The\n  procedure below covers it.\n- Performance-sensitive change: a perf run. Read `cofactor perf guide`. A\n  query change, for example, needs both a functional proof and a perf proof.\n- UI change: a Workflow with `visual_checkpoint` nodes. Read\n  `cofactor workflow guide visual-checkpoints`, and step 7 below for how\n  attaching runs the test at the PR base and shows the checkpoint diffs.\n- Agent behavior: evals (coming). `cofactor eval guide` is not available yet.\n\nTHE PROCEDURE\n\n1. Find coverage before writing a Workflow:\n     cofactor workflow list --search "<words>"\n     cofactor workflow get <wf_...> --format markdown\n   Read the candidate assertions. If a test already walks the journey, use it.\n   Never add near-duplicates or a new test for a changed filter, column or field.\n\n2. Choose the Workflow:\n   - If an approved Workflow already proves the criterion without changes (the\n     journey must still work, for example after a query or refactor change),\n     run it as is and attach its run. It is cited as an existing test: it\n     proves the journey still works, it is not new coverage, and it is never\n     promoted (it is already in its suites). It cannot prove new behavior: a\n     new filter, column or field needs a fork that asserts it. An approved\n     fork is still treated as a fork; to cite an existing test, attach the\n     approved test that is not a fork.\n   - Fork an approved Workflow with\n     `cofactor workflow fork fork <wf_...> --org <org>` and edit the fork.\n     Never edit the approved original.\n   - Create a new draft only when no existing journey fits or it needs its own\n     data or role (see `cofactor workflow guide write-a-test`).\n\n3. Configure promotion on the fork or new draft before attaching evidence:\n     cofactor workflow set-promotion <workflowId> --promote-on merge|never|deploy:<stage> [--target-suite <suite>]... --org <org>\n   Repeat `--target-suite` for multiple suites. The command replaces the target\n   suite list; omit it to clear extra suites. Promotion adds target suites and\n   the default regression suite when present. An org without one can use the\n   **Create default suite** button. Do not choose a layer.\n   `never` archives the test at merge instead of adding it to any suite, and\n   takes no `--target-suite`; use it when the proof is about the change itself\n   (see CURATING THE SUITE). It has no effect on an already-approved test.\n\n4. Prove the change at the exact pushed commit. Start from a clean checkout,\n   commit and push the application change, then use the pushed commit from\n   `git rev-parse HEAD` as `<sha>` in `--at <sha>`. Claim that SHA and sync it:\n     cofactor sandbox claim --application <app> --at <sha> --wait --org <org>\n     cofactor sandbox sync <sandboxId> [--build] --org <org>\n     cofactor workflow run <workflowId> --sandbox <sandboxId> --stream --org <org>\n   Iterate until it passes, then run it once more after the last application or\n   Workflow test change and use that passing run ID. An existing test is run the\n   same way, at the pushed commit and on its current revision. For application edits,\n   commit and push, then sync and rerun. Leave the checkout clean. Attach\n   refuses dirty checkouts or missing commit evidence. If the run records a\n   synced tree, it must equal `HEAD^{tree}`; otherwise its recorded source SHA\n   must equal `HEAD`. The run must exist, belong to the cited Workflow, pass,\n   and use its current revision. Attach requires a GitHub-delivered application;\n   upload-delivered applications cannot supply this proof.\n\n5. After proving, commit any remaining changes and push the branch. If those\n   commits change the application or Workflow tests, return to step 4 and\n   prove them before proceeding. Open a DRAFT pull request and note its number\n   `<n>`; attach needs that PR number.\n\n6. Write concise numbered acceptance criteria. State observable outcomes\n   plainly. One run may support several criteria; multiple runs may support one\n   criterion. For each evidence item, use the most specific node or assertion\n   ID available and state what it proves as `Asserted that \u2026`. Omit optional\n   `--node` only when there is no specific ID.\n   A performance run can prove a criterion too, and one criterion can mix\n   kinds: for a query change, attach a Workflow run for the behavior and a\n   performance run for the speed on the same criterion number. Run it at the pushed head SHA\n   and attach it with `--perf-run <prun_...>`; one criterion can carry several\n   runs, and every attached item must pass. A performance run must be completed,\n   compare different base and head commits, and be at the commit you attach; a\n   slower result is refused. Attach a new run at the current head, then detach\n   an older stale item when the criterion should become proved again.\n\n7. After the draft PR exists, attach evidence. The server refuses a new\n   criterion number without both `--text` and `--detail`; reuse the same text\n   and detail for additional evidence on that number:\n     cofactor proofs attach --pr <n> --application <app> --criterion <n> --text "<criterion>" --detail "<why this matters>" --test <wf_...> --run <wrun_...> [--node <most-specific-id>] [--base <sha>] --asserted "Asserted that \u2026" --org <org>\n   For performance evidence, use `--perf-run` instead of `--test` and `--run`:\n     cofactor proofs attach --pr <n> --application <app> --criterion <n> --perf-run <prun_...> --asserted "Asserted that \u2026" --org <org>\n   An approved Workflow that is not a fork is attached the same way; the\n   result says `"existing": true`.\n   Attach exactly one evidence subject per command. A test containing any\n   `visual_checkpoint` node is a UI test, including a test that also has other\n   steps. Attaching it runs the same test at the PR base commit and the proof\n   page shows each checkpoint\'s base, head, and diff. When `--base` is omitted,\n   the CLI uses `git merge-base HEAD origin/<default>` when that ref is available.\n   Put checkpoints before\n   steps that depend on the new behavior so the base run can reach them.\n\n8. Render the criteria block:\n     cofactor proofs render --pr <n> --org <org>\n   The output already includes the markers. Paste the entire output into the\n   PR description, replacing any existing proof block. Never hand-format or\n   edit criteria blocks; use `proofs render`. The rendered block contains\n   numbered criteria and details links only: no IDs, suite configuration, or\n   status glyphs.\n\n9. Inspect or revise the proof:\n     cofactor proofs status --repo <owner/repo> --pr <n> --org <org>\n   The repo is inferred from `GITHUB_REPOSITORY` or `git remote get-url origin`\n   and can be overridden with `--repo`.\n   Detaching removes a criterion and all evidence attached to it:\n     cofactor proofs detach --pr <n> --criterion <n> --org <org>\n   Remove just one item with `--test <wf_...>`, `--perf-run <prun_...>` or\n   `--manual`:\n     cofactor proofs detach --pr <n> --criterion <n> --perf-run <prun_...> --org <org>\n   Render again and replace the PR proof block after every attach or detach.\n\nWHEN COFACTOR CANNOT PROVE A CRITERION\n\nManual evidence is for a criterion Cofactor cannot exercise at all (for example\nit needs a desktop client, real hardware or a third-party console). If the\ncriterion is plainly outside a browser or a sandbox, go straight to it;\notherwise try a Cofactor test first. A failing, flaky or hard-to-write test is\nnever a reason for manual evidence: fix the test or the change, and never detach\nfailing evidence to replace it with manual evidence.\n\nSay what you did and why Cofactor could not prove it, from a clean checkout at\nthe pushed commit:\n     cofactor proofs attach --pr <n> --application <app> --criterion <n> --text "<criterion>" --detail "<why this matters>" --manual --notes <text|@file> [--artifact <https-url>]... --org <org>\n   Notes (up to 10,000 characters) and links (up to 20) are shown to everyone\n   who can read the proof: keep notes to what you did and why, and redact\n   secrets, tokens and customer data from anything you link. Links must be\n   https URLs reviewers can open, never signed or tokenized links and never\n   with credentials (an image attached to the pull request works; where your\n   organization has Cofactor utilities, `cofactor utilities object upload\n   <file> --public --json` returns one).\n   A criterion holds one manual item, and attaching again replaces its notes\n   and links, so pass the same `--notes` and every `--artifact` again. A\n   criterion whose only evidence is manual passes the check with `\u{1F4DD}` and\n   `[manual]`, renders as `(manual)` in the block, and shows a Manual badge with\n   your notes on the proof page; a criterion that mixes manual with other kinds\n   keeps `\u2705` and is decided by its other items. Manual evidence never promotes\n   anything and reads stale after a push; attach it again at the new head.\n\nCHECKS AND STALE EVIDENCE\n\nThe App publishes `cofactor / proofs`; the Actions job reports the same server\nverdict. Diagnose with a body file:\n     cofactor proofs check --pr <n> --sha <head> --body-file <file> --org <org>\n   Or pass `--body -` for stdin. The App queues a refreshed check after attach\nor detach. In the Actions path, rerun the check job after attaching or\ndetaching. Successful stale evidence remains successful and is\nmarked stale. Use Re-run on the Cofactor proof page for stale E2E evidence at\nthe PR head. For stale performance evidence, run it at the new head, attach\nthat run and detach the old item. Cofactor does not rerun automatically. Server and CI own promotion\ntriggers; `cofactor trigger` is not your job.\n\nNo block means no proof check; a block with no criteria fails. When the pull\nrequest has no observable acceptance criterion at all (for example a dependency\nbump or a docs-only change), type this v2 block by hand in the PR description,\nreplacing any existing proof block and filling in the explanation. A criterion\nthat only Cofactor cannot exercise gets manual evidence instead (above).\n\n<!-- cofactor:proof -->\nnone: <why this pull request has no criterion to prove>\n<!-- /cofactor:proof -->\n\nThis `none:` block reports a neutral result. The never-hand-format rule applies\nonly to criteria blocks rendered with `proofs render`; the `none:` block is\ntyped by hand.\n\nCURATING THE SUITE\n\nEvery promoted test runs from then on, so keep the suite worth running:\n   - Reuse first: attach the run of an existing test or eval that already proves\n     the criterion before creating one.\n   - Extend an existing test instead of duplicating its journey with a new one.\n   - One test per user goal, named for that goal (what the user accomplishes,\n     not the component or the ticket).\n   - Promote lasting behaviour whose regression would matter.\n   - Set a Workflow to `--promote-on never` when its proof is about the change\n     itself: a one-time migration, backfill, redirect or flag rollout step,\n     behaviour about to be removed, or a one-off visual before/after of a\n     redesign.\n   - Perf and eval runs never join a suite through proofs: a perf A/B or an\n     eval experiment for one decision stays a run. Save a perf test only for a\n     hot path (see the perf guide).\n   - Don\'t keep a test nobody would miss if it disappeared.\n\nPROOF NOTES\n\nAdd a concise `## Proof notes` section to the PR body. Explain uncertain choices\n(for example, why a Workflow was forked or created), what the evidence covers,\nand what remains uncovered, with reasons. The block rendered by `proofs render`\nis separate from this section.\n\nUse neutral example names and never include customer names, domains, or\ncredentials. A human approves Workflows by merging the pull request; do not\napprove them yourself.\n';
+
+// ../content/src/proofs-guide/index.ts
+var PROOFS_GUIDE_SECTIONS = [
+  { title: "Prove a Change with Tests", slug: "overview", content: overview_default3 }
+];
+
+// ../content/src/perf-guide/overview.txt
+var overview_default4 = "Use a perf test to compare two commits of the same Application in a sandbox:\nLighthouse for page loading, k6 for HTTP load, and server spans when the app\nexports OpenTelemetry (OTel). Choose a target metric and a goal before iterating.\n\nWRITE perf.yaml\n\n  rounds: 7\n  lighthouse:\n    formFactor: desktop\n    pages:\n      - { name: dashboard, path: /dashboard, as: admin }\n  k6:\n    script: perf/dashboard.k6.js\n    vus: 10\n    durationSeconds: 30\n    as: admin\n\n  - rounds: integer 5..15, default 7. Each arm (base or head) gets that many\n    measured rounds after a discarded warm-up: one Lighthouse load per page\n    and a 10-second k6 pass. Measured rounds alternate base/head then head/base;\n    each arm runs all Lighthouse pages before k6.\n  - Configure lighthouse, k6, or both. Omit a block to skip that flavor.\n  - lighthouse.formFactor: required desktop or mobile, with Lighthouse's stock\n    simulated throttling. pages: 1..10 entries, each with a required name and\n    path. name is 1..40 lowercase letters, digits or hyphens. path starts with\n    /, cannot start with //, and cannot contain backslashes.\n  - k6.script: required path relative to perf.yaml; the CLI inlines its contents.\n    vus: required integer 1..200. durationSeconds: required integer 10..300.\n  - as: optional persona name, per Lighthouse page or for k6. Omit for anonymous\n    access. Use a persona configured in the Application's sandbox definition.\n  - Configs whose estimated time for both arms exceeds 90 minutes are rejected;\n    reduce rounds, pages or k6 duration.\n\nWRITE THE k6 SCRIPT\n\n  Put one default function in perf/dashboard.k6.js:\n\n    import http from 'k6/http';\n\n    export default function () {\n      http.get(`${__ENV.BASE_URL}/api/projects`, {\n        headers: { Cookie: __ENV.COOKIE },\n      });\n    }\n\n  The runner supplies BASE_URL and COOKIE as environment variables, read through\n  __ENV. COOKIE contains the persona's cookie header (empty for anonymous).\n  Send it on your requests as above; setting as does not add the header to your\n  script. Load duration and VUs come from perf.yaml.\n\n  Lighthouse runs inside the sandbox against the app's PUBLIC port URL, with\n  the page persona's cookies installed in Chrome. It must finish on the requested\n  path with a 2xx document status; a login redirect fails the run. k6 uses that\n  same public sandbox base URL and sends the persona cookie through your script.\n\nENABLE SERVER SPANS (OPTIONAL)\n\n  Instrument your app with OTel and add these values to the sandbox definition's\n  top-level env: block:\n\n    env:\n      OTEL_EXPORTER_OTLP_ENDPOINT: http://127.0.0.1:4318\n      OTEL_SERVICE_NAME: acme\n      OTEL_EXPORTER_OTLP_PROTOCOL: http/protobuf\n\n  Environment variables configure an instrumented app; they do not instrument it.\n  Apps without OTel lose nothing from Lighthouse or k6: leave the endpoint\n  undeclared and the result has otel: null and no otel rows. Declaring the endpoint\n  but receiving zero spans on either arm fails the run.\n\nRUN AND READ THE VERDICT\n\n    cofactor perf run --config perf.yaml --application acme \\\n      --environment preview --base <base-sha> --head <head-sha> --org acme\n\n  --head is required. --head and --base take what `cofactor sandbox claim --at`\n  takes: for an Application built from GitHub, a full 40-character lowercase\n  commit SHA; for an Application pushed as an image, a push id or a tag (for\n  example nightly). Omit --base to compare against the environment's\n  default-branch head (GitHub) or against the ready push before --head (pushed\n  image). Omit --environment to use the Application's default environment.\n  Both arms use the same Application and environment. The CLI waits for\n  completion.\n\n  The table shows base/head medians, delta, 95% CI and verdict. Relative rows\n  compare median(head) / median(base) - 1 with a 95% bootstrap confidence interval\n  (10,000 resamples). For a gated row, slower requires the entire CI above\n  +10% (minEffect) AND the absolute median difference beyond its floor; faster\n  requires the entire CI below -10% and the same floor. Otherwise: no_change.\n  Higher requests/s is better: JSON flips its delta sign so positive means worse;\n  the printed table shows throughput gains as positive.\n\n  Gated rows and absolute floors:\n    Lighthouse LCP: 100 ms; TBT: 50 ms, per page.\n    k6 p95 latency: 5 ms; requests/s: no extra floor; error rate: 1 percentage point.\n    OTel endpoint p95: 5 ms, only with data in every measured round on both arms\n      and at least 30 spans per arm for that endpoint.\n\n  Error-rate rows (unit ratio) and rows with any zero base-round value use an\n  absolute difference instead of a ratio. Their CI must clear zero and the\n  difference must exceed the floor; the 10% minEffect does not apply. Error-rate\n  deltas print as +x.x pt (percentage points), zero-base timing deltas as +x ms;\n  their CIs use the same units. JSON deltaPct and ci95 also hold those absolute\n  units for these rows, despite the field name.\n\n  FCP, CLS, speed index, bytes, p50s and insufficiently sampled OTel endpoints\n  are reported, never gated. Ungated rows always have verdict no_change.\n  Rule: never trust a single `faster` row of an ungated metric.\n\n  The run takes the worst gated verdict: any slower wins, otherwise any faster\n  wins, otherwise no_change. The table prints SLOWER for regressions; most\n  ungated rows are omitted (use --json for all rows). A slower run with OTel\n  includes slowest head spans and new or slower spans. Incomplete measurements,\n  failed Lighthouse navigation or any k6 round above 50% errors fail the run\n  instead of producing a verdict.\n\n  Exit codes: 0 = faster or no_change; 3 = slower; 1 = failed run, timeout or error.\n  Handle exit 3 in a shell loop. --json flattens the result into run metadata:\n  id, status, verdict, baseSha, headSha, rounds, rows[], otel and tools are at the\n  top level. Each row has gated, verdict, base/head median and values, deltaPct\n  and ci95. For example, count regressions after capturing a completed run:\n\n    cofactor perf run --config perf.yaml --application acme --head <head-sha> \\\n      --org acme --json > perf-result.json\n    jq '[.rows[] | select(.gated and .verdict==\"slower\")] | length' perf-result.json\n\nSAVE A DURABLE TEST\n\n    cofactor perf save --config perf.yaml --name dashboard --application acme \\\n      --environment preview --cron \"0 9 * * 1-5\" --timezone UTC --org acme\n    cofactor perf list --org acme\n    cofactor perf get dashboard --org acme\n    cofactor perf run --test dashboard --head <head-sha> --org acme\n    cofactor perf runs dashboard --limit 20 --org acme\n    cofactor perf get <prun_id> --json --org acme\n    cofactor perf delete dashboard --org acme\n\n  A scheduled run measures the default branch head against its first parent\n  commit (GitHub), or the default-tag push head against the previous ready push\n  (pushed image), and skips a head that already has a run; \"Run now\" is never\n  skipped.\n\n  Save a GitHub test with --on-merge to run it when a pull request or merged SHA\n  reaches the repository's default branch:\n\n    cofactor perf save --config perf.yaml --name dashboard \\\n      --application ExampleApp --on-merge --org ExampleOrg\n\n  Merge runs fire only when a merge reaches the default branch and compare the\n  merge commit with its first parent. A root commit with no first parent is\n  skipped. Repeated deliveries for a test and head SHA create at most one run.\n  Upload-delivered applications cannot use --on-merge. The trigger works\n  without a proof record; proofs promotion and perf measurement are independent.\n\n  A perf run attached as proof joins nothing at merge. Save a perf test (on a\n  schedule or --on-merge) only for a hot journey or endpoint: one ongoing perf\n  test each. An A/B for one change stays an ad hoc run.\n\n  save replaces the saved config, schedule, and on-merge marker by name. Omit\n  --on-merge to clear that marker. Without timing flags and --on-merge, the test\n  is manual. For a schedule, supply exactly one timing flag: --schedule \"every weekday at 9am\",\n  --cron \"0 9 * * 1-5\", --at 09:00, or --every 2h. --timezone defaults to UTC.\n  --test uses the saved Application, environment and inlined script; do not pass\n  --application or --environment with it. get accepts a test name, ptest_ id or\n  prun_ id. runs lists newest first (--limit 1..100, default 20). delete removes\n  the saved test, its automation rules and its runs.\n\n  Open the Performance page (/performance) to browse saved tests and recent\n  ad hoc runs, inspect a test's history and metric confidence intervals, or open\n  a run's verdict table, tool versions and server spans for both arms.\n\nTHE hill-climb LOOP\n\n  0. Every new SHA or push needs a snapshot and a perf layer before its sandboxes are\n     ready. Builds take minutes (up to 90), so batch changes per iteration.\n  1. Run once on the unchanged branch. If the verdict surprises you, do an A/A\n     sanity check: set --base and --head to the same full SHA.\n  2. Read the worst gated row. If otel is present, inspect its endpoint rows and\n     slow spans (otel.topSlowSpans.base/head in --json).\n  3. Change code, commit and push.\n  4. Measure the new commit, keeping the same base for the comparison:\n       cofactor perf run --config perf.yaml --application acme \\\n         --base <base-sha> --head <new-sha> --org acme\n  5. Keep the commit if faster, or no_change with a better target median. Revert\n     it if slower. Lower latency is better; higher requests/s is better.\n  6. Stop when no gated row is slower and the target row is under its goal.\n\nREFERENCE\n\n  - Current flags: `cofactor perf --help`\n  - Sandbox definitions and personas: `cofactor sandbox guide v2`\n";
+
+// ../content/src/perf-guide/index.ts
+var PERF_GUIDE_SECTIONS = [
+  { title: "Performance Tests", slug: "overview", content: overview_default4 }
+];
+
 // ../content/src/session-guide/start.txt
 var start_default = 'Drive a real browser from the CLI to explore or verify a web app. You work\nthrough snapshots (an accessibility tree plus a screenshot) and issue commands\nagainst element refs.\n\nSTART A SESSION\n\n  cofactor session start --url https://app.example.com\n  cofactor session start --credential                       (interactive picker)\n  cofactor session start --credential "Admin User" --url https://app.example.com\n  cofactor session start --storage-state ./auth.json --url <url>\n  cofactor session start --headless --url <url>\n\n  Credentials belong to an application and carry saved login state, so a\n  session started with --credential is already signed in. Load one into a\n  running session with `cofactor session load-credential`.\n\n  Credentials only work for the deployed app they were saved against. Their\n  cookies are bound to that domain. For localhost or 127.0.0.1, start without\n  --credential, ask the user to sign in in the browser window, and wait for\n  them to confirm before continuing (or pass --storage-state with a local file).\n\nMANAGE SESSIONS\n\n  cofactor session list\n  cofactor session status\n  cofactor session stop            (or: stop --all)\n  cofactor session snapshot --session s1     (target one when several exist)\n\n  Always stop sessions you started when you finish.\n\nTHE LOOP\n\n  snapshot -> read -> act -> snapshot -> verify\n  Never assume an action worked; look at the page afterwards.\n  Run `cofactor session --help` for the full command list.\n';
 
@@ -1940,6 +1956,8 @@ export {
   SANDBOX_GUIDE_SECTIONS,
   EXTERNAL_RUN_GUIDE_SECTIONS,
   ISSUES_GUIDE_SECTIONS,
+  PROOFS_GUIDE_SECTIONS,
+  PERF_GUIDE_SECTIONS,
   SESSION_GUIDE_SECTIONS,
   command,
   packageName,
@@ -1958,4 +1976,4 @@ export {
   shouldBrandConsoleOutput,
   installConsoleBranding
 };
-//# sourceMappingURL=chunk-UEJ2HTKU.js.map
+//# sourceMappingURL=chunk-MJVUMVLO.js.map