Tasks in Depth
Chapter 3 covered what happens when you process an inbox item into a task — the seven fields you fill in, the decision you make. This chapter covers everything a task can be after that: its lifecycle states, the additional fields available from the detail view, due dates, dependencies between tasks. Use this chapter as a reference when a specific task feature is unclear.
Task states — the full lifecycle
Every task has a status that tracks where it is in its lifecycle. You don't set these manually — the system manages them based on what happens to the task. Understanding them helps you understand why a task is or isn't appearing where you expect it.
| Status | What it means |
|---|---|
| inbox | Captured but not yet processed. Sitting in the inbox waiting for a fate decision. Not eligible for the Launchpad. |
| active | Processed and in the live task pool. Eligible for fit score computation. Will surface in the Launchpad when it scores high enough. |
| pending | Recurring task instance that exists in the database but hasn't entered its lead time window yet. Invisible to you — it will become active automatically on the right date. |
| someday | Parked. Real but not timely. Completely inert — won't appear in the Launchpad or affect any score. Surfaces during your monthly Someday review. |
| done | Completed. Removed from the active pool. Time and difficulty logged. Retained as a record. |
| missed | Recurring task instance whose due date passed, plus the grace period, without completion. Archived automatically. The next instance is generated regardless. |
| deleted | Soft-deleted. Gone from all views. Recoverable for 30 days from Settings → Recently deleted, then permanently purged. |
| template | The permanent master record for a recurring task. Holds the recurrence rule and settings. Never appears in the Launchpad — only the instances it generates do. |
The full field set
The seven fields you fill in during inbox processing — title, role, energy, time estimate, who it serves, stakes, and ease of starting — are the minimum. A task has additional fields available from its detail view, most of them optional and most of them adding either context or constraint.
Fields set at processing time
Fields available from the detail view
Due dates — when to use them and when not to
Due dates are the most commonly misused feature in task management systems. The temptation is to add a due date to everything — it creates a feeling of structure and urgency. The problem is that when everything has a due date, nothing is genuinely urgent, and the system loses its ability to distinguish what actually has a deadline from what doesn't.
ATEND supports due dates but deliberately doesn't prompt for them during processing. You have to opt in explicitly from the task detail view. This is a design choice: the system works harder to protect the signal value of a due date by making it slightly effortful to set one.
When a due date is set, the task receives an escalating urgency boost in the fit score as the date approaches. Within seven days it surfaces more often. Within three days it surfaces prominently. On the due date, it surfaces at the top of the Now list regardless of other scoring factors. If it passes its due date uncompleted, it carries a red date indicator — not as a judgment, but as information.
If you find yourself adding due dates to tasks that don't have real external deadlines — "I want this done by Friday" — consider using the Defer feature instead. Deferring to a date moves the task out of your active pool until that date arrives, without adding false urgency. The task reappears when you said you wanted it to, without telling the system it's urgent when it isn't.
Due today with no scheduled time is a special case. If a task has a due date of today but no time block on your calendar, ATEND treats this as urgent and acts — automatically scheduling it into your first available sovereign window, even if you haven't opened the app. The system also watches throughout the day and intervenes if the task hasn't been started. See Chapter 14 for the full treatment of how due-today tasks are handled.
Dependencies — when one thing must happen first
Some tasks can't start until another task is done. Dropping the key at the realtor's office depends on having made the key first. Sending the proposal depends on finishing the cost estimate. ATEND models this with a dependency link — one task referencing another as its blocker.
Setting a dependency is straightforward from the task detail view: tap "Depends on," then select the blocking task from your active pool. The dependent task immediately disappears from the Launchpad and all task views. It exists in the database but is completely invisible until the blocker is completed.
When the blocking task is marked done, the dependent task activates automatically. A notification fires: "You can now start [task title]." The task enters the active pool and will surface in the Launchpad when the fit score puts it there.
If two tasks are both part of a project, the project's next action sequence already handles ordering — only the current next action surfaces at any given time. Dependencies are most useful for tasks that aren't in the same project but have a real-world ordering constraint. "Make key" and "Drop key at realtor" might be two separate tasks in different roles — the dependency link is what connects them.
The task iceberg
Every task has a visible portion and a hidden portion. The visible portion is what you plan for — the thing itself. The hidden portion is everything underneath: the time to get ready, the drive there, the drive home, and the follow-up the event creates. ATEND gives you two tools to make that hidden mass visible, and which one you use depends on how substantial the time is.
Prep time and follow-up time — the blobs
For incidental time that doesn't need to be scheduled as a distinct block — getting dressed, gathering documents, brief decompression after — ATEND has two optional fields on every task: prep time and follow-up time. You enter a single number for each. ATEND reserves that time on the time strip as a muted segment immediately before or after the task block, includes it in your sovereign window computation, and fires a single prompt when prep time begins: "Time to get ready for dinner with the Chens."
Both are optional and most tasks don't need them. They're there for the small stuff that doesn't deserve its own entry but still costs real time.
Underneath tasks — for travel and substantial blocks
For travel specifically — and any other substantial before or after commitment — ATEND supports Underneath tasks. These are real tasks attached to a parent, with their own time estimates, their own place on the time strip as full-color blocks, and their own fit scores. A 90-minute drive to San Francisco deserves to be a real schedulable item, not a number in a field. If something commits your time in a meaningful way, it should exist in the system as a task.
Underneath tasks have a position — Before or After the parent. They appear on the time strip in order: before-tasks, then the parent block, then after-tasks. When the parent is deferred or rescheduled, all Underneath tasks shift by the same amount automatically. When the parent is deleted, they go with it.
To create an Underneath task, open the parent task's detail view and scroll to the Underneath section. Tap Add task. Three fields: title, time estimate, position. No inbox processing required.
The rule of thumb: if the time is incidental — getting dressed, brief prep — use the blob fields. If the time is substantial and needs to appear as a real block on your schedule — driving 90 minutes, meaningful preparation — make it an Underneath task. Both approaches account for the iceberg. The difference is how much structure the time needs.
A few things worth knowing
The MIT flag
Every task has an is_mit field — a boolean that marks it as today's Most Important Task. Only one task can be MIT at a time. The flag is set during the morning setup or the daily close, and cleared when the task is completed or when a new MIT is designated. You don't set this field directly — it's set by the MIT selection flow in those two rituals.
Sort order
When you manually reorder tasks in the Launchpad via long-press drag, the new sequence is stored in the sort_order field. It persists until tomorrow's first Launchpad render, at which point the system resumes control. The "Custom order — resets tomorrow" indicator is visible when a manual order is active.
Tags
Tasks support an optional tags field — a freeform list of text labels. Tags aren't used by the fit score algorithm and don't drive any system behavior. They're available for personal organization if you find them useful, and can be searched from the task list view. They're entirely optional and most users don't use them.
Soft deletes
Deleting a task sets its status to deleted rather than removing it from the database. Deleted tasks are invisible in all normal views but recoverable for 30 days from Settings → Recently deleted. After 30 days they're permanently purged. This applies to all task types including recurring instances — deleting an instance doesn't delete the template or affect future instances.