TORCH/docs/OPS_FLOW_IMPROVEMENT_SPEC.md

Operational flow improvements and Ops responsibility pilot

Owner approved 2026-10-03. Extends SELF_HEALING_QUALIFICATION_PLAN.md and existing services, backlog and authority. No additional standing agent is created.

Operational incidents and wait resolution

An incident connects the existing task, message, approval, check, resource and runtime evidence. It does not become a second task ledger. Record stable cause identity, accountable resolver, affected work, first/last observation, next action, configurable response deadline, escalation authority and resolution evidence. Keep received, acknowledged, acted-on and resolved distinct. A reply, timeout, state churn or healthy doctor result cannot resolve the underlying condition.

Acceptance scenarios:

• A waits on B, B acknowledges but does not decide: A remains waiting; a due deadline produces one actionable escalation to the correct manager.
• A current decision resolves the wait: a refreshed observation removes the active escalation, preserving original history and exact decision evidence.
• Duplicate, reordered or missed notifications: one incident per exact cause, periodic reconciliation catches the missing notification; unrelated candidates, scopes and approvers remain separate.
• Manager is offline or authority revoked: deterministic monitoring persists the wait and routes only to a currently authorized resolver; it cannot assume approval, impersonate a manager or launch a duplicate executor.
• Quota/auth failure or an uncertain live executor: persisted hold/backoff and guarded recovery remain; repeated incident notices do not create model loops.

Reuse existing event/reconciler, approval-dedup and attention tasks. Contract/API changes require owned review, revision checks and independent QA; no prompt-only claim of successful incident handling.

Source adoption and test/QA handoffs

Provide a supported, attributable path from a legitimate contributor/release candidate to registered ownership and native exact-candidate qualification. Bind source and destination identities, immutable SHA, ownership/path scope, required contributor consent and actual engine/adapter provenance. Preview current branch/worktree/assignment/guard/lease state before any mutation.

• A clean exact owner-approved release candidate can be transferred or composed through the supported route and produce fresh native check receipts, independent review and serialized integration without a manual branch reset.
• Dirty destination, active task/check/lease, stale source or changed approval refuses/defer with an exact remedy and responsible owner; preserve every byte and unique commit. Installation activation never counts as canonical landing.
• Interrupted/repeated adoption is idempotent; preserve original lineage and failure evidence. Never fabricate receipts or silently change scope.
• Test handoff has a named test implementer, exact permitted paths/scenarios, candidate/revision binding and reviewer. Approved additive tests can proceed without repeatedly seeking the same consent; new scope needs a new decision.
• QA rejection returns an actionable issue to a named owner. QA acceptance is exact and independent, never a blanket authority or weakened test criterion.

Extend the existing candidate-source qualification and authority services, not a parallel landing queue. Agree owned interfaces and contribution boundaries once, then validate them mechanically. Preserve one active assignment per specialist.

Additive acceptance for existing Chat and evidence tasks

Applies to TASK-owner-agent-chat, TASK-console-agent-chat-ui, TASK-company-evidence-ux and TASK-console-attention-actions. Retain all original criteria. The installer currently has no owner criterion-amendment API; attach this owner-approved addendum by durable references, with manager-owned tracked reconciliation rather than unsupported live task-file rewriting.

• Message status distinguishes queued, delivered/observed, acknowledged, action started, decision/result and failed; unsupported stages remain unknown.
• Configurable response expectations show overdue requests and next resolver, using deterministic reconciliation without duplicate wakes or owner nagging.
• Explicit permission-denied/provider-unavailable/offline states explain delay; measured response latency is not an invented completion-time guarantee.
• Separate process activity from implementing, checking, coordinating and waiting. Progress includes timestamp/source and links to exact changes/checks/decisions; unavailable evidence is unknown, not idle, success or a fabricated percentage.
• A continuously active agent with an unresolved wait is visibly waiting or coordinating; acknowledgements and unchanged status reports never imply useful delivery. Display owner interventions and verified integration separately.
• Desktop/mobile/keyboard and stale/reconnected observation scenarios preserve current modal accessibility, recipient identity, drafts and approval boundaries.

Ops responsibility pilot

Provider Runtime is the initial Ops engineering contact, with Work and Integration and Release collaborating within their existing implementation ownership. Session Manager retains priority/assignment authority. This request creates no new role capability, worktree, model choice or overlapping implementation owner. Manager must arrange eligible task slices without overloading the existing active assignment. Native temporary helpers stay under their responsible identity and are used only when supported by the approved runtime policy.

Deterministic monitoring handles routine detection and qualified recovery. Ops investigates novel incidents, proposes repairs/runbooks and measures recurring failure causes. Ops cannot self-approve checks, overwrite dirty work, change product priorities, spend through a paid fallback, or broaden recovery authority.

Review after ten resolved incidents or seven active development days, whichever comes first. Record investigation vs waiting time, repeat incidents, escalations, owner interventions, regression/recovery failures and displaced implementation work. Recommend a dedicated standing Ops specialist only if sustained incident load crowds out implementation and a distinct ownership/outcome can be shown. Any new identity follows the existing approved organization-change pathway.

Success means fewer repeated unresolved handoffs and owner interventions without weaker checks, higher failure rates or unbounded retries. Report the baseline and observed result; do not claim the organizational change worked from agent count.