Decisions

  • Pending: Polling vs event-driven intake?
  • Pending: Auto-advance threshold — when can tasks skip human approval?
  • Pending: Priority calculation for incoming tasks

User Tasks


Summary

The glue between task arrival and autonomous execution — classifies incoming tasks, decides human vs autonomous handling, and dispatches to the orchestrator.

Problem / Motivation

  • Tasks arrive from multiple channels: /idea skill, quick-notes, GitHub Issues (FR-065), Telegram (FR-069), email (FR-012) — but nothing connects them to the orchestrator.
  • FR-025 (Inbox Zero) processes raw input into FRs. FR-056 (Orchestrator) polls for planned FRs. But the journey new → planned → dispatched has no owner.
  • Without a dispatcher, every task requires manual /approve/implement — defeating the purpose of autonomy.
  • Different tasks need different routing: a typo fix can go straight to autonomous execution, a new feature needs design review first, a vague idea needs clarification.
  • The system needs a single entry point that all channels feed into, with consistent classification and routing logic.

Proposed Solution

A Task Dispatcher that:

  1. Watches all intake channels (vault inbox, GitHub Issues, Telegram, email)
  2. Classifies each task (complexity, risk, type, completeness)
  3. Routes based on classification:
    • Simple + low-risk → auto-advance to planned, dispatch to orchestrator
    • Medium complexity → create FR, queue for human review
    • Complex / high-risk → create FR + flag for design review (FR-008)
    • Incomplete / vague → request clarification from source channel
  4. Dispatches approved tasks to the orchestrator (FR-056)

Open Questions

1. Intake Model

Question: How does the dispatcher discover new tasks?

OptionDescription
A) Polling + webhooksPoll vault/inbox periodically, receive webhooks from GitHub/Telegram
B) Polling onlySimple, works everywhere, but slower
C) Event-driven onlyReal-time but requires infrastructure for every channel

Recommendation: Option A — polling for vault (low-tech), webhooks for external channels (real-time).

Decision:

2. Auto-Advance Criteria

Question: When can a task skip human approval and go straight to the orchestrator?

OptionDescription
A) Rule-based + escalation policyCombine task classification with FR-059 escalation rules
B) Never auto-advanceHuman always approves (safe but slow)
C) Always auto-advanceFull autonomy (fast but risky)

Recommendation: Option A — leverage FR-059’s risk framework. Example: bug fix in registered project with tests → auto-advance. New feature → human review.

Decision:

3. Clarification Flow

Question: How does the dispatcher request clarification for vague tasks?

OptionDescription
A) Reply via source channelTelegram task → reply on Telegram; GitHub Issue → comment on issue
B) Always create FR with questionsCreate FR in new/ with open questions, wait for human
C) AI-assisted completionLLM attempts to fill gaps, flags low-confidence assumptions

Recommendation: Option A for external channels, Option B as fallback.

Decision:


Phase Overview

PhaseDescriptionStatus
Phase 1Vault inbox watcher + classification + manual dispatch
Phase 2Auto-advance for qualifying tasks + orchestrator integration
Phase 3External channel intake (GitHub Issues, Telegram, email)
Phase 4Clarification flow + feedback loop to improve classification

Phase 1: Vault Watcher & Classification —

Goal: Watch vault inbox for new items, classify them, and prepare for dispatch.

File / FeatureDetailsOwnerStatus
src/opus/dispatch/watcher.pyInboxWatcher: poll vault/90_inbox/ and vault/10_features/02_new/opus
src/opus/dispatch/classifier.pyTaskClassifier: assess complexity, risk, type, completenessopus
src/opus/dispatch/router.pyRoutingEngine: apply rules to classification outputopus
Classification outputTag FRs with dispatch: auto/review/design/clarify in frontmattermv
/dispatch skillManual trigger: classify and route all pending tasksmv

Classification dimensions:

DimensionValuesSignal
Complexitytrivial / low / medium / highPhase count, scope description, dependencies
Risklow / medium / high / criticalFiles touched, external APIs, data changes
Typebugfix / feature / refactor / docs / infraKeywords, affected paths
Completenesscomplete / needs-detail / vagueHas acceptance criteria? Clear scope?

Routing rules:

ClassificationRoute
trivial + low-risk + completeplanned, queue for orchestrator
low + low-risk + completeplanned, queue for orchestrator
medium + anynew, flag for human review
high + anynew, flag for design review (FR-008)
any + incompletenew, add clarification questions

Phase 2: Auto-Advance & Orchestrator Integration —

Goal: Qualifying tasks flow from intake to execution without human intervention.

File / FeatureDetailsOwnerStatus
src/opus/dispatch/dispatcher.pyDispatcher: advance FR status + notify orchestratoropus
Escalation integrationCheck FR-059 policy before auto-advancingopus
NotificationLog auto-advanced tasks, notify user of batch decisionsmv
OverrideUser can override any auto-advance decisionmv

Flow:

intake → classify → route → [auto: advance + dispatch] or [manual: queue + notify]

Phase 3: External Channel Intake —

Goal: GitHub Issues, Telegram messages, and emails become tasks in the pipeline.

File / FeatureDetailsOwnerStatus
src/opus/dispatch/channels/github.pyPoll labeled issues → create FRsopus
src/opus/dispatch/channels/telegram.pyReceive messages → create FRs (depends on FR-069)opus
src/opus/dispatch/channels/email.pyParse emails → create FRs (depends on FR-012)opus
Channel metadataTrack source channel on FR for reply routingopus
DeduplicationDetect duplicate tasks across channelsopus

Phase 4: Clarification & Learning —

Goal: Request missing information and improve classification over time.

File / FeatureDetailsOwnerStatus
Clarification templatesPer-type question templates for incomplete tasksopus
Reply routingSend clarification via source channel (FR-059 escalation channel)opus
Classification feedbackTrack human overrides of classification → improve rulesmv
Accuracy metrics% of auto-advanced tasks that succeeded vs were revertedopus

Prerequisites / Gap Analysis

Requirements

RequirementDescription
REQ-0Design doc reviewed and approved
REQ-1FR-056 (Orchestrator) — dispatch target
REQ-2FR-059 (Escalation Policy) — auto-advance rules
REQ-3FR-009 (Python scaffold) — code infrastructure

Current State

ComponentStatusDetails
Inbox processingin-progressFR-025 /inbox-review skill (manual)
FR lifecyclenewFR-043 /approve skill (manual)
OrchestratornewFR-056 polls for planned FRs
ClassificationNothing exists
Auto-routingNothing exists

Gap (What’s missing?)

GapEffortBlocker?
Task classifierMediumNo
Routing rules engineMediumNo
Vault watcherLowNo
Orchestrator handoffLowDepends on FR-056
External channel adaptersHighDepends on FR-069, FR-012

Test

Manual tests

TestExpectedOwnerActualLast
Drop quick-note in inboxClassified and routed within polling intervalopuspending-
Trivial bugfix taskAuto-advanced to planned, dispatchedopuspending-
Complex feature taskStays in new, flagged for human reviewopuspending-
Vague task with no detailsTagged for clarification, questions generatedopuspending-
GitHub Issue with opus-task labelFR created in vault, classified, routedopuspending-

AI-verified tests

ScenarioExpected behaviorVerification method

E2E tests

ScenarioAssertion

Integration tests

ComponentCoverage

Unit tests

ComponentTestsCoverage

History

DateEventDetails
2026-03-12CreatedIdentified as missing glue between intake and orchestrator

References

  • FR-025 (Inbox Zero Automation) — current manual intake processing
  • FR-056 (Autonomous Coding Orchestrator) — dispatch target
  • FR-059 (Escalation Policy) — auto-advance rules
  • FR-038 (Complexity Routing) — complexity scoring feeds classification
  • FR-043 (Approve & Implement Skills) — manual approve/implement, this FR automates
  • FR-069 (Phone Access / Telegram) — external intake channel
  • FR-012 (Email & WhatsApp) — external intake channel
  • FR-065 (Multi-Repo) — tasks may target different projects