omnius 1.0.811 → 1.0.813

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js CHANGED
@@ -1,4 +1,4 @@
1
1
  [diffend] Oversized file quarantined before diffing.
2
2
  name: package/dist/index.js
3
- size: 41440515 bytes
4
- sha256: 9640eabe6501fbee41cb81f68bfc7d1df8f5adc8e7ccabcb95ea1964421ef4d0
3
+ size: 34612673 bytes
4
+ sha256: 32b8ef11e773bbf71fd93ebd34f5c95217a9ff0995bc6a8f486e2457df1d3f07
@@ -29473,6 +29473,41 @@
29473
29473
  }
29474
29474
  ]
29475
29475
  },
29476
+ {
29477
+ "id": "guide.engineering-telegram-task-context-repair-20261007",
29478
+ "kind": "guide",
29479
+ "title": "Telegram task context repair: evidence, research, and acceptance contract",
29480
+ "summary": "Date: 2026-10-07. Status: design induction for an isolated repair; this document does not certify live Telegram behavior.",
29481
+ "keywords": [
29482
+ "engineering",
29483
+ "telegram",
29484
+ "task",
29485
+ "context",
29486
+ "repair",
29487
+ "20261007",
29488
+ "md"
29489
+ ],
29490
+ "maturity": "stable",
29491
+ "audiences": [
29492
+ "user",
29493
+ "integrator",
29494
+ "coding-agent"
29495
+ ],
29496
+ "layer": "documentation",
29497
+ "interfaces": [
29498
+ {
29499
+ "type": "file",
29500
+ "target": "docs/engineering/telegram-task-context-repair-20261007.md"
29501
+ }
29502
+ ],
29503
+ "references": [
29504
+ {
29505
+ "type": "documentation",
29506
+ "target": "docs/engineering/telegram-task-context-repair-20261007.md",
29507
+ "relation": "canonical-artifact"
29508
+ }
29509
+ ]
29510
+ },
29476
29511
  {
29477
29512
  "id": "guide.ephemeral-skill-pack-small-context",
29478
29513
  "kind": "guide",
package/docs/DISCOVERY.md CHANGED
@@ -428,6 +428,7 @@ Daemon equivalents are `GET /v1/discovery/bootstrap`, `GET /v1/discovery?q=<inte
428
428
  | `guide.discovery-markdown` | Omnius Discovery Catalog | Human-readable generated index of every discoverable Omnius capability and bundled documentation artifact. |
429
429
  | `guide.duplicate-calls-root-cause-analysis` | Duplicate Tool Calls — Root Cause Analysis | The agent repeatedly calls the same tool with the same arguments (e.g., fileread on the same path, grepsearch with the same pattern, shell with the same command). This wastes turns, burns context, and creates visible "looping" behavior. |
430
430
  | `guide.duplicate-calls-root-cause-deep` | Duplicate Tool Calls — Deep Root Cause Analysis | The agent repeatedly calls the same tool with the same arguments right after having already called it. This is visible even in this agent's own conversation — fileread and grepsearch calls get duplicated within 1-2 turns. |
431
+ | `guide.engineering-telegram-task-context-repair-20261007` | Telegram task context repair: evidence, research, and acceptance contract | Date: 2026-10-07. Status: design induction for an isolated repair; this document does not certify live Telegram behavior. |
431
432
  | `guide.ephemeral-skill-pack-small-context` | Ephemeral Skill Pack Small-Context Plan | AIWG and Omnius skills are valuable, but full SKILL.md bodies are too large for small and medium context windows. The main agent should see only a tiny, task-scoped skill manifest, then delegate full skill unpacking to a sub-agent that returns a compact extraction. |
432
433
  | `guide.explorations-context-window-todo-association` | Exploration: Associating Context-Window Entries with Todo-Scoped Run Periods | Goal (from user): Understand how granular context-window entries (messages / tool results) are associated with periods of an agentic run, and specifically whether they are tied to a todo item so that, when that todo completes, its context content can be compressed. |
433
434
  | `guide.explorations-todo-association-verify` | Todo Association Verify | Bundled Omnius documentation artifact: docs/explorations/todo-association-verify.json. |
@@ -0,0 +1,115 @@
1
+ # Telegram task context repair: evidence, research, and acceptance contract
2
+
3
+ Date: 2026-10-07. Status: design induction for an isolated repair; this document does not certify live Telegram behavior.
4
+
5
+ ## Observed incident
6
+
7
+ The local native intake and saved request dumps establish a host provenance defect before primary inference:
8
+
9
+ | Evidence | Observation | What it establishes |
10
+ | --- | --- | --- |
11
+ | Native message `3140` | A PDF and its caption requested document extraction into weekly totals and deductions. | The attachment and requested result were available to the host. |
12
+ | Native message `3142` | “pick this up” explicitly replied to `3140`; its retained reply metadata included the document caption and attachment identity. | The follow-up had a concrete native antecedent. |
13
+ | Earlier message `3075` | An unresolved remote-access objective remained in the same conversation. | There was competing historical task state, not a new instruction to perform that task. |
14
+ | Saved main requests at `08:21:49Z`, `08:22:34Z`, and `08:23:23Z` | A host-generated causal-meaning section described `3075` as the original referenced request while also reporting the native edge `3142 → 3140`. It relied on the earlier admitted interpretation of `3140` citing the older task. | Derived interpretation was promoted into source lineage, contaminating the current objective. |
15
+ | The same requests' admission receipts | An observed context ceiling of `8192`, conservative input estimates of `8671` or `8931`, a `492` token safety margin, and rejected admission with zero admitted output. | A separate capacity failure prevented primary transport. |
16
+
17
+ Message numbers above are meaningful only within the incident's exact conversation and topic. Private conversation identities, attachment identifiers, raw prompts, and host paths are intentionally omitted.
18
+
19
+ The old requests retained both the document evidence and the wrong projected objective. The primary runner's zero turns and zero tool calls therefore do **not** demonstrate that the primary model forgot or preferred the older request: those primary requests were rejected before inference. Earlier routing decisions and host projection are distinct stages.
20
+
21
+ The `8192` rejection was a real enforced limit at that boundary, even though its origin could be stale transport policy rather than the model's architectural maximum. Repair the verified model/server capacity and resource admission separately; preserve genuine hardware ceilings. Increasing capacity alone cannot correct misattributed input provenance.
22
+
23
+ ## Primary sources inducted
24
+
25
+ Full PDFs and the complete engineering article were acquired and read, including methods, evaluation, and limitations. Large source copies remain outside the repository. The quality labels below are an engineering adaptation of GRADE: confidence in the reported evidence and its transfer to this design, not a clinical assessment.
26
+
27
+ ### R1 — Positional sensitivity
28
+
29
+ Liu et al., *Lost in the Middle: How Language Models Use Long Contexts*, arXiv v3, 2023; accepted at TACL. [Primary paper](https://arxiv.org/abs/2307.03172v3).
30
+
31
+ Sections 2–4 vary relevant-document position and context length in question answering and synthetic key-value retrieval. Accuracy often falls when relevant information is in the middle; some models perform key-value retrieval nearly perfectly. Appendix C preserves the main pattern after randomizing distractor order. Section 4.2 finds that placing the query before and after data helps key-value retrieval substantially but does not reliably solve multi-document answering.
32
+
33
+ Quality: **MODERATE** for the controlled positional finding. Limitations: the evaluated model generations and tasks differ from this deployment; these experiments do not diagnose a host lineage bug or establish that prompt placement fixes it.
34
+
35
+ ### R2 — Instruction provenance and positive controls
36
+
37
+ Wallace et al., *The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions*, arXiv v1, 2024. [Primary paper](https://arxiv.org/abs/2404.13208v1).
38
+
39
+ Sections 3–4 train GPT-3.5 Turbo with synthetic aligned and conflicting instructions using supervised fine-tuning and RLHF. The evaluation measures attack robustness **and** compliance with benign, aligned instructions. Section 4 reports some over-refusal regressions; Appendix A finds training more effective than a hierarchy prompt alone. Sections 5–6 describe complementary system safeguards and acknowledge remaining vulnerabilities and text-only scope.
40
+
41
+ Quality: **MODERATE** for the reported training comparison; limited direct transfer to an unmodified local model. This is not evidence that the incident was an attack, that a new prompt confers equivalent training, or that all historical user context should be ignored.
42
+
43
+ ### R3 — Context selection and durable state
44
+
45
+ Anthropic Applied AI, *Effective context engineering for AI agents*, September 29, 2025. [Official engineering article](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents).
46
+
47
+ The article recommends selecting useful context on each inference cycle, clear section boundaries, unambiguous tools, and just-in-time retrieval from lightweight references. Its long-horizon discussion covers compaction and persistent structured notes while warning that aggressive compression can lose critical details. It discourages brittle collections of special-case instructions and recommends diverse canonical examples.
48
+
49
+ Quality: **LOW** as causal evidence for this incident: this is practitioner guidance without a controlled evaluation of this Telegram implementation. It supports investigating context assembly and persistence; it does not prove a particular format, token count, or model will resolve continuation correctly.
50
+
51
+ ## Design inference for this repair
52
+
53
+ The following decisions are engineering inferences from the incident and sources, not findings established by those publications.
54
+
55
+ 1. **Keep native facts separate from interpretation.** Preserve current input identity, exact human text, reply edges, attachment identity, and causal boundary as immutable source facts. A prior routing decision is a dated interpretation with its own provenance. It must not manufacture a native edge or become an “original request” merely by citing an open task.
56
+
57
+ 2. **Let the model determine meaning within validated scope.** Supply the current request and its native antecedents, plus clearly labeled candidate task context. Validate any model-selected continuation against the exact current input, actor, conversation/topic, task identity, contract, and decision receipt. A host fallback may report unresolved routing; it cannot invent a continuation citation or silently admit an unchecked zero-tool actor.
58
+
59
+ 3. **Preserve valid continuation.** An explicit, validated continuation may retain its exact older objective and relevant evidence. Do not fix the negative example by deleting all older context, always starting a new task, banning a subject, or recognizing a phrase such as “pick this up.” A native reply is evidence for resolving meaning, not universal permission to execute any quoted instruction.
60
+
61
+ 4. **Retain displaced work durably.** A newly admitted independent objective can become current while the old unresolved task remains addressable by identity. Persist the old task's objective, resources, evidence, and effect state. Late callbacks for it must not replace the new current task. Restart and compaction must preserve this separation.
62
+
63
+ 5. **Bind effects and completion to the admitted task.** Prior resources, grants, delivery destinations, effect receipts, and verification receipts must not transfer to an unrelated task. Unknown or ambiguous effects remain reconciliation blockers. A new task needs its own grounded observations and delivery evidence; emitting a plausible answer or changing status cannot substitute for those receipts.
64
+
65
+ 6. **Preserve typed capacity failures.** The terminal record should retain the exact run/epoch-bound rejected admission receipt, numeric budget, and safe diagnostic reference. Stop unchanged automatic replay of a deterministic pre-transport rejection. A changed verified capacity or explicit fresh input can be reassessed through ordinary admission. Do not truncate protected task facts, expose private prompt contents, or mark the task complete to escape the failure.
66
+
67
+ ## Acceptance contract without reward hacking
68
+
69
+ Use mocked routing and transport for deterministic regression tests. The oracle is the admitted identity and evidence lineage at the actual runner boundary, not a preferred natural-language response or a fabricated successful completion.
70
+
71
+ | Scenario | Required assertion |
72
+ | --- | --- |
73
+ | Independent document objective beside unresolved older work | The new admitted task retains the document request and bound attachment. Older objective/resources/effect/verifier receipts do not appear as current ownership or completion evidence. |
74
+ | Reply to that document | Resolve the native antecedent and caption. A legacy host-authored task citation cannot redefine the source request. |
75
+ | Legitimate older-task continuation | A fresh validated continuation selecting the exact owned task retains its objective and evidence and remains executable under a fresh valid grant. This positive control must pass alongside isolation. |
76
+ | Reordered and extended context | Move candidate tasks and irrelevant history before, between, and after the relevant source; vary IDs, captions, filenames, and unrelated task subjects. Native provenance and admission decisions must remain correctly bound. |
77
+ | Persistence and late callbacks | Save and restore multiple unresolved tasks; restart; then deliver an older task callback. The old record survives and cannot overwrite the current task. |
78
+ | Task-scoped effects | Seed an older applied receipt, verifier receipt, resource manifest, and separately an ambiguous effect. No unrelated task inherits them; ambiguity is preserved rather than reset. |
79
+ | Invalid router payload | No unchecked primary actor launches. Keep the exact input and a bounded, truthful routing failure diagnostic. |
80
+ | Context admission rejection | Zero primary transport calls, immutable matching failure receipt, truthful incomplete status, no blind primary recovery, and no raw prompt or secret in the public diagnostic. |
81
+
82
+ Also vary whether a prior decision is model-authored, host-authored, malformed, stale, or bound to another input. Test actual persistence and request projection rather than assertions that merely repeat the implementation's helper output.
83
+
84
+ Production code must not branch on these message numbers, the document's subject, the older objective's topic, or a test-specific phrase. Do not fabricate observed evidence, widen tool authority, clear unresolved tasks, weaken verification, or suppress failure reporting to make a test pass.
85
+
86
+ ## Implementation and validation references
87
+
88
+ - [Telegram bridge](../../packages/cli/src/tui/telegram-bridge.ts): native causal source collection, causal-meaning projection, current-task admission, durable task retention, and outer recovery.
89
+ - [Objective isolation regression](../../packages/cli/tests/telegram-pdf-objective-isolation.test.ts): incident-shaped mocked admission, host citation provenance, positive continuation, persistence, and terminal rejection handling.
90
+ - [Terminal report tests](../../packages/orchestrator/tests/terminal-task-report.test.ts) and [runner boundary tests](../../packages/orchestrator/tests/terminal-task-report-runner.test.ts): immutable typed failure projection, scope checks, redaction, and no pre-transport inference.
91
+ - Related existing work: [canonical context projection](../work-orders/runtime-health-remediation/WO-04-canonical-context-projection.md) and [durable intake health](../work-orders/runtime-health-remediation/WO-06-durable-telegram-intake-health.md).
92
+
93
+ These links identify implementation and regression targets. They do not claim every acceptance row is already covered or that a live extraction has succeeded. Record the final tested revision and any remaining coverage separately in the delivery report.
94
+
95
+ ## Limits of this induction
96
+
97
+ The local artifacts prove the native-source/projection mismatch and the rejected 8K primary requests. They do not isolate every earlier routing model error or establish successful document extraction after repair. The three publications motivate the design and evaluation; none validates this deployment. Live behavior requires a separately authorized end-to-end check under the host's hardware and delivery policies.
98
+
99
+ ## Follow-up: stale auxiliary capacity and repeated quick-chat failures
100
+
101
+ Later group intakes repeatedly deferred quick-chat failures as transient no-delivery events. The exact reported 10,757-token rejection was not retained in those journals, so its numeric limit cannot be established from that evidence. Source inspection did establish two remaining downgrade paths: a global, indefinitely cached training-context lookup could lower verified model capacity, and cached live discovery could hide a newer host policy for the same model. A producer could also reject against cached capacity before final transport admission refreshed it.
102
+
103
+ Refresh read-only metadata using the selected backend's own model, endpoint, and credentials before producer admission. Under verified maximum policy, use the negotiated capacity, including any real hard/resource limit, rather than a stale producer preference or unrelated global training cache. Preserve protected source input. A genuine overflow retains its typed accounting receipt, ends the intake as failed, and cannot become an endless quick-chat or JSON/plain retry. A newer queued input retains its independent ownership.
104
+
105
+ Regression checks must exercise stale 8K metadata with fresh 262,144-token capacity, the quick-chat producer's stale declared window, and a genuine 8K hard limit as a negative control. Mocked metadata and dispatch establish host behavior; they do not certify a live Telegram answer or completed PDF extraction. Publishing requires a fresh bundle, and an already running TUI adopts that code only through restart or its supported update handoff.
106
+
107
+ ## Follow-up: GUI transport and active backend capacity
108
+
109
+ A later daemon GUI failure had a different boundary defect. Its captured request omitted `numCtx`, reported `unknown_limit`, and used OpenAI chat for an Ollama model whose wrapper fixed `num_ctx` at 199,680. Exact read-only discovery admitted the model's architectural maximum of 262,144 and reported the OpenAI wrapper incompatible. The broker's HTTP 422 correctly rejected that wire contract; the protected input itself did not exceed the native maximum.
110
+
111
+ The CLI's Cascade wrapper must expose the active delegate's capability and refresh it before runner context assembly. Capacity, observed server limits, and recovery pressure belong to that exact transport/model/credential scope. Switching delegates retires cached limits from the previous scope; temporary metadata loss within the same scope retains verified capacity. Run-owned cancellation reaches metadata requests and newly created delegates.
112
+
113
+ For an Ollama protocol, a positive admitted context or verified managed capability selects native `/api/chat` directly, carrying `options.num_ctx`. Unknown managed model metadata is resolved using that backend's own endpoint, model, and credentials. Explicit OpenAI providers retain their JSON/SSE transport. Native failures are not replayed through OpenAI compatibility. Tests assert the actual unary and streaming wire contract, complete source/tool messages, split UTF-8/NDJSON framing, authentication, logical request identity, real hard limits, startup admission, and Stop during metadata refresh. Broker validation remains intact.
114
+
115
+ The idle GPU lease reminder is separately a presentation defect: an explicitly empty lease list is healthy state, while acquisition requirements remain in `lease_policy`. The broker should emit warnings for existing reservations, unknown live state, GPU health faults, and quarantine. Older broker compatibility in the CLI removes only the exact idle notice paired with a valid empty list; it does not infer that an unavailable or malformed list is empty.
@@ -1,12 +1,12 @@
1
1
  {
2
2
  "name": "omnius",
3
- "version": "1.0.811",
3
+ "version": "1.0.813",
4
4
  "lockfileVersion": 3,
5
5
  "requires": true,
6
6
  "packages": {
7
7
  "": {
8
8
  "name": "omnius",
9
- "version": "1.0.811",
9
+ "version": "1.0.813",
10
10
  "bundleDependencies": [
11
11
  "image-to-ascii"
12
12
  ],
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "omnius",
3
- "version": "1.0.811",
3
+ "version": "1.0.813",
4
4
  "description": "AI coding agent powered by open-source models (Ollama/vLLM) — interactive TUI with agentic tool-calling loop",
5
5
  "type": "module",
6
6
  "main": "./dist/library.js",