Tasks

The engagement's work, tracked per work stream. Every task traces to an activity in SOW Schedule "A" — the SOW's activity lists are the plan of record, and this section is that plan with state attached.

This is also where working notes live. Thinking happens here before it is promoted into architecture/, decisions/ or a deliverable.

Work stream	Duration	Tasks	Deliverables
WS 1 — Immersion & Validation	1 week	5	2
WS 2 — Target State Architecture	3 weeks	7	4
WS 3 — Implementation Roadmap & Cost Estimate	2 weeks	11	3

Conventions

Task IDs are WS<n>-A<m>, where m is the activity's number in Schedule "A". They are not renumbered — if the SOW says activity 4, the task is WS1-A4 regardless of what order we do the work in. Sub-tasks get a letter suffix.

Status is one of ⚪ not started · 🟡 in progress · 🔵 blocked · 🟢 done. A task is done when its output exists and is linked, not when the activity has been performed.

Blocked requires naming what it is blocked on. If the blocker is a client decision it belongs in open questions with an owner and a needed-by date; a task that is blocked on nothing in particular is not blocked, it is not started.

Current position

WS 1 is under way. The review of client-provided materials (WS1-A2) has produced summaries of all seven artifacts under Client resources. Everything downstream of validation with the client is waiting on sessions that have not happened.

The repository's standing risk is its tooling-to-content ratio: the diagram pipeline, version history and site shell all work, and the target state they exist to communicate is not written yet. The only diagram is a placeholder. Prefer writing content over extending the shell.