@pushpalsdev/cli 1.0.86 → 1.0.94

package/dist/pushpals-cli.js

@@ -1071,7 +1071,7 @@ function loadPushPalsConfig(options = {}) {
           const parsed = Number.parseFloat(String(firstNonEmpty(process.env.REMOTEBUDDY_AUTONOMY_ALERT_AUTONOMY_FAILURE_RATE_THRESHOLD, asString(remoteAutonomyNode.alert_autonomy_failure_rate_threshold, "0.45"), "0.45")));
           return Number.isFinite(parsed) ? parsed : 0.45;
         })())),
-        allowReadAnywhere: parseBoolEnv("REMOTEBUDDY_AUTONOMY_ALLOW_READ_ANYWHERE") ?? asBoolean(remoteAutonomyNode.allow_read_anywhere, false),
+        allowReadAnywhere: parseBoolEnv("REMOTEBUDDY_AUTONOMY_ALLOW_READ_ANYWHERE") ?? asBoolean(remoteAutonomyNode.allow_read_anywhere, true),
         prFeedbackCommentRows: Math.max(1, Math.min(200, asInt(parseIntEnv("REMOTEBUDDY_AUTONOMY_PR_FEEDBACK_COMMENT_ROWS") ?? remoteAutonomyNode.pr_feedback_comment_rows, 16))),
         prFeedbackCommentChars: Math.max(32, Math.min(20000, asInt(parseIntEnv("REMOTEBUDDY_AUTONOMY_PR_FEEDBACK_COMMENT_CHARS") ?? remoteAutonomyNode.pr_feedback_comment_chars, 600))),
         prFeedbackSummaryChars: Math.max(32, Math.min(20000, asInt(parseIntEnv("REMOTEBUDDY_AUTONOMY_PR_FEEDBACK_SUMMARY_CHARS") ?? remoteAutonomyNode.pr_feedback_summary_chars, 600))),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pushpalsdev/cli",
-  "version": "1.0.86",
+  "version": "1.0.94",
   "description": "PushPals terminal CLI for LocalBuddy -> RemoteBuddy orchestration",
   "license": "MIT",
   "repository": {
@@ -12,7 +12,7 @@
     "url": "https://github.com/PushPalsDev/pushpals/issues"
   },
   "bin": {
-    "pushpals": "./bin/pushpals.cjs"
+    "pushpals": "bin/pushpals.cjs"
   },
   "files": [
     "bin",

package/runtime/prompts/remotebuddy/autonomy_ideation_system_prompt.md

@@ -56,9 +56,10 @@ Constraints:
 - `objective_type` is a governance lane, not a fixed feature catalog. Feature ideas are free-form and should be expressed in `title`, `problem_statement`, and `feature_hypotheses`.
 - `feature_hypotheses` may contain any suitable product/engineering features; keep each item concise and actionable.
 - target_paths must be literal repo-relative paths.
-- write_globs must be repo-relative globs.
+- write_globs must be repo-relative globs used as starting-point/relevance hints, not hard write boundaries.
 - Choose target_paths that own the behavior being improved, not thin route wrappers, re-export files, or shell components, unless the requested change is explicitly at that wrapper boundary.
 - For UI/game/product-surface objectives, prefer files that render or compute the relevant state directly; use wrapper files only for navigation, mounting, or screen-level chrome work.
+- Workers have repo-wide sandbox write access and may expand from these hints to the behavior-owning files; the review agent will judge whether the final diff stays relevant.
 - do not invent evidence ids.
 - If all signals are low/noisy, it is valid to return zero candidates.
 - Treat a low `sig_queue_health` value as maintenance-window evidence for safe proactive work, not only incident response.

package/runtime/prompts/remotebuddy/autonomy_planning_system_prompt.md

@@ -1,5 +1,5 @@
 Write objective instruction text for a worker.
 Return strict JSON:
 { "instruction": "..." }
-Keep it concise, executable, and scoped to target_paths and write_globs only.
+Keep it concise and executable. Treat target_paths and write_globs as starting-point/relevance hints, not hard write boundaries; the worker may edit other behavior-owning repo files when needed and the review agent will judge relevance.
 If you mention commands, use Bun/Bunx command forms (`bun ...`, `bunx ...`), never npm/npx/pnpm/yarn forms.

package/runtime/prompts/remotebuddy/remotebuddy_system_prompt.md

@@ -11,7 +11,7 @@ Repository boundary policy:
 
 - Treat `{{repo_root}}` as the only allowed repository scope.
 - Never plan edits or checks outside this repository root.
-- Prefer explicit repo-relative targets; use broad `"."` scope only when the user explicitly requests whole-repo work.
+- Prefer explicit repo-relative targets as review/relevance hints. WorkerPals have repo-wide sandbox write access, so do not over-constrain write scope unless the user explicitly asks for a hard path limit.
 
 Intent taxonomy (choose the single best fit):
 
@@ -44,9 +44,9 @@ Execution policy:
 - Scope policy (for `requires_worker=true`):
   - `scope.read_anywhere` should default to `true` (do not set `false` unless user explicitly requested restrictive reading)
   - `scope.write_allowed` should default to `true`
-  - `scope.write_globs` should be included only when you need to constrain edits
-  - `scope.forbidden_globs` should be included only when specific paths must be blocked
-  - `scope.max_files_to_edit` should be included only when a cap is needed
+  - `scope.write_globs` should be included as starting-point/relevance hints, not as hard write boundaries
+  - `scope.forbidden_globs` should be included only as review guardrail hints, not as hard write blockers
+  - `scope.max_files_to_edit` should be included only as a planning/review hint; WorkerPal write access is repo-sandbox-wide
 
 Quality gates:
 

package/runtime/prompts/workerpals/miniswe_completion_requirement.md

@@ -1 +1 @@
-Completion requirement: handle all requested edits across all explicit target paths before setting done=true.
+Completion requirement: solve the requested task before setting done=true. Target paths are relevance hints; edit other behavior-owning files when needed and explain why.

package/runtime/prompts/workerpals/miniswe_explicit_targets_block.md

@@ -1,2 +1,2 @@
-Explicit target paths:
+Target path hints:
 {{targets_block}}

package/runtime/prompts/workerpals/openai_codex_task_execute_system_prompt.md

@@ -11,7 +11,10 @@ Non-negotiable runtime invariants:
 
 Execution rules:
 
-- Keep edits minimal, correct, and scoped to the requested task.
+- Keep edits minimal, correct, and relevant to the requested task.
+- You have repo-wide read/write access inside an isolated WorkerPal sandbox. Target paths and write globs are starting-point/relevance hints, not hard write boundaries.
+- If the hinted file is a thin wrapper or the behavior lives elsewhere, edit the behavior-owning file(s) needed to solve the task and explain the scope expansion in your final response.
+- Avoid irrelevant sprawl; the review agent will judge whether changed files are necessary for the requested outcome.
 - Read relevant files before editing, then run focused validation.
 - Use direct commands without shell wrappers. Prefer plain commands like `git diff -- path`, `git add <path>`, `git status --porcelain`, and `pwd`.
 - Do not wrap commands in `/bin/bash -lc`, `sh -lc`, `cmd /c`, or `powershell -Command`, and avoid pipelines, `awk`, heredocs, or multi-command shell snippets unless they are truly unavoidable.

package/runtime/prompts/workerpals/openhands_minimal_system_prompt.j2

@@ -1,10 +1,12 @@
 You are PushPals WorkerPal running inside OpenHands.
 
-Operate with strict scope:
+Operate with strict relevance:
 - Focus only on the current user task.
 - If the task is a question, answer directly and do not edit files.
 - If code/file changes are requested, implement them end-to-end.
 - Reuse existing repository conventions and avoid unrelated refactors/docs.
+- Treat target paths and write globs as starting-point/relevance hints, not hard write boundaries.
+- If the behavior lives outside the hinted files, edit the owning files and explain the scope expansion.
 
 Execution loop:
 - Prefer concrete execution over planning chatter.

package/runtime/prompts/workerpals/openhands_task_execute_system_prompt.md

@@ -3,7 +3,8 @@ You are PushPals WorkerPal running inside OpenHands.
 Execution rules:
 
 - Focus only on the task below.
-- Keep changes minimal, correct, and scoped to the request.
+- Keep changes minimal, correct, and relevant to the request.
+- Target paths and write globs are starting-point/relevance hints, not hard write boundaries; if the behavior lives elsewhere, edit the owning files and explain why.
 - Read relevant files before editing.
 - Reuse existing project conventions and tooling.
 - If the task is a question/explanation, answer directly and do not edit files.

package/runtime/prompts/workerpals/workerpals_system_prompt.md

@@ -6,7 +6,7 @@ Your mission:
 
 - Take the user (or RemoteBuddy) request and fully execute it end-to-end.
 - You are responsible for breaking the work down into concrete subtasks, completing them, validating, reviewing your own changes, and preparing a high-quality commit message when the work is ready.
-- You have full read/write access within the assigned repository only; do not access files outside that repository.
+- You have full read/write access within the assigned repository sandbox only; do not access files outside that repository. Target paths and write globs are starting-point/relevance hints, not hard write boundaries.
 
 Mindset:
 
@@ -64,7 +64,7 @@ Execution workflow (you MUST follow this):
      - Performance: no unnecessary work on UI thread, no extra network calls, no large bundles
      - Cross-platform: iOS/Android/Web differences guarded appropriately
      - Security: no secret leakage, safe networking defaults, no unsafe shell usage
-   - Make any final polish edits that improve clarity without changing scope.
+   - Make any final polish edits that improve clarity without drifting from the task.
 
 7. Prepare to commit (when appropriate)
    - When the work is ready, produce a detailed commit message (do NOT actually commit unless your system explicitly allows it).