@pushpalsdev/cli 1.0.32 → 1.0.33

package/runtime/sandbox/packages/shared/src/localbuddy_runtime.ts

@@ -50,10 +50,7 @@ export function parseLocalBuddyRuntimeSnapshot(raw: string): LocalBuddyRuntimeSn
   return {
     localbuddy: {
       enabled,
-      port:
-        Number.isFinite(port) && port >= 1 && port <= 65_535
-          ? port
-          : DEFAULT_LOCALBUDDY_PORT,
+      port: Number.isFinite(port) && port >= 1 && port <= 65_535 ? port : DEFAULT_LOCALBUDDY_PORT,
     },
   };
 }
@@ -155,7 +152,9 @@ function resolveRuntimeConfigDir(workspaceRoot: string, configuredDir?: string):
 }
 
 function parseBoolEnv(value: string | undefined): boolean | undefined {
-  const text = String(value ?? "").trim().toLowerCase();
+  const text = String(value ?? "")
+    .trim()
+    .toLowerCase();
   if (!text) return undefined;
   if (TRUTHY.has(text)) return true;
   if (FALSY.has(text)) return false;

package/runtime/sandbox/packages/shared/src/vision.ts

@@ -40,7 +40,9 @@ export type VisionDocValidation = {
 const MAX_KEY_ITEMS_PER_BUCKET = 8;
 
 function toLines(markdown: string): string[] {
-  return String(markdown ?? "").replace(/\r\n/g, "\n").split("\n");
+  return String(markdown ?? "")
+    .replace(/\r\n/g, "\n")
+    .split("\n");
 }
 
 function extractOneSentence(lines: string[]): string {
@@ -75,7 +77,9 @@ function extractOneSentence(lines: string[]): string {
 }
 
 function normalizeItem(value: string): string {
-  return String(value ?? "").replace(/\s+/g, " ").trim();
+  return String(value ?? "")
+    .replace(/\s+/g, " ")
+    .trim();
 }
 
 function dedupeAndClamp(values: string[]): string[] {

package/runtime/sandbox/prompts/workerpals/commit_message_prompt.md

@@ -10,6 +10,7 @@ Output only the raw commit message text — no markdown fences, no explanation,
 - <specific implementation detail>
 
 Tests:
+
 - <test runner command>
 
 ## Writing rules
@@ -25,12 +26,14 @@ Background context: "can you add one more unit test for localbuddy"
 
 Bad (copies instruction / uses planning language):
 {{type}}({{area}}): lets add one more unit test for localbuddy
+
 - At least one new unit test is added validating a meaningful LocalBuddy behavior.
 - All existing and new tests pass.
 - No unrelated files are modified.
 
 Good (reads the diff):
 {{type}}({{area}}): add unit test for LocalBuddy request routing and error response handling
+
 - add test case in localbuddy.test.ts asserting router returns 404 for unknown tool calls
 - add negative test for malformed request payload returning 400 with error message
 - extract shared test fixtures into testHelpers.ts to reduce duplication

package/runtime/sandbox/prompts/workerpals/miniswe_broker_system_prompt.md

@@ -5,18 +5,19 @@ Repository root: {{repo}}
 
 Output format (STRICT JSON, no markdown, no extra keys unless specified):
 {
-  "actions": [
-    {"type":"read_file","path":"README.md"},
-    {"type":"append_line","path":"README.md","line":"..."},
-    {"type":"replace_text_once","path":"x","old":"a","new":"b"},
-    {"type":"write_file","path":"x","content":"..."},
-    {"type":"run_shell","command":"git status --porcelain"}
-  ],
-  "done": false,
-  "note": "short explanation"
+"actions": [
+{"type":"read_file","path":"README.md"},
+{"type":"append_line","path":"README.md","line":"..."},
+{"type":"replace_text_once","path":"x","old":"a","new":"b"},
+{"type":"write_file","path":"x","content":"..."},
+{"type":"run_shell","command":"git status --porcelain"}
+],
+"done": false,
+"note": "short explanation"
 }
 
 Rules:
+
 - Keep actions minimal and directly relevant.
 - JSON syntax must be exact: use ":" between keys and values, never ",".
 - Use double quotes for all keys and string values.

package/runtime/sandbox/prompts/workerpals/miniswe_strict_tool_use_guidance.md

@@ -1,4 +1,5 @@
 CRITICAL: You must use tools to make progress.
+
 - Use the environment's tools (file read/list/search, and file edit/write/patch) to inspect and modify the repo.
 - Do NOT only describe what you would do; actually do it.
 - Avoid broad scans; choose one target file quickly.

package/runtime/sandbox/prompts/workerpals/openai_codex_runtime_policy_appendix.md

@@ -1,4 +1,5 @@
 Runtime policy guardrails (mandatory):
+
 - Codex CLI is required infrastructure in this environment.
 - Never bypass Codex usage by changing tests/code expectations.
 - If Codex CLI auth/execution is unavailable, hard-fail and stop.

package/runtime/sandbox/prompts/workerpals/openai_codex_task_execute_system_prompt.md

@@ -1,12 +1,14 @@
 You are PushPals WorkerPal running via the OpenAI Codex CLI backend.
 
 Non-negotiable runtime invariants:
+
 - Codex CLI is required infrastructure in this environment.
 - Do not modify tests or production code to bypass, stub, or remove Codex CLI usage due to assumed environment limitations.
 - Do not "adapt around" missing Codex access by rewriting coverage or behavior expectations.
 - If Codex CLI authentication/execution is unavailable, fail loudly with a clear error and stop.
 
 Execution rules:
+
 - Keep edits minimal, correct, and scoped to the requested task.
 - Read relevant files before editing, then run focused validation.
 - Report blockers explicitly; do not hide platform/runtime issues with workaround edits.

package/runtime/sandbox/prompts/workerpals/task_quality_critic_system_prompt.md

@@ -2,8 +2,9 @@ You are a strict code-review critic for worker-generated patches.
 Return exactly one JSON object with keys:
 {"score": <0-10 number>, "findings": [string], "must_fix": [string], "revision_guidance": string}
 Scoring rubric:
+
 - 10: complete, correct, and robust with strong validation coverage.
 - 8-9: good quality with minor non-blocking issues.
 - <=7: requires revision before commit.
-must_fix must list blocking issues only.
-Do not include markdown or prose outside JSON.
+  must_fix must list blocking issues only.
+  Do not include markdown or prose outside JSON.

package/runtime/vision.example.md

@@ -9,18 +9,21 @@
 ## 1) Who this is for
 
 ### Primary users
+
 - **User type A:** (e.g., app developers, SREs, analysts, end-users)
   - Jobs-to-be-done: …
   - Pain today: …
   - Success looks like: …
 
 ### Secondary users
+
 - **User type B:** …
   - Jobs-to-be-done: …
   - Pain today: …
   - Success looks like: …
 
-### Non-users (explicitly *not* optimizing for)
+### Non-users (explicitly _not_ optimizing for)
+
 - **Not for:** …
   - Why: …
 
@@ -31,13 +34,15 @@
 ## 2) The problem we solve
 
 ### Today’s reality
+
 - What is hard / slow / risky today?
 - What failures happen repeatedly? (bugs, incidents, misconfig, confusion)
 - What is expensive? (time, money, cognitive load, coordination)
 
 ### The change we want
-- In 6–12 months, what should feel *meaningfully easier*?
-- In 2–3 years, what should be *obviously different*?
+
+- In 6–12 months, what should feel _meaningfully easier_?
+- In 2–3 years, what should be _obviously different_?
 
 > **Optional:** Add a 3–5 line “story” of a user before vs after.
 
@@ -66,11 +71,13 @@ These are **tie-breakers** when tradeoffs happen. Put them in priority order.
 Pick a small set of metrics you can actually track.
 
 ### User-facing outcomes
+
 - **Time-to-success:** e.g., median time from install → first successful use
 - **Quality:** e.g., bug rate / support tickets per active user
 - **Trust:** e.g., SLO compliance, error rate, crash-free sessions
 
 ### Developer / maintainer outcomes
+
 - **Change velocity:** PR cycle time, lead time to release
 - **Operational burden:** pages/alerts per week, toil hours
 - **Maintainability:** test coverage for critical paths, build time, flake rate
@@ -81,17 +88,20 @@ Pick a small set of metrics you can actually track.
 
 ## 5) Scope and boundaries
 
-### In scope (what we *are*)
+### In scope (what we _are_)
+
 - Core capability A: …
 - Core capability B: …
 - Core capability C: …
 
-### Out of scope / non-goals (what we are *not*)
+### Out of scope / non-goals (what we are _not_)
+
 - Not a replacement for: …
 - Not trying to support: …
 - Not optimizing for: …
 
 ### Compatibility & support policy (optional)
+
 - Supported platforms / versions: …
 - Breaking changes policy: …
 - Deprecation timeline: …
@@ -120,6 +130,7 @@ Pick 3–5 items max. Each should be **outcome-oriented**.
 These are “bets” with explicit results.
 
 ### Objective A: <name>
+
 - **Problem:** …
 - **Approach:** …
 - **Deliverables:** …
@@ -127,6 +138,7 @@ These are “bets” with explicit results.
 - **Exit criteria:** How we’ll know it worked (measurable)
 
 ### Objective B: <name>
+
 - …
 
 ---
@@ -136,6 +148,7 @@ These are “bets” with explicit results.
 Describe where this repo is going, without over-promising.
 
 ### Strategic bets
+
 - **Bet 1:** …
   - Why it matters: …
   - What we’ll likely build: …
@@ -143,6 +156,7 @@ Describe where this repo is going, without over-promising.
 - **Bet 2:** …
 
 ### “If we’re right, then…”
+
 - Users will be able to: …
 - Maintainers will spend less time on: …
 - The ecosystem will have: …
@@ -152,6 +166,7 @@ Describe where this repo is going, without over-promising.
 ## 9) Guardrails and constraints
 
 ### Guardrails (how we avoid harm / churn)
+
 - Prefer changes that are **reversible** or behind flags.
 - Default to **secure / safe** settings.
 - Optimize for the **common path**; support escape hatches for experts.
@@ -159,6 +174,7 @@ Describe where this repo is going, without over-promising.
 - Pay down operational toil before adding big surface area.
 
 ### Constraints (reality checks)
+
 - Staffing level / maintainer bandwidth: …
 - Hard requirements (privacy, compliance, perf, cost): …
 - External dependencies: …
@@ -181,11 +197,14 @@ Describe where this repo is going, without over-promising.
 ## Appendix (optional but powerful)
 
 ### A) Glossary
+
 - Term: definition…
 
 ### B) Personas (one-page each)
+
 - Persona, environment, constraints, success criteria…
 
 ### C) Example “no” responses (template)
+
 - “Thanks — this is valuable, but it conflicts with our non-goal X…”
 - “We’d reconsider if metric Y becomes a problem…”