Receiving a task is only the beginning

A form submission starts a chain of work: check prerequisites, find an owner, update the source task, create the downstream work and retain the decision. My Intake Router contributions addressed that chain, including the initial preflight system, the submission wizard, Teamwork integration, routing controls and delivery recovery.

The difficult boundary was completion.

An HTTP acknowledgement proves that a request reached an endpoint. It does not prove that the source task moved, an assignee was applied or the downstream task exists. The router needed to keep those facts separate.

The workflow grew beyond a webhook

The initial the authored change established parallel prerequisite checks, a structured Teamwork comment, routing and a retained log. The authored change added a progressive form, deadline rules, companion tasks and orchestration. Later changes integrated client affinity and the DRI ownership system.

My implementation history also contains the less visible work that made this usable: field parsing, task metadata, board-stage identifiers, calendar scheduling, source-task containment and child assignment. Those changes belong in the workflow story. A presentation describing hundreds of decision paths is a design record; it does not independently establish that every path ran in production.

Inspect the system diagram

Open full-size SVG →Horizontal version →

Editable model and SVGs. The queue and provider operations are separate boundaries.

The check status and routing policy answer different questions.

Isolate checks without inventing a pass

The inspected preflight runner settles its checks independently. A thrown check becomes a FAIL result with its error message, allowing the other checks to contribute evidence. That error result has blockWork: false; a check failure is not automatically a work-blocking policy decision. The routing policy must interpret the check results.

That distinction matters when explaining the system.

I would show the failed check next to the other results, then trace how the router uses it. I would not describe catching an exception as successful validation. Likewise, read-only, shadow and active routing are different operation modes. Shadow mode can post an advisory comment and telemetry; it is not free of all external effects.

A real integration failure

The authored change corrected a payload that used a human-readable boardColumn string where the integration needed a numeric columnId. It also corrected the comment endpoint. The inspected diff shows the column resolved from configuration and included only when available.

The lesson is concrete: a locally plausible payload can be ignored by the provider. Completion must depend on the required mutations being confirmed, not on the shape of the proposed routing decision.

The authored change tightened that completion contract. In the inspected source, mvpReady requires the preflight comment, confirmed routing mutations and retained preflight log. Calendar and efficiency failures can remain warnings. The processor also checks for the retained log before recording completion.

Recovery after acknowledgement

Later the authored change and the authored change contributions addressed recoverable provider payloads and stranded queued tasks. Their descriptions explain why a deferred acknowledgement and an independent poller were needed. The queue version and bounded draining path are visible in the inspected source.

The queue records a normalized task identity in a Firestore transaction. Completed tasks and fresh processing claims are skipped; eligible work can be queued for the poller. The shared processor hydrates shallow payloads and excludes Atlas-created destination tasks to prevent routing recursion.

My case-study boundary stops short of exactly-once delivery. A Firestore claim does not atomically commit Teamwork updates, task creation and the local completion record. A failure after an external mutation can leave partial work. Recovery must inspect the affected operations rather than assume that a retry starts from nothing.

Synthetic sequence

This invented task uses no client data or live endpoint.

1. A provider sends a shallow payload for task 101. The authenticated receiver queues the task identity.
2. A duplicate hint arrives. The queue refreshes delivery metadata; a fresh processing claim prevents a second eligible processing attempt.
3. The processor hydrates the task. One prerequisite check throws, while the others return evidence. The failure remains visible.
4. Routing resolves the owner and stage. The source task comment succeeds, but a required downstream mutation fails.
5. The processor records failure rather than completion. An operator inspects the partial provider state before recovery.
6. Only confirmed required mutations plus the retained log permit a completed run record. An Atlas-created destination task is excluded from becoming another source intake.

What I can defend

My authored record supports a story about converting intake into inspectable workflow execution: parallel evidence collection, explicit routing modes, provider-specific fixes, durable queuing and stricter completion. It does not establish zero manual triage, universal duplicate prevention, current launch configuration or a measured reduction in routing time.

The September history adds conditional replay holds, atomic template-dependency work, maintenance containment and further assignment repairs. Those records extend the chapter's coverage but require later-revision inspection before their behavior is presented as verified implementation.