# Chore Concepts
## Tasks
Chore is built around _tasks_, which are the smallest unit of work to be
tracked. These are represented with a single line of text. For example:
```
write README.md
```
## Projects
A _project_ is metadata associated with a given task used to organize it.
Multiple tasks may be associated with the same project to create a "super" task
of all the tasks with the same project. If it fits your mental model better,
consider thinking of what Chore calls a project as a "task" and what Chore
calls a task as a "subtask."
Projects are represented by a `+` followed by non-whitespace characters. They
may appear anywhere within the body of a task. For example,
```
write +chore README.md
complete +chore test coverage
```
are two tasks associated with the `+chore` project. A task may have zero, one,
or more projects.
## Contexts
A _context_ is metadata associated with a given task used to restrict the
task's visibility to the time and place it is meaningful. Contexts are
generally locations, tools, or people required to pursue the task.
Contexts are represented by a `@` followed by non-whitespace characters. They
may appear anywhere within the body of a task. For example,
```
@home clean kitchen
give intern tour around @work office
```
are two tasks with different contexts. The first task is only applicable at
home, and the second only at work. A task may have zero, one, or more
contexts.
## Pairs
A _pair_ is generic key-value metadata associated with a given task.
These are represented by a _key_ composed of a series of non-whitespace
characters followed by a `:` which is in turn followed by a _value_ composed of
non-whitespace characters. Keys have several additional constraints to avoid
parsing ambiguities:
- Keys may not contain a `.` or `:`.
- Keys may not start with a `+` or `@`.
Keys must contain at least one character, but values may (for most keys) be
empty. Pairs may appear anywhere within the body of a task. For example,
```
@work code review issue:123
```
contains the pair `issue:123` composed of the key `issue` paired with the value
`123`. A task may have no more than one pair for any given key.
## Tags
Collectively, projects, contexts, and pairs are referred to as "tags."
## Annotations
An _annotation_ is a bit of text associated with a task used to quickly add
information to an already created task.
These are segregated from the main text body by a `|` character. By design,
they must occur at the end of a task. For example, after this task is created:
```
+chore implement annotation system
```
the user may wish to annotate additional thoughts:
```
A task may have zero, one, or more annotations.
## Completion marker
A task which starts with an `x` whitespace separated from any other content is
considered completed; otherwise, a task is considered pending. For example,
```
+chore +document entry and end dates
+chore +document priority
x +chore +document contexts
x +chore +document pairs
x +chore +document projects
```
has two pending tasks and three completed tasks. This `x` is referred to as a
_completion marker_.
Note that when sorting by ASCII value pending tasks will generally sort before
completed ones.
## End date
A task's _end_ indicates when the task was completed.
These are represented in the `YYYY-MM-DD` form and must immediately follow a
task's completion marker. For example, in
```
x 2020-12-29 +chore +document projects
x 2020-12-30 +chore +document contexts
x 2020-12-30 +chore +document pairs
```
one task was completed on December 29th, 2020, and two were completed on the
following day.
To ease manual maintenance of Chore files, end dates are optional.
Note that when sorting by ASCII value completed tasks are generally sorted by
end date.
## Priority
A _priority_ is an indication of the relative importance and urgency of a given
task.
These are represented by a `(` followed by a capital letter `A` through `Z`
then a `)`. Earlier letters in the English alphabet are interpreted as higher
priorities than later letters. To be interpreted as a priority, these must
follow any completion marker and end date but precede a task's body. For
example:
```
(H) pay +gas bill due:2020-12-31
(M) +chore +document entry and end dates
(M) +chore +document priority
(Z) +movies watch Citizen Kane
x 2020-12-29 (M) +chore +document projects
x 2020-12-30 (M) +chore +document contexts
x 2020-12-30 (M) +chore +document pairs
```
is composed of tasks with priority `H`, `M`, and `Z`.
A task may lack a priority, in which case it is interpreted a being lower
priority than `(Z)`.
Note that when sorting by ASCII values pending tasks are generally sorted by
priority.
## Entry date
A task's _entry_ indicates when the task was created.
These are represented in `YYYY-MM-DD` form. To be interpreted as an entry
date, these must immediately precede the task body, following any completion
marker, end date, and priority.
For example:
```
(H) 2020-12-14 pay +gas bill due:2020-12-31
(M) 2020-12-27 +chore +document entry and end dates
(M) 2020-12-27 +chore +document priority
(Z) 2021-01-02 +movies watch Citizen Kane
x 2020-12-29 (M) 2020-12-27 +chore +document projects
x 2020-12-30 (M) 2020-12-27 +chore +document contexts
x 2020-12-30 (M) 2020-12-27 +chore +document pairs
```
To ease manual maintenance of Chore files, entry dates are optional. Chore's
`add` command will automatically set an entry date.
If a completed task which lacks a priority only has one date, making it
ambiguous whether the date is an end date or an entry date, it is
interpreted as an end date. For example:
```
x 2020-12-29 +chore +document projects
```
is interpreted to have completed on December 29th, 2020 and lacks an entry date.
## Task format summary
Tasks are represented by:
```
x YYYY-MM-DD (X) YYYY-MM-DD task body +proj @ctx key:val
| | | | | `--------+- optional entry tags and annotations
| | | `-+- optional priority
| `--------+- optional end
`- completion marker, if task is completed
```