omnius 1.0.696 → 1.0.698

package/docs/research/aiwg-long-horizon-feature-workflow.md

@@ -0,0 +1,94 @@
+# AIWG research teams and long-horizon feature delivery
+
+Date: 2026-09-05. Status: design research for consolidation; no runtime implementation in this note.
+
+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.
+
+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.
+
+## Source identity and limits
+
+`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.
+
+Primary AIWG sources, all retrieved through `show`:
+
+| ID | Mechanism and exact installed source | Inspected sections |
+|---|---|---|
+| 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 |
+| 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 |
+| 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 |
+| 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 |
+| 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 |
+| 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 |
+| 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 |
+| 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 |
+| 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 |
+
+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.
+
+## Mechanism to retain
+
+```mermaid
+flowchart LR
+  O[Authorized objective] --> R[Bounded evidence streams]
+  R --> S[Synthesis and open questions]
+  S --> D[Requirements, design and acceptance artifacts]
+  D --> V[Independent review of exact versions]
+  V --> W[Ready dependency wave]
+  W --> I[Implementation and local verification]
+  I --> G[Integrated revision verification]
+  G --> H[Evidence-backed handoff]
+  V -->|changes requested| D
+  G -->|failed acceptance| W
+```
+
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+
+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.
+
+## Existing Omnius mechanisms to reuse
+
+| Concern | Existing implementation and actual boundary | Integration implication |
+|---|---|---|
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+
+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.
+
+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.
+
+## Proposed narrow integration
+
+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.
+
+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.
+
+| Candidate work order | Narrow changes | Acceptance and recovery cases |
+|---|---|---|
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+
+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.
+
+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.
+
+## Validation performed for this research note
+
+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.

package/docs/work-orders/long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md

@@ -0,0 +1,122 @@
+# 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.
+
+Research: [AIWG mechanism and Omnius mapping](../../research/aiwg-long-horizon-feature-workflow.md).
+
+## Result
+
+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.
+
+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.
+
+## Execution ownership
+
+- Core: strict plan/compiler, immutable artifact slots, durable accepted references, host-only operation admission/settlement and restart fixtures.
+- Runner integration: native tool, ordinary admission, dependency/frontier projection, explicit completion constraints, scope retirement and production-loop tests.
+- Root integration: independent review, accepted terminal handoff, test/build verification, durable workorder reconciliation and scoped Git delivery.
+- 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.
+
+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.
+
+## Minimal implementation boundary
+
+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.
+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.
+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.
+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.
+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.
+
+## Intended files and ownership seams
+
+The implemented ownership boundaries are listed below; repository acceptance and delivery are recorded at the end of this workorder.
+
+| Area | Intended files | Boundary |
+|---|---|---|
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+
+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.
+
+## Acceptance scenarios — 12 required
+
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+
+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.
+
+## Independent implementation review
+
+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.
+
+- [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.
+- [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.
+- [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.
+- [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.
+- [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.
+- [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.
+- [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.
+- [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.
+- [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.
+
+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.
+
+### Parent context loss reproduced during acceptance
+
+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.
+
+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.
+
+## Acceptance evidence map
+
+All twelve scenarios are reconciled against these concrete assertions and the final aggregate run; counts alone do not establish acceptance.
+
+| Scenario | Concrete verification |
+| --- | --- |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+
+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.
+
+## Final verification and delivery — 2026-09-05
+
+| Package | Passed | Skipped | Passing suites |
+| --- | ---: | ---: | ---: |
+| Schemas | 248 | 0 | 15 |
+| Execution | 1,763 | 3 | 161 |
+| Orchestrator | 2,736 | 1 | 224 |
+| CLI | 2,563 | 0 | 271 |
+| Total | 7,310 | 4 | 671 |
+
+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.
+
+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.
+
+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).
+
+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.

package/docs/work-orders/runtime-health-remediation/LIVE-TELEGRAM-LOG-REVIEW-2026-09-05.md

@@ -0,0 +1,58 @@
+# Telegram field review after publication — September 5, 2026
+
+Scope: read-only review requested after the user observed improvement. Runtime package is **1.0.697**. The launcher started at 01:05 PDT; its current runtime child and Telegram poll owner is PID 4160370, started at 13:33 PDT. Two processes are the launcher/child relationship, not evidence of competing pollers.
+
+Sources are under the sibling `telegram_test/.omnius/`. Selected records were copied and hashed before analysis; capture directories are `/tmp/omnius-latest-completion-audit-oeh__cit`, `/tmp/omnius-telegram-delivery-audit-20260905-2045`, and `/tmp/omnius-field-context-w8e603c3`. Timestamps below are PDT (UTC−07:00). This review does not send inference or Telegram requests or change the running workspace.
+
+## Confirmed improvement
+
+The assessment run `telegram-64ac9937dc7647a8-1788640550740-1` executed from 13:35:50 to 13:41:07: 17 turns, 25 tool calls, about 316 seconds. Its task was to identify remaining work and validation for boutique-agent-services. Its completed status applies to that assessment; the project itself remains unfinished.
+
+At **13:41:08.452**, Telegram received a concrete 1,494-character final answer with six remaining integration gaps and ordered next actions. It did not contain the previous opaque completion fallback or internal router rationale. The reported checks have supporting tool output: TypeScript exited zero and Vitest reported **21/21 passing**, exit zero. No project mutations were recorded for the assessment.
+
+Evidence:
+
+- `telegram-conversations/64ac9937dc7647a833ca.events.jsonl:1510`: final message 2767.
+- `telegram-intake/98fe41d25e55150bca68.jsonl:836`: assessment consumed because the reply was delivered.
+- `terminal-trajectories/telegram-64ac9937dc7647a8-1788640550740-1.json:8`: run outcome and scope.
+- Captured debug records `2026-09-05T20-39-34-017Z-shell-d1e40f17f3.json:21` and `2026-09-05T20-39-35-953Z-shell-686a982eff.json:21`: actual check output.
+
+## Liveness, routing and context
+
+Both recent requests moved from deferred to dispatched in about 352–353 ms. Routing/admission still took approximately 37–38 seconds before each execution began. The assessment used one strict routing retry and subsequently delivered its answer. The selected records do not identify the first retry's cause.
+
+Twelve draft updates were accepted across the assessment and its continuation by the sampled delivery window, with no recorded rejection, rate limit or ambiguity. A draft-only delivery ledger remaining pending is expected; terminal state requires a final, fallback or receipt. The poll health snapshot had zero consecutive poll failures and one pending update corresponding to active work.
+
+Continuous typing cannot be established from these records: they do not log every typing pulse. Current stdout/stderr point to `/dev/pts/3`; the ordinary `.omnius/logs` files are stale and must not be treated as current transport evidence.
+
+The continuation `telegram-64ac9937dc7647a8-1788640948905-1` began at **13:42:28**. By the final **13:48:02** snapshot it retained the boutique-agent-services wiring objective, acknowledged 14 file reads and updated four relevant todos, marking discovery done and implementation in progress at 13:46:46. No source mutation, completed verification, ambiguous effect or terminal result was observed yet. Five completed main calls took 23–82 seconds each; the current call had been pending 59 seconds at capture, which does not establish a stall.
+
+All **22 sampled main requests** were admitted: roughly 9,752–33,023 input tokens against 262,144 capacity, with at least 79.3% free capacity. The latest prompt dropped from 31,729 to 16,784 input tokens through canonical supersession of 20 messages, preserving current task continuity. No memory-compilation stage or capacity-driven compaction was exercised. Latest admission and todo evidence are in `context-window-dumps/2026-09-05T20-47-03-254Z-main-d47c4be5a1.json:87` and `:1265`.
+
+The native `feature_workflow` was **not selected**: no workflow store, workflow tool call or protected workflow-owner context appeared in the captured records. This review establishes ordinary task continuity under the observed load, not live acceptance of native long-horizon workflow recovery or compaction.
+
+## Remaining findings
+
+### F1 — P2: source reads are falsely classified as runtime failures
+
+Two successful `cat` commands returned native transcript `status: success`, `exit_code: 0`, no stderr and no mutations, but the runner changed the result to `Runtime exception: throw new Error`. The phrase was source code being read.
+
+Root: `packages/orchestrator/src/agenticRunner.ts:32094` applies semantic stdout failure detection to successful shell output; the detector at line 15911 treats a literal `throw new Error` as an exception without a command-role or typed-process-receipt boundary. The contradiction survives in `context-window-dumps/2026-09-05T20-37-42-904Z-main-06ca92faa6.json:915` and `:942`. Raw typed receipts were not retained for this conversation run, so the field conclusion relies on its native transcript and non-mutation records.
+
+Required repair: preserve successful observation commands using host-owned command/receipt classification. Keep actual nonzero exits, timeouts and declared verification failures authoritative. Regressions should execute source-reading commands whose output contains exception/build/test-failure literals and confirm they remain observations, alongside real failing-command controls.
+
+### F2 — P2: malformed diagnostic arguments escape validation and crash
+
+The model supplied `steps` as a JSON-encoded string. `DiagnosticTool` casts it to `string[]` at `packages/execution/src/tools/diagnostic.ts:53`, then calls `.filter` at line 60. It has no executable input schema or value-level validator, so the runner's required-field-only fallback admits the value. The recorded error is `requestedSteps.filter is not a function` in captured debug record `2026-09-05T20-38-27-750Z-diagnostic-537aa683ec.json:22`.
+
+Required repair: introduce an executable input contract and validate direct invocation too; return an actionable argument error before executing anything. Test string/null/object steps, invalid members, valid subsets and explicit unavailable checks. This run recovered by executing TypeScript and Vitest directly.
+
+### F3 — coverage limitation: conversation checks do not populate the terminal evidence ledger
+
+The new bound terminal report exists in `completion-finalizations/telegram-64ac9937dc7647a8-1788640550740-1.json:83`, but its structured changes/checks/observations are empty and it explicitly reports the absent evidence snapshot. Telegram's chat profile selects conversation interaction mode; `writesUserTaskArtifacts()` at `agenticRunner.ts:6719` and startup at line 24954 leave that mode's completion ledger null.
+
+This is a reporting-coverage limitation, not evidence of a failed persistence write or missing delivered answer in this run. The accepted model final was delivered. The action continuation has an open ledger with actual command evidence. A follow-up design should retain observational command receipts for conversation reports without granting task/mutation authority or manufacturing verification claims.
+
+## Assessment
+
+No hard blocker was established in the sampled records. Useful final delivery, prompt continuity and queue dispatch improved; two tool defects caused avoidable failures but recovered. The implementation continuation remains active and must not be reported as completed. F1–F3 are findings from this review, not repaired or live-validated claims. Native workflow behavior and continuous typing still require the corresponding field evidence.

package/docs/work-orders/runtime-health-remediation/TRACKER.md

@@ -4,6 +4,44 @@
 **Checked-item rule:** code, focused tests, and named evidence must all exist
 **Last reconciled:** 2026-09-05
 
+## September 5 post-publication field review
+
+[Runtime 1.0.697 field review](LIVE-TELEGRAM-LOG-REVIEW-2026-09-05.md): a useful assessment final was delivered at 13:41 PDT, supported by TypeScript and 21 passing tests. At the reviewed checkpoint, the next implementation run was active. No hard blocker was established; source-read false failures, malformed diagnostic input handling and conversation-mode report coverage triggered the repairs below. Native feature workflow selection and continuous typing are not established by this sample.
+
+The user authorized end-to-end repair of the remaining defects; repository work is now complete:
+
+- [x] [WO-46: shell result authority](WO-46-shell-result-authority.md).
+- [x] [WO-47: diagnostic execution contract](WO-47-diagnostic-execution-contract.md).
+- [x] [WO-48: conversation result evidence](WO-48-conversation-result-evidence.md).
+
+Repairs `a3c26eca` (shell authority), `d4c37489` (validated asynchronous diagnostics), and `672bef53` (durable conversation evidence and terminal reporting) are delivered to `origin/main`. Clean workspace build passed. Execution: 1,820 passed / 3 existing skips; CLI: 2,575 passed. Orchestrator: 2,847 passed / 1 existing skip in the full run, with its sole outdated receipt fixture corrected and all 10 tests in that suite passing on rerun. All 7,243 distinct non-skipped affected-package tests have a passing result on the final implementation; the workorders retain exact commands, initial failures, limits and evidence paths. Publication and live acceptance remain with the user.
+
+
+## September 5 terminal result and long-horizon follow-up
+
+Current terminal repair authority: [WO-44](WO-44-evidence-backed-terminal-results.md).
+
+- [x] Evidence-backed terminal report survives automatic completion and reaches Telegram.
+- [x] Genuine final answers retain source, task and receipt ownership.
+- [x] AIWG research-team mechanisms mapped into existing execution and recovery primitives.
+- [x] Native long-horizon feature implementation and 12-scenario acceptance: [workflow WO-01](../long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md).
+- [x] Native Ollama tool request and response parity: [WO-45](WO-45-native-ollama-tool-contract.md).
+- [x] WO-44 regression verification, review and scoped Git delivery recorded.
+
+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.
+
+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.
+
+## September 5 post-publication Telegram progress follow-up
+
+Current authority: [WO-43](WO-43-telegram-router-progress-boundary.md).
+
+- [x] Remove router failure prose from request-comprehension progress.
+- [x] Repair confirmed routing contract/correlation defects.
+- [x] Verify typing and delivery regressions, record review, build and scoped delivery.
+
+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.
+
 ## September 5 tool-quality and live-behavior follow-up
 
 Current follow-up authority: [TOOL-QUALITY-2026-09-05.md](TOOL-QUALITY-2026-09-05.md).

package/docs/work-orders/runtime-health-remediation/WO-43-telegram-router-progress-boundary.md

@@ -0,0 +1,71 @@
+# 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
+
+## User-visible failure
+
+The initial Telegram card displays Working / Understanding followed by internal typed-router failure, retry and admin-admission diagnostics. The user reports seeing this first on every interaction. This is generated by the host rather than an assistant-authored explanation.
+
+Read-only process inspection confirms the active Telegram workspace is using installed Omnius 1.0.696. No installed files or running services were changed.
+
+## Root cause and code locations
+
+The router's diagnostic reason is copied into subAgent.intakeComprehension when no explicit expected-outcome reason exists. The admin panel then renders that field as Understanding and publishes it during initial startup status handling.
+
+- [telegram-bridge.ts](../../../packages/cli/src/tui/telegram-bridge.ts): processTelegramMessageWork, buildTelegramRouterUnavailableDecision, ensureTelegramAdminLivePanel, renderTelegramAdminWorkingSummary.
+- [telegram-admin-live-panel.test.ts](../../../packages/cli/tests/telegram-admin-live-panel.test.ts) and [telegram-bot-api-10.test.ts](../../../packages/cli/tests/telegram-bot-api-10.test.ts): existing summary and router tests lack this production failure-to-progress boundary.
+- [telegram-working-indicator.test.ts](../../../packages/cli/tests/telegram-working-indicator.test.ts): ongoing three-second typing ownership must remain intact.
+
+An earlier persisted decision at 00:58 PDT on September 5 records router JSON admission rejected with logical_request_conflict, followed by a plain response and a strict retry rejected with direct_turn_conflicts_with_reply_target. Read-only source analysis reproduced the matching defects:
+
+- Generated broker request identity hashes only sessionKey plus an instance-local inf-N counter. Restarting the bridge resets the counter, so the same session and inference kind can reuse an old broker identity for different request content. A per-bridge cryptographic nonce must separate lifetimes while each admitted logical request retains its identity across transport retries.
+- The host evidence packet correctly marks private messages as directDeliveryToSelf. However, both the validator and routing prompt reject a direct turn when its reply edge targets another actor, without a private-delivery exception. An operator replying to their own earlier message in a DM is still speaking directly to the bot. The repair must honor that host-owned transport fact while preserving group reply-target checks and explicit self/evidence requirements.
+
+The historical receipt establishes concrete matching failure mechanisms, not a claim that every reported failure had the same cause. The latest running process is 1.0.696; no live inference was sent to reproduce it.
+
+## Repair plan and acceptance
+
+- [x] Trace the reported string to its exact construction and delivery path.
+- [x] Initialize request comprehension only from validated expected-outcome comprehension, never from routing reasons.
+- [x] Keep internal reasons and detailed failure receipts available in diagnostics; ordinary progress remains useful and plain.
+- [x] Cover unavailable and valid routers without outcome summaries, plus genuine outcome-summary display.
+- [x] Reproduce and resolve confirmed request-correlation or reply-evidence contradictions without weakening typed reply authorization.
+- [x] Preserve background typing, native draft lifecycle, cancellation and final delivery.
+- [x] Complete independent review, affected tests, build and scoped commit/push to origin/main.
+
+## Implementation and review
+
+Routing reasons remain in TUI and durable social decision diagnostics. The initial Telegram response panel uses only comprehension from a validated, identity-bound expected-outcome contract. Otherwise its existing Working / Intake / Accepted presentation remains available. Native drafts and the independently owned typing heartbeat retain their lifecycle.
+
+Generated inference identities include a cryptographic namespace for the bridge lifetime. Transport retries preserve the identity of the same request; a newly constructed bridge cannot reuse the previous bridge's inf-N identity in the same session.
+
+Both initial and recovery prompts distinguish private transport delivery from group reply edges. The validator accepts private current-message evidence for direct delivery, while retaining self-role, addressed-actor and citation validation. Group replies aimed at someone else still require the appropriate authorization basis.
+
+Independent review also found that failed normalization or rebinding could preserve a raw expected-outcome contract and stale matching decision IDs. This was found in synthetic boundary tests, not established as the live router failure. Invalid contracts are now cleared after safe effect augmentation/normalization, and failed trusted rebinding removes both the rejected contract and its stale decision ID. Presentation independently requires matching input and decision receipts. Existing implied visible-response effects are preserved.
+
+## Runtime and publication boundary
+
+Tests use temporary fixtures, mocked inference and mocked Telegram transport. No live inference, Telegram messages, GPU workloads, service restart or package publication is authorized by this repair. Existing publication staging and unrelated discovery changes are preserved. The user owns publication and subsequent live validation.
+
+## Verification and delivery
+
+- Baseline reproductions fail with the exact synthetic broker 409 identity conflict and with direct-turn conflicts for private replies to two different author identities. The initial recovery fixture had a separate mock setup error; it was corrected before final verification. No live request was involved.
+- Presentation: 35 tests passed across the new seven-case production intake presentation suite, admin live panel and working indicator; four selected Bot API regressions also passed. The tests assert actual mocked first-message payloads, retained TUI/durable diagnostics, nine seconds of typing refresh, final response and cleanup.
+- Routing: 29 tests passed across the ten new identity/private-reply cases, attention evidence and inference contracts. Coverage includes fresh bridge identity, stable queue retries, group rejection controls, strict recovery, malformed outcomes and stale outcome rebinding.
+- Independent review resolved the stale receipt counterexample and confirmed group authorization, supplied logical IDs, unary request variants and typing/native draft ownership remain intact. Parent review confirmed safe array-shape handling preserves the existing implied visible-response effect before final normalization.
+- CLI clean rebuild passed. The complete CLI suite passed all **2,531 tests across 268 suites**, with zero failures or skipped tests. This includes Telegram intake/typing/delivery and the daemon frontend transport regression suites.
+
+Local reproduction and focused logs: /tmp/omnius-telegram-router-roots-before.log and /tmp/omnius-telegram-router-roots-after.log. Final logs: /tmp/omnius-wo43-cli-build.log and /tmp/omnius-wo43-cli-verified.log.
+
+Scoped repair commit: **3f3c37f1**, delivered to **origin/main** with this workorder closure. The installed package and publication staging remain untouched; live acceptance follows the user's publication.
+
+Regression source: [telegram-intake-presentation.test.ts](../../../packages/cli/tests/telegram-intake-presentation.test.ts) and [telegram-router-identity-and-private-replies.test.ts](../../../packages/cli/tests/telegram-router-identity-and-private-replies.test.ts).
+
+## Field acceptance after user publication
+
+Start a DM task without an explicit outcome summary: the initial card may show Working / Intake / Accepted, but no routing reason or failure prose. Reply to an earlier own message and confirm direct delivery is accepted. Typing continues throughout silent work, and genuine task summaries can replace initial intake. Restart the bridge and confirm its next inference is admitted without a reused logical-request conflict. Group replies to other actors retain their normal authorization checks.
+
+These field checks remain pending user publication; repository tests use mocked transport.

package/docs/work-orders/runtime-health-remediation/WO-44-evidence-backed-terminal-results.md

@@ -0,0 +1,56 @@
+# 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 telegram_test; read-only inspection
+
+## Reported failure
+
+After applying the operator's continuation of boutique-agent-services, Telegram ended with: “The run reached its completion boundary, but it did not produce a user-facing result. Open Evidence for the recorded outcome.”
+
+Run telegram-64ac9937dc7647a8-1788624121778-1 finalized at 09:27:18 PDT on September 5 with status completed, disposition ready, and task epoch 1. Its host summary records four changed files (payment.ts, solana.ts, signature.ts and boutique.test.ts) and a successful post-mutation TypeScript check. The preceding tool output reports 21 passing tests; its piped shell receipt is classified as observation, so it must not be silently upgraded into typed verifier authority.
+
+## Confirmed root causes
+
+- Truth-based automatic completion emits assistant_text with source task_complete_summary and finishes without a separately authored user_reply. Telegram intentionally discards untyped runner summaries to avoid exposing bookkeeping. No structured result crosses that gap.
+- A typed model_visible_text answer delivered without stream events can also be lost: the retention helper considers stream/accumulated content, and completion then excludes uncommitted assistant text.
+- Auxiliary handoff grounding occurs after terminal commit and writes memory handoff state; its advisory outcome is not a user-facing terminal result.
+- Finalization's selected command evidence excludes failed observations, while testsRun is attempted-command metadata. Neither can independently establish a complete, truthful check report.
+
+## Code and contracts
+
+- [completionAutoFinalize.ts](../../../packages/orchestrator/src/completionAutoFinalize.ts): implicit completion from direct file and validation evidence.
+- [agenticRunner.ts](../../../packages/orchestrator/src/agenticRunner.ts): terminal commit, emitted events, AgenticResult and auxiliary handoff.
+- [completionFinalization.ts](../../../packages/orchestrator/src/completionFinalization.ts): immutable terminal receipt and selected projections.
+- [telegram-bridge.ts](../../../packages/cli/src/tui/telegram-bridge.ts): selectTelegramFinalResponse, runSubAgent, task_complete adapter and all final delivery paths.
+
+## Accepted design and work plan
+
+- [x] Reconstruct the reported terminal path from live receipts and source.
+- [x] Build a bounded host-owned terminal report from current-epoch typed ledger evidence at commit, bound to run, epoch and terminal receipt.
+- [x] Preserve actual file effects, check outcomes/freshness, failures and explicit gaps. Report truncation rather than implying complete coverage.
+- [x] Deliver the typed report when no accepted user-facing answer exists; retain explicit user replies and genuine non-stream model answers.
+- [x] Reject stale reports, unaccepted completion replies and arbitrary bookkeeping/old streams.
+- [x] Replace opaque final fallbacks with a useful result or a clear account of missing evidence and the next required action.
+- [x] Preserve typing, Stop, authenticated delivery, artifact receipts and inert-link validation.
+- [x] Complete production-path mocked regressions, independent review, build and scoped commit/push.
+
+Completion authority and verification audit remain separate. A generic mutation does not manufacture mandatory checks. The final result reports the evidence that exists, including uncertainty; it does not promote attempted commands or model claims to verified outcomes.
+
+## Relationship to long-horizon work
+
+The user additionally requested adaptation of AIWG's research-team mechanism for feature specification, creation, integration and testing across very long runs. Its source mechanisms and fit with existing Omnius workboard/recovery are recorded in [the research mapping](../../research/aiwg-long-horizon-feature-workflow.md), with native implementation tracked in [workflow WO-01](../long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md). This terminal report provides the durable, evidence-bound handoff those longer workflows need; it does not by itself close that broader request.
+
+## Verification and delivery
+
+Implementation: 691532df, delivered to origin/main with this closure record.
+
+- Full orchestrator regression: 218 suites passed; 2,650 tests passed and one intentionally skipped with OMNIUS_SQLITE_TESTS=1.
+- Full CLI regression: 269 suites and 2,550 tests passed. An initial run found one source-regex fixture expecting the prior event guard; the expectation was updated for the stronger terminal-settled guard, its 51 focused tests passed, and the full CLI suite was rerun successfully.
+- Orchestrator and CLI builds passed; git diff --check passed. Independent review covered actual mutation attribution, typed command role and freshness, failed or missing checks, held completion replies, epoch/receipt isolation, and bounded Telegram payloads.
+- Production runner tests in accepted-terminal-reply.test.ts cover accepted replies, held attempts, terminal readiness rejection and runner reuse. terminal-task-report-runner.test.ts covers report commit and event/result identity. telegram-terminal-delivery.test.ts exercises actual mocked bridge delivery, explicit/model/report precedence, stale ownership, missing evidence and long-result truncation with full Evidence detail.
+
+The report is generated from the committed ledger without another model request. Telegram receives concrete changed paths, recorded checks, limitations and next actions; untyped piped command output is never upgraded to a verification pass.
+
+Tests use mocked inference/Telegram and temporary fixtures. No live inference, service restart, installed package replacement, external messaging or publication occurred. Existing publication staging and discovery changes remain untouched. The installed runtime remains unchanged until the user publishes.

package/docs/work-orders/runtime-health-remediation/WO-45-native-ollama-tool-contract.md

@@ -0,0 +1,33 @@
+# 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
+
+## Finding
+
+Tracing the new feature workflow schema through the actual backend found that its definitions and references survive the ordinary OpenAI-compatible and Ollama-v1 transports. The separate native Ollama unary and streaming request builders in `packages/orchestrator/src/agenticRunner.ts` omit the request's tools entirely.
+
+This is a transport contract defect for native-chat callers, not evidence that the normal v1 feature-workflow path loses its schema. A tool-capable request cannot work reliably if the adapter silently removes every tool before sending it.
+
+## Repair and acceptance
+
+- [x] Reproduce the native unary and streaming omissions with mocked HTTP responses.
+- [x] Preserve the exact advertised tools, including nested definitions and references, in both native request bodies.
+- [x] Preserve returned native tool calls and their arguments through the normalized runner response and stream lifecycle.
+- [x] Retain direct-answer/tool thinking policy, cancellation and ordinary text-only behavior.
+- [x] Run focused transport regressions, package checks and scoped Git delivery; record the implementation and verification here.
+
+The actual host runner and HTTP encoders are in scope. No live model loading, inference, service restart, installed-package replacement or publication is authorized by this verification task.
+
+## Verification and delivery — 2026-09-05
+
+Commit **26d4cbed** is delivered to **origin/main**. The repair adds the original nonempty `request.tools` to both native request bodies in `agenticRunner.ts`; existing native response decoders already preserve typed tool calls and required no change.
+
+`packages/orchestrator/tests/feature-workflow-transport.test.ts` contributes eight mocked transport cases. Exact tool schemas, including definitions and references, are compared at the actual HTTP boundary for ordinary compatible requests and native unary/streaming requests; native tool responses retain their names and arguments. The focused transport set passed **38 tests**. The final orchestrator suite passed **2,736 tests**, with **one skipped**, across **224 suites**; the clean workspace build and final workspace rebuild passed. Full cross-package acceptance is recorded in [workflow WO-01](../long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md).
+
+Publication and live model compatibility testing remain with the user.
+
+## Related work
+
+Discovered while verifying production tool delivery for [native feature workflow WO-01](../long-horizon-feature-delivery/WO-01-native-research-feature-workflow.md). The preceding Telegram final-result repair is [WO-44](WO-44-evidence-backed-terminal-results.md).