# Project Sprint

A structured workflow for executing a scoped unit of business work — a client project, a renovation, a product launch, an operational improvement. The sprint ensures nothing falls through the cracks: every deliverable is checked against what was agreed, every deviation is surfaced, and every project produces a structured record and accumulated learnings.

## Adaptive Tiers

Not every project needs the same level of structure. Select the tier based on the project's complexity, risk, and duration.

| Tier | When to use | Phases |
|------|-------------|--------|
| Quick | Simple, low-risk work: fix a leak, send an invoice, single deliverable with no dependencies | Scope, Execute, Done |
| Standard | Medium complexity: multi-step work with some dependencies and a client-facing deliverable | Plan, Execute, Verify, Debrief |
| Full | Complex projects: multi-week, multiple dependencies, significant risk, multiple stakeholders | Plan, Challenge Premise, Lock Execution, Execute, Verify, Plan Conformity, Debrief, Deliverable Review, Learnings |

When the user's intent is ambiguous, suggest a tier and let them adjust. If a Quick sprint reveals unexpected complexity mid-execution, offer to upgrade to Standard.

---

## Quick Tier

### Scope

Understand what needs doing. Confirm the deliverable, the deadline (if any), and who it's for. Create the parent Task with `[PROJECT:START]` and a single child task for the work.

### Execute

Do the work. Track progress via task notes. Check `work-ready` if there are any dependencies. Mark the child task complete when done.

### Done

Confirm the deliverable is complete. Mark the parent Task complete with `[PROJECT:COMPLETE]`. If there's a follow-up, create a new task for it.

---

## Standard Tier

### Plan

Understand the project scope: what are the deliverables, who are they for, what's the deadline, what are the dependencies. Create the parent Task and child tasks for each work item. Link dependencies via `BLOCKS` and related entities via `AFFECTS`.

Check for prior learnings: call `memory-search` with a description of the project to surface relevant learnings from past similar work. If learnings exist, factor them into the plan — adjust timelines, flag known risks, apply lessons learned.

### Execute

Work through the child tasks in dependency order. Before starting each task, check `work-ready` to confirm no blockers or AFFECTS conflicts. Append progress notes as work progresses. If a blocker is discovered mid-execution, create a new child task for it and link via `BLOCKS`.

Record phase transitions: `[PROJECT:PHASE] Execute — starting {task name}`.

### Verify

Walk through each deliverable against the acceptance criteria agreed in the Plan phase. For each deliverable:
- Is it complete?
- Does it meet the agreed standard?
- Are there any outstanding items?

Use domain-appropriate verification (see Domain Verification below).

Flag any deliverable that was promised but not delivered, or delivered differently than agreed.

### Debrief

Produce a structured record:
- **What was done:** Each deliverable and its outcome
- **What changed:** Any deviations from the original plan and why
- **What's next:** Immediate follow-up actions, if any
- **Known limitations:** Anything intentionally deferred or incomplete

Mark the parent Task complete with `[PROJECT:COMPLETE]`.

---

## Full Tier

### Plan

Same as Standard Plan, but more thorough: map all stakeholders, identify risks, estimate timeline for each work item, and define acceptance criteria for every deliverable.

### Challenge Premise

Before locking in the execution plan, challenge the scope:
- Is this the right work to do right now? Could a different framing yield a better outcome?
- What would happen if this project didn't happen? Is the pain real or hypothetical?
- Are we solving the root cause or a symptom?
- Is the scope right-sized? Too ambitious for the timeline? Too conservative for the opportunity?

Surface any concerns and resolve them before proceeding.

### Lock Execution

Finalise the execution plan: confirm the task list, dependency order, timeline, resource requirements, and acceptance criteria. This is the agreement — Phase 6 (Plan Conformity) will check the outcome against this.

Record the locked plan in the parent Task notes: `[PROJECT:PHASE] Execution locked — {n} tasks, estimated {timeline}`.

### Execute

Same as Standard Execute, with additional discipline:
- At each session start, report project health (RAG signal from the PLUGIN.md)
- Surface risks proactively — if a task is trending overdue, flag it before it becomes critical
- When a blocker is discovered, assess its impact on the overall timeline

### Verify

Same as Standard Verify, plus:
- Verify graph state — correct entities created or modified, relationships intact
- Verify communication log — messages sent, confirmations received (if applicable)
- Run domain-appropriate verification

### Plan Conformity

Compare every item in the locked execution plan against what was actually delivered. Every plan item must appear in exactly one category:

- **Implemented as planned** — delivered as agreed, with evidence
- **Deviated** — delivered differently than planned. State what changed and why.
- **Omitted** — not delivered. State why it was dropped or deferred.
- **Added** — delivered but not in the original plan. State why it was necessary.

Silent omissions — items that were in the plan but neither delivered nor flagged — are the failure mode this phase exists to prevent. If deviations or omissions are found, present them for acknowledgement before proceeding.

### Debrief

Same as Standard Debrief, plus:
- **Change log:** For every deliverable, what was done, why, and what it means
- **Dependency resolution:** Were all blockers resolved? Any still outstanding?
- **Completion checklist:** Every requirement from the plan with pass/fail status

### Deliverable Review

Review each deliverable against the original brief (not the execution plan — the brief that initiated the project). Check for completeness, accuracy, and client-readiness. Flag anything that was promised in the brief but not delivered, or delivered differently.

### Learnings

Extract operational knowledge from the project. Load `references/retrospective.md` via `plugin-read` and follow that process. This produces persistent learnings that inform future projects.

---

## Domain Verification

The verification phase should feel relevant to the business domain. Use the `businessType` property on the `LocalBusiness` node to select appropriate verification prompts. If no businessType is set, use the general prompts.

### Trades (plumbing, electrical, building, renovation)
- Has the work been physically completed to standard?
- Are all materials accounted for?
- Has the client inspected and approved?
- Are there any snagging items?
- Is the site left clean and safe?
- Has the warranty or guarantee period been communicated?

### Estate Agency (property sales, lettings, management)
- Are all required documents complete and accurate? (EPC, floor plan, particulars, contracts)
- Are photographs professional and current?
- Has the listing been posted to all agreed portals?
- Have all parties been notified of progress?
- Are compliance requirements satisfied? (anti-money laundering, right to rent)
- Is the file complete for audit?

### Professional Services (consulting, accounting, legal, design)
- Has the deliverable been reviewed against the statement of work?
- Has the client signed off or provided written acceptance?
- Are all project files organised and accessible?
- Has the final invoice been issued?
- Are intellectual property and confidentiality obligations met?
- Have handover notes been prepared for ongoing work?

### General (no specific businessType or unknown)
- Is each deliverable complete against its acceptance criteria?
- Has the recipient confirmed receipt and satisfaction?
- Are there any outstanding actions or follow-ups?
- Is the project file complete — communications, documents, decisions recorded?
