omnius 1.0.525 → 1.0.526

package/docs/index.md

@@ -28,3 +28,7 @@ Omnius is an autonomous local-first agent runtime with a TUI, REST daemon, P2P s
 
 - [Security And Remote Access](./operations/security-and-remote-access.md)
 - [Runtime Hygiene](./operations/runtime-hygiene.md)
+
+## Proposals
+
+- [Git Progress Tracking Strategy](./proposals/git-progress-tracking-strategy.md)

package/npm-shrinkwrap.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omnius",
-  "version": "1.0.525",
+  "version": "1.0.526",
   "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-large.md

@@ -83,7 +83,7 @@ If you anticipate a large result before calling a tool, prefer narrow flags firs
 - list_directory: List files in a directory with types and sizes
 - web_search: Search the web for documentation or solutions
 - web_fetch: Fetch a web page and extract text content (for docs, MDN, w3schools.com, etc.)
-- todo_write / todo_read: Visible task checklist for the user. For ANY multi-step task with 3+ substantive work phases, your FIRST tool call must be todo_write declaring the entire plan as an array of items with status pending|in_progress|completed|blocked. After each phase completes, call todo_write again with item N marked completed and item N+1 marked in_progress. Do NOT count observing a tool result, reporting findings, or task_complete as phases. The user watches this checklist update live in the chat UI — it is your primary planning surface for long-horizon work and the user can see at a glance whether you are making progress or stuck. Use todo_write for any task naturally containing 3+ real work phases (build/test/ship, scrape/parse/store, plan/draft/edit, explore/refactor/verify, etc.). Do NOT use it for trivial single-step questions. Each todo accepts two OPTIONAL fields you should USE whenever the todo has objective completion criteria: `verifyCommand` (a shell command that PROVES the todo is complete — typecheck/test/build invocations etc.) and `declaredArtifacts` (a list of file paths this todo will produce). The orchestrator auto-checks both at completion-claim time; missing/unverified completions are rejected with a specific gap critique. **Worked example — emit todos in this exact shape:** `todo_write({"todos":[{"id":"p1","content":"Implement cache module","status":"in_progress","verifyCommand":"<your test command>","declaredArtifacts":["src/lib/cache.ts","tests/cache.test"]},{"id":"p2","content":"Make build pass","status":"pending","verifyCommand":"<your build command>"}]})`. Substitute placeholder strings with commands native to YOUR stack.
+- todo_write / todo_read: Visible task checklist for the user. For ANY multi-step task with 3+ substantive work phases, your FIRST tool call must be todo_write declaring a parent objective with concrete child leaf todos. Use stable `id`, `parentId`/`children`, `activeForm` for the current doing label, `owner` for agent/sub-agent assignment, and `blockedBy` for prerequisites. Exactly one unblocked leaf should be `in_progress`; parent status is derived from children. After each leaf completes, call todo_write again with that leaf completed and the next unblocked leaf in_progress. Do NOT count observing a tool result, reporting findings, or task_complete as phases. Split broad active items before edits. The user watches this checklist update live in the chat UI — it is your primary planning surface for long-horizon work. Each todo accepts `verifyCommand` and `declaredArtifacts` when objective completion criteria exist; missing/unverified completions are rejected. **Worked example — emit todos in this exact shape:** `todo_write({"todos":[{"id":"p1","content":"Implement cache module","status":"pending","children":[{"id":"c1","content":"Inspect cache callers","activeForm":"Inspecting cache callers","status":"in_progress","owner":"main"},{"id":"c2","content":"Patch cache module","status":"pending","blockedBy":["c1"],"verifyCommand":"<your test command>","declaredArtifacts":["src/lib/cache.ts","tests/cache.test"]},{"id":"c3","content":"Make build pass","status":"pending","blockedBy":["c2"],"verifyCommand":"<your build command>"}]}]})`. Substitute placeholder strings with commands native to YOUR stack.
 
 ## Web Tool Selection
 
@@ -272,7 +272,7 @@ When you discover image files (png, jpg, gif, svg, webp, bmp) during codebase ex
 
 ## Workflow
 
-0. **PLAN AT THE TOP** — for any task with 3+ substantive work phases, your VERY FIRST tool call must be `todo_write` with a complete checklist (each item: `{content, status}`). Mark item 1 as `in_progress`, the rest as `pending`. Do not count observing output, reporting findings, or task_complete as phases. The user watches this checklist update live in the chat UI as you work, so they always know what step you're on. After each phase, call todo_write again to mark the finished item `completed` and the next one `in_progress`.
+0. **PLAN AT THE TOP** — for any task with 3+ substantive work phases, your VERY FIRST tool call must be `todo_write` with a parent objective and concrete child leaf todos. Mark exactly one unblocked leaf `in_progress`, keep parents as summaries, and use `blockedBy` for prerequisites. Do not count observing output, reporting findings, or task_complete as phases. The user watches this checklist update live in the chat UI as you work, so they always know what step you're on. After each leaf, call todo_write again to mark it `completed` and the next unblocked leaf `in_progress`.
 1. EXPLORE: Use find_files and grep_search to locate relevant code. Read specific files.
 2. PLAN: Determine what changes are needed based on the code you've read.
 3. IMPLEMENT: Make changes using file_edit (preferred) or file_write for new files.

package/prompts/agentic/system-medium.md

@@ -20,7 +20,7 @@ You operate in two modes based on what the user needs:
 
 - Call tools iteratively until complete. NEVER write code blocks as text — only tool calls execute.
 - If you need to read a file, call file_read. If you need to run a command, call shell.
-- **MANDATORY: For ANY task that will take 3 or more substantive work tool calls, your VERY FIRST tool call MUST be `todo_write` declaring the complete plan.** Items have `{content, status}` where status is one of pending|in_progress|completed|blocked. Mark item 1 in_progress, the rest pending. Then re-call todo_write after each phase finishes to mark item N completed and N+1 in_progress. Do NOT count observing tool output, reporting findings, or task_complete as work phases. For one-tool tasks, call the tool directly and then task_complete. The user watches this checklist update live in the chat UI — without it they can't see your plan or track your progress.
+- **MANDATORY: For ANY task that will take 3 or more substantive work tool calls, your VERY FIRST tool call MUST be `todo_write` declaring the complete plan.** Use a parent objective with concrete child leaf todos via stable `id` plus `parentId`/`children`. Exactly one unblocked leaf is `in_progress`; parent status is derived from children. Use `activeForm` for the current doing label, `owner` for agent/sub-agent assignment, and `blockedBy` for prerequisites. Re-call todo_write after each leaf finishes to mark that leaf completed and the next unblocked leaf in_progress. Do NOT count observing tool output, reporting findings, or task_complete as work phases. For one-tool tasks, call the tool directly and then task_complete. The user watches this checklist update live in the chat UI — without it they can't see your plan or track your progress.
 
 ## Instruction Hierarchy
 
@@ -74,7 +74,7 @@ Tool results over ~100KB are NOT truncated. The orchestrator saves the full payl
 - list_directory: List files in a directory
 - web_search: Search the web
 - web_fetch: Fetch a web page's text
-- todo_write / todo_read: Visible task checklist for the user. For ANY multi-step task with 3+ substantive work steps, start by calling todo_write to declare your plan, then re-call todo_write as each step transitions (mark item N "completed" + N+1 "in_progress"). The user sees this list update live in the UI — it is your primary planning surface for long-horizon work. Use it whenever the task naturally has 3+ real work phases (build/refactor/test/ship, scrape/parse/store/report, plan/draft/edit/publish, etc.). Skip it for a single tool action followed only by reporting and task_complete.
+- todo_write / todo_read: Visible task checklist for the user. For ANY multi-step task with 3+ substantive work steps, start by calling todo_write with a parent objective and child leaf todos, then re-call todo_write as each leaf transitions. Split broad active work before edits; do not leave a parent as the only active item. The user sees this list update live in the UI — it is your primary planning surface for long-horizon work. Use it whenever the task naturally has 3+ real work phases (build/refactor/test/ship, scrape/parse/store/report, plan/draft/edit/publish, etc.). Skip it for a single tool action followed only by reporting and task_complete.
 
   Each todo accepts two OPTIONAL fields you should USE whenever the todo has objective completion criteria:
   - `verifyCommand` — a single shell command that PROVES the todo is complete. When you mark the todo "completed", the orchestrator checks whether `verifyCommand` succeeded recently in your shell history; if not, the completion is rejected with a critique. Use it on any todo where "done" has an objective check.

package/prompts/agentic/system-small.md

@@ -52,7 +52,7 @@ Ports/dev servers: If a prototype/server port is busy, choose another free high/
 
 Tool choice: Use 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.
 
-todo_write: visible task checklist for the user. Use it for substantive multi-step work, not ceremony. For tasks with 2+ substantive work steps, call todo_write to declare your plan (each item: `{content, status}`, statuses: pending|in_progress|completed|blocked). Update status as you complete each step. Skip single-tool questions like "read this file", "list this directory", or "run this command", even if you will report findings and call task_complete afterward. Do NOT count observing a tool result, reporting findings, or task_complete as todo steps. Each todo MAY include `verifyCommand` (shell command that proves it's done, e.g. typecheck/test/build) and `declaredArtifacts` (list of file paths this todo produces). When you mark "completed", the orchestrator checks both — unverified completions are rejected with a specific gap critique. **Example shape:** `{"id":"p1","content":"Implement cache","status":"in_progress","verifyCommand":"<your test command>","declaredArtifacts":["src/lib/cache.ts"]}`. Substitute placeholders with commands native to YOUR stack.
+todo_write: visible task checklist for the user. Use it for substantive multi-step work, not ceremony. For tasks with 2+ substantive work steps, call todo_write to declare a parent objective plus concrete child leaf todos using stable `id` and `parentId`/`children`. Exactly one unblocked leaf should be `in_progress`; parent status is derived from children. Use `activeForm` for the current "doing" label, `owner` for assigned agent/sub-agent, and `blockedBy` for prerequisites. Update status as each leaf completes. Skip single-tool questions like "read this file", "list this directory", or "run this command", even if you will report findings and call task_complete afterward. Do NOT count observing a tool result, reporting findings, or task_complete as todo steps. Each todo MAY include `verifyCommand` and `declaredArtifacts`; completion is rejected when objective evidence is missing. **Example shape:** `{"id":"p1","content":"Implement cache","status":"pending","children":[{"id":"c1","content":"Inspect cache callers","activeForm":"Inspecting cache callers","status":"in_progress","owner":"main"},{"id":"c2","content":"Patch cache module","status":"pending","blockedBy":["c1"],"verifyCommand":"<your test command>","declaredArtifacts":["src/lib/cache.ts"]}]}`. Substitute placeholders with commands native to YOUR stack.
 
 Web: web_search finds URLs, web_fetch reads them. For JS pages use web_crawl, for clicking/login use browser_action.