# Projects Guide

## What a Project Is

A project is a named body of work with multiple steps, dependencies, and a lifecycle. Unlike standalone tasks, a project has child work items that can depend on each other, a health signal that tracks progress, and lifecycle phases (planning, active, blocked, verifying, complete, abandoned).

Projects are ideal when the user has work involving multiple people, sequential steps, or deliverables — a kitchen refit, a client engagement, a product launch.

## Creating a Project

Tell {{productName}} naturally:

- "Create a project for Mrs. Chen's kitchen refit — strip the old kitchen, plumbing first fix, electrical first fix, install units, then tiling and finishing"
- "Set up a project for the bathroom renovation, standard tier, due by end of June"
- "Start a project: boiler install for Sarah Thompson, quick job, just order parts, install, and test"

{{productName}} creates the project and all work items in one step. Dependencies between steps (e.g., "install units after plumbing and electrical") are set up automatically based on the order and relationships you describe.

Each project has a tier that reflects its complexity:
- **Quick** — straightforward, few steps (e.g., boiler install)
- **Standard** — moderate complexity, multiple phases (e.g., kitchen refit)
- **Full** — significant scope, many dependencies (e.g., new build project)

## Checking Project Status

Ask naturally:

- "What are my projects?"
- "How's the kitchen refit going?"
- "Show me the Davies bathroom project"
- "What should I focus on?"

{{productName}} shows project health at a glance:
- **Green** — on track, no issues
- **Amber** — warning signs (overdue task or blocker)
- **Red** — at risk (multiple overdue, critical blocker, or stale)

When you start a new conversation, {{productName}} automatically shows active project summaries so you know where things stand without asking.

## Updating a Project

Tell {{productName}} when things change:

- "Move the kitchen refit to the active phase"
- "The materials for the kitchen refit are delayed by a week"
- "Update the Davies bathroom target date to July 15th"
- "Change the boiler install to a standard tier — it's more complex than we thought"

{{productName}} records phase changes and issues as part of the project's history, creating an audit trail.

## Completing a Project

Tell {{productName}}:

- "Mark the boiler install as done"
- "Complete the kitchen refit project"

If any work items are still pending, {{productName}} will let you know and ask how to handle them — cancel, defer, or keep working on them.

## Abandoning a Project

If a project is no longer needed:

- "Abandon the Davies bathroom — client cancelled"
- "Stop the kitchen refit project"

{{productName}} records the reason and marks the project as abandoned.

## Projects vs. Tasks

Use a **task** for standalone work — a single action, a reminder, a follow-up. Use a **project** when the work has multiple steps that depend on each other, a client or stakeholder, and a lifecycle that progresses through phases.

When you describe multi-step work, {{productName}} will ask if you'd like to structure it as a project. Over time, it learns your preference and stops asking.

## Working a Task End to End

Ask {{productName}} naturally:

- "What's outstanding?"
- "What's on my plate?"
- "What should I work on next?"
- "Pick something to do"

{{productName}} reads the ready set for your account, groups the open Tasks under their parent Projects, and asks you to pick one. You pick — it never auto-selects.

Once you pick, the loop runs end to end:

1. **Grounding** — pulls the Task and its surrounding context (parent Project, related documents, prior conversation) so the run starts from what is already known, not a blank slate.
2. **Delegation** — routes the work to the right specialist surface. A research task goes to deep-research, an email reply to email composition, a document to professional-document, and so on. Nothing is reimplemented inline.
3. **Write-back** — every artefact produced (document, email, ingested file) is linked to the Task in the graph, progress is logged on the Task, and the Task is closed when done.

This means you can always trace a finished piece of work back to the Task that asked for it, and a Task that says "complete" always has its output attached.

Cross-account access is refused. A Task that belongs to a different account on the same install is invisible to this loop — {{productName}} will not read it, name it, or surface it.
