specpi 0.10.0 → 0.11.2

package/scripts/specpi.mjs

@@ -729,7 +729,18 @@ function validManagedModelScope(value) {
 }
 
 function desiredSettingsOperations() {
-    return [{ path: ["theme"], value: "specpi-spec" }];
+    return [
+        {
+            path: ["theme"],
+            value: "specpi-spec",
+            userTunable: true,
+            validate: (value) =>
+                typeof value === "string" &&
+                value.trim().length > 0 &&
+                value.length <= 128 &&
+                !/[\u0000-\u001f\u007f]/u.test(value),
+        },
+    ];
 }
 
 function managedFiles(includeShell) {
@@ -755,6 +766,11 @@ function managedFiles(includeShell) {
             path.join(agentDir, "extensions", "workflow-controls", "scope.mjs"),
             0o644,
         ],
+        [
+            path.join(repoRoot, "extensions", "workflow-controls", "task-contract.mjs"),
+            path.join(agentDir, "extensions", "workflow-controls", "task-contract.mjs"),
+            0o644,
+        ],
         [
             path.join(repoRoot, "extensions", "workflow-controls", "experiments.mjs"),
             path.join(agentDir, "extensions", "workflow-controls", "experiments.mjs"),
@@ -805,6 +821,11 @@ function managedFiles(includeShell) {
             path.join(agentDir, "extensions", "tool-wishlist", "core.mjs"),
             0o644,
         ],
+        [
+            path.join(repoRoot, "extensions", "tool-wishlist", "verification.mjs"),
+            path.join(agentDir, "extensions", "tool-wishlist", "verification.mjs"),
+            0o644,
+        ],
         [
             path.join(repoRoot, "extensions", "tool-wishlist", "registry.mjs"),
             path.join(agentDir, "extensions", "tool-wishlist", "registry.mjs"),
@@ -1091,6 +1112,7 @@ function assertSources() {
         "extensions/ui-refresh/index.ts",
         "extensions/workflow-controls/index.ts",
         "extensions/workflow-controls/scope.mjs",
+        "extensions/workflow-controls/task-contract.mjs",
         "extensions/workflow-controls/experiments.mjs",
         "extensions/workflow-controls/challenge.mjs",
         "extensions/workflow-controls/smoke.mjs",
@@ -1103,6 +1125,7 @@ function assertSources() {
         "browser-runtime/package-lock.json",
         "extensions/tool-wishlist/index.ts",
         "extensions/tool-wishlist/core.mjs",
+        "extensions/tool-wishlist/verification.mjs",
         "extensions/tool-wishlist/registry.mjs",
         "extensions/tool-wishlist/validators.mjs",
         "extensions/tool-wishlist/capabilities.json",
@@ -1151,7 +1174,7 @@ Managed files:`);
     console.log(`  ${manifestPath}`);
 
     console.log("\nSettings ownership:");
-    console.log("  theme = specpi-spec");
+    console.log("  theme defaults to specpi-spec; existing valid user choices are preserved");
     console.log("  pinned package entries (merged by npm package identity)");
     console.log("  command-guard mode and approvals are session-only and no raw commands are persisted");
     console.log("  scope and completion state stays in the active Pi session branch without raw tool content");
@@ -1161,6 +1184,12 @@ Managed files:`);
     console.log("  collection requires one explicit local on/off decision and never uploads data");
     console.log("  wishlist lifecycle decisions are explicit, append-only, and reversible");
     console.log("  isolated browser contexts never reuse the user's Chrome profile or cookies");
+    console.log("\nPrivacy boundaries:");
+    console.log("  SpecPi keeps its wishlist and improvement evidence local; this does not make Pi offline");
+    console.log(
+        "  model requests go to the selected provider; browser pages and installed packages may use the network",
+    );
+    console.log("  Pi controls its own telemetry and update checks; review Pi settings separately");
 
     console.log("\nManaged browser runtime:");
     if (options.skipBrowserInstall) {

package/skills/specpi-improve/SKILL.md

@@ -1,54 +1,60 @@
----
-name: specpi-improve
-description: Turns a selected SpecPi capability-gap wishlist item into a minimal, evidence-backed, reversible improvement. Use when the user asks to improve SpecPi from its wishlist, act on a selected gap, or complete the notice-to-retire loop.
----
-
-# SpecPi Improve
-
-Improve the harness through an explicit experiment, never through quiet self-modification.
-
-## Preconditions
-
-1. Begin through `/harness-improvement`. Its menu exposes qualified and review-needed items, records the chosen item as selected, and starts this workflow.
-2. Treat that exact menu choice as approval for the smallest sufficient implementation of that item. Ask again only if scope expands or external/remote state would change.
-3. Treat wishlist summaries as leads, not proof. Inspect the current repository, tools, docs, tests, and runtime behavior before designing a change.
-4. Do not inspect Pi credentials, trust decisions, sessions, history, missions, or unrelated private state.
-
-## Improvement card
-
-Before editing, present one compact card:
-
-- **Gap ID and evidence:** occurrences, reach, impact, and representative sanitized needs.
-- **Smallest intervention:** choose among bug fix, config, prompt, skill, or tool; prefer the least powerful sufficient option.
-- **Hypothesis:** what friction the change should remove.
-- **Acceptance check:** direct behavior that proves the capability works.
-- **Rollback:** how the change can be removed or reverted cleanly.
-- **Privacy/security:** state what new data, permissions, dependencies, or external state would be introduced; prefer none.
-- **Non-goals:** reject adjacent feature accumulation.
-
-The `/harness-improvement` selection authorizes this exact smallest-sufficient card. Do not add another approval step unless the proposed work exceeds it.
-
-## Implementation
-
-1. Preserve a single writer for the active worktree.
-2. Implement the smallest coherent intervention.
-3. Add focused tests that reproduce the gap and prove the new behavior.
-4. Update the reviewed capability registry only when the capability is actually shipped. Use exact aliases; do not hide adjacent unsupported cases.
-5. Link deterministic capabilities to an existing or new `specpi doctor` check.
-6. Update README, security documentation, changelog, third-party notices, and installer source lists only where the change requires it.
-7. Keep installation explicit, reversible, backed up, atomic, and checksum-tracked.
-8. If the user chooses to commit the improvement, include a `SpecPi-Gap: <gap-id>` trailer so the commit can be linked to its retirement in the journal. SpecPi itself never commits.
-
-## Verification and retirement
-
-1. Run the narrowest focused checks, then `npm run check`.
-2. For installer changes, exercise plan/install/doctor/update/uninstall with a temporary `PI_CODING_AGENT_DIR`; never use the live Pi directory.
-3. Inspect the final diff and obtain fresh read-only review when risk warrants it.
-4. At the end, call `finish_harness_improvement` with the exact gap ID, concise direct acceptance evidence, and a sanitized validation note. The tool independently requires source-registry integration, runs `npm run check`, executes every capability validator through the closed validators catalog, persists that proof into the local improvement journal, and retires only if every gate passes.
-5. If validation fails, fix or revert. Do not retire on plausibility; leave the item selected and report the blocker.
-6. A later regression returns the retired item to the `/harness-improvement` menu. Choosing it there explicitly reopens and selects it for review.
-7. When a retired item reopens, start from `/wishlist history <gap-id>`: the journal supplies the original proof and the changed-file set of the original change. Propose an explicit revert plan for human approval; never revert autonomously.
-
-## Handoff
-
-Report the gap ID, changed files, acceptance evidence, commands and exit codes, lifecycle action, rollback path, and residual risks. Never claim that silence or the absence of later reports proves success.
+---
+name: specpi-improve
+description: Turns a selected SpecPi capability-gap wishlist item into a minimal, evidence-backed, reversible improvement. Use when the user asks to improve SpecPi from its wishlist, act on a selected gap, or complete the notice-to-retire loop.
+---
+
+# SpecPi Improve
+
+Improve the harness through an explicit experiment, never through quiet self-modification.
+
+## Preconditions
+
+1. Begin through `/harness-improvement`. Its menu exposes qualified and review-needed items, records the chosen item as selected, and starts this workflow.
+2. Treat that exact menu choice as approval for the smallest sufficient implementation of that item. Ask again only if scope expands or external/remote state would change.
+3. Treat wishlist summaries as leads, not proof. Inspect the current repository, tools, docs, tests, and runtime behavior before designing a change.
+4. Do not inspect Pi credentials, trust decisions, sessions, history, missions, or unrelated private state.
+
+## Improvement card
+
+Before editing, present one compact card:
+
+- **Gap ID and evidence:** occurrences, reach, impact, and representative sanitized needs.
+- **Smallest intervention:** choose among bug fix, config, prompt, skill, or tool; prefer the least powerful sufficient option.
+- **Hypothesis:** what friction the change should remove.
+- **Acceptance check:** direct behavior that proves the capability works.
+- **Rollback:** how the change can be removed or reverted cleanly.
+- **Privacy/security:** state what new data, permissions, dependencies, or external state would be introduced; prefer none.
+- **Non-goals:** reject adjacent feature accumulation.
+
+The `/harness-improvement` selection authorizes this exact smallest-sufficient card. Do not add another approval step unless the proposed work exceeds it.
+
+Record the card with `record_harness_contract` before editing. Include stable requirement IDs and direct acceptance checks, and declare the expected source paths. The tool binds the card to the selected gap, selection generation, session, and source checkout. An identical retry is allowed; a changed card requires the human to revise it with `/task set` or select the improvement again. Never use a new card to manufacture authorization for another gap. `/scope task` is the human command for importing its paths into scope monitoring.
+
+The selection preserves verification policy, including task/scope and wishlist lifecycle rules, the package check, and formatter configuration. If the work changes those rules, obtain human review of that concrete policy change and a fresh `/harness-improvement` selection before using it to retire the item. Do not weaken or bypass preserved gates to make a change pass.
+
+## Implementation
+
+1. Preserve a single writer for the active worktree.
+2. Implement the smallest coherent intervention.
+3. Add focused tests that reproduce the gap and prove the new behavior.
+4. Update the reviewed capability registry only when the capability is actually shipped. Use exact aliases; do not hide adjacent unsupported cases.
+5. Link deterministic capabilities to an existing or new `specpi doctor` check.
+6. Update README, security documentation, changelog, third-party notices, and installer source lists only where the change requires it.
+7. Keep installation explicit, reversible, backed up, atomic, and checksum-tracked.
+8. If the user chooses to commit the improvement, include a `SpecPi-Gap: <gap-id>` trailer so the commit can be linked to its retirement in the journal. SpecPi itself never commits.
+
+## Verification and retirement
+
+1. Run the narrowest focused checks, then `npm run check`.
+2. For installer changes, exercise plan/install/doctor/update/uninstall with a temporary `PI_CODING_AGENT_DIR`; never use the live Pi directory.
+3. Inspect the final diff and obtain fresh read-only review when risk warrants it.
+4. At the end, call `finish_harness_improvement` with the exact gap ID, concise direct acceptance evidence, and a sanitized validation note. The tool requires the matching task contract, checks newly changed source paths against it, requires source-registry integration, runs `npm run check`, and executes every linked closed validator. It rejects stale selection or changed source and journals the resulting verification receipt separately from model-reported evidence. Retirement occurs only when every gate passes.
+5. If validation fails, fix or revert. Do not retire on plausibility; leave the item selected and report the blocker.
+6. A later regression returns the retired item to the `/harness-improvement` menu. Choosing it there explicitly reopens and selects it for review.
+7. When a retired item reopens, start from `/wishlist history <gap-id>`: the journal supplies the original proof and the changed-file set of the original change. Propose an explicit revert plan for human approval; never revert autonomously.
+
+## Handoff
+
+Report the gap ID, changed files, acceptance evidence, commands and exit codes, lifecycle action, rollback path, and residual risks. Never claim that silence or the absence of later reports proves success.
+
+When a separate human-directed review is useful, `/task handoff` assembles a bounded review packet in the current conversation. The human can later use `/wishlist outcome <gap-id>` to assess the latest local retirement. Do not submit outcome feedback on the human's behalf or treat a negative assessment as permission to start work.

package/templates/AGENTS.md

@@ -1,23 +1,25 @@
-## SpecPi Working Agreement
-
-- Prefer direct execution for small, well-scoped tasks; do not add workflow ceremony without a concrete benefit.
-- Ask concise, decision-oriented questions when material requirements are ambiguous instead of guessing.
-- Inspect existing code and repository guidance before editing. Keep changes surgical and avoid unrelated cleanup.
-- Use project-native commands and dependencies. Do not introduce global tooling when a local script or dependency already exists.
-- Treat plans and model output as context rather than proof. Files, diffs, command output, tests, and runtime behavior are authoritative.
-- Use visible `PLAN.md`, `TODO.md`, `DECISIONS.md`, or `HANDOFF.md` artifacts only when they improve continuity.
-- Delegate only when fresh context, parallel independent investigation, specialist judgment, or review justifies the overhead.
-- Keep one writer per shared working directory. Use `/experiment` or another isolated worktree for intentional parallel writers, and open the separate session yourself.
-- When `/scope` is active, treat outside-scope findings as pending until the human allows once, acknowledges them with `/scope accept`, expands the declared scope with `/scope add`, or clears it; never describe observed drift as accepted scope, and never assume an acknowledged path was added to the contract.
-- Use `/challenge` for material completion review when its adversarial checklist provides concrete value; its readiness card supports human review but is not independent proof.
-- Never launch `codex-exec` or `codex-exec-writer`; SpecPi disables these external subscription runners.
-- Treat command-guard denials as hard runtime constraints: use the stated safer alternative or ask the user; never obfuscate, split, encode, or reroute a denied operation to evade protection.
-- When Command Guard is active, prefer direct tool calls and simple, explicit commands. Avoid unnecessary command substitution, process substitution, stdin-driven `xargs`, compound shell programs, inline interpreter code, and executable heredocs because opaque forms require approval. When complexity is genuinely required, keep it transparent and request approval rather than restructuring it to bypass protection.
-- For material changes, run the narrowest relevant checks, inspect the final diff, and use fresh read-only review when risk warrants it.
-- Never claim completion from plausibility alone. Report commands run, validation results, and residual risks.
-- Treat wishlist observations as leads, not permission to edit. Start only from an exact `/harness-improvement` menu choice, use the `specpi-improve` skill, and retire through its verification gate only after direct evidence passes.
-- Do not commit, push, publish, deploy, or alter remote state unless the user explicitly requests it.
-- Prefer Pi web tools for ordinary research. Use the DonSeTch skill for whole-site crawling, bot walls, JavaScript-heavy extraction, or focused probes.
-- Use SpecPi browser tools to validate rendered web interfaces at relevant desktop, tablet, and mobile viewports; source review and HTTP checks are not proof of visual correctness.
-- Create or replace visual baselines only when explicitly requested, and report current, baseline, and diff artifact paths for regression comparisons.
-- Keep final responses concise and identify changed files clearly.
+## SpecPi Working Agreement
+
+- Prefer direct execution for small, well-scoped tasks; do not add workflow ceremony without a concrete benefit.
+- Ask concise, decision-oriented questions when material requirements are ambiguous instead of guessing.
+- Inspect existing code and repository guidance before editing. Keep changes surgical and avoid unrelated cleanup.
+- Use project-native commands and dependencies. Do not introduce global tooling when a local script or dependency already exists.
+- Treat plans and model output as context rather than proof. Files, diffs, command output, tests, and runtime behavior are authoritative.
+- Use visible `PLAN.md`, `TODO.md`, `DECISIONS.md`, or `HANDOFF.md` artifacts only when they improve continuity.
+- For material work, an optional `/task` card keeps the original requirement IDs, acceptance checks, expected paths, rollback, and non-goals together. Use it as the shared reference for `/spec`, `/challenge`, and experiments; only the human's `/scope task` command imports its paths into scope monitoring.
+- Preserve the original task requirements in reviews. A changed card invalidates earlier completion evidence; a handoff packet is review context, not permission to implement or launch another agent.
+- Delegate only when fresh context, parallel independent investigation, specialist judgment, or review justifies the overhead.
+- Keep one writer per shared working directory. Use `/experiment` or another isolated worktree for intentional parallel writers, and open the separate session yourself.
+- When `/scope` is active, treat outside-scope findings as pending until the human allows once, acknowledges them with `/scope accept`, expands the declared scope with `/scope add`, or clears it; never describe observed drift as accepted scope, and never assume an acknowledged path was added to the contract.
+- Use `/challenge` for material completion review when its adversarial checklist provides concrete value; its readiness card supports human review but is not independent proof.
+- Never launch `codex-exec` or `codex-exec-writer`; SpecPi disables these external subscription runners.
+- Treat command-guard denials as hard runtime constraints: use the stated safer alternative or ask the user; never obfuscate, split, encode, or reroute a denied operation to evade protection.
+- When Command Guard is active, prefer direct tool calls and simple, explicit commands. Avoid unnecessary command substitution, process substitution, stdin-driven `xargs`, compound shell programs, inline interpreter code, and executable heredocs because opaque forms require approval. When complexity is genuinely required, keep it transparent and request approval rather than restructuring it to bypass protection.
+- For material changes, run the narrowest relevant checks, inspect the final diff, and use fresh read-only review when risk warrants it.
+- Never claim completion from plausibility alone. Report commands run, validation results, and residual risks.
+- Treat wishlist observations as leads, not permission to edit. Start only from an exact `/harness-improvement` menu choice, use the `specpi-improve` skill, and retire through its verification gate only after direct evidence passes.
+- Do not commit, push, publish, deploy, or alter remote state unless the user explicitly requests it.
+- Prefer Pi web tools for ordinary research. Use the DonSeTch skill for whole-site crawling, bot walls, JavaScript-heavy extraction, or focused probes.
+- Use SpecPi browser tools to validate rendered web interfaces at relevant desktop, tablet, and mobile viewports; source review and HTTP checks are not proof of visual correctness.
+- Create or replace visual baselines only when explicitly requested, and report current, baseline, and diff artifact paths for regression comparisons.
+- Keep final responses concise and identify changed files clearly.

package/templates/settings.json

@@ -1,10 +1,10 @@
-{
-  "theme": "specpi-spec",
-  "packages": [
-    "npm:pi-web-access@0.25.0",
-    "npm:@juicesharp/rpiv-ask-user-question@2.7.1",
-    "npm:@llblab/pi-codex-usage@0.9.3",
-    "npm:@tunnckocore/pi-gpt-fast-mode@0.4.0",
-    "npm:@narumitw/pi-goal@0.54.3"
-  ]
-}
+{
+  "theme": "specpi-spec",
+  "packages": [
+    "npm:pi-web-access@0.25.0",
+    "npm:@juicesharp/rpiv-ask-user-question@2.7.1",
+    "npm:@llblab/pi-codex-usage@0.9.3",
+    "npm:@tunnckocore/pi-gpt-fast-mode@0.4.0",
+    "npm:@narumitw/pi-goal@0.54.3"
+  ]
+}

package/themes/specpi-spec.json

@@ -1,96 +1,96 @@
-{
-	"$schema": "https://raw.githubusercontent.com/earendil-works/pi/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
-	"name": "specpi-spec",
-	"vars": {
-		"blueprint": "#8FB6D9",
-		"blueprintBright": "#B8D4EC",
-		"blueprintDeep": "#6F93B3",
-		"paper": "#E9EDF4",
-		"paperBright": "#F7F9FC",
-		"paperSoft": "#D6DCE6",
-		"slate": "#A3ADBC",
-		"quiet": "#78838F",
-		"faint": "#5D6876",
-		"rule": "#2A313B",
-		"ruleStrong": "#39424F",
-		"success": "#7FB08A",
-		"warning": "#D7B36A",
-		"error": "#E07A7A",
-
-		"selectedBg": "#202A35",
-		"searchBg": "#8FB6D9",
-		"userMsgBg": "#181C22",
-		"customMsgBg": "#20252D",
-		"toolPendingBg": "#171E26",
-		"toolSuccessBg": "#192027",
-		"toolErrorBg": "#2A1B20"
-	},
-	"colors": {
-		"accent": "blueprint",
-		"border": "ruleStrong",
-		"borderAccent": "blueprint",
-		"borderMuted": "rule",
-		"success": "success",
-		"error": "error",
-		"warning": "warning",
-		"muted": "slate",
-		"dim": "quiet",
-		"text": "paper",
-		"thinkingText": "slate",
-
-		"selectedBg": "selectedBg",
-		"scrollbarThumb": "ruleStrong",
-		"searchMatchBg": "searchBg",
-		"searchMatchText": "#121519",
-		"userMessageBg": "userMsgBg",
-		"userMessageText": "paperBright",
-		"customMessageBg": "customMsgBg",
-		"customMessageText": "paperSoft",
-		"customMessageLabel": "blueprint",
-		"toolPendingBg": "toolPendingBg",
-		"toolSuccessBg": "toolSuccessBg",
-		"toolErrorBg": "toolErrorBg",
-		"toolTitle": "paperBright",
-		"toolOutput": "slate",
-
-		"mdHeading": "paperBright",
-		"mdLink": "blueprintBright",
-		"mdLinkUrl": "quiet",
-		"mdCode": "blueprint",
-		"mdCodeBlock": "paperSoft",
-		"mdCodeBlockBorder": "ruleStrong",
-		"mdQuote": "slate",
-		"mdQuoteBorder": "blueprintDeep",
-		"mdHr": "ruleStrong",
-		"mdListBullet": "blueprint",
-
-		"toolDiffAdded": "success",
-		"toolDiffRemoved": "error",
-		"toolDiffContext": "quiet",
-
-		"syntaxComment": "faint",
-		"syntaxKeyword": "blueprint",
-		"syntaxFunction": "blueprintBright",
-		"syntaxVariable": "paperSoft",
-		"syntaxString": "success",
-		"syntaxNumber": "warning",
-		"syntaxType": "#9FC4DF",
-		"syntaxOperator": "slate",
-		"syntaxPunctuation": "quiet",
-
-		"thinkingOff": "ruleStrong",
-		"thinkingMinimal": "faint",
-		"thinkingLow": "#6B7688",
-		"thinkingMedium": "blueprintDeep",
-		"thinkingHigh": "blueprint",
-		"thinkingXhigh": "blueprintBright",
-		"thinkingMax": "paperBright",
-
-		"bashMode": "success"
-	},
-	"export": {
-		"pageBg": "#121519",
-		"cardBg": "#181C22",
-		"infoBg": "#20252D"
-	}
-}
+{
+	"$schema": "https://raw.githubusercontent.com/earendil-works/pi/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
+	"name": "specpi-spec",
+	"vars": {
+		"blueprint": "#8FB6D9",
+		"blueprintBright": "#B8D4EC",
+		"blueprintDeep": "#6F93B3",
+		"paper": "#E9EDF4",
+		"paperBright": "#F7F9FC",
+		"paperSoft": "#D6DCE6",
+		"slate": "#A3ADBC",
+		"quiet": "#78838F",
+		"faint": "#5D6876",
+		"rule": "#2A313B",
+		"ruleStrong": "#39424F",
+		"success": "#7FB08A",
+		"warning": "#D7B36A",
+		"error": "#E07A7A",
+
+		"selectedBg": "#202A35",
+		"searchBg": "#8FB6D9",
+		"userMsgBg": "#181C22",
+		"customMsgBg": "#20252D",
+		"toolPendingBg": "#171E26",
+		"toolSuccessBg": "#192027",
+		"toolErrorBg": "#2A1B20"
+	},
+	"colors": {
+		"accent": "blueprint",
+		"border": "ruleStrong",
+		"borderAccent": "blueprint",
+		"borderMuted": "rule",
+		"success": "success",
+		"error": "error",
+		"warning": "warning",
+		"muted": "slate",
+		"dim": "quiet",
+		"text": "paper",
+		"thinkingText": "slate",
+
+		"selectedBg": "selectedBg",
+		"scrollbarThumb": "ruleStrong",
+		"searchMatchBg": "searchBg",
+		"searchMatchText": "#121519",
+		"userMessageBg": "userMsgBg",
+		"userMessageText": "paperBright",
+		"customMessageBg": "customMsgBg",
+		"customMessageText": "paperSoft",
+		"customMessageLabel": "blueprint",
+		"toolPendingBg": "toolPendingBg",
+		"toolSuccessBg": "toolSuccessBg",
+		"toolErrorBg": "toolErrorBg",
+		"toolTitle": "paperBright",
+		"toolOutput": "slate",
+
+		"mdHeading": "paperBright",
+		"mdLink": "blueprintBright",
+		"mdLinkUrl": "quiet",
+		"mdCode": "blueprint",
+		"mdCodeBlock": "paperSoft",
+		"mdCodeBlockBorder": "ruleStrong",
+		"mdQuote": "slate",
+		"mdQuoteBorder": "blueprintDeep",
+		"mdHr": "ruleStrong",
+		"mdListBullet": "blueprint",
+
+		"toolDiffAdded": "success",
+		"toolDiffRemoved": "error",
+		"toolDiffContext": "quiet",
+
+		"syntaxComment": "faint",
+		"syntaxKeyword": "blueprint",
+		"syntaxFunction": "blueprintBright",
+		"syntaxVariable": "paperSoft",
+		"syntaxString": "success",
+		"syntaxNumber": "warning",
+		"syntaxType": "#9FC4DF",
+		"syntaxOperator": "slate",
+		"syntaxPunctuation": "quiet",
+
+		"thinkingOff": "ruleStrong",
+		"thinkingMinimal": "faint",
+		"thinkingLow": "#6B7688",
+		"thinkingMedium": "blueprintDeep",
+		"thinkingHigh": "blueprint",
+		"thinkingXhigh": "blueprintBright",
+		"thinkingMax": "paperBright",
+
+		"bashMode": "success"
+	},
+	"export": {
+		"pageBg": "#121519",
+		"cardBg": "#181C22",
+		"infoBg": "#20252D"
+	}
+}