omnius 1.0.591 → 1.0.592

package/docs/work-orders/hermes-architecture-deltas/03-typed-gateway-event-stream/WORKORDER.md

@@ -0,0 +1,172 @@
+# Workorder: Typed Gateway Event Stream
+
+## Objective
+
+Replace fragile renderer-facing string events with a typed event stream that separates what happened in the runner from how each gateway renders it.
+
+## Problem Statement
+
+Telegram currently mixes runner state, progress, admin live panel text, public progress text, and completion status through loosely typed events and string filtering. This creates recurring risks:
+- `task_complete.summary` can leak into visible replies if filtering drifts.
+- `incomplete_verification` can be rendered like a successful completion.
+- Progress messages depend on status text instead of event intent.
+- Different surfaces duplicate completion and failure interpretation.
+
+Hermes has a typed stream event layer and a dispatcher that lets adapters render events without changing agent execution.
+
+## Existing Code Anchors
+
+Omnius:
+- `packages/orchestrator/src/agenticRunner.ts:15760` emits final `complete` events.
+- `packages/orchestrator/src/agenticRunner.ts:14155` handles streaming `task_complete`.
+- `packages/orchestrator/src/agenticRunner.ts:14382` handles non-streaming `task_complete`.
+- `packages/orchestrator/src/agenticRunner.ts:15586` handles another task completion path.
+- `packages/cli/src/tui/telegram-bridge.ts:2828` has task_complete visibility filtering.
+- `packages/cli/src/tui/telegram-bridge.ts:12504` builds public progress messages.
+- `packages/cli/src/tui/telegram-bridge.ts:12650` determines admin completion success.
+- `packages/cli/src/tui/telegram-bridge.ts:13450` cleans final text for Telegram.
+
+Hermes:
+- `/home/robit/Documents/repositories/hermes-agent/gateway/stream_events.py:151` defines `StreamEvent` as a union.
+- `/home/robit/Documents/repositories/hermes-agent/gateway/stream_dispatch.py:88` dispatches typed events to adapters.
+
+## Target Architecture
+
+Add `packages/orchestrator/src/runEvents.ts`.
+
+Suggested event union:
+
+```ts
+type AgentRunEvent =
+  | { type: "run_started"; runId: string; surface: string; goalPreview: string }
+  | { type: "assistant_visible_text"; runId: string; text: string; source: "model" | "summary_fallback" }
+  | { type: "tool_call_started"; runId: string; toolName: string; callId?: string; argsPreview: string }
+  | { type: "tool_call_finished"; runId: string; toolName: string; callId?: string; success: boolean; outputPreview: string; evidenceId?: string }
+  | { type: "completion_requested"; runId: string; summary: string; sourcePath: "stream" | "batch" | "direct" | "text_detected" }
+  | { type: "completion_accepted"; runId: string; summary: string }
+  | { type: "completion_held"; runId: string; reasonCode: string; feedback: string }
+  | { type: "completion_incomplete_verification"; runId: string; summary: string; missingEvidence: string[] }
+  | { type: "run_failed"; runId: string; error: string }
+  | { type: "run_finished"; runId: string; status: "completed" | "incomplete" | "incomplete_verification"; success: boolean };
+```
+
+Adapter responsibilities:
+- Telegram public adapter renders only `assistant_visible_text` and bounded progress events.
+- Telegram admin adapter renders provenance sections and incomplete verification status.
+- TUI adapter renders detailed status and tool events.
+- REST/SSE adapter serializes typed events directly.
+
+## Phased Implementation
+
+### Phase 0: Event Inventory
+
+Tasks:
+- List all current `emit({ type: ... })` shapes in `AgenticRunner`.
+- List all Telegram handlers that branch on event type or status string.
+- Add tests for current task_complete filtering and incomplete verification rendering.
+
+Completion metrics:
+- Event inventory exists in a temporary test fixture or doc comment.
+- Current behavior is pinned before refactor.
+
+### Phase 1: Define Event Types and Compatibility Adapter
+
+Tasks:
+- Add `runEvents.ts` with `AgentRunEvent` union and helpers.
+- Add a compatibility function that maps existing runner events to typed events.
+- Do not change runner emission sites yet.
+
+File-by-file notes:
+- `packages/orchestrator/src/runEvents.ts`: new event definitions.
+- `packages/orchestrator/src/index.ts`: export events if CLI imports them.
+- `packages/orchestrator/tests/runEvents.test.ts`: mapping coverage.
+
+Completion metrics:
+- Existing events can be converted without data loss for current fields.
+- Unknown legacy events produce a typed diagnostic rather than throwing.
+
+### Phase 2: Runner Emits Typed Events
+
+Tasks:
+- Replace completion-related emits first:
+  - `completion_requested`
+  - `completion_held`
+  - `completion_accepted`
+  - `completion_incomplete_verification`
+  - `run_finished`
+- Replace tool call start/finish next.
+- Keep legacy event compatibility until all adapters are migrated.
+
+Completion metrics:
+- All four `task_complete` paths emit the same typed completion lifecycle.
+- `incomplete_verification` has its own event type and cannot be mistaken for `completion_accepted`.
+- Tests assert event sequence for approve, request_changes, blocked, and max-cycle incomplete cases.
+
+### Phase 3: Telegram Adapter
+
+Tasks:
+- Add a `TelegramRunEventAdapter` inside `telegram-bridge.ts` or a new `telegram-run-events.ts`.
+- Move task_complete visibility filtering from scattered checks to adapter rules.
+- Render public progress from typed progress/tool events.
+- Render admin final text based on `run_finished.status`.
+
+Completion metrics:
+- Public Telegram never renders `task_complete.summary` directly.
+- Admin Telegram says "completed" only for `status === "completed"`.
+- `incomplete_verification` renders as failed/incomplete with evidence details.
+
+### Phase 4: TUI and REST/SSE Adapters
+
+Tasks:
+- Update TUI progress renderers to use typed tool events.
+- Update REST/SSE event surface if `/v1/run` streams legacy runner events.
+- Document event schema in `docs/rest/endpoints/events.md` if exposed.
+
+Completion metrics:
+- REST clients can distinguish completion accepted from incomplete verification.
+- Existing UI tests pass without relying on status text substrings.
+
+### Phase 5: Remove Legacy String Coupling
+
+Tasks:
+- Delete compatibility paths once callers are migrated.
+- Add source tests that reject direct renderer parsing of key strings:
+  - `task_complete blocked by verification guard`
+  - `INCOMPLETE_VERIFICATION`
+  - `completed:` as authoritative backend status.
+
+Completion metrics:
+- Renderers consume typed status fields.
+- String text remains presentation only.
+
+## Required Tests
+
+- Runner event sequence: successful completion.
+- Runner event sequence: provenance hold.
+- Runner event sequence: critic request_changes then approve.
+- Runner event sequence: critic blocked.
+- Telegram public adapter suppresses internal completion summaries.
+- Telegram admin adapter refuses completed rendering for `incomplete_verification`.
+- REST/SSE event contract snapshot.
+
+## Rollout Plan
+
+1. Add typed definitions and compatibility mapper.
+2. Emit typed completion events.
+3. Migrate Telegram admin completion rendering.
+4. Migrate public progress/rendering.
+5. Migrate REST/SSE.
+6. Remove legacy parsing.
+
+## Risks
+
+- Event duplication during compatibility phase. Mitigation: run IDs and event IDs.
+- UI tests may depend on current strings. Mitigation: update tests to assert typed fields and only snapshot final presentation where necessary.
+- REST consumers may depend on legacy event names. Mitigation: version or dual-emit during one release.
+
+## Definition of Done
+
+- Completion state is represented by typed events, not renderer string parsing.
+- Telegram public/admin rendering cannot mislabel incomplete verification.
+- All task_complete paths emit the same lifecycle.
+- Event schema is tested and documented.

package/docs/work-orders/hermes-architecture-deltas/04-task-local-gateway-context/INDEX.md

@@ -0,0 +1,19 @@
+# Task-Local Gateway Context Index
+
+Progress: not started.
+
+Files in this folder:
+- [WORKORDER.md](WORKORDER.md) - Full phased implementation workorder.
+
+Primary Omnius anchors:
+- `packages/cli/src/tui/telegram-bridge.ts:13149` - tool context resolution.
+- `packages/cli/src/tui/telegram-bridge.ts:13368` - sub-agent state creation.
+- `packages/cli/src/tui/telegram-bridge.ts:16746` - Telegram reply preference tool depends on current message.
+- `packages/cli/src/tui/telegram-bridge.ts:16807` - Telegram image analyze tool depends on current media scope.
+
+Primary Hermes anchors:
+- `/home/robit/Documents/repositories/hermes-agent/gateway/session_context.py:51` - `ContextVar` session fields.
+- `/home/robit/Documents/repositories/hermes-agent/tools/env_passthrough.py:30` - ContextVar-backed environment allowlist.
+
+Completion target:
+- Tools and gateway helpers read current platform/session context from task-local storage instead of captured mutable bridge state when possible.

package/docs/work-orders/hermes-architecture-deltas/04-task-local-gateway-context/WORKORDER.md

@@ -0,0 +1,169 @@
+# Workorder: Task-Local Gateway Context
+
+## Objective
+
+Introduce a task-local gateway context based on Node `AsyncLocalStorage` so Telegram, REST, TUI, scheduler, and background runs can share a common current-session context without mutable cross-run leakage.
+
+## Problem Statement
+
+Current Telegram tools and helpers frequently capture `chatId`, `currentMsg`, `sessionKey`, and tool context in closures. This works, but it makes concurrent run isolation fragile and causes repeated plumbing through many helper constructors.
+
+Hermes uses Python `ContextVar` for gateway session context so tools can resolve active platform/chat/thread/user/run state in an async-safe way.
+
+## Existing Code Anchors
+
+Omnius:
+- `packages/cli/src/tui/telegram-bridge.ts:13149` resolves `ToolContext`.
+- `packages/cli/src/tui/telegram-bridge.ts:13368` creates `TelegramSubAgent`.
+- `packages/cli/src/tui/telegram-bridge.ts:16746` builds reply preference tool using current Telegram message.
+- `packages/cli/src/tui/telegram-bridge.ts:16807` builds image analysis tool using current scoped media.
+- `packages/cli/src/tui/telegram-bridge.ts:17064` builds Telegram file send tool using current chat/admin state.
+- `packages/cli/src/api/serve.ts:7079` registers chat run process leases for API-originated runs.
+
+Hermes:
+- `/home/robit/Documents/repositories/hermes-agent/gateway/session_context.py:51` defines session `ContextVar`s.
+- `/home/robit/Documents/repositories/hermes-agent/gateway/session_context.py:87` synchronizes session id with environment.
+- `/home/robit/Documents/repositories/hermes-agent/tools/env_passthrough.py:30` uses `ContextVar` for per-session environment allowlists.
+
+## Target Architecture
+
+Add `packages/orchestrator/src/runContext.ts` or `packages/cli/src/runtime/run-context.ts` depending on ownership.
+
+Suggested type:
+
+```ts
+export interface OmniusRunContext {
+  runId: string;
+  surface: "tui" | "telegram" | "api" | "scheduler" | "background";
+  projectRoot?: string;
+  ownerKind?: string;
+  ownerId?: string;
+  telegram?: {
+    chatId: string | number;
+    chatType: "private" | "group" | "supergroup" | "channel";
+    messageId?: number;
+    threadId?: number;
+    userId?: number;
+    username?: string;
+    sessionKey: string;
+    toolContext: string;
+  };
+}
+```
+
+API:
+- `runWithOmniusContext(ctx, fn)`
+- `getOmniusRunContext()`
+- `requireOmniusRunContext()`
+- `getTelegramRunContext()`
+
+## Phased Implementation
+
+### Phase 0: Concurrency Regression Tests
+
+Tasks:
+- Add tests that run two simulated Telegram messages concurrently and prove media/reply tools resolve the correct chat state.
+- Add a test that no context is visible outside `runWithOmniusContext`.
+
+Completion metrics:
+- Current behavior is characterized before migration.
+- Tests fail if global mutable context leaks across runs.
+
+### Phase 1: Add Context Store
+
+Tasks:
+- Implement `AsyncLocalStorage<OmniusRunContext>`.
+- Add small helpers and type guards.
+- Keep it dependency-free.
+
+File-by-file notes:
+- `packages/orchestrator/src/runContext.ts` if runner and execution packages should share it.
+- `packages/cli/src/tui/telegram-bridge.ts` imports helpers when spawning sub-agents.
+- `packages/execution/src/tools/*` should not import CLI internals, so put shared helpers outside CLI if execution tools will consume them.
+
+Completion metrics:
+- Unit tests prove nested async calls retain the correct context.
+- Missing context produces clear errors only in helpers that require it.
+
+### Phase 2: Wrap Run Entrypoints
+
+Tasks:
+- Wrap Telegram sub-agent execution with context.
+- Wrap Telegram quick-chat execution with context.
+- Wrap REST/API run execution with context.
+- Wrap background/scheduler execution if the owner id is available.
+
+Completion metrics:
+- Each run emits a context diagnostic with run id and surface.
+- Existing tool behavior remains unchanged.
+
+### Phase 3: Migrate Telegram Tools Incrementally
+
+Tasks:
+- Update tools that currently capture `currentMsg` to prefer task-local context:
+  - reply preference,
+  - image/media analysis,
+  - file send target defaults,
+  - reminder scope,
+  - identity memory media resolution.
+- Keep explicit constructor arguments as fallback during migration.
+
+Completion metrics:
+- Tools work when called through current explicit path.
+- Tests prove task-local path works without passing current message through every helper.
+
+### Phase 4: Process Lease Integration
+
+Tasks:
+- When registering process leases, default `ownerKind`, `ownerId`, and `projectRoot` from current run context.
+- Ensure child environment receives:
+  - `OMNIUS_PROCESS_LEASE_ID`,
+  - `OMNIUS_OWNER_ID`,
+  - `OMNIUS_PROJECT_ROOT`,
+  - optional `OMNIUS_RUN_ID`.
+
+Completion metrics:
+- Shell/background/API spawned children have correct owner fields without duplicate call-site logic.
+- Process lifecycle tests still pass.
+
+### Phase 5: Cleanup and Docs
+
+Tasks:
+- Remove redundant parameters only after all call sites are migrated.
+- Document the context lifecycle and prohibited usage:
+  - never store mutable message objects long-term,
+  - never use context outside the current async run,
+  - never infer authorization from context alone.
+
+Completion metrics:
+- Docs exist under `docs/architecture/`.
+- Source tests prevent direct global current-message variables if any are introduced.
+
+## Required Tests
+
+- Async context isolation under concurrent Telegram runs.
+- No context outside wrapper.
+- Telegram media tool resolves correct chat with context.
+- API run context sets lease owner.
+- Background task context sets lease owner.
+
+## Rollout Plan
+
+1. Add context store and tests.
+2. Wrap run entrypoints.
+3. Migrate read-only tools.
+4. Migrate mutating tools with explicit authorization checks preserved.
+5. Remove redundant plumbing.
+
+## Risks
+
+- Async context can be lost through unawaited promises. Mitigation: tests around timers, streaming callbacks, and tool executors.
+- Authorization confusion. Mitigation: context identifies session but does not grant permission.
+- Package dependency cycles. Mitigation: place shared context in orchestrator or a small shared package, not CLI.
+
+## Definition of Done
+
+- Current run context is available task-locally across Telegram, API, and background execution.
+- Concurrent sessions do not bleed state.
+- Tools can use context without importing Telegram bridge internals.
+- Process leases can inherit owner metadata from context.

package/docs/work-orders/hermes-architecture-deltas/05-process-lifecycle-monitoring-notifications/INDEX.md

@@ -0,0 +1,22 @@
+# Process Lifecycle Monitoring Notifications Index
+
+Progress: not started.
+
+Files in this folder:
+- [WORKORDER.md](WORKORDER.md) - Full phased implementation workorder.
+
+Primary Omnius anchors:
+- `packages/execution/src/process-lifecycle.ts:18` - 10 minute stale threshold.
+- `packages/execution/src/process-lifecycle.ts:316` - lease registration.
+- `packages/execution/src/process-lifecycle.ts:448` - lease sweep.
+- `packages/execution/src/process-lifecycle.ts:556` - sweeper start.
+- `packages/cli/src/api/serve.ts:6639` - scheduler kill route.
+- `packages/cli/src/api/serve.ts:9139` - port holder handling.
+- `packages/cli/src/daemon.ts:217` - daemon stop lease path.
+
+Primary Hermes anchors:
+- `/home/robit/Documents/repositories/hermes-agent/tools/process_registry.py:137` - Hermes process registry class.
+- `/home/robit/Documents/repositories/hermes-agent/gateway/run.py:9621` - process watcher delivery path.
+
+Completion target:
+- Omnius keeps its registry-based kill authority, adds better watcher/notification coverage, and removes remaining pattern-only or direct legacy kill paths where lease ownership can be used.

package/docs/work-orders/hermes-architecture-deltas/05-process-lifecycle-monitoring-notifications/WORKORDER.md

@@ -0,0 +1,189 @@
+# Workorder: Process Lifecycle Monitoring Notifications
+
+## Objective
+
+Extend Omnius's registry-based process lifecycle architecture with active monitoring, user-visible diagnostics, and cleanup of remaining direct legacy kill paths. Keep the lease registry as the only authority for automatic stale process termination.
+
+## Problem Statement
+
+Omnius already has the stronger ownership model:
+- durable leases,
+- 10 minute stale threshold,
+- identity verification,
+- persistent lease support,
+- sweeper lock and periodic cleanup.
+
+The remaining opportunity from Hermes is not to replace that registry. It is to add watcher delivery, richer diagnostics, and to finish absorbing call sites that still use direct `process.kill` for stale or spawned work where a lease can be the authority.
+
+## Existing Code Anchors
+
+Omnius:
+- `packages/execution/src/process-lifecycle.ts:18` sets `PROCESS_LEASE_STALE_MS = 10 * 60_000`.
+- `packages/execution/src/process-lifecycle.ts:316` registers leases.
+- `packages/execution/src/process-lifecycle.ts:448` sweeps stale leases.
+- `packages/execution/src/process-lifecycle.ts:503` verifies process identity before kill.
+- `packages/execution/src/process-lifecycle.ts:556` starts the periodic sweeper.
+- `packages/execution/src/tools/shell.ts:426` creates shell lease ids.
+- `packages/execution/src/tools/background-task.ts:45` creates background task lease ids.
+- `packages/cli/src/api/serve.ts:6639` handles `/v1/scheduled/kill` through leases.
+- `packages/cli/src/api/serve.ts:9139` handles stale port holders.
+- `packages/cli/src/daemon.ts:217` stops daemon leases before direct signal.
+- `packages/execution/tests/process-lifecycle.test.ts:120` covers stale lease kill.
+- `packages/cli/tests/process-cleanup-regression.test.ts:37` asserts `/destroy processes` is registry-backed.
+
+Hermes:
+- `/home/robit/Documents/repositories/hermes-agent/tools/process_registry.py:137` defines `ProcessRegistry`.
+- `/home/robit/Documents/repositories/hermes-agent/gateway/run.py:9621` drains pending process watchers.
+
+## Target Architecture
+
+Keep current lease registry APIs and add:
+- watcher events emitted by sweeper:
+  - `lease_stale_detected`,
+  - `lease_kill_attempted`,
+  - `lease_killed`,
+  - `lease_suspect_unverified`,
+  - `legacy_untracked_reported`.
+- a diagnostic endpoint and TUI summary:
+  - active leases,
+  - stale leases,
+  - suspect leases,
+  - untracked report-only Omnius-like processes,
+  - last sweep summary.
+- adoption hooks for reliable legacy records only:
+  - daemon pid files,
+  - scheduler job records,
+  - expose state,
+  - Nexus pid files,
+  - in-flight chat records.
+
+## Phased Implementation
+
+### Phase 0: Direct Kill Inventory
+
+Tasks:
+- Audit every `process.kill` in CLI/API/daemon code.
+- Classify each call as:
+  - liveness probe,
+  - current process shutdown,
+  - leased child kill,
+  - legacy direct kill needing migration,
+  - report-only diagnostic.
+
+Completion metrics:
+- A short inventory exists in the work PR.
+- Source tests cover the highest-risk paths.
+
+### Phase 1: Sweeper Watcher Events
+
+Tasks:
+- Add optional callback to `startProcessLeaseSweeper` and `sweepProcessLeases`.
+- Emit structured events for every sweep action.
+- Keep event emission best-effort and never block cleanup.
+
+File-by-file notes:
+- `packages/execution/src/process-lifecycle.ts`: add event callback type.
+- `packages/execution/tests/process-lifecycle.test.ts`: assert watcher callback receives stale, killed, and suspect actions.
+
+Completion metrics:
+- Sweeper emits action list and summary.
+- Test fake system verifies callbacks without real process kills.
+
+### Phase 2: TUI/API Diagnostics
+
+Tasks:
+- Add API endpoint:
+  - `GET /v1/processes/leases`
+  - optional `POST /v1/processes/sweep`
+- Add TUI `/destroy processes` output sections:
+  - killed registered leases,
+  - active leases,
+  - suspect unverified,
+  - untracked report-only diagnostics.
+- Keep `/destroy processes --global` lease registry only; no pattern-authorized kills.
+
+Completion metrics:
+- `/destroy processes` output clearly distinguishes killed vs report-only.
+- Unleased Omnius-like processes are never killed automatically.
+- Tests assert response shape and no pattern kill path.
+
+### Phase 3: Migrate Remaining Legacy Kill Paths
+
+Tasks:
+- For child processes spawned by API `/v1/run`, chat runs, installers, expose, Nexus, voice/model helpers, ensure registration exists before spawn can outlive the parent.
+- Replace direct deadline kills with `stopProcessLease` when a lease exists.
+- Keep direct signal only as fallback for current-process shutdown or when no lease exists and the action is explicitly user-owned.
+
+High-priority anchors:
+- `packages/cli/src/api/serve.ts:3627` direct child deadline kill.
+- `packages/cli/src/api/serve.ts:4411` RCA/job child kill.
+- `packages/cli/src/api/serve.ts:4779` task cascade kill.
+- `packages/cli/src/api/serve.ts:7294` chat run deadline kill.
+- `packages/cli/src/api/serve.ts:9139` port holder handling.
+- `packages/cli/src/daemon.ts:241` pid-file direct kill.
+
+Completion metrics:
+- Any automatic kill of a spawned child uses a lease when one exists.
+- PID-file adoption marks reliable records before kill where possible.
+- Source tests block new pattern-authorized kill functions.
+
+### Phase 4: Reliable Adoption
+
+Tasks:
+- Add adoption helpers per reliable source:
+  - `adoptDaemonPidFileLease`,
+  - `adoptSchedulerLease`,
+  - `adoptExposeLease`,
+  - `adoptNexusLease`,
+  - `adoptInFlightChatLease`.
+- Adoption must record original source and identity basis.
+- Adoption failure produces `suspect_unverified` or report-only output, not kill.
+
+Completion metrics:
+- Pre-registry daemon pid can be adopted when identity matches.
+- Unreadable or mismatched PID is report-only.
+- Tests cover PID reuse protection.
+
+### Phase 5: Notifications and Rate Limits
+
+Tasks:
+- Send compact TUI notification when sweeper kills stale Omnius-owned children.
+- Admin Telegram may optionally receive a summary for high-severity repeated stale cleanup if configured.
+- Rate-limit notifications to avoid chat noise.
+
+Completion metrics:
+- Operators see cleanup summaries without flooding.
+- Notification includes lease id, owner, lifecycle, reason, and action.
+
+## Required Tests
+
+- Active task lease survives sweep.
+- Heartbeat-stale task lease is killed after identity verification.
+- Completed owner kills non-persistent children.
+- Persistent scheduler/reminder lease survives.
+- Expired persistent lease is killed.
+- Unverified PID is reported but not killed.
+- Watcher callback receives action events.
+- Legacy pid adoption succeeds only from reliable files.
+- `/destroy processes` and `/scheduler kill` remain registry-backed.
+
+## Rollout Plan
+
+1. Add watcher callbacks and diagnostics without changing kill behavior.
+2. Add endpoint/TUI summaries.
+3. Migrate direct child kills one call site at a time.
+4. Add reliable adoption.
+5. Add optional Telegram/admin notifications.
+
+## Risks
+
+- Killing wrong process if adoption is too broad. Mitigation: adopt only from reliable records and retain identity verification.
+- Leaking stale children during migration. Mitigation: source tests and sweep diagnostics.
+- Notification noise. Mitigation: rate limit and admin-only delivery.
+
+## Definition of Done
+
+- Automatic cleanup only kills verified registered/adopted leases.
+- Remaining direct kills are documented as current-process or explicit user-owned actions.
+- Sweeper activity is observable through API/TUI and tests.
+- Legacy Omnius-like processes are report-only unless ownership is reliable.

package/docs/work-orders/hermes-architecture-deltas/06-vision-evidence-routing-ladder/INDEX.md

@@ -0,0 +1,22 @@
+# Vision Evidence Routing Ladder Index
+
+Progress: not started.
+
+Files in this folder:
+- [WORKORDER.md](WORKORDER.md) - Full phased implementation workorder.
+
+Primary Omnius anchors:
+- `packages/cli/src/tui/telegram-bridge.ts:1275` - public Telegram vision/media stack prompt.
+- `packages/cli/src/tui/telegram-bridge.ts:16807` - Telegram image analysis tool.
+- `packages/cli/src/tui/telegram-bridge.ts:17393` - Telegram media processing.
+- `packages/execution/src/tools/vision.ts` - core vision tool.
+- `packages/execution/src/tools/ocr-image-advanced.ts` - OCR tool.
+- `packages/cli/tests/telegram-media-evidence.test.ts` - Telegram media evidence tests.
+
+Primary Hermes anchors:
+- `/home/robit/Documents/repositories/hermes-agent/tools/computer_use/vision_routing.py:118` - capture routing decision.
+- `/home/robit/Documents/repositories/hermes-agent/tools/vision_tools.py:599` - native vision fast-path check.
+- `/home/robit/Documents/repositories/hermes-agent/tools/vision_tools.py:797` - auxiliary vision analysis tool.
+
+Completion target:
+- Telegram and tool callers resolve image input reliably and choose cheap observation, OCR, or auxiliary vision from the request-derived evidence need.