ADR-0238accepted

Human vs Machine Task Surfaces

Context

ADR-0045 established Todoist as a co-managed task system, but it never defined a hard boundary between:

  • work Joel must see, decide, or do
  • machine backlog the agent should execute or babysit itself
  • automation review queues and system bookkeeping

That missing boundary let the system rot into the same mess from two directions:

  1. Todoist contamination

    • Joel-facing views mixed human commitments with memory review tasks, infra follow-ups, stale agent chores, and system self-talk
    • non-recurring machine tasks accumulated stale due dates and created fake urgency
    • fallback behavior allowed machine queues to spill into Joel-facing projects

  2. Telegram contamination

    • the gateway surfaced repetitive low-signal operational chatter instead of reserving proactive delivery for real blockers and decisions
    • the task system felt noisy and untrustworthy because the same machine bookkeeping leaked into both Todoist and Telegram

Observed symptom at the start of this cleanup:

  • 50 open Todoist tasks
  • 19 overdue
  • 31 with no due date
  • human work buried under memory-review, infra, and agent backlog

This is not a Todoist problem. It is an audience separation problem.

Decision

Adopt an explicit task-surface split based on audience.

1. Human-facing task surface

The canonical human-facing Todoist surface is for tasks Joel must personally:

  • do
  • review
  • decide
  • track because someone will expect a follow-up from him

Default home:

  • Joel's Tasks as the canonical human project
  • minimal sections inside that project for human work
  • if Questions for Joel remains during migration, treat it as a transitional decision queue, not a general backlog sink

Human-facing tasks must be:

  • concrete
  • current
  • few enough to scan without disgust
  • free of machine bookkeeping

2. Machine task surface

Machine work does not belong in Joel-facing Todoist views.

Machine surface includes:

  • memory review queues
  • friction tasks
  • o11y triage tasks
  • infra follow-ups
  • agent research backlog
  • implementation reminders for work the agent can already perform
  • any task whose main audience is the system, not Joel

Default home:

  • Agent Work if the task truly benefits from Todoist tracking
  • otherwise a repo issue, ADR follow-up, loop PRD, or direct execution without task creation

3. Decision surface

Explicit decision requests for Joel are allowed to break out from general task flow, but they must stay narrow.

Allowed examples:

  • approve/reject a proposal
  • choose between architecture options
  • answer a blocking business question

Not allowed:

  • stuffing unresolved machine backlog into a project called Questions for Joel
  • using a decision queue as a shame pile for stale agent work

4. Default execution rule

Before creating any task, the system must ask:

  1. Can the agent do this now? If yes, do it.
  2. Does Joel actually need to see this? If no, keep it off the human surface.
  3. Is this a real decision? If yes, route it to the decision surface.
  4. Is this machine bookkeeping only? If yes, keep it on the machine surface or out of Todoist entirely.

5. No human fallback for machine queues

Machine queues must never fall back into Joel-facing projects just because the preferred machine surface is unavailable.

If machine-surface task creation fails:

  • log degraded state
  • emit OTEL
  • optionally notify only if work is blocked
  • do not spill memory review or infra junk into Joel's Tasks

6. Telegram is not a task feed

Telegram proactive delivery is reserved for:

  • blocked flows
  • explicit decisions
  • repeated failures
  • critical operator-facing state changes

Telegram must not mirror machine task churn.

7. Human prep and triage only read human surfaces by default

Daily prep, check-ins, and operator-facing task summaries should read:

  • the human-facing task surface
  • the decision surface when relevant

They should not sweep machine backlog unless Joel explicitly asks.

Consequences

Positive

  • Joel-facing Todoist becomes small enough to trust again
  • machine bookkeeping stops impersonating real urgency
  • Telegram becomes high-signal again instead of a daemon diary
  • task triage becomes more honest because it stops judging its own robot sludge as if it were Joel’s day
  • fallback behavior becomes safer: degraded machine queues no longer contaminate human views

Negative

  • some existing automation will stop creating visible Todoist tasks until machine routing is fixed properly
  • a chunk of existing Todoist inventory must be migrated, parked, or deleted
  • some old project structures will need folding into the canonical human surface over time

Non-Goals

  • replacing Todoist as the primary human task surface
  • removing TaskPort or undoing ADR-0045
  • forcing every machine workflow into Todoist; many should skip task creation entirely
  • redesigning Joel’s personal productivity philosophy from scratch
  • solving every collaboration/project taxonomy in one pass

Implementation Plan

Required skills preflight

  • task-management — human-facing Todoist behavior and capture rules
  • system-bus — task-producing functions and runtime conventions
  • inngest-durable-functions — durable machine-task routing changes
  • inngest-steps — safe step boundaries for degraded task creation paths
  • inngest-events — explicit routing and failure event contracts
  • inngest-flow-control — prevent retry spam or duplicate machine-task creation
  • gateway — Telegram/operator delivery boundaries
  • o11y-logging — degraded machine queue failures must be visible, not silent

Affected paths

  • skills/task-management/SKILL.md
  • packages/system-bus/src/inngest/functions/memory/proposal-triage.ts
  • packages/system-bus/src/inngest/functions/friction.ts
  • packages/system-bus/src/inngest/functions/friction-fix.ts
  • packages/system-bus/src/inngest/functions/nas-soak.ts
  • packages/system-bus/src/inngest/functions/task-triage.ts
  • packages/system-bus/src/inngest/functions/channels/channel-intelligence-todoist.ts
  • docs/inngest-functions.md
  • packages/gateway/src/operator-relay.ts
  • docs/gateway.md

Ordered implementation steps

  1. Declare surface ownership explicitly

    • define canonical homes for human, decision, and machine tasks
    • stop relying on implicit project names or fallback guesses

  2. Fix interactive task guidance first

    • update the task-management skill so interactive sessions stop creating machine junk in Joel-facing views
    • document the execution-first rule before any new task is created

  3. Remove machine fallback into Joel's Tasks

    • update memory/proposal-triage so failure to create machine review tasks degrades visibly instead of falling back to the human surface
    • apply the same rule to friction/o11y/infra style task emitters

  4. Retarget machine producers

    • ensure machine-generated tasks default to Agent Work or another machine-only sink
    • where Todoist is unnecessary, replace task creation with direct execution or structured logging

  5. Narrow human-facing triage

    • make tasks/triage review human-facing and decision surfaces by default
    • keep machine backlog out of operator-facing task summaries unless explicitly requested

  6. Keep Telegram out of the task swamp

    • continue suppressing low-signal recovery chatter
    • ensure machine task churn does not page Telegram unless it becomes a real blocker or decision

  7. Run migration cleanup

    • clear stale due dates from false-urgent machine tasks
    • move or park machine tasks out of Joel-facing sections/projects
    • leave recurring human habits and genuine human follow-ups intact

  8. Update docs to match runtime

    • docs and skills must describe the actual surface split, not the old mixed-state behavior

Verification

  • No machine queue function falls back to Joel's Tasks when its preferred machine surface is unavailable
  • skills/task-management/SKILL.md states the human-vs-machine split and execution-first rule clearly
  • Operator-facing Telegram delivery does not page for routine machine-task churn or low-signal recoveries
  • Human-facing task review surfaces show Joel work and explicit decision requests, not memory-review/system backlog
  • Existing stale machine urgency has been reduced by migration cleanup
  • ADR index updated and sync to system knowledge requested

Status

Accepted for immediate implementation guidance.

Runtime work is only partially complete at acceptance time:

  • gateway relay spam suppression is already underway
  • Todoist contamination cleanup has started manually
  • task-producing runtime functions still need the explicit audience split implemented