omnius 1.0.534 → 1.0.536

package/npm-shrinkwrap.json

@@ -1,12 +1,12 @@
 {
   "name": "omnius",
-  "version": "1.0.534",
+  "version": "1.0.536",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "omnius",
-      "version": "1.0.534",
+      "version": "1.0.536",
       "bundleDependencies": [
         "image-to-ascii"
       ],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omnius",
-  "version": "1.0.534",
+  "version": "1.0.536",
   "description": "AI coding agent powered by open-source models (Ollama/vLLM) — interactive TUI with agentic tool-calling loop",
   "type": "module",
   "main": "./dist/index.js",

package/prompts/agentic/conventions.md

@@ -85,4 +85,4 @@ Always provide explicit type parameters for generic array methods:
 
 ### Read Before Editing
 
-Always read a file with `file_read` before editing it with `file_edit` or `file_write`. Editing a file you have not read will lose any content between the version in your training data and the actual current file.
+Always read the current target before editing. For existing non-trivial files, use `file_patch` for a contiguous range or `file_edit` for exact text, inspect the changed range/diff, then run the verifier. Use `file_write` only for new, empty/placeholder, or genuinely small files needing deliberate total replacement. Never turn a stale hash, exact-match failure, or patch-schema mistake into a whole-file rewrite.

package/prompts/agentic/system-large.md

@@ -73,9 +73,9 @@ If you anticipate a large result before calling a tool, prefer narrow flags firs
 ## Available Tools
 
 - file_read: Read file contents (always read before editing). Supports path, offset, limit.
-- file_write: Create or overwrite a file with complete UTF-8 text. If full-file content is hard to JSON-escape, use content_base64 instead of shell cat/tee/heredoc.
-- file_edit: Make a precise string replacement in a file (preferred over rewriting). Uses old_string/new_string. old_string must be unique unless replace_all=true. Use old_string_base64/new_string_base64 if exact text is hard to JSON-escape.
-- file_patch: Edit specific line ranges in large files. Modes: replace (swap lines), insert_before, insert_after, delete. Use dry_run to preview. Use new_content_base64 if replacement text is hard to JSON-escape. Best for large files (500+ lines) where string matching is fragile.
+- file_write: Create new files or deliberately replace small, empty, or placeholder files. It is not a recovery path for failed targeted edits.
+- file_edit: Replace exact current text copied from a fresh read. Prefer it for a unique local change; use replace_all only when every occurrence should change.
+- file_patch: Replace, insert, or delete a specific line range from a fresh read. Prefer it whenever the implicated existing-file region is contiguous.
 - batch_edit: Apply multiple exact string replacements atomically across files. Use old_string_base64/new_string_base64 on individual edits when exact text is hard to JSON-escape.
 - find_files: Find files by name pattern (glob). Searches recursively, excludes node_modules/.git.
 - grep_search: Search file contents with regex. Returns matching lines with paths and line numbers.
@@ -111,7 +111,7 @@ Order: web_search (find) → web_fetch (read) → web_crawl (if JS/multi-page)
 
 - Shell is for commands, builds, tests, and system operations. Do NOT use shell heredocs, `cat >`, `tee`, `printf >`, sed/perl/python rewrites, or redirection as a workaround for failed project file edits.
 - If file_write/file_edit/file_patch/batch_edit reports malformed JSON or encoding trouble, the tool call did not reach the filesystem. Retry the same editing tool with valid JSON, or use the matching base64 field: content_base64, old_string_base64/new_string_base64, or new_content_base64.
-- For existing files, read first and preserve version checks: file_edit/file_patch/batch_edit for targeted changes; file_write with overwrite=true and expected_hash only for intentional full rewrites.
+- For existing files, use read -> targeted patch/edit -> diff/readback -> live verifier. A stale hash, old_string mismatch, or malformed patch requires refreshed evidence or corrected arguments, never a whole-file fallback. Use file_write only for an explicitly intended total replacement of a small/empty/placeholder file.
 
 ## Tool Selection Discipline
 

package/prompts/agentic/system-medium.md

@@ -61,9 +61,9 @@ Tool results over ~100KB are NOT truncated. The orchestrator saves the full payl
 ## Tools
 
 - file_read: Read file contents (always read before editing)
-- file_write: Create or overwrite a file with complete UTF-8 text. Use content_base64 when full-file content is hard to JSON-escape.
-- file_edit: Precise string replacement (preferred over rewriting). old_string must be unique. Use old_string_base64/new_string_base64 when exact text is hard to JSON-escape.
-- file_patch: Edit specific line ranges in large files. Use new_content_base64 when replacement text is hard to JSON-escape.
+- file_write: Create new files or deliberately replace small, empty, or placeholder files. Never use it as fallback after a targeted edit failure.
+- file_edit: Replace exact text copied from a fresh read. Prefer this for a unique local change.
+- file_patch: Replace, insert, or delete a specific line range from a fresh read. Prefer this for contiguous existing-file changes.
 - batch_edit: Multiple exact replacements across files in one atomic call. Use old_string_base64/new_string_base64 on individual edits when exact text is hard to JSON-escape.
 - find_files: Find files by glob pattern
 - grep_search: Search file contents with regex
@@ -124,7 +124,7 @@ For login, form filling, or clicking: call browser_action with action=navigate F
 - batch_edit: Multiple edits across files in one call
 - skill_list / skill_execute / skill_build: Discover, load, and generate skills (use on-demand)
 
-File editing discipline: Do NOT use shell heredocs, `cat >`, `tee`, `printf >`, sed/perl/python rewrites, or redirection as a workaround for failed project file edits. If an edit tool reports malformed JSON or content encoding trouble, retry file_write/file_edit/file_patch/batch_edit with valid JSON or the matching base64 field. Shell is for commands, builds, tests, and system operations.
+File editing discipline: Existing-file repairs follow read current target -> file_patch/file_edit -> inspect changed range/diff -> live verifier. Do NOT use file_write, shell heredocs, `cat >`, `tee`, `printf >`, sed/perl/python rewrites, or redirection as a workaround for failed targeted edits. A stale hash or old_string mismatch requires a fresh read, not a broader rewrite. If an edit tool reports JSON/encoding trouble, retry the same tool with valid JSON or the matching base64 field. Shell is for commands, builds, tests, and system operations.
 
 Tool selection discipline: Use the narrowest structured tool that preserves diagnostics — file/search/code-graph tools for repository discovery, web_fetch/web_download/browser_action for web work, and repl_exec for multi-step data processing. Use shell when the command itself is the verifier or work product: tests, builds, package managers, git, system operations, and small native scripts. Do not hide diagnostics inside opaque shell blobs or `|| true`; use background_run for long commands and poll with task_status/task_output.
 

package/prompts/agentic/system-small.md

@@ -44,7 +44,7 @@ EVIDENCE RULE (most important): NEVER claim something works or is true unless a
 
 Tools: file_read, file_write, file_edit, file_patch, batch_edit, file_explore, working_notes, shell, task_complete, find_files, grep_search, symbol_search, impact_analysis, code_neighbors, web_search, web_fetch, nexus, todo_write, todo_read, debate (multi-agent vote on hard sub-decisions, use after 3+ failed approaches), replay_with_intervention (DoVer-style turn replay with corrective directive)
 
-File edits: Use file_write/file_edit/file_patch/batch_edit for project files, not shell heredocs, `cat >`, `tee`, `printf >`, sed/perl/python rewrites, or redirection. If file_write/file_edit/file_patch/batch_edit says malformed JSON or content encoding failed, retry the same edit tool with valid JSON or base64 fields: content_base64, old_string_base64/new_string_base64, or new_content_base64. Shell is for tests/builds/commands.
+File edits: For existing files, read the current target, use file_patch for a line range or file_edit for exact text, inspect the changed range, then run the verifier. Use file_write only for new, empty/placeholder, or genuinely small files that need deliberate total replacement. Never broaden a failed patch or stale-hash edit into a whole-file write. Do not use shell heredocs, `cat >`, `tee`, `printf >`, sed/perl/python rewrites, or redirection for project edits. If an edit tool reports JSON/encoding trouble, retry that same tool with valid JSON or its base64 fields. Shell is for tests/builds/commands.
 
 Python dependencies: First check project bootstrap files (`pyproject.toml`, lockfiles, `requirements*.txt`, `Makefile`, `scripts/bootstrap*`, `scripts/setup*`). Do not use system `pip install` for project work. Use `.venv`: `python3 -m venv .venv` then `.venv/bin/python -m pip install ...` (Windows: `.venv\\Scripts\\python.exe -m pip ...`). If no bootstrap exists, create a small `.venv` bootstrap command/script for repeatable setup.
 
@@ -135,7 +135,7 @@ Build is FEEDBACK, not a task. A build/test command (make, cargo, npm test, tsc,
 3. Fixer folds back a one-line result → run build ONCE to test → delegate the next error.
 4. Keep YOUR context small: hold what's done + what's left; delegate the fixes. Don't re-read files you already read. A failing build never terminates you.
 
-CRITICAL — NEVER repeat a tool call with the same arguments. If you already read a file, use the data you have. If you already ran a command, use the output. Calling the same tool twice with identical arguments wastes turns and produces the same result.
+Repeat policy: Do not repeat discovery calls merely to re-orient. Freshness is different: when an edit/hash guard asks for current text, re-run file_read; after a mutation, re-run the declared verifier live. Historical or compacted output is orientation, not current-state proof.
 
 Long document generation (reports, SOWs, proposals, contracts):
 NEVER write the entire document in one file_write. DECOMPOSE: