# Parallel Task Analysis Rules

## Purpose
Define a consistent, rigorous standard for identifying which implementation tasks can safely execute in parallel during the generation of `tasks.md`.

Parallelization reduces implementation calendar time, but incorrect parallel marking causes merge conflicts, broken builds, or flawed integration. Apply these rules conservatively.

---

## Eligibility Criteria
A task qualifies for parallel marking (`(P)`) only when **all four** of the following conditions are satisfied:

1. **No data dependency**: The task does not consume the output — data, types, schemas, or side effects — of any other task that has not yet been completed when this one starts.

2. **No shared mutable resource conflicts**: The task does not write to, rename, or delete any file, table, store, or configuration item that another concurrently running task also writes to.

3. **No required prior approval or review**: The task does not depend on a human decision, review, or merge that would be produced by another task in the same batch.

4. **Environment and setup are self-contained**: Either the required infrastructure, migrations, and setup already exist in the repository, or they are entirely contained within this task and need not be produced by a sibling task.

If any single condition fails, do not mark the task with `(P)` and explain the blocking dependency in the task's detail bullets.

---

## Marking Convention

- Append `(P)` immediately after the numeric task identifier — outside the checkbox brackets
- Apply to major tasks and sub-tasks independently based on their own eligibility
- **Example**:
  ```markdown
  - [ ] 2.1 (P) Build the background notification worker
  - [ ] 2.2 (P) Build the notification preference reader
  - [ ] 2.3 Integrate worker with preference reader
  ```
  Tasks 2.1 and 2.2 each introduce a new isolated component; 2.3 depends on both, so it cannot run in parallel with them.

- **Skip `(P)` on container-only major tasks**: If a major task has no actionable detail bullets of its own and exists purely to group sub-tasks, evaluate parallelism at the sub-task level — do not mark the container.

- **Sequential mode**: When `--sequential` is requested, omit all `(P)` markers from the entire task list.

---

## Grouping and Ordering Guidelines

- Group parallel tasks under the same parent major task when they belong to the same thematic area — this makes concurrent work obvious to the implementer.
- List any ordering caveats, prerequisites, or shared state assumptions explicitly in the detail bullets (e.g., "Requires schema migration from task 1.2 to be deployed before this task can begin").
- When two tasks appear similar but are not parallel-safe, call out the specific blocking dependency explicitly in the detail bullets rather than leaving it implicit.

---

## Pre-Marking Quality Checklist

Before adding `(P)` to any task, verify:

- [ ] Running this task concurrently with its siblings will not cause a merge conflict in shared files
- [ ] No shared mutable state (database table, in-memory store, event stream) is written by two parallel tasks in a way that could cause corruption or ordering issues
- [ ] The task can be tested in isolation before its siblings complete
- [ ] Any shared interface expectations are documented in the detail bullets so concurrent implementers have a common contract to code against

If any check cannot be confirmed, **remove** the `(P)` marker and document the blocking dependency. A missed parallel opportunity is recoverable; a concurrent conflict can be expensive to debug.
