pi-ui-extend 1.0.40 → 1.0.42

package/schemas/pix.json

@@ -308,6 +308,30 @@
         }
       },
       "description": "Voice dictation (Vosk) configuration."
+    },
+    "desktop": {
+      "type": "object",
+      "properties": {
+        "externalEditor": {
+          "type": "string",
+          "description": "External editor used by Pix Desktop project explorer. Known aliases include zed, code/vscode, cursor, subl/sublime, idea/intellij, and webstorm; an executable path/name is also accepted."
+        },
+        "git": {
+          "type": "object",
+          "properties": {
+            "reviewModelRef": {
+              "type": "string",
+              "description": "Model reference used by Pix Desktop for LLM review of Git diffs, optionally with a :thinking suffix."
+            },
+            "commitMessageModelRef": {
+              "type": "string",
+              "description": "Model reference used by Pix Desktop to generate Git commit messages, optionally with a :thinking suffix."
+            }
+          },
+          "description": "Pix Desktop Git/Source Control LLM preferences."
+        }
+      },
+      "description": "Pix Desktop-specific preferences."
     }
   },
   "$id": "https://unpkg.com/pi-ui-extend/schemas/pix.json",

package/schemas/tasks.json

@@ -0,0 +1,132 @@
+{
+  "type": "object",
+  "required": [
+    "version",
+    "tasks"
+  ],
+  "properties": {
+    "$schema": {
+      "type": "string",
+      "description": "JSON Schema URL used by editors for validation and autocomplete."
+    },
+    "version": {
+      "type": "number",
+      "const": 1,
+      "description": "Task document format version."
+    },
+    "tasks": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "required": [
+          "id",
+          "title",
+          "type",
+          "status",
+          "priority",
+          "createdAt",
+          "updatedAt"
+        ],
+        "properties": {
+          "id": {
+            "type": "string",
+            "minLength": 1,
+            "maxLength": 128,
+            "description": "Stable unique task id."
+          },
+          "title": {
+            "type": "string",
+            "minLength": 1,
+            "maxLength": 200,
+            "description": "Short task title."
+          },
+          "description": {
+            "type": "string",
+            "maxLength": 10000,
+            "description": "Optional detailed task description."
+          },
+          "type": {
+            "anyOf": [
+              {
+                "type": "string",
+                "const": "bug"
+              },
+              {
+                "type": "string",
+                "const": "feature"
+              },
+              {
+                "type": "string",
+                "const": "improvement"
+              }
+            ]
+          },
+          "status": {
+            "anyOf": [
+              {
+                "type": "string",
+                "const": "backlog"
+              },
+              {
+                "type": "string",
+                "const": "todo"
+              },
+              {
+                "type": "string",
+                "const": "in-progress"
+              },
+              {
+                "type": "string",
+                "const": "done"
+              }
+            ]
+          },
+          "priority": {
+            "anyOf": [
+              {
+                "type": "string",
+                "const": "low"
+              },
+              {
+                "type": "string",
+                "const": "medium"
+              },
+              {
+                "type": "string",
+                "const": "high"
+              },
+              {
+                "type": "string",
+                "const": "urgent"
+              }
+            ]
+          },
+          "sessionId": {
+            "type": "string",
+            "minLength": 1,
+            "maxLength": 512,
+            "description": "Optional Pi session associated with this task."
+          },
+          "createdAt": {
+            "type": "string",
+            "format": "date-time",
+            "description": "RFC 3339 creation timestamp."
+          },
+          "updatedAt": {
+            "type": "string",
+            "format": "date-time",
+            "description": "RFC 3339 last-update timestamp."
+          }
+        },
+        "additionalProperties": false
+      },
+      "maxItems": 10000,
+      "description": "Project tasks. Task ids must be unique."
+    }
+  },
+  "$id": "https://unpkg.com/pi-ui-extend/schemas/tasks.json",
+  "$schema": "https://json-schema.org/draft-07/schema#",
+  "title": "Pix Project Tasks",
+  "description": "Project-scoped task document stored in <cwd>/.pi/tasks.jsonc.",
+  "additionalProperties": false
+}

package/skills/spec-wiki/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: spec-wiki
+description: >-
+  Use this skill for behavior-changing project work or behavioral specs/contracts:
+  write/verify as-is/change behavior from code/tests, find requirements, detect
+  spec-code drift/impact, or maintain a spec wiki. Skip mechanical/refactor/
+  debug-only changes and code-only impact with no contract/doc work. Not for
+  runbooks or general docs.
+---
+
+# Spec Wiki
+
+Primary specs are the source of truth. `.spec-wiki/` is only derived navigation
+and freshness metadata. Specs may live anywhere and use any structure.
+
+## Router
+
+Choose one mode. Read only the referenced file unless the task expands.
+
+- One spec: create/update/check/verify → `references/focused-spec.md`.
+- Find/answer from specs → `references/query.md`.
+- First discovery/index build → `references/bootstrap.md`.
+- Refresh/audit/impact/repair → `references/maintenance.md`.
+- Exact CLI/state/config details → `references/index-schema.md`.
+
+Do not bootstrap or scan the whole repository for a narrow single-spec task.
+Do not load all specs when the wiki can narrow retrieval.
+
+## Invariants
+
+- Never invent spec behavior; separate code/tests/docs evidence from inference.
+- Distinguish current (`as-is`) from intended (`change`) behavior.
+- Never treat generated indexes, overviews, catalogs, or TOCs as primary specs.
+- Keep document lifecycle separate from spec type: active/proposed/historical/
+  superseded is not the same question as as-is/change.
+- Never infer semantic correctness from hashes alone. Changed inputs require
+  verification, not automatic rewriting.
+- After a material production-behavior change, run the post-change checkpoint in
+  `references/maintenance.md` before declaring the task complete.
+- Do not force specs into a new layout or template.
+- Do not change production code unless the user asked for implementation.
+
+## Bundled CLI
+
+When wiki state is involved, use:
+
+```bash
+python3 <SKILL_DIR>/scripts/spec_wiki.py --root <PROJECT_ROOT> <command>
+```
+
+Commands: `discover`, `record`, `verify`, `relate`, `search`, `changes`, `impact`,
+`remove`, `status`, `audit`, `affected`, `render`, `validate`.
+
+The CLI owns deterministic discovery, relationships, hashes, state, and
+rendering. The agent owns semantic classification and verification.

package/skills/spec-wiki/evals/evals.json

@@ -0,0 +1,132 @@
+{
+  "skill_name": "spec-wiki",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We are going to change the session refresh contract in the supplied fixture: a transient token-load failure should be retried exactly once, while a second failure must still propagate. Before implementation, inspect the fixture code and tests and write a compact change spec named session-refresh-spec.md in the run output directory. Do not modify production code and do not bootstrap a repository-wide spec wiki for this narrow task.",
+      "expected_output": "A focused Change spec grounded in the fixture's current code/tests, with intended retry behavior, edge cases, verification, evidence/unknowns, and no production-code or wiki-state mutation.",
+      "files": [
+        "evals/files/focused/src/session.ts",
+        "evals/files/focused/tests/session.test.ts"
+      ],
+      "expectations": [
+        "The output contains a spec explicitly identified as Change/intended behavior.",
+        "The spec states that current fixture behavior performs one token-load attempt with no retry.",
+        "The intended behavior retries a transient token-load failure exactly once and propagates a second failure.",
+        "The spec contains a concrete verification path covering success, retry-success, and retry-failure behavior.",
+        "The spec explicitly distinguishes confirmed code/test evidence from inference or unknowns instead of presenting every claim at the same confidence level.",
+        "The run does not modify fixture production code and does not create .spec-wiki state for this narrow task.",
+        "The with-skill run reads focused-spec.md and does not read bootstrap.md, maintenance.md, query.md, or index-schema.md unless the task actually expands to need them."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "In the supplied fixture, answer this narrowly from the project's primary specifications: what are the cancellation semantics for background jobs, and which primary spec defines them? There is also an overview and a retry document nearby. Do not build a wiki and do not treat an overview/index summary as primary evidence. Include source paths in the answer.",
+      "expected_output": "A concise answer grounded in the cancellation primary spec, distinguishing it from the overview and unrelated retry spec, without creating wiki state.",
+      "files": [
+        "evals/files/query/docs/spec-overview.md",
+        "evals/files/query/features/jobs/cancellation-contract.md",
+        "evals/files/query/features/jobs/retry-spec.md",
+        "evals/files/query/docs/how-to-run-jobs.md"
+      ],
+      "expectations": [
+        "The answer identifies features/jobs/cancellation-contract.md as the primary source.",
+        "The answer states that cancellation is idempotent, running jobs become cancelled, and already terminal jobs remain terminal.",
+        "The overview is not cited as primary evidence for the behavior claim.",
+        "The run does not create .spec-wiki state or perform repository-wide bootstrap.",
+        "The with-skill run reads query.md and does not read bootstrap.md or maintenance.md unless the task actually expands to need them."
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Bootstrap a Spec Wiki for the supplied standalone fixture. Its specification knowledge is intentionally scattered across different folders and formats, and docs/overview.md is only a hand-written catalog. Build the wiki under the fixture root, classify the useful documents, exclude the catalog and user guide from primary specs, and report what was indexed. Do not edit any primary source document.",
+      "expected_output": "A schema-v2 .spec-wiki index/state containing the payment requirements and RFC as primary spec knowledge, with lifecycle recorded, overview classified as meta-index, guide excluded from primary specs, and bootstrap entries left unverified until a separate semantic code/test review; primary sources remain unchanged.",
+      "files": [
+        "evals/files/bootstrap/requirements/payment-behavior.md",
+        "evals/files/bootstrap/architecture/rfc-007.md",
+        "evals/files/bootstrap/docs/overview.md",
+        "evals/files/bootstrap/docs/how-to-pay.md",
+        "evals/files/bootstrap/src/payments.ts",
+        "evals/files/bootstrap/tests/payments.test.ts"
+      ],
+      "expectations": [
+        "The generated wiki indexes requirements/payment-behavior.md as primary spec knowledge.",
+        "The generated wiki indexes architecture/rfc-007.md as primary spec knowledge despite the different directory/convention.",
+        "docs/overview.md is classified as meta-index or otherwise excluded from primary specs.",
+        "docs/how-to-pay.md is classified as guide/other or otherwise excluded from primary specs.",
+        "Production source and test files are treated as evidence/relationships, not as primary specification documents themselves.",
+        "Bootstrap classification does not create a semantic verification baseline: newly indexed primary specs are unverified rather than fresh.",
+        "Primary entries record lifecycle separately from as-is/change type, so current requirements and an intended RFC are not forced into the same precedence state.",
+        "The generated state uses schemaVersion 2 and the generated index is a compact routing projection rather than the primary source of detailed claims.",
+        "The generated index is derived navigation and primary source documents are not modified.",
+        "The with-skill run reads bootstrap.md; it reads index-schema.md only if exact CLI/state details are needed and does not read focused-spec.md/query.md/maintenance.md without a concrete need."
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Maintenance scenario: initialize the supplied fixture as a Git repo and commit only docs/session-refresh.md and src/session.ts as the baseline; keep incoming/refresh-worker.ts outside that baseline. Build the minimal Spec Wiki entry for the existing active as-is session refresh contract and semantically verify it. Then move incoming/refresh-worker.ts to src/refresh-worker.ts as the only post-baseline production change. Run the required post-change maintenance checkpoint. The new worker implements the same background refresh retry contract but is not yet in the spec's tracked relations. Do not change behavioral claims unless evidence shows drift. Finish with a valid rendered wiki and report the impact/repair steps.",
+      "expected_output": "The maintenance workflow notices that the new worker has no known relation, semantically associates it with the existing session refresh spec despite an initially empty direct affected result for that path, repairs the durable relation, verifies the unchanged contract against both implementation surfaces, and ends fresh.",
+      "files": [
+        "evals/files/maintenance/new-relation/docs/session-refresh.md",
+        "evals/files/maintenance/new-relation/src/session.ts",
+        "evals/files/maintenance/new-relation/incoming/refresh-worker.ts"
+      ],
+      "expectations": [
+        "The post-change workflow runs impact or equivalent task-scoped coverage analysis and treats src/refresh-worker.ts as an uncovered changed path before relation repair.",
+        "The workflow performs semantic spec retrieval/inspection even though the new path has no pre-existing affected relation.",
+        "The final primary entry for docs/session-refresh.md tracks src/refresh-worker.ts as a durable implementation relation.",
+        "The behavioral retry contract is not rewritten merely because a new implementation file appeared; it remains exactly-once retry with second failure propagation.",
+        "After relation repair the old verification baseline is not trusted until verify is run again.",
+        "Final status reports the current session refresh spec fresh with no unresolved relation drift."
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Maintenance scenario: initialize the supplied fixture as Git, commit docs/old-job-contract.md and src/job.ts, record that document as an active as-is primary spec, and verify it. Then perform `git mv docs/old-job-contract.md contracts/job-cancellation.md` without changing its behavior. Run Spec Wiki maintenance for the move. Preserve the contract's lifecycle/type/summary/implementation relation, and do not leave duplicate current entries.",
+      "expected_output": "The move is recognized as an old missing tracked source plus a new document candidate; the new path is recorded and verified before the old metadata is removed, leaving one fresh active primary spec at the new path.",
+      "files": [
+        "evals/files/maintenance/move/docs/old-job-contract.md",
+        "evals/files/maintenance/move/src/job.ts"
+      ],
+      "expectations": [
+        "Impact/change inspection recognizes the old tracked primary path as missing/moved and the new path as a document requiring classification.",
+        "contracts/job-cancellation.md becomes the active as-is primary entry with the src/job.ts relation preserved.",
+        "The new path is verified before or as part of completing the move workflow.",
+        "docs/old-job-contract.md metadata is removed only after the new source has been recorded.",
+        "Final state contains no duplicate current primary entry for the old path and validates cleanly."
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "Maintenance scenario: initialize Git and commit only src/capture.ts as the baseline. Keep incoming/capture.txt outside the baseline, then move it to notes/capture.txt as a new document in the current task. Run the Spec Wiki post-change maintenance checkpoint. The text file intentionally has a neutral filename, no headings, and no path hints; only its contents state the current idempotency contract. Do not discard it because of a zero/below-threshold heuristic score. Inspect implementation evidence to determine the durable relation.",
+      "expected_output": "The changed-document path is inspected regardless of score, semantically classified as a current primary spec, related to src/capture.ts, verified, rendered, and validated.",
+      "files": [
+        "evals/files/maintenance/low-signal/src/capture.ts",
+        "evals/files/maintenance/low-signal/incoming/capture.txt"
+      ],
+      "expectations": [
+        "The new notes/capture.txt is surfaced for classification even though its discovery score is zero or below the normal threshold.",
+        "The document is classified from its contents rather than its location/name and becomes an as-is active primary spec.",
+        "The primary entry tracks src/capture.ts and has a non-empty semantic summary/topic metadata.",
+        "The entry is verified only after inspecting the implementation evidence, then the wiki renders/validates cleanly."
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "Negative maintenance control: initialize Git and commit docs/auth-contract.md plus src/auth.ts. Record/verify the active auth spec. Then move incoming/telemetry-format.ts to src/telemetry-format.ts as the only new production file. Run the post-change checkpoint. The telemetry formatting helper is unrelated to authentication. Perform the mandatory uncovered-path semantic sweep, but do not invent a spec relation or modify the auth contract just to make coverage non-empty.",
+      "expected_output": "The new telemetry path is reported as uncovered, the semantic sweep explicitly concludes it does not affect the auth contract, no false relation/spec edit is introduced, and the existing auth spec remains valid/fresh.",
+      "files": [
+        "evals/files/maintenance/no-impact/docs/auth-contract.md",
+        "evals/files/maintenance/no-impact/src/auth.ts",
+        "evals/files/maintenance/no-impact/incoming/telemetry-format.ts"
+      ],
+      "expectations": [
+        "The workflow does not stop at an empty affected result; it semantically inspects the uncovered telemetry path.",
+        "No inferred relation from docs/auth-contract.md to src/telemetry-format.ts is added.",
+        "The auth spec's behavioral claims are not modified.",
+        "The final report records a semantic no-impact decision rather than pretending every changed path must belong to a spec.",
+        "The existing auth spec remains fresh and state validates cleanly."
+      ]
+    }
+  ]
+}

package/skills/spec-wiki/evals/files/bootstrap/architecture/rfc-007.md

@@ -0,0 +1,14 @@
+# RFC 007 — Payment timeout contract
+
+## Goal
+
+Define the intended timeout contract for payment capture.
+
+## Behavior
+
+Capture requests should time out after 10 seconds and return a retryable timeout
+error without claiming that the payment failed at the provider.
+
+## Non-goals
+
+This document does not define provider reconciliation.

package/skills/spec-wiki/evals/files/bootstrap/docs/how-to-pay.md

@@ -0,0 +1,4 @@
+# How to run a payment test
+
+Run the development server, open the sandbox checkout page, enter the test card,
+and inspect the local logs. This page is an operator/developer guide.

package/skills/spec-wiki/evals/files/bootstrap/docs/overview.md

@@ -0,0 +1,9 @@
+# Payment docs index
+
+This catalog links the current payment documents:
+
+- [Requirements](../requirements/payment-behavior.md)
+- [Timeout RFC](../architecture/rfc-007.md)
+- [How-to](./how-to-pay.md)
+
+Use the linked primary documents for actual behavior.

package/skills/spec-wiki/evals/files/bootstrap/requirements/payment-behavior.md

@@ -0,0 +1,17 @@
+# Payment capture requirements
+
+## Behavior
+
+- A capture request with the same idempotency key must not charge twice.
+- A successful capture returns the existing capture result when the same key is
+  replayed.
+- A different amount with a reused idempotency key is rejected.
+
+## Related files
+
+- `src/payments.ts`
+- `tests/payments.test.ts`
+
+## Verification
+
+Cover first capture, exact replay, and conflicting replay.

package/skills/spec-wiki/evals/files/bootstrap/src/payments.ts

@@ -0,0 +1,12 @@
+const captures = new Map<string, { amount: number; id: string }>();
+
+export function capture(key: string, amount: number): { amount: number; id: string } {
+  const existing = captures.get(key);
+  if (existing) {
+    if (existing.amount !== amount) throw new Error("idempotency conflict");
+    return existing;
+  }
+  const result = { amount, id: `capture-${captures.size + 1}` };
+  captures.set(key, result);
+  return result;
+}

package/skills/spec-wiki/evals/files/bootstrap/tests/payments.test.ts

@@ -0,0 +1,11 @@
+// @ts-nocheck
+import assert from "node:assert/strict";
+import { test } from "node:test";
+
+import { capture } from "../src/payments.js";
+
+test("idempotent replay returns the same capture", () => {
+  const first = capture("key-1", 100);
+  assert.deepEqual(capture("key-1", 100), first);
+  assert.throws(() => capture("key-1", 200), /idempotency conflict/);
+});

package/skills/spec-wiki/evals/files/focused/src/session.ts

@@ -0,0 +1,5 @@
+export type TokenLoader = () => Promise<string>;
+
+export async function refreshSession(loadToken: TokenLoader): Promise<string> {
+  return loadToken();
+}

package/skills/spec-wiki/evals/files/focused/tests/session.test.ts

@@ -0,0 +1,17 @@
+// @ts-nocheck
+import assert from "node:assert/strict";
+import { test } from "node:test";
+
+import { refreshSession } from "../src/session.js";
+
+test("refreshSession performs one token-load attempt", async () => {
+  let attempts = 0;
+  await assert.rejects(
+    refreshSession(async () => {
+      attempts += 1;
+      throw new Error("transient");
+    }),
+    /transient/,
+  );
+  assert.equal(attempts, 1);
+});

package/skills/spec-wiki/evals/files/maintenance/low-signal/incoming/capture.txt

@@ -0,0 +1,2 @@
+Duplicate capture requests with the same idempotency key return the original result.
+This rule describes current production behavior for capture requests.

package/skills/spec-wiki/evals/files/maintenance/low-signal/src/capture.ts

@@ -0,0 +1,3 @@
+export function capture(idempotencyKey: string, previous?: string): string {
+  return previous ?? `capture:${idempotencyKey}`;
+}

package/skills/spec-wiki/evals/files/maintenance/move/docs/old-job-contract.md

@@ -0,0 +1,18 @@
+# Background job cancellation contract
+
+## Type
+
+As-is
+
+## Lifecycle
+
+Active
+
+## Behavior
+
+Cancelling a running job is idempotent. Running jobs become cancelled; already
+terminal jobs remain terminal.
+
+## Related files
+
+- `src/job.ts`

package/skills/spec-wiki/evals/files/maintenance/move/src/job.ts

@@ -0,0 +1,5 @@
+export type JobState = "running" | "done" | "failed" | "cancelled";
+
+export function cancelJob(state: JobState): JobState {
+  return state === "running" ? "cancelled" : state;
+}

package/skills/spec-wiki/evals/files/maintenance/new-relation/docs/session-refresh.md

@@ -0,0 +1,24 @@
+# Session refresh contract
+
+## Type
+
+As-is
+
+## Lifecycle
+
+Active
+
+## Behavior
+
+Interactive and background session refresh retry a transient token-acquisition
+failure exactly once. A second token-acquisition failure propagates to the
+caller. Successful acquisition is not retried.
+
+## Related files
+
+- `src/session.ts`
+
+## Verification
+
+- Interactive refresh covers success, retry-success, and second-failure paths.
+- Every additional refresh entrypoint must preserve the same retry contract.

package/skills/spec-wiki/evals/files/maintenance/new-relation/incoming/refresh-worker.ts

@@ -0,0 +1,7 @@
+export async function refreshInBackground(loadToken: () => Promise<string>): Promise<string> {
+  try {
+    return await loadToken();
+  } catch {
+    return await loadToken();
+  }
+}

package/skills/spec-wiki/evals/files/maintenance/new-relation/src/session.ts

@@ -0,0 +1,7 @@
+export async function refreshSession(loadToken: () => Promise<string>): Promise<string> {
+  try {
+    return await loadToken();
+  } catch {
+    return await loadToken();
+  }
+}

package/skills/spec-wiki/evals/files/maintenance/no-impact/docs/auth-contract.md

@@ -0,0 +1,17 @@
+# Authentication contract
+
+## Type
+
+As-is
+
+## Lifecycle
+
+Active
+
+## Behavior
+
+Authentication accepts a valid token and rejects an empty token.
+
+## Related files
+
+- `src/auth.ts`

package/skills/spec-wiki/evals/files/maintenance/no-impact/incoming/telemetry-format.ts

@@ -0,0 +1,3 @@
+export function formatTelemetryName(name: string): string {
+  return name.trim().toLowerCase();
+}

package/skills/spec-wiki/evals/files/maintenance/no-impact/src/auth.ts

@@ -0,0 +1,3 @@
+export function authenticate(token: string): boolean {
+  return token.length > 0;
+}

package/skills/spec-wiki/evals/files/query/docs/how-to-run-jobs.md

@@ -0,0 +1,4 @@
+# How to run jobs locally
+
+Start the worker, enqueue a sample job, and tail the development log. This is a
+usage guide and does not define cancellation semantics.

package/skills/spec-wiki/evals/files/query/docs/spec-overview.md

@@ -0,0 +1,9 @@
+# Job specifications overview
+
+The primary job behavior documents are linked below.
+
+- [Cancellation contract](../features/jobs/cancellation-contract.md) — jobs can
+  be stopped safely.
+- [Retry spec](../features/jobs/retry-spec.md) — retry timing and limits.
+
+This page is a catalog, not a behavioral source of truth.

package/skills/spec-wiki/evals/files/query/features/jobs/cancellation-contract.md

@@ -0,0 +1,15 @@
+# Background job cancellation contract
+
+## Behavior
+
+- Cancellation requests are idempotent.
+- A running job transitions to `cancelled` when cancellation is accepted.
+- Jobs already in `completed`, `failed`, or `cancelled` remain in that terminal
+  state when cancellation is requested again.
+- Cancellation does not imply that already-committed external side effects are
+  rolled back.
+
+## Verification
+
+Tests should cover repeated cancellation, running-to-cancelled transition, and
+all terminal states.

package/skills/spec-wiki/evals/files/query/features/jobs/retry-spec.md

@@ -0,0 +1,6 @@
+# Background job retry behavior
+
+## Behavior
+
+Failed jobs retry at most three times with exponential backoff. Cancellation is
+outside this document's scope.