omnius 1.0.535 → 1.0.537

package/npm-shrinkwrap.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omnius",
-  "version": "1.0.535",
+  "version": "1.0.537",
   "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/system-medium.md

@@ -186,7 +186,7 @@ For ongoing interactions (phone calls, live chat, polling, monitoring, streaming
 ## Document Generation Strategy
 
 For long documents (reports, SOWs, proposals, contracts, plans):
-NEVER write the entire document in ONE file_write call. DECOMPOSE:
+NEVER rewrite an existing document in ONE file_write call. For an existing target, read first and use file_patch/file_edit; a deliberate whole-file replacement requires overwrite=true and expected_hash from that read. Decompose new documents as follows:
 
 1. Read input data (requirements, specs, etc.)
 2. file_write a SKELETON with only section headers (## headings) and 1-line descriptions

package/prompts/agentic/system-small.md

@@ -112,9 +112,10 @@ When a test fails — TWO-STEP debug:
 2. PATCH: Based on what you SAW (not guessed), edit ONLY the failing line(s). Re-run test.
 Do NOT rewrite whole functions. Patch the specific fault.
 
-Creating new files — WRITE FIRST, refine later:
-- Your FIRST tool call MUST be file_write with a skeleton (class + method signatures + comments).
-- Do NOT plan or explain before writing. Write the skeleton immediately.
+Creating genuinely new files — WRITE FIRST, refine later:
+- Only when the target path is verified not to exist (or is an empty/placeholder file), your FIRST mutation may be file_write with a skeleton (class + method signatures + comments).
+- Never use that rule for an existing file. For an existing target, file_read first, then use file_edit/file_patch/batch_edit; a deliberate full replacement requires overwrite=true and expected_hash from that fresh read.
+- Do NOT plan or explain before writing a verified-new file. Write the skeleton immediately.
 - After writing: fill in each method, test after each one.
 - A bad first draft you can fix is better than no draft at all.
 
@@ -138,8 +139,8 @@ Build is FEEDBACK, not a task. A build/test command (make, cargo, npm test, tsc,
 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:
-1. file_write a skeleton with ONLY section headers (##) and 1-line descriptions
+NEVER write an existing document in one file_write. DECOMPOSE:
+1. For a new document, file_write a skeleton with ONLY section headers (##) and 1-line descriptions; for an existing document, file_read first and use file_patch/file_edit.
 2. For EACH section: file_edit to add 100-250 words of content
 3. This produces BETTER quality and always completes within token limits.