omnius 1.0.695 → 1.0.697

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.
Files changed (31) hide show
  1. package/dist/api/py-embed.js +4215 -2598
  2. package/dist/index.js +41242 -35198
  3. package/dist/library.js +8063 -6080
  4. package/dist/python-cuda-runtime.js +512 -0
  5. package/dist/update-worker.js +4250 -2633
  6. package/docs/DISCOVERY.json +802 -1
  7. package/docs/DISCOVERY.md +22 -1
  8. package/docs/guides/long-horizon-feature-workflow.md +42 -0
  9. package/docs/research/aiwg-long-horizon-feature-workflow.md +94 -0
  10. package/docs/work-orders/long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md +122 -0
  11. package/docs/work-orders/runtime-health-remediation/TOOL-QUALITY-2026-09-05.md +84 -0
  12. package/docs/work-orders/runtime-health-remediation/TRACKER.md +48 -1
  13. package/docs/work-orders/runtime-health-remediation/WO-30-structured-tool-invocation.md +65 -0
  14. package/docs/work-orders/runtime-health-remediation/WO-31-complete-runtime-policy.md +62 -0
  15. package/docs/work-orders/runtime-health-remediation/WO-32-evidence-dependent-steering.md +55 -0
  16. package/docs/work-orders/runtime-health-remediation/WO-33-file-mutation-transactions.md +55 -0
  17. package/docs/work-orders/runtime-health-remediation/WO-34-shell-authority-and-results.md +46 -0
  18. package/docs/work-orders/runtime-health-remediation/WO-35-search-and-exploration-isolation.md +56 -0
  19. package/docs/work-orders/runtime-health-remediation/WO-36-media-evidence-integrity.md +44 -0
  20. package/docs/work-orders/runtime-health-remediation/WO-37-browser-and-process-lifecycle.md +86 -0
  21. package/docs/work-orders/runtime-health-remediation/WO-37-point-localization-cancellation.md +24 -0
  22. package/docs/work-orders/runtime-health-remediation/WO-38-tool-contract-preservation.md +83 -0
  23. package/docs/work-orders/runtime-health-remediation/WO-39-telegram-working-indicator.md +76 -0
  24. package/docs/work-orders/runtime-health-remediation/WO-40-web-content-and-crawl-receipts.md +44 -0
  25. package/docs/work-orders/runtime-health-remediation/WO-41-completion-evidence-consistency.md +45 -0
  26. package/docs/work-orders/runtime-health-remediation/WO-42-media-execution-and-configuration.md +79 -0
  27. package/docs/work-orders/runtime-health-remediation/WO-43-telegram-router-progress-boundary.md +71 -0
  28. package/docs/work-orders/runtime-health-remediation/WO-44-evidence-backed-terminal-results.md +56 -0
  29. package/docs/work-orders/runtime-health-remediation/WO-45-native-ollama-tool-contract.md +33 -0
  30. package/npm-shrinkwrap.json +5 -5
  31. package/package.json +1 -1
package/docs/DISCOVERY.md CHANGED
@@ -434,6 +434,7 @@ Daemon equivalents are `GET /v1/discovery/bootstrap`, `GET /v1/discovery?q=<inte
434
434
  | `guide.guides-agent-integration` | Agent And Service Integration | An integration should discover Omnius at runtime instead of encoding a partial provider or tool list. |
435
435
  | `guide.guides-bring-your-own-inference` | Bring Your Own Inference | Omnius routes local and hosted models through an explicit provider descriptor. The descriptor determines the wire protocol, URL paths, authentication headers, and supported operations. It is the source of truth used by setup, model discovery, TUI runs, REST chat, summaries, voice, Telegram, sponsors, and endpoint probes. |
436
436
  | `guide.guides-dashboard` | Web Dashboard | The Omnius daemon serves a zero-build, self-contained dashboard from the same origin as the REST API. Start it with omnius serve, then open http://127.0.0.1:11435/. The interface uses Omnius's compact NOCLIP-derived style kit and shared responsive observability-card grids; the route registry in packages/cli/src/api/web-ui.ts is the source of truth for pages |
437
+ | `guide.guides-long-horizon-feature-workflow` | Long-horizon feature work | Implementation, acceptance cases and delivery records are tracked in WO-01. |
437
438
  | `guide.guides-media-generation` | Media Generation | Omnius exposes media generation through TUI commands, tools, Telegram creative workflows, and sponsor media endpoints. |
438
439
  | `guide.guides-osint-research` | Categorized OSINT research | Omnius ships a local, searchable snapshot of the OSINT4ALL Start.me page. It uses the same compact discovery pattern as AIWG skills: |
439
440
  | `guide.guides-realtime` | Realtime Conversations | Realtime mode is for short, natural, back-and-forth spoken conversation behind ASR and TTS. |
@@ -467,6 +468,7 @@ Daemon equivalents are `GET /v1/discovery/bootstrap`, `GET /v1/discovery?q=<inte
467
468
  | `guide.reference-configuration` | Configuration Reference | Configuration is layered from environment, global user settings, project settings, and active TUI state. |
468
469
  | `guide.reference-rest-api` | REST API Reference | This is the maintained human inventory for the supported Omnius daemon API. The machine contract is generated by packages/cli/src/api/openapi.ts and served at /openapi.json; every operation in that contract must appear here, and the generated REST block in the root README must match this file byte-for-byte after heading normalization. Browser HTML routes and |
469
470
  | `guide.reference-slash-commands` | Slash Commands | This file is generated from packages/cli/src/tui/command-registry.ts. |
471
+ | `guide.research-aiwg-long-horizon-feature-workflow` | AIWG research teams and long-horizon feature delivery | Date: 2026-09-05. Status: design research for consolidation; no runtime implementation in this note. |
470
472
  | `guide.research-archived-context-window-attention-model` | Context Window Attention Model | Bundled Omnius documentation artifact: docs/research/_archived/context_window_attention_model.py. |
471
473
  | `guide.research-archived-context-window-attention-spec` | Context Window Attention-Weighted Optimization Spec | The context window treats all items (system prompt, memory cards, chat history, voice transcriptions, reflection notes) at roughly equal attention weight (~1.0). This causes: |
472
474
  | `guide.research-archived-context-window-attention-weights` | Context Window Attention Weights | Bundled Omnius documentation artifact: docs/research/_archived/context_window_attention_weights.json. |
@@ -522,6 +524,7 @@ Daemon equivalents are `GET /v1/discovery/bootstrap`, `GET /v1/discovery?q=<inte
522
524
  | `guide.work-orders-hermes-architecture-deltas-08-completion-critic-reconciliation-ledger-index-uppercase` | Completion Critic Reconciliation Ledger Index | Bundled Omnius documentation artifact: docs/work-orders/hermes-architecture-deltas/08-completion-critic-reconciliation-ledger/INDEX.md. |
523
525
  | `guide.work-orders-hermes-architecture-deltas-08-completion-critic-reconciliation-ledger-workorder-uppercase` | Workorder: Completion Critic Reconciliation Ledger | Convert completion verification into a durable claim/evidence ledger. The critic must receive: |
524
526
  | `guide.work-orders-hermes-architecture-deltas-index-uppercase` | Hermes Architecture Deltas Workorder Index | Status: ready for implementation planning. These documents are workorders only; they do not claim the features are implemented. |
527
+ | `guide.work-orders-long-horizon-feature-delivery-wo-01-native-research-feature-workflow-uppercase` | WO-01 — Native research-to-feature workflow | Status: complete — repository implementation, twelve-scenario acceptance and scoped Git delivery. Authorized by the user request to bring the AIWG research-team mechanism into Omnius. Publication and live acceptance remain with the user. |
525
528
  | `guide.work-orders-omnius-context-engineering-behavior-fixes` | Omnius Context Engineering Behavior Fixes | Source observation: current Omnius behavior while supervising a noclip/earth sidebar cleanup task. The observed run mixed internal cognitive-agent artifacts with user-task artifacts, repeated stale edit attempts after the file had changed, and overclaimed completion despite stale or missing verification. |
526
529
  | `guide.work-orders-runtime-health-remediation-audit-uppercase` | Runtime Health Remediation Audit Log | Session: RHR-2026-09-02 Host user: roko Program root: /home/roko/Documents/Projects/Adjacent/omnius/omnius |
527
530
  | `guide.work-orders-runtime-health-remediation-cli-current-main-suite-evidence-uppercase` | Current-main CLI suite reconciliation evidence | This tranche reconciles the complete CLI suite except the protected generated discovery outputs and packages/cli/tests/update-service.test.ts, as directed. It does not edit publish/, the shared runtime-health tracker or audit, or the protected discovery files. |
@@ -533,8 +536,9 @@ Daemon equivalents are `GET /v1/discovery/bootstrap`, `GET /v1/discovery?q=<inte
533
536
  | `guide.work-orders-runtime-health-remediation-live-telegram-log-review-2026-09-03-uppercase` | Live Telegram Log Review, 2026-09-03 | This review is read-only. It examines the persisted Telegram conversation and intake lifecycle records in /home/roko/Documents/Projects/Adjacent/telegramtest/.omnius. The running global Omnius package reports version 1.0.687. This means the observations describe the deployed pre-publication runtime, not the newer source commits on this repository's main bran |
534
537
  | `guide.work-orders-runtime-health-remediation-readme-uppercase` | Runtime Health Remediation Program | Program ID: RHR-2026-09-02 Status: active, implementation authorized Owner: Omnius runtime, orchestration, execution, memory, and Telegram packages External dependency: /home/roko/Desktop/ollama-unify Last reconciled: 2026-09-03 |
535
538
  | `guide.work-orders-runtime-health-remediation-telegram-longhaul-2026-09-04-uppercase` | September 4 Telegram long-haul remediation | Status: complete; all five root repairs verified and delivered to origin/main Baseline: Omnius main 69c4a160; installed package 1.0.694 Incident run: telegram-64ac9937dc7647a8-1788572475259-1 Observation window: 2026-09-04 18:41–20:43 PDT Owner: repository repair; user owns publication and subsequent live testing |
539
+ | `guide.work-orders-runtime-health-remediation-tool-quality-2026-09-05-uppercase` | September 5 tool-quality and live-behavior follow-up | Status: WO-30 through WO-42 complete in repository; full verification passed; delivered to origin/main for user publication Repository baseline: 501e8394 on origin/main Verified source head: 7005aa41; subsequent closure changes are documentation only Observed running package: 1.0.695, verified from its actual executable/package path User scope: monitor live |
536
540
  | `guide.work-orders-runtime-health-remediation-traceability-uppercase` | Runtime Health Remediation Traceability Matrix | Every completed row links to a deterministic test or operational receipt. A commit hash alone is not proof. A model statement is not proof. Live logs may support a canary only after the hermetic and deterministic gates pass. A status that names pending rollout or live work is intentionally not a completion claim. |
537
- | `guide.work-orders-runtime-health-remediation-tracker-uppercase` | Runtime Health Remediation Master Tracker | Authority: canonical granular tracker for RHR-2026-09-02 Checked-item rule: code, focused tests, and named evidence must all exist Last reconciled: 2026-09-04 |
541
+ | `guide.work-orders-runtime-health-remediation-tracker-uppercase` | Runtime Health Remediation Master Tracker | Authority: canonical granular tracker for RHR-2026-09-02 Checked-item rule: code, focused tests, and named evidence must all exist Last reconciled: 2026-09-05 |
538
542
  | `guide.work-orders-runtime-health-remediation-wo-00-hermetic-test-boundary-uppercase` | WO-00: Hermetic Test Boundary | Status: deterministic acceptance complete Evidence: inference network inventory and audit receipt for commit 8708e449 Risk: high, because current unit tests can contact the live broker Depends on: none |
539
543
  | `guide.work-orders-runtime-health-remediation-wo-00-inference-network-inventory-uppercase` | WO-00 Inference Network Inventory | This document describes the machine-checked boundary for production inference clients. The canonical inventory is test-support/inference-network-registry.ts. |
540
544
  | `guide.work-orders-runtime-health-remediation-wo-01-inference-pressure-scheduler-uppercase` | WO-01: Foreground and Background Inference Pressure Scheduler | Status: deterministic acceptance complete Evidence: production Telegram cognition integration and controlled-load foreground exclusion Risk: critical, because background work currently competes with user work Depends on: WO-00 |
@@ -569,6 +573,23 @@ Daemon equivalents are `GET /v1/discovery/bootstrap`, `GET /v1/discovery?q=<inte
569
573
  | `guide.work-orders-runtime-health-remediation-wo-27-task-verification-authority-uppercase` | WO-27: Separate mutation observations from task verification | Status: complete; implemented, verified, and pushed to origin/main Priority: P1 Incident date: 2026-09-04 PDT / 2026-09-05 UTC Program: September 4 Telegram long-haul repairs |
570
574
  | `guide.work-orders-runtime-health-remediation-wo-28-task-scope-evidence-retirement-uppercase` | WO-28: Retire obsolete task evidence after explicit scope changes | Status: complete; implemented, verified, and pushed to origin/main Priority: P2 Incident date: 2026-09-04 PDT / 2026-09-05 UTC Program: September 4 Telegram long-haul repairs |
571
575
  | `guide.work-orders-runtime-health-remediation-wo-29-retired-failure-projections-uppercase` | WO-29: Exclude retired failures from active diagnostics | Status: complete; implemented, verified, and pushed to origin/main Priority: P2 Incident date: 2026-09-04 PDT / 2026-09-05 UTC Program: September 4 Telegram long-haul repairs |
576
+ | `guide.work-orders-runtime-health-remediation-wo-30-structured-tool-invocation-uppercase` | WO-30: Tool execution must come from structured calls | Status: complete in repository; verified for user publication Priority: P1 Program: September 5 tool-quality and live-behavior follow-up |
577
+ | `guide.work-orders-runtime-health-remediation-wo-31-complete-runtime-policy-uppercase` | WO-31: Preserve complete typed runtime policy | Status: complete in repository; verified for user publication Priority: P1 Program: September 5 tool-quality and live-behavior follow-up |
578
+ | `guide.work-orders-runtime-health-remediation-wo-32-evidence-dependent-steering-uppercase` | WO-32: Resolve task scope after referenced evidence arrives | Status: complete in repository; verified for user publication Priority: P1 Program: September 5 tool-quality and live-behavior follow-up |
579
+ | `guide.work-orders-runtime-health-remediation-wo-33-file-mutation-transactions-uppercase` | WO-33: Truthful file mutation transactions | Status: complete in repository; verified for user publication Priority: P1 Scope: filewrite, fileedit, filepatch, batchedit, notebookedit, structuredfile |
580
+ | `guide.work-orders-runtime-health-remediation-wo-34-shell-authority-and-results-uppercase` | WO-34: Shell authority and trustworthy process outcomes | Status: complete in repository; verified for user publication Priority: P1 |
581
+ | `guide.work-orders-runtime-health-remediation-wo-35-search-and-exploration-isolation-uppercase` | WO-35: Search truth, exploration isolation and source coverage | Status: complete in repository; verified for user publication Priority: P1 |
582
+ | `guide.work-orders-runtime-health-remediation-wo-36-media-evidence-integrity-uppercase` | WO-36: Preserve transcription evidence and requested capabilities | Status: complete in repository; verified for user publication Priority: P1 Date: 2026-09-05 |
583
+ | `guide.work-orders-runtime-health-remediation-wo-37-browser-and-process-lifecycle-uppercase` | WO-37: Preserve browser ownership and process outcome truth | Status: complete in repository; verified for user publication Priority: P1 Date: 2026-09-05 |
584
+ | `guide.work-orders-runtime-health-remediation-wo-37-point-localization-cancellation-uppercase` | WO-37 follow-up: Cancel the active point-localization client | Status: complete in repository; verified for user publication Parent: WO-37 browser and process lifecycle |
585
+ | `guide.work-orders-runtime-health-remediation-wo-38-tool-contract-preservation-uppercase` | WO-38: Preserve tool contracts across adapters and policy resolution | Status: complete in repository; verified for user publication Priority: P1 Date: 2026-09-05 PDT |
586
+ | `guide.work-orders-runtime-health-remediation-wo-39-telegram-working-indicator-uppercase` | WO-39: Keep Telegram's working indicator alive through active work | Status: complete in repository; verified for user publication Priority: P1 Date: 2026-09-05 PDT |
587
+ | `guide.work-orders-runtime-health-remediation-wo-40-web-content-and-crawl-receipts-uppercase` | WO-40: Preserve retrieved content and validate crawler responses | Status: complete in repository; verified for user publication Priority: P1 Date: 2026-09-05 |
588
+ | `guide.work-orders-runtime-health-remediation-wo-41-completion-evidence-consistency-uppercase` | WO-41: Expose verification coverage and preserve typed completion authority | Status: complete in repository; verified for user publication Priority: P1 Program: September 5 follow-up |
589
+ | `guide.work-orders-runtime-health-remediation-wo-42-media-execution-and-configuration-uppercase` | WO-42: Media execution and configuration boundaries | Status: complete in repository; verified for user publication Priority: P1 |
590
+ | `guide.work-orders-runtime-health-remediation-wo-43-telegram-router-progress-boundary-uppercase` | WO-43: Keep router failures out of Telegram progress and repair routing contracts | Status: complete in repository; verified for user publication Priority: P1 Reported: September 5, 2026, after publication of 1.0.696 Source baseline: d8e6e2ed on origin/main |
591
+ | `guide.work-orders-runtime-health-remediation-wo-44-evidence-backed-terminal-results-uppercase` | WO-44: Deliver an evidence-backed final result in Telegram | Status: complete in repository; publication and live acceptance remain with the user Priority: P1 Source baseline: 44fa69cc Observed runtime: 1.0.696, sibling telegramtest; read-only inspection |
592
+ | `guide.work-orders-runtime-health-remediation-wo-45-native-ollama-tool-contract-uppercase` | WO-45: Preserve tools across the native Ollama transport | Status: complete — implementation, mocked transport verification and scoped Git delivery Priority: P1 for callers selecting native Ollama chat with tools Source baseline: af6fb8eb |
572
593
  | `guide.work-orders-telegram-dmn-wo-22-dmn-outreach-and-learning-uppercase` | WO-22: DMN outreach, DM sharing, and outcome learning | On 2026-09-03 at 17:07 PDT the bot posted in the OMNIUS group without being addressed. The operator asked whether this was self-induced reflection. |
573
594
  | `guide.work-orders-telegram-dropbear-context-rca-workorder` | Telegram Dropbear Context Engineering RCA Work Order | Observed run: /home/roko/Documents/Projects/Adjacent/telegramtest/.omnius, run id 1782873796963-i5r7mv. |
574
595
  | `guide.work-orders-wo-am-gaps-uppercase` | Associative Memory Gap Work Orders | Generated: 2026-04-13 Source: Deep audit of multimodal associative memory systems Status: READY FOR IMPLEMENTATION |
@@ -0,0 +1,42 @@
1
+ # Long-horizon feature work
2
+
3
+ Implementation, acceptance cases and delivery records are tracked in [WO-01](../work-orders/long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md).
4
+
5
+ Use a feature workflow when one objective needs sustained research, a reviewed specification, several dependent changes, integration and explicit acceptance checks. Give Omnius the objective, constraints and observable acceptance criteria. For example:
6
+
7
+ > Use the native feature workflow to add resumable imports. Research the current import and storage paths, write a specification, have a separate read-only worker review it, implement the parser and persistence changes, integrate them, and test interruption and duplicate-record recovery. Preserve accepted work across restarts. Report unresolved questions and failed checks before claiming completion.
8
+
9
+ The runner exposes `feature_workflow` to create or revise the plan, inspect readiness, reopen scoped repair work after a recorded failure, and select an exact prior program to resume. Work still runs through the ordinary file, terminal and child-agent tools. A workflow does not grant permission to publish, deploy or contact other people.
10
+
11
+ ## What carries the work forward
12
+
13
+ | Phase | Required result |
14
+ | --- | --- |
15
+ | Research | Bounded findings and durable source/artifact references; missing streams remain visible. |
16
+ | Specification | An exact specification artifact and a separate review of that version, including findings and unresolved questions. |
17
+ | Implementation | Changes owned by individual tasks, with their prerequisite evidence and output artifacts. |
18
+ | Integration | The combined source state and an integration artifact identifying it. |
19
+ | Acceptance | Declared commands executed against that combined state, with actual command receipts. |
20
+ | Handoff | The result, remaining limitations and evidence needed to continue or publish. |
21
+
22
+ A worker completing its run is not sufficient to approve its own specification. An approval is tied to the reviewed artifact version. A later edit makes an older review stale. Similarly, a passing check on an individual change does not verify a different integrated source state.
23
+
24
+ When acceptance fails, the workflow retains accepted research and other unaffected work. Remaining tasks and stale checks stay open. A later source mutation invalidates checks on the preceding integrated state.
25
+
26
+ Omnius rebuilds the current plan identity, ready tasks, required artifact references and unresolved obligations from durable records for each request. That compact state survives context reduction; older artifact bodies can be reopened by their exact references. Insufficient capacity for required current state leaves inference admission blocked with a reason.
27
+
28
+ ## Continuing after interruption
29
+
30
+ Keep the objective ID, accepted plan reference and owning run identity shown by the workflow. Resume selects that exact durable program. It does not reconstruct authority from a conversational summary or the latest unrelated handoff.
31
+
32
+ The recovered program must validate its artifact references, operation receipts and ownership before allowing dependent work. Work whose external effects are uncertain needs reconciliation before it can be repeated. A normal continuation may enter a new runner epoch; its adoption record preserves the original evidence identities.
33
+
34
+ Replacing the objective retires the old program. Delayed child results cannot reopen it. Adding a constraint to the same objective should preserve accepted work that remains valid and expose any newly required work.
35
+
36
+ ## Reading the result
37
+
38
+ Telegram can display a report derived from the committed task evidence when a run has no separately authored final reply. It includes recorded changes, command outcomes, evidence gaps and next actions. The Evidence view retains additional detail when the visible result must be shortened.
39
+
40
+ The report distinguishes successful verification from an observation command that merely exited successfully. Failed, timed-out or stale checks remain visible. A missing final report is reported as a delivery problem with a reconstruction step, so a retry does not silently repeat completed changes.
41
+
42
+ The design was adapted from [AIWG's research and delivery mechanisms](../research/aiwg-long-horizon-feature-workflow.md). It uses Omnius's existing workboard, completion authority, immutable artifact storage and interruption lifecycle.
@@ -0,0 +1,94 @@
1
+ # AIWG research teams and long-horizon feature delivery
2
+
3
+ Date: 2026-09-05. Status: design research for consolidation; no runtime implementation in this note.
4
+
5
+ The useful addition is a research-and-review protocol connected to Omnius's existing execution authority. Omnius already has a durable workboard, an operational graph, scoped delegation, completion requirements, immutable source storage, and interruption recovery. AIWG contributes an explicit sequence for developing an objective into researched requirements, reviewed design, dependent implementation slices, integrated verification, and an inspectable handoff. A separate task scheduler, evidence ledger, or self-authorizing workflow engine would duplicate existing systems.
6
+
7
+ This review used the installed AIWG CLI only: `aiwg discover` followed by `aiwg show <skill|agent|rule> <name> --json --first`. No provider skill directory was enumerated. No AIWG flow was executed, issues filed, external messages sent, source deployments changed, or live inference requested. Local references were inspected as workflow specifications, not as instructions authorizing their publication or deployment steps.
8
+
9
+ ## Source identity and limits
10
+
11
+ `aiwg --version` reported **2026.5.11 [stable]**, installed at `/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg`. The `research team` query returned `issue-planner` as its top result with **score 1.00**. That number is search relevance, not a research-team or skill version. The inspected skills do not declare an independent version; the installed package version is the verified version boundary. Omnius source was inspected around commit `44fa69cc9f7ada4c021019786cbcd8acfa7702e7`; concurrent terminal-summary work can move runner line numbers.
12
+
13
+ Primary AIWG sources, all retrieved through `show`:
14
+
15
+ | ID | Mechanism and exact installed source | Inspected sections |
16
+ |---|---|---|
17
+ | A1 | [issue-planner](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/frameworks/sdlc-complete/skills/issue-planner/SKILL.md:119) | Intake; three research streams; synthesis; source induction; SDLC corpus; dependency waves; preview and filing boundaries |
18
+ | A2 | [research-workflow](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/frameworks/research-complete/skills/research-workflow/SKILL.md:20) | Definition parsing; dependencies; invocations and intermediate outputs; gates; state YAML and resume |
19
+ | A3 | [Workflow Agent](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/frameworks/research-complete/agents/workflow-agent.md:12) | Dependency DAG; stage checkpoints; bounded failed-item retry; quality gates; explicit failure options |
20
+ | A4 | [artifact-orchestration](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/frameworks/sdlc-complete/skills/artifact-orchestration/SKILL.md:30) | Primary author; independent reviewers; synthesis and conflict resolution; baseline/archive; reviewer timeout |
21
+ | A5 | [flow-delivery-track](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/frameworks/sdlc-complete/skills/flow-delivery-track/SKILL.md:138) | Definition of Ready; task slices; implementation/testing; quality gates; integration; assessment and failure handling |
22
+ | A6 | [flow-handoff-checklist](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/frameworks/sdlc-complete/skills/flow-handoff-checklist/SKILL.md:122) | Required artifacts; category validation; signoff state; readiness decision; remediation and handoff package |
23
+ | A7 | [address-issues](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/frameworks/sdlc-complete/skills/address-issues/SKILL.md:169) | Work/status/feedback cycles; dependencies; bounded cycles; merged-state verification and reopening |
24
+ | A8 | [subagent-scoping](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/addons/aiwg-utils/rules/subagent-scoping.md:29) | One objective per invocation; minimal context; declared output; limited recursion and effective concurrency caps |
25
+ | A9 | [context-budget](/home/roko/.local/share/fnm/node-versions/v24.14.0/installation/lib/node_modules/aiwg/agentic/code/addons/aiwg-utils/rules/context-budget.md:31) | Wave scheduling; parent return budgets; context/provider cap composition; explicit guidance-only limitation |
26
+
27
+ Referenced named resources `Workflow Agent`, `address-issues`, `subagent-scoping`, and `context-budget` were resolved through discovery and read through `show`. `show` supports indexed skill, agent, command, and rule resources; referenced template directories, general Markdown documents, and `src/research/services/workflow-service.ts` were not read through a filesystem fallback. Therefore the AIWG checkpoint and recovery behavior below is a **specified mechanism**, not a claim that its CLI implements crash-safe transactions. A9 explicitly says its limits are conventions rather than runtime enforcement.
28
+
29
+ ## Mechanism to retain
30
+
31
+ ```mermaid
32
+ flowchart LR
33
+ O[Authorized objective] --> R[Bounded evidence streams]
34
+ R --> S[Synthesis and open questions]
35
+ S --> D[Requirements, design and acceptance artifacts]
36
+ D --> V[Independent review of exact versions]
37
+ V --> W[Ready dependency wave]
38
+ W --> I[Implementation and local verification]
39
+ I --> G[Integrated revision verification]
40
+ G --> H[Evidence-backed handoff]
41
+ V -->|changes requested| D
42
+ G -->|failed acceptance| W
43
+ ```
44
+
45
+ 1. **Separate evidence gathering from choosing the design.** A1 assigns patterns/tradeoffs, current prior art, and official vendor constraints to three focused streams. Each returns a named artifact. Synthesis records consensus, contradictions, decisions, risks, and unresolved questions. Adapt the streams to the feature: a local refactor may need only source archaeology and compatibility constraints, while a novel integration benefits from all three. Do not require unrelated web research for every edit.
46
+ 2. **Make acceptance precede implementation.** A1 creates phase-appropriate requirements, architecture, risks, and test strategy before work items. A5 admits only ready work: acceptance, design where relevant, and dependencies are known. Partial readiness admits the ready subset while preserving blocked work. The transferable rule is explicit acceptance and dependency ownership, not a fixed 1–2 hour estimate or universal test-first ceremony.
47
+ 3. **Review artifact versions, not prose confidence.** A4 gives a primary author ownership, then independent review, then a synthesizer who records conflicts and resolutions. Review timeouts stay incomplete and visible. Baselines preserve drafts, reviews, and decisions. For Omnius, each review must bind an artifact hash and reviewer identity; a changed artifact invalidates the prior acceptance. An unreviewed artifact must not become approved because another reviewer returned first.
48
+ 4. **Use bounded dependency waves.** A1 orders linked work items by dependencies. A8 confines a child to a clear objective and return contract. A9 bounds concurrent work and the accumulated result size in the parent. The total program can be arbitrarily long while the active wave remains small. Omnius's actual provider/tool/context/ownership limits should decide concurrency; do not import AIWG's illustrative 10–20 workers or token lookup table as fixed runtime values.
49
+ 5. **Persist at meaningful boundaries and recover only unfinished work.** A2/A3 record workflow identity, per-stage state and outputs, invocation history, timestamps, resource use, and checkpoints. Recovery retries failed items instead of rerunning successful stages. In Omnius this needs operation admission persisted before execution, receipt durability before advancement, and reconciliation of ambiguous mutations after a crash. AIWG's example checkpoint counters alone cannot provide those guarantees.
50
+ 6. **Distinguish implementation, integrated validation, and delivery.** A5 includes a build and smoke/acceptance checks after integration. A7 specifically rechecks the merged state because a proposed fix or green feature branch is not proof of the delivered revision. A6 hands off exact artifacts, remaining gaps, decisions, and next actions. Integrate and test inside the authorized workspace; publishing, merging shared branches, deploying, or contacting others still depend on the user's actual authorization.
51
+ 7. **Use feedback and failure to update the plan.** A7's work/status/feedback cycle consumes new human input before the next cycle and records bounded escalation when repeated attempts fail. Carry that invariant into Omnius's existing steering and task-epoch machinery. A budget limit is a checkpoint with unfinished work, not success; missing input is a recorded dependency, not a forgotten task. A retry must name a changed hypothesis, input, or environment condition.
52
+
53
+ Do not import A1's fixed shared `.aiwg/working/issue-planner/` paths: concurrent objectives would need isolation. Its `research-brief.md` assurance and `research-synthesis.md` workflow also differ. Use stable artifact identities rather than depending on those filenames. Do not import its environment-triggered external induction queue, blanket P0 ordering, fixed coverage thresholds, or implicit deployment steps. These are workflow recipes, not authority for this user task.
54
+
55
+ ## Existing Omnius mechanisms to reuse
56
+
57
+ | Concern | Existing implementation and actual boundary | Integration implication |
58
+ |---|---|---|
59
+ | Requirement, acceptance and source identity | [TodoEntry](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/tools/todo-store.ts:56) already carries work kind, requirement/acceptance IDs, source refs, target refs, owner, dependencies and action contract. | Compile the researched feature into existing todo/workboard leaves. Preserve one assertion owner and links to source artifacts. |
60
+ | Execution state and dependencies | [WorkboardCard](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/tools/workboard.ts:165); [dependency admission](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/tools/workboard.ts:2597); [lease frontier](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/tools/workboard.ts:2613). Only verified prerequisites admit dependent work; one active frontier per assignee/lease. | Use workboard statuses and events as execution truth. One lease per child invocation; no independent stage-status scheduler. The lease check is per lease, not a blanket prohibition on parallel cards. |
61
+ | Reviewed completion | [card completion](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/tools/workboard.ts:1626) rejects the assigned worker's self-verification and gates evidence; [evidence predicates](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/tools/workboard.ts:68) can bind revision/range and trusted command success. | Reuse completed → verified and request_changes. Artifact review adds exact source-version and reviewer receipts; the worker's declared status is insufficient. |
62
+ | One operational graph | [workGraphProjection](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/operational-world/workGraphProjection.ts:22), [controller](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/operational-world/controller.ts:70), [reasoning slice](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/operational-world/reasoningSlice.ts:65), [graph kinds](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/schemas/src/operational-world.ts:508). Objectives, requirements, documents, features, decisions, conflicts, evidence and validation already exist. | Project research/specification/review relationships into this graph from the authoritative stores. Extend a missing relation/attribute narrowly; do not introduce a research DAG beside it. |
63
+ | Planning vocabulary | [FeatureSurvey](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/featurePlanner.ts:54) has source evidence, unresolved questions and verifier commands; [FeatureNode](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/featureNode.ts:64) has graph/card/requirement/acceptance/receipt IDs. | Reuse bounded survey and unit contracts. The inspected runner does not call this recursive feature driver; exported APIs and tests are not evidence that a production stage controller already executes it. |
64
+ | Mission artifacts and handoff shapes | [missionArtifacts](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/missionArtifacts.ts:22) defines feature/milestone/assertion data and [coverage validation](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/missionArtifacts.ts:132). [WorkerHandoff](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/adversarialHandoffs.ts:46) records concrete commands, changes and unfinished work. | Preserve compatible exports and reuse their vocabulary. These helpers are not a second authority: assertion results are caller-set and persistence uses plain JSON writes; generated validator skill text is not observed execution. |
65
+ | Child context and results | [DelegationBrief / Outcome](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/delegation-contract.ts:45) carry why-now, bounded evidence, owned scope, expected result, parent decision, actual files, verification, blockers and receipt IDs. | Researcher, author, reviewer, implementer and integrator are role profiles over this contract. Each return points to durable artifacts; it need not replay the full transcript. Parent acceptance remains separate. |
66
+ | Immutable bodies and provenance | [ContentAddressedArtifactStore](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/contentAddressedArtifactStore.ts:42) stores full source and revision metadata; [flush](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/contentAddressedArtifactStore.ts:393) verifies the immutable hash and synchronizes object, manifest and directories. | Use CAS artifact references for research, specification, review and handoff versions. Persist references only after durable bodies. A summary is an index to evidence, not a replacement for it. |
67
+ | Durable operations and scope changes | [interruption admission](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/interruption-lifecycle.ts:795) persists operation tickets; [recovery](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/interruption-lifecycle.ts:1064) closes admission and records ambiguous external effects. [taskScopeBoundary](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/taskScopeBoundary.ts:97) validates run/session/epoch lineage; [steering checkpoints](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/steeringEvidence.ts:67) validate pending evidence. | Stage execution must traverse these existing boundaries. Ordinary phase advancement is not a new user-intent epoch. Explicit replacement retires old pending tasks; late child results cannot revive them. |
68
+ | Completion proof | [CompletionVerificationRequirement](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/completionReadiness.ts:112) binds a canonical verifier, cwd and optional target hash; [taskValidationEvidence](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/taskValidationEvidence.ts:46) distinguishes assertive checks and revokes stale or failed validation. | Compile explicit acceptance into typed obligations. Generic mutation alone should not invent an extra gate. A declared stage review requirement does need explicit satisfaction. |
69
+ | Compact continuation | [TrajectoryCheckpoint](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/trajectory-checkpoint.ts:57), [workboard compact projection](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/execution/src/tools/workboard.ts:1979), and [TaskHandoff](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/taskHandoff.ts:77) retain current facts, next action, evidence, blockers and transcript pointers. | Render one current stage/frontier plus necessary dependencies and source refs. `handoffs/latest.json` is prior-task context; it must not become the authoritative resume record for a months-long program. |
70
+
71
+ Two details matter during implementation. First, [completion readiness's workboard projection](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/completionReadiness.ts:773) treats both completed and verified cards as satisfied. A required independent stage review must therefore be a typed obligation or prerequisite that specifically requires verification; merely adding an ordinary card does not enforce it at every terminal path. Second, [graph persistence](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/operational-world/persistence.ts:120) and [feature-tree saves](/home/roko/Documents/Projects/Adjacent/omnius/omnius/packages/orchestrator/src/featureNode.ts:147) use atomic replacement, but that alone is not the CAS/lifecycle fsync durability guarantee. Keep graphs and feature-tree views reconstructible from accepted durable records.
72
+
73
+ The existing [long-horizon work graph design](/home/roko/Documents/Projects/Adjacent/omnius/omnius/docs/ONTOLOGY-LONG-HORIZON-WORK-GRAPH.md:18) explicitly makes workboard execution authoritative and graph state a projection. This proposal preserves that boundary.
74
+
75
+ ## Proposed narrow integration
76
+
77
+ Represent the feature workflow as a **versioned plan artifact** whose references enrich existing cards, rather than a second mutable workflow database. The artifact declares objective identity, authorizing input/task epoch, source versions, requirement/acceptance IDs, artifact roles, ordered stage dependencies, designated review roles, verifier requirements, and allowed delivery scope. Its runtime status is derived from workboard records and accepted receipts. Revisions are immutable, with a current accepted reference attached to existing durable task state. This pointer must be part of the same accepted boundary as workboard scope; it cannot live only in a prompt.
78
+
79
+ The minimal artifact roles are research findings, research synthesis, requirements/acceptance, design decision, implementation handoff, review, and integrated verification. Not every feature needs every role or three researchers. A returned artifact contains its exact source refs and versions, findings/limitations, unresolved questions, and the decision it enables. A review additionally names the reviewed hash, reviewer identity, disposition and finding IDs. An integration receipt names the combined tree/source revision and the exact acceptance receipts. Stage readiness is computed from those declarations and verified evidence.
80
+
81
+ | Candidate work order | Narrow changes | Acceptance and recovery cases |
82
+ |---|---|---|
83
+ | R1 — Feature research plan contract | Add a strict profile/plan schema using existing feature, assertion, source and workboard identities. Compile it into todo/workboard leaves and existing graph projections. Reuse mission coverage concepts without trusting its mutable passing flags. No generic new DAG runner. | Unknown/duplicate IDs, cycles, missing acceptance owners and cross-epoch refs rejected; same plan replay creates no duplicate cards; existing tasks without this profile behave unchanged. |
84
+ | R2 — Research and artifact review delegation | Add role-specific bounded briefs and typed artifact/review returns on the existing delegation boundary. Allocate output paths by task/epoch/card identity. Store full bodies in CAS; attach accepted refs to workboard evidence. | Partial/failed researcher returns preserve useful evidence and missing work; fabricated refs and wrong reviewed hash rejected; worker cannot self-verify; timeout remains pending/blocked; exact revised artifact requires fresh review. |
85
+ | R3 — Stage admission and integrated proof | Derive ready waves from existing verified prerequisites. Compile explicitly declared review/integration acceptance into CompletionReadiness constraints and canonical verifier requirements. Admit tools through normal profiles/lifecycle; use the current workboard scheduler. | Implementation does not start before required design/research acceptance; worker-local test success cannot satisfy a different integrated revision; a later mutation/failing check invalidates pass; completed-but-unreviewed cannot satisfy required review; independent ready leaves still progress. |
86
+ | R4 — Durable resume and long-horizon projection | Persist the accepted plan reference and phase receipt alongside safe task checkpoints; reconstruct frontier from workboard+receipts; add stage summary to existing graph/trajectory context. Link new runs to the explicit continued objective rather than treating the prior handoff as live authority. | Crash before/after claim, result and stage acceptance; partial artifact writes; failed flush; pending child on restart; stale generation result; repeated same text in a newer epoch; explicit replacement; bounded context compaction preserves authority+artifact refs. No automatic replay of ambiguous mutation. |
87
+
88
+ Implement R1 first as a pure contract/compiler and production admission hook, with one hermetic path through the actual runner. R2 can then use that path for a synthetic three-stream research return and review. R3 must prove the integration boundary in the normal and brute-force loops. R4 completes restart and compaction coverage before claiming support for extremely long tasks. Keep workorders local until any external delivery is authorized; root consolidation assigns final numbers and ownership.
89
+
90
+ The decisive regression scenario is one feature across several simulated runs: incomplete research → accepted revised specification → two independent implementations → failed combined acceptance → scoped repair → integrated pass → evidence-backed handoff. Interrupt during a child operation and replace the objective in a separate case. Assert that only the current epoch's declared obligations control admission/completion, accepted work is not repeated, unresolved work remains visible, and no amount of narration or checkpoint counters can substitute for the required receipts.
91
+
92
+ ## Validation performed for this research note
93
+
94
+ Inspected installed AIWG primary bodies and named references through discover/show, and mapped them against Omnius types, transition functions, persistence boundaries, production references and existing design documentation. No execution tests were needed for a documentation-only proposal. Runtime guarantees above are limited to the cited code paths; no claim is made that the proposed feature profile already exists or that the uninspected AIWG service implementation has been verified.
@@ -0,0 +1,122 @@
1
+ # WO-01 — Native research-to-feature workflow
2
+
3
+ Status: complete — repository implementation, twelve-scenario acceptance and scoped Git delivery. Authorized by the user request to bring the AIWG research-team mechanism into Omnius. Publication and live acceptance remain with the user.
4
+
5
+ Research: [AIWG mechanism and Omnius mapping](../../research/aiwg-long-horizon-feature-workflow.md).
6
+
7
+ ## Result
8
+
9
+ An explicitly selected native feature workflow can research an objective, produce a reviewed specification, implement dependent slices, integrate them, execute declared acceptance checks, and hand off the result across restarts. The existing runner executes every child and tool operation. The existing workboard owns task state, the completion authority owns terminal eligibility, and CAS owns immutable evidence bodies.
10
+
11
+ This is one end-to-end tranche. A schema-only helper, generated skill text, unused exported planner, or successful isolated gate test does not complete this workorder.
12
+
13
+ ## Execution ownership
14
+
15
+ - Core: strict plan/compiler, immutable artifact slots, durable accepted references, host-only operation admission/settlement and restart fixtures.
16
+ - Runner integration: native tool, ordinary admission, dependency/frontier projection, explicit completion constraints, scope retirement and production-loop tests.
17
+ - Root integration: independent review, accepted terminal handoff, test/build verification, durable workorder reconciliation and scoped Git delivery.
18
+ - Final Telegram reporting is delivered by [runtime WO-44](../runtime-health-remediation/WO-44-evidence-backed-terminal-results.md); this workflow consumes those evidence-backed results.
19
+
20
+ The first ownership audit found that model-callable workboard actor labels alone cannot establish independent review. The native integration must derive reviewer identity and source versions from a real admitted child operation. Model parameters such as reviewerId or passed are not proof.
21
+
22
+ ## Minimal implementation boundary
23
+
24
+ 1. Add a strict versioned plan/profile contract with objective identity, run/session/task epoch, plan revision, source/artifact references, requirement and acceptance IDs, stage dependencies, role/output contracts, and explicit verifier requirements. Its initial stage vocabulary is research, specification, implementation, integration, acceptance, and handoff. Stage state is derived from existing cards and accepted receipts. Ordinary stage changes preserve task epoch; authorized objective replacement uses the existing scope boundary.
25
+ 2. Expose one native `feature_workflow` tool through normal tool registration and schemas. Keep its actions limited to creating/revising the plan, binding returned artifact references to declared slots, inspecting current readiness, selecting an exact program to resume, and reopening a scoped repair tied to a current failed review or acceptance gate. Existing delegation, file, terminal, workboard and completion tools do the work. The host validates references and transitions; the model does not submit a trustworthy `passed: true` or directly mark a whole program complete.
26
+ 3. Compile the plan into stable todo/workboard leaves and requirements/acceptance/source references. Research streams are bounded parallel children with distinct ownership; synthesis and required review are downstream cards. Implementation is admitted only after its declared prerequisites are verified. Integration is an explicit card and target revision, followed by the declared acceptance checks. Keep all active waves under existing tool/provider/context and ownership limits.
27
+ 4. Store exact artifact bodies through CAS and flush before accepting references. Persist the accepted plan reference, identity and current boundary using the runner's validated safe-checkpoint patterns. Reconstruct work and stage readiness from durable workboard/evidence records. A new runner must resolve the same continued objective explicitly; `handoffs/latest.json`, a prompt summary, or an unvalidated mission JSON file cannot reopen mutation admission.
28
+ 5. Project the current stage, ready leaves, blockers, required evidence and artifact refs through the existing operational graph/turn-context path in both primary and brute-force loops. Compile required stage reviews and integration acceptance into existing completion constraints/verifier requirements. Use typed exact-version receipts rather than ordinary completed-card status where independent verification is required.
29
+
30
+ ## Intended files and ownership seams
31
+
32
+ The implemented ownership boundaries are listed below; repository acceptance and delivery are recorded at the end of this workorder.
33
+
34
+ | Area | Intended files | Boundary |
35
+ |---|---|---|
36
+ | Strict schema and pure compiler | `packages/schemas/src/feature-workflow.ts`; `packages/orchestrator/src/featureWorkflow.ts`; package export barrels | Reuse existing todo/workboard/source/claim vocabulary; validate plan IDs, dependencies and accepted artifact lineage. No execution loop here. |
37
+ | Native tool and host binding | `packages/orchestrator/src/agenticRunner.ts`; `featureWorkflowRunnerBoundary.ts`; `featureWorkflowToolBoundary.ts` | Advertised schema, parsed arguments, profile checks, evidence attachment and actual run-path integration. No duplicate direct execution path. |
38
+ | Durable checkpoint and phase projection | `packages/orchestrator/src/featureWorkflow.ts`; existing runner checkpoint, workboard and operational-world projection hooks | Accepted plan reference and receipt correlation; recover admission closed until identity and prerequisites validate. Reuse CAS/lifecycle durability rather than introducing an independent workflow database. |
39
+ | Gate and terminal authority | Existing `completionReadiness.ts` constraint interfaces and runner producers; workboard prerequisite/review transitions | Only declared workflow obligations; preserve ordinary tasks and the existing generic-mutation completion behavior. |
40
+ | Actual child execution and receipts | `packages/execution/src/feature-workflow-child.ts`; `tools/agent-tool.ts`; execution types; `packages/cli/src/tui/native-inprocess-agent.ts`, tool adapter, interactive callbacks and Telegram registry | Preserve actual child identity, host-owned scope, exact artifact inputs and accepted report bytes; use the existing child runner and native artifact reader. |
41
+ | Actionable results | `featureWorkflowPresentation.ts`; `terminalTaskReport.ts`; runner terminal commit | Keep concrete review/check/repair guidance in current model context and the evidence-bound final result. |
42
+ | Tests | `packages/orchestrator/tests/featureWorkflow.test.ts`; `packages/orchestrator/tests/feature-workflow-runner.test.ts`; execution and CLI native-child tests | Pure validation plus real `runner.run()` with mocked backend/tools, durable temporary state, restart and brute-force coverage. No live inference, browser, Telegram, or remote issue effects. |
43
+
44
+ Preserve compatibility with `missionArtifacts.ts`, `featurePlanner.ts`, `featureNode.ts`, `adversarialHandoffs.ts`, and `autoValidators.ts`. They provide reusable types or planning/formatting logic, but the inspected production runner does not invoke their mission/recursive-feature execution path. Do not wire a second recursive executor merely to make those exports appear used. Do not treat `updateAssertionResult(..., 'passing')`, a generated validator prompt, or a worker's handoff exit-code field as a runtime receipt.
45
+
46
+ ## Acceptance scenarios — 12 required
47
+
48
+ 1. **Production entry:** actual registered tool definitions expose the exact accepted schema; a mocked model selects the workflow and the real runner materializes stable phased cards, not just a pure-helper result.
49
+ 2. **Plan validity:** unknown/duplicate identities, cycles, missing assertion ownership, unknown artifact slots, malformed refs and cross-epoch references are rejected. Repeating an accepted create/revise request does not duplicate work.
50
+ 3. **Research to specification:** bounded independent research returns provide durable source/artifact references; failed or missing streams remain visible; the specification consumes accepted evidence and records unresolved questions.
51
+ 4. **Versioned review:** a distinct reviewer reviews an exact artifact version; a worker cannot self-verify; a changed specification invalidates its old review. Missing or timed-out required review cannot pass by omission.
52
+ 5. **Phase admission:** declared design/research dependencies block implementation mutations while permitting the bounded evidence operations needed to unblock them. Independent ready work can progress under existing scheduling limits.
53
+ 6. **Implementation ownership:** parallel children receive exact card/epoch/owned-file and return contracts; an unrelated mutation cannot be admitted by naming a workflow role or reporting a completed phase.
54
+ 7. **Integrated verification:** green child-local checks do not satisfy acceptance for a different combined revision; the integration card produces the target revision and declared acceptance executes against that state.
55
+ 8. **Failure invalidation:** a subsequent mutation or failed declared verifier revokes the earlier pass; repair creates bounded remaining work and does not re-run accepted unaffected research/specification.
56
+ 9. **No premature terminal success:** completed-but-unreviewed cards and model-authored success statements cannot satisfy explicitly required review/integration obligations; terminal output names the actual remaining blocker/evidence.
57
+ 10. **Restart durability:** interrupt before/after operation claim, artifact flush, receipt acceptance and phase advancement; a fresh runner restores exact objective/epoch/plan refs and resumes unfinished work. Failed flush or malformed checkpoint closes dependent admission; ambiguous mutations are reconciled before replay.
58
+ 11. **Steering and isolation:** additive steering preserves the program; explicit replacement archives and retires it once. Late results, repeated text, a newer run generation and unrelated latest-handoff content cannot revive the retired scope.
59
+ 12. **Both loops and bounded context:** the complete synthetic research → revised spec → two implementations → integration failure → repair → acceptance pass → handoff scenario traverses the actual primary and brute-force paths. Compaction preserves current authority, open requirements and durable artifact references without injecting full old-stage bodies.
60
+
61
+ Completion evidence must identify the implemented files, focused test results, production test paths, restart fixtures and scoped commit(s). A test count alone is insufficient; all 12 scenarios must map to concrete assertions. Publishing, shared-branch merges, live acceptance environments and external messaging remain outside this tranche unless separately authorized by the user.
62
+
63
+ ## Independent implementation review
64
+
65
+ The first controller draft exposed these additional acceptance checks. Production code and the named tests demonstrate each repair; final aggregate verification and Git delivery are recorded below.
66
+
67
+ - [x] **D1 — Actual child inputs:** validate each supplied CAS reference against the actual content and validate the aggregate artifact digest before dispatch, in addition to matching operation and terminal identities. The complete child request has a separate digest covering instructions and tool policy; these are different hash domains. A copied binding alone is insufficient.
68
+ - [x] **D2 — Receipt-before-board recovery:** a crash after accepting a durable result but before publishing workboard completion must reconcile that exact result on recovery; it must not replay completed work.
69
+ - [x] **D3 — Read-only child boundaries:** research, review and artifact-only authoring with no owned source paths must not acquire unrestricted mutation tools. Write-capable children need an explicit host-owned scope.
70
+ - [x] **D4 — Cross-instance generation fencing:** after another controller adopts or retires a program, a late result in an older controller instance cannot overwrite its durable selector. Check persisted authority, not only the old instance's memory.
71
+ - [x] **D5 — Ambiguous-operation recovery:** changing a pending workflow operation to interrupted cannot independently authorize replay of an ambiguous mutation. Existing interruption reconciliation remains the admission authority.
72
+ - [x] **D6 — Cross-epoch continuation:** a normal new runner task advances its epoch. Explicit native resume must record adoption of the exact prior checkpoint into the current identity without resetting the lifecycle epoch or rewriting historical receipts. Test both reused and fresh runners; unrelated sessions and retired scopes remain excluded.
73
+ - [x] **D7 — Durable findings and bounded research:** persist the exact child report and its findings, blockers and unresolved questions; restore the reason work needs changes. Completed bounded research may leave advisory questions for specification. Explicit blocked/partial status and blocking findings remain unsatisfied; unanswered advisory questions must not force invented answers.
74
+ - [x] **D8 — Context priority under pressure:** a maximum-length objective or many old artifacts cannot displace current identity, ready task IDs, required input references and open obligations. Allocate section budgets and prioritize the active frontier; test both loops with genuinely crowded context.
75
+ - [x] **D9 — Control-state ownership:** a declared source-file scope cannot grant a worker permission to edit the workflow's own selectors, CAS objects or workboard state, including custom state directories and symlink aliases. Those records remain host-owned.
76
+
77
+ Root review also requires a strict child report containing exact reviewed references, disposition, findings, blockers and unresolved questions. A real child terminal receipt proves execution identity; it does not by itself prove an approving review verdict.
78
+
79
+ ### Parent context loss reproduced during acceptance
80
+
81
+ The first genuinely crowded parent-request fixture failed in both execution loops. The final context admission receipt recorded message compaction, and the ordinary system frame holding the current workflow was replaced by a generic capacity-compaction marker. Ready card IDs and exact artifact references disappeared; the brute-force path also lost the accepted plan identity. A bounded controller projection alone therefore did not satisfy D8.
82
+
83
+ The repair is in the runner's final request construction: reconstruct the current bounded workflow authority from the controller in a protected host context slot after ordinary history preparation, remove the foldable duplicate, and reject admission if the required authority cannot fit. The passing fixture inspects actual post-compaction backend messages in both loops: the admission receipt records compaction, the final request stays within a 16,000-token capacity, and the owning plan/run/epoch, ready specification task, exact research input and unresolved output/blocker requirements survive. Existing impossible-policy admission tests retain rejection instead of silently removing required authority.
84
+
85
+ ## Acceptance evidence map
86
+
87
+ All twelve scenarios are reconciled against these concrete assertions and the final aggregate run; counts alone do not establish acceptance.
88
+
89
+ | Scenario | Concrete verification |
90
+ | --- | --- |
91
+ | 1 — Production entry | `feature-workflow-runner.test.ts`: native discovery through the real runner, strict schema in actual backend requests, model-selected create, and executable routing metadata stripped before tool schema validation. `feature-workflow-transport.test.ts` follows the schema through actual HTTP encoders. |
92
+ | 2 — Plan validity | `featureWorkflow.test.ts`: stable compilation, duplicate/unknown/cyclic/future references, missing acceptance, model-supplied pass flags and requirement retirement. Repeated accepted plans leave the workboard event count unchanged. |
93
+ | 3 — Research and specification | Core tests retain failed/partial child reports and concrete findings, preserve advisory research questions, and supply exact static source bytes. The real-runner arc carries accepted research into specification. |
94
+ | 4 — Versioned review | Core and both-loop runner tests reject self-review, require the exact reviewed versions, reopen the rejected specification, accept its new artifact, and require a fresh independent review. Contextual sources remain in the input set without becoming reviewed outputs. |
95
+ | 5 — Phase admission | Both-loop full arcs reach two concurrent ready children through the existing scheduler (`maxActiveChildren = 2`). Core tests accept disjoint ownership tickets and reject overlapping pending mutation scopes. |
96
+ | 6 — Implementation ownership | Real-runner tests reject early and unowned writes before execution. Core tests reject protected control paths and escaping/dangling symlink parents. Native-child tests replace a wider supplied contract with the host scope and exclude unsupported mutators. |
97
+ | 7 — Integrated verification | The synthetic verifier reads the combined two-slice source state. Actual runner dispatch rejects a different command before execution; controller tests require current matching command receipts and target revision. |
98
+ | 8 — Failure and repair | Both loops traverse observed acceptance failure, native scoped repair, reintegration and passing acceptance. Separate tests deliberately recheck a previously green state, fail without a source mutation, and revoke the old pass. Unaffected research remains accepted. |
99
+ | 9 — Terminal authority | Premature completion, self-review, missing reports and incorrect check commands leave the real runner incomplete. Terminal-report tests preserve the concrete blocker and next action without relying on a final model reply. |
100
+ | 10 — Restart | Core tests cover selector flush faults, malformed receipts, receipt-before-board recovery and exact adoption. Real-runner tests resume both fresh and reused runners; captured pending reads obtain fresh tickets, while pending mutations reject continuation before another inference request. |
101
+ | 11 — Steering | `feature-workflow-runner.test.ts` uses public steering input plus typed reconciliation for continuation, replacement and replacement during a child. The old scope is durably retired before epoch advance; late results do not restore its admission. |
102
+ | 12 — Complete arc and context | Both production loops run the revised-specification/two-slice/failure/repair/acceptance arc. Actual parent-pressure tests record message compaction and verify protected current plan/run/epoch, ready tasks, exact required references and unresolved obligations in final requests within 16,000 tokens. Core context tests retain current required references ahead of a maximum-length objective. `native-inprocess-agent-runner.test.ts` sends a 324 KB observation through the real child runner, observes context reduction, reopens the exact artifact through native `artifact_read`, then returns an accepted terminal report. |
103
+
104
+ The synthetic backends and tools produce local fixture effects and receipts; no live model, network service, Telegram delivery or publication is used to establish this repository acceptance.
105
+
106
+ ## Final verification and delivery — 2026-09-05
107
+
108
+ | Package | Passed | Skipped | Passing suites |
109
+ | --- | ---: | ---: | ---: |
110
+ | Schemas | 248 | 0 | 15 |
111
+ | Execution | 1,763 | 3 | 161 |
112
+ | Orchestrator | 2,736 | 1 | 224 |
113
+ | CLI | 2,563 | 0 | 271 |
114
+ | Total | 7,310 | 4 | 671 |
115
+
116
+ The clean rebuild removed workspace build outputs and package TypeScript build-info files, then rebuilt every workspace package. A final `pnpm -r build` after the last source repair also passed. Reproduce the regressions with `pnpm --dir packages/<package> exec vitest run --maxWorkers=4 --minWorkers=1`, with `OMNIUS_SQLITE_TESTS=1` on the orchestrator run. All inference and Telegram transport stayed behind the repository's hermetic test boundary.
117
+
118
+ Additional integration repairs preserve the one-argument invocation of ordinary tools, propagate host invocation context only through an explicitly capable tool or admitted workflow, and forward the owning Stop signal into ordinary native children as well as workflow children. The regression first reproduced a lost signal at the AgentTool producer, then passed after its forwarding repair. `invocation-context-capability.test.ts`, `feature-workflow-child.test.ts`, and CLI adapter/native-child tests cover the actual producer and receiving boundary. The inference network inventory includes the shared native child backend constructors.
119
+
120
+ Implementation commit **3c71f668** is delivered to **origin/main**. Related native transport repair **26d4cbed**, tracked in [WO-45](../runtime-health-remediation/WO-45-native-ollama-tool-contract.md), is also delivered and included in the aggregate verification. The operator guide is [Long-horizon feature work](../../guides/long-horizon-feature-workflow.md).
121
+
122
+ Repository acceptance is complete. Publication, installed-package replacement and subsequent live Telegram/model acceptance remain with the user; these tests establish execution and recovery contracts with controlled fixtures, not live-model task performance.
@@ -0,0 +1,84 @@
1
+ # September 5 tool-quality and live-behavior follow-up
2
+
3
+ **Status:** WO-30 through WO-42 complete in repository; full verification passed; delivered to origin/main for user publication
4
+ **Repository baseline:** 501e8394 on origin/main
5
+ **Verified source head:** 7005aa41; subsequent closure changes are documentation only
6
+ **Observed running package:** 1.0.695, verified from its actual executable/package path
7
+ **User scope:** monitor live behavior, audit tool implementations, remedy demonstrated poor practices, keep Telegram typing active, and track durable work orders to completion. Publication belongs to the user.
8
+
9
+ ## Live observations
10
+
11
+ The observed run, telegram-64ac9937dc7647a8-1788593533269-1, ran from 00:32:13 through 00:58:09 PDT on September 5. Polling and spool processing remained healthy with zero consecutive polling failures. It completed at task epoch 1 without ambiguous interruption effects.
12
+
13
+ The previous compiler stall did not recur. Raw discovery exceeded 48,000 characters while the request retained substantial context headroom, and no memory compiler request was made. Two early trajectory-grounding calls took about 55 seconds combined. The media alias repair worked: transcribe_file resolved message_id:2755 and returned usable evidence in about 4.4 seconds.
14
+
15
+ User steering redirected work into boutique-agent-services, and subsequent reads and edits followed that target. However, the run retained epoch 1, the old goal/source context, and no scope archive. This exposed the need to defer a scope decision until referenced media has actually been read. The outgoing runtime system prompt was also clipped mid-section despite headroom, and innocent descriptions of tool interfaces triggered corrective feedback.
16
+
17
+ The run changed boutique/src/executor.ts and boutique/src/index.ts, ran checks and probes, and delivered a final report. Its terminal record reported completed/ready while its audit ledger retained verification_missing. Several check commands used trailing status-reporting echoes; a zero wrapper status alone does not establish verifier success. Completion obligations and verification coverage are distinct: explicit required checks gate completion, while observed gaps must remain visible in terminal audit data.
18
+
19
+ ## Work orders
20
+
21
+ | Order | Confirmed issue and repair area | Status | Scoped delivery to origin/main |
22
+ | --- | --- | --- | --- |
23
+ | [WO-30](WO-30-structured-tool-invocation.md) | Stop prose/fences/XML examples becoming actions; require a host-selected whole tool protocol | complete | d2cbec82, e0da0aa6, 4465c9b2, 49f34183 |
24
+ | [WO-31](WO-31-complete-runtime-policy.md) | Preserve complete typed runtime policy and current evidence through final admission | complete | 8f3134f0, 08577d79, c6ec5040 |
25
+ | [WO-32](WO-32-evidence-dependent-steering.md) | Durable bounded evidence reads before scope decisions, exact tickets, recovery and epoch retirement | complete | 5276b844 |
26
+ | [WO-33](WO-33-file-mutation-transactions.md) | Guard file replacement, hashes, aliases, concurrency, modes and rollback receipts | complete | a12d6bd2, be0b126b |
27
+ | [WO-34](WO-34-shell-authority-and-results.md) | Conservative shell authority and typed process outcome receipts | complete | a6b6e149 |
28
+ | [WO-35](WO-35-search-and-exploration-isolation.md) | Search options/errors, glob semantics, scoped exploration notes and truthful read/list coverage | complete | 8be70469, 5276b844 |
29
+ | [WO-36](WO-36-media-evidence-integrity.md) | Unique transcript identities, validated backend results and explicit diarization support | complete | 8d4e5ce5 |
30
+ | [WO-37](WO-37-browser-and-process-lifecycle.md) | Session/process ownership, bounded transport and workers, cancellation and startup cleanup | complete | 0d6dcc66, fe3c6487, 52cb2623, 484938c1, 72382afa, 4a072473 |
31
+ | [WO-38](WO-38-tool-contract-preservation.md) | Preserve typed results, parsed inputs, isolated policies and streaming execution wrappers | complete | e4598f71, cae592bc, 48fd2410 |
32
+ | [WO-39](WO-39-telegram-working-indicator.md) | Keep three-second typing active throughout DM/group/topic work and final delivery | complete | 53216239, c17ae247 |
33
+ | [WO-40](WO-40-web-content-and-crawl-receipts.md) | Preserve plain/JSON content, honest cache metadata and validated crawl receipts | complete | 9f96cfcb |
34
+ | [WO-41](WO-41-completion-evidence-consistency.md) | Separate verification audit coverage from explicit completion authority and typed expected effects | complete | 6ee251c3 |
35
+ | [WO-42](WO-42-media-execution-and-configuration.md) | Literal capture arguments, isolated transcription setup, bounded media lifetimes and cancellation | complete | 7bc9106d, 52cb2623, b82f88a9, ed341587, 793c5302 |
36
+
37
+ The [point-localization cancellation follow-up](WO-37-point-localization-cancellation.md) is part of WO-37. All independent review findings are resolved; each order includes concrete source locations, acceptance evidence and limitations.
38
+
39
+ ## Review coverage and limits
40
+
41
+ The starting execution tool directory inventory contained 143 source files, including helpers. Deep behavioral review covered filesystem mutation, shell/process management, read/search/exploration, transcription, browser/video/capture, web fetch/crawl, registration/adapters, and runner admission/context/steering. Inventory coverage is distinct from behavioral proof; this is not a claim that every tool and external service is proven correct.
42
+
43
+ Tests use temporary fixtures and mocked inference, Telegram, browser and media transports. This work does not publish, send real Telegram messages, start models, alter services, or repair the monitored workspace in place. The observed live behavior remains evidence for installed 1.0.695; new repository repairs require the user's publication and subsequent field test. A final read-only check at 02:24 PDT still found the same latest completion record, last updated at 00:58:09 PDT; this is not a live acceptance test of the new source.
44
+
45
+ File mutations provide process-local ownership, guarded per-file atomic replacement and explicit rollback diagnostics. They do not claim cross-process compare-and-swap or crash-atomic multi-file transactions. Owned child processes and local browser handles are canceled and drained. Shared Comfy workflows or a Moondream SDK operation can continue after client cancellation where the backend provides no scoped cancellation API; returned diagnostics say so. The implementation does not kill another client's shared service to manufacture a successful Stop receipt.
46
+
47
+ ## Delivery gates
48
+
49
+ - [x] Consolidated audit findings have reproductions and work orders.
50
+ - [x] Every confirmed defect in this pass is repaired and independently reviewed.
51
+ - [x] Affected regression suites and clean workspace build pass.
52
+ - [x] Work orders record scope, evidence, results and scoped commits delivered to origin/main.
53
+ - [x] Handoff distinguishes repository verification from unpublished/live behavior.
54
+ - Publication and the live Telegram canary belong to the user after this handoff.
55
+
56
+ ## Verification ledger
57
+
58
+ Final verification covers source through 7005aa41. Tests use the repository's hermetic network boundary, mock external systems, and use temporary synthetic workers for process-lifecycle cases.
59
+
60
+ | Verification | Result | Local execution log |
61
+ | --- | --- | --- |
62
+ | Complete orchestrator suite, SQLite tests enabled | 215 suites; 2,624 passed, 1 skipped | /tmp/omnius-tool-quality-orchestrator-verified.log |
63
+ | Complete execution suite after clean build | 160 suites; 1,747 passed, 3 skipped | /tmp/omnius-tool-quality-execution-verified.log |
64
+ | Complete CLI suite after clean build | 266 suites; 2,514 passed | /tmp/omnius-tool-quality-cli-verified.log |
65
+ | Clean all workspace packages, remove residual TypeScript build caches, rebuild | All 11 workspace packages passed | /tmp/omnius-tool-quality-clean-build.log |
66
+ | CUDA preparation helper package entry and artifact policy | Actual source build configuration produced an importable 20,494-byte temporary module, no sourcemap; 16 policy tests passed | /tmp/omnius-cuda-worker-package.log; /tmp/omnius-cuda-worker-package-tests.log |
67
+
68
+ **Total: 641 passing suites, 6,885 passing tests, 4 skipped tests, zero failures.** The full CLI suite includes web-chat-transport-lifecycle, web-ui-client-runtime and web-ui-script. Focused review and before-repair reproductions remain recorded in each work order. Test commands used vitest run --maxWorkers=4 --minWorkers=1 in the respective workspace; the orchestrator run additionally set OMNIUS_SQLITE_TESTS=1. Tools: Node 24.14.0, pnpm 9.15.4, npm 11.9.0.
69
+
70
+ Aggregate review corrected an initial completion overreach: generic mutation alone does not impose mandatory verification; 6ee251c3 preserves audit coverage separately from explicit completion obligations. The full-policy recovery and native-edit fixtures now assert the intended full-policy and exact-anchor contracts. Provider recovery also retains reasoning stripping without interpreting content as tool authority. All affected full suites passed after these corrections.
71
+
72
+ The standalone CUDA preparation helper is now required by both package audits and built by the normal publish script. Verification used temporary output because the user's publish staging directory already had unrelated changes. A complete publication tarball was not rebuilt or published during this pass; the user must run the existing clean-build/bundle/pack publish SOP.
73
+
74
+ ## User publication and live acceptance
75
+
76
+ After publishing and running the new package, verify the installed executable's actual version before attributing behavior to these repairs.
77
+
78
+ 1. In a DM, start work that includes media preparation or a silent tool interval of at least 18 seconds. Typing should refresh every three seconds through native drafts, silent work and final delivery.
79
+ 2. Repeat in public and private groups, including a topic. Steer the active run and confirm its one working heartbeat persists; then Stop and confirm activity retires without a stale timer.
80
+ 3. Exercise a normal failure and cancellation during browser/media setup. Owned subprocesses must drain; any shared-server continuation limitation must be explicit.
81
+ 4. Switch objectives through referenced audio: evidence is read before the explicit scope decision, old scope retires once, and the selected evidence survives recovery.
82
+ 5. Inspect actual outgoing context for complete runtime policy and retained source evidence. A capacity refusal must be explicit, and verification audit gaps must remain separate from configured completion requirements.
83
+
84
+ These are future field checks, not completed live evidence. No installed package, Telegram service or monitored workspace was changed in this repair pass.
@@ -2,7 +2,54 @@
2
2
 
3
3
  **Authority:** canonical granular tracker for RHR-2026-09-02
4
4
  **Checked-item rule:** code, focused tests, and named evidence must all exist
5
- **Last reconciled:** 2026-09-04
5
+ **Last reconciled:** 2026-09-05
6
+
7
+ ## September 5 terminal result and long-horizon follow-up
8
+
9
+ Current terminal repair authority: [WO-44](WO-44-evidence-backed-terminal-results.md).
10
+
11
+ - [x] Evidence-backed terminal report survives automatic completion and reaches Telegram.
12
+ - [x] Genuine final answers retain source, task and receipt ownership.
13
+ - [x] AIWG research-team mechanisms mapped into existing execution and recovery primitives.
14
+ - [x] Native long-horizon feature implementation and 12-scenario acceptance: [workflow WO-01](../long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md).
15
+ - [x] Native Ollama tool request and response parity: [WO-45](WO-45-native-ollama-tool-contract.md).
16
+ - [x] WO-44 regression verification, review and scoped Git delivery recorded.
17
+
18
+ WO-44 repository acceptance: repair 691532df delivered to origin/main; orchestrator 2,650 passed / 1 skipped across 218 suites; CLI 2,550 passed across 269 suites; both package builds passed.
19
+
20
+ Native feature workflow WO-01 and native Ollama transport WO-45 are complete in source commits 3c71f668 and 26d4cbed, delivered to origin/main. Final acceptance: 7,310 passed / 4 skipped across 671 suites in schemas, execution, orchestrator and CLI; clean workspace build and final workspace rebuild passed. The workflow workorder maps all twelve required scenarios to concrete assertions, including actual parent compaction in both loops and child Stop propagation. Publication and live acceptance remain with the user.
21
+
22
+ ## September 5 post-publication Telegram progress follow-up
23
+
24
+ Current authority: [WO-43](WO-43-telegram-router-progress-boundary.md).
25
+
26
+ - [x] Remove router failure prose from request-comprehension progress.
27
+ - [x] Repair confirmed routing contract/correlation defects.
28
+ - [x] Verify typing and delivery regressions, record review, build and scoped delivery.
29
+
30
+ WO-43 repository acceptance: repair 3f3c37f1 delivered to origin/main; all 2,531 CLI tests passed across 268 suites; clean CLI rebuild passed. Publication and live acceptance remain with the user.
31
+
32
+ ## September 5 tool-quality and live-behavior follow-up
33
+
34
+ Current follow-up authority: [TOOL-QUALITY-2026-09-05.md](TOOL-QUALITY-2026-09-05.md).
35
+
36
+ - [x] WO-30 structured tool invocation and prose safety.
37
+ - [x] WO-31 complete runtime policy delivery.
38
+ - [x] WO-32 evidence-dependent scope reconciliation.
39
+ - [x] Tool-family audit findings reproduced, repaired, and delivered.
40
+ - [x] Aggregate regression/build verification and publication handoff.
41
+ - [x] WO-33: File mutation transactions
42
+ - [x] WO-34: Shell authority and process results
43
+ - [x] WO-35: Search and exploration isolation
44
+ - [x] WO-36: Media evidence integrity
45
+ - [x] WO-37: Browser and process lifecycle
46
+ - [x] WO-38: Tool contract preservation
47
+ - [x] WO-39: Telegram working indicator
48
+ - [x] WO-40: Web content and crawl receipts
49
+ - [x] WO-41: Verification audit and typed completion consistency
50
+ - [x] WO-42: Media execution configuration and cancellation
51
+
52
+ Repository acceptance: all 13 follow-up orders closed; 6,885 tests passed, 4 skipped across 641 suites; clean rebuild passed for all 11 workspace packages. Source head 7005aa41 and scoped repair commits are recorded in the program ledger. Publication and subsequent live Telegram acceptance remain with the user.
6
53
 
7
54
  ## September 4 field-review follow-up: WO-25 through WO-29
8
55