People plan their own tasks by date, and projects need no repository

Mission Control was built to hand work to agents, but a person's day also holds work no agent touches, such as an errand or a call, and work that only sometimes needs one. We decided that it is also a person's daily task manager, without a second operating model: a task can have a start date, a deadline and a priority, and a person sees their own tasks in lists derived from those, such as Today. Only the start date does anything: when a backlog task's start date arrives, Mission Control moves it to todo, and from there the rules that already exist apply, so a role's agent starts on it and a person finds it in Today. Deadlines and priority inform people and agents and change nothing. A project no longer needs a repository, so work that is not code, such as a household, has a place to be filed; the repository was only ever where agents look, not a limit on where they work (ADR 0016, ADR 0023).

Considered Options

• A start date as a view only, which hides a task until its day and changes nothing else: rejected. A role's task "to start on Monday" would start at once, which surprises.
• A start date as a gate on agents, like a blocker that clears on a date: rejected. It is a second rule for when agents start, beside blocking links, and overlaps one-off routines. A transition to todo keeps one rule and shows in the task's history.
• A start date that also moves tasks, such as a todo task back to backlog when a later date is set: rejected. It only ever moves a backlog task to todo; setting it moves nothing.
• Escalating overdue tasks up the reporting chain, as stalled ones are (ADR 0025): rejected. Late is not stuck, and Mission Control does not chase people.
• A planning field per person, such as their own Today: rejected. A task has one assignee, so the task's dates are the assignee's plan.
• An inbox for capture: rejected; capture is triage, a task not yet accepted. Inbox stays the feed of what others did.
• Areas, ongoing responsibilities above projects: rejected. A project already never finishes, and a finite piece of work with steps is a task with subtasks. When a person works across organizations, the organization will be that context.
• Checklists as their own records: rejected for checkboxes in the description, which agents already read and edit. A step someone works on is a subtask.

Consequences

• Dates are days in the organization's timezone. An organization has a timezone, which also becomes the default for its routines; a start date is reached at the start of its day there.
• A start date fires once. Mission Control moves a backlog task to todo once for each start date, as the System with the reason the date was reached. A person who moves it back to backlog keeps it there until they set another date; a start date set to today or earlier on a backlog task moves it on the next tick. Tasks in any other status ignore it.
• A role's task runs for its requester when its start date moves it and nobody sponsors it yet, as a person handing it over would have (ADR 0019); otherwise its run would wait for a runtime configuration.
• No polling for agents. The start date is checked on the tick that already makes routines due; agents still wake only on what happens to their tasks.
• Agents see the dates and priority through the template context (ADR 0008), so a role can say a deadline is near, and they can set them as they set any field.
• Lists show only a person's own tasks, and those whose agent waits for their reply. Other work given to a role is followed on the board and in the inbox, not in Today, whatever its dates.
• A project has a forge and a repository together, or neither, and can gain or lose them later. Pull requests are linked by their repository, not the project, so losing one changes no task. An organization's own edited copy of a built-in skill keeps its advice to clone every project.
• Ticking a checkbox edits the description, so ticking while an agent rewrites it keeps the last write; for a checklist that is accepted.