DeepWorkPlan — Status

Report the current state of one or more Deep Work Plans — progress, completed
tasks, current task, checkpoint, blockers, consistency — without executing or
modifying anything, and without loading the whole plan.

Shared resources (read these)

• `../shared/context.sh` — resolve dwp_dir.
• `../shared/dwp-paths.md` — plans at
  .dwp/plans/<plan>/.
• Guide (essential — read for this flow): none. Status is a read-only report; it does not load the methodology guide.

Parameter Support

• /dwp-status {plan_name} — check a specific plan.
• /dwp-status latest — check the highest numbered plan, or the most recently modified legacy plan.
• /dwp-status all — check all plans.
• No parameter → interactive scope selection (Step 1).

Normalize the PLAN_ prefix; validate that single plans exist under
.dwp/plans/. If not found, show available plans and ask the user to choose.

Lite-aware status

For v2 plans report format, materialization, approval and promotion separately
from execution progress. Read them from state.json; fall back to the README's
Approval row when the field is absent, and to pending when neither is present. A ready pending-review Lite proposal is valid but not
executable. Resolve inline task locators against unique README anchors and count
only canonical task-index checkboxes, never fenced examples. Report a missing or
duplicate anchor, pending approval, or promotion marker as a finding; do not
repair it in this read-only flow.

Trust boundary (write scope)

This skill is read-only by contract. allowed-tools lists Bash (which
Trust Hub treats as write-capable in general) — here it is used exclusively
for read-only inspection. Status reads plan folders, progress checkmarks, and
state.json, and reports; it performs no writes of any kind.

It MUST NOT: modify tasks, progress, state.json or source files; "fix" a
plan while reporting on it; or write anywhere. If the status reveals an
inconsistency, report it and point at refine/resume — do not repair it
silently.

Workflow

Step 0 — Check for Parameters

all → scope "all", skip to Step 2. Otherwise resolve the supplied full name,
ID, unique slug or latest with ../shared/plan_paths.py --plans-dir <dwp_dir>/plans resolve <selector>, set scope "single", then go to Step 2.
No parameter → Step 1.

Step 1 — Ask for Scope

Use ../shared/plan_paths.py --plans-dir <dwp_dir>/plans list to list plans;
the numbered folders appear in numeric order. latest is the highest plan ID
when numbered plans exist, or the most recently modified legacy plan otherwise.
Offer: a single plan (by ID or name), all plans, or latest.
Accept an ID, name, all, or latest.

Resolve a single selection with ../shared/plan_paths.py --plans-dir <dwp_dir>/plans resolve <selector>; accept full names, IDs and unique slugs.
If a slug is ambiguous, request the full name or ID.

Step 2 — Gather Status Information (compact projection first)

v6 plans first: a plan folder with a manifest.json contract pointer,
contract.json or a contracts/ chain is v6 — its records are the journal,
not state.json. Report from the shipped read-only commands, never by
re-deriving by hand: python3 ../shared/ledger.py --plan <dir> inspect
(events, one line each, torn tails reported); python3 ../shared/scheduler.py ready <dir> (next dispatch, read-only);
python3 ../shared/resources.py --plan <dir> report / routing / hold
(envelope posture, incl. any exhaustion hold); python3 ../shared/outcomes.py --plan <dir> receipt (recomputed outcome receipt —
it changes when the records change). Do not run project or
views.py render here — both write, and this flow stays read-only; the
state.json already on disk is a v6 projection and may be quoted with its
generated_at stamp, marked as derived. Status findings (torn tail, no
approval event, projection disagreement) are reported with their suggested
repair, never repaired. For a v7 plan, also run python3 ../shared/ledger.py --plan <dir> delegate observe (read-only) and report each delegation's
task, transport, addon and state — a completed delegate is still
asserted until a gate observes it. Then continue with the README index and
consistency reading below (items 2–5 apply unchanged; item 1's
state.json is a v6 projection).

For each (non-v6) plan:

1. State first. If state.json exists, read it: status, completed_count
   / task_count, checkpoint, blocked, updated_at/updated_by, and the
   per-task status list. This is the compact projection; it is enough for the
   summary.
2. README index. Read the README's goal, Plan Status line, task list
   ([x]/[ ], any (re-validate…) markers), **Standard:** line and
   pre-approval note. When there is no state.json, the README is the only
   source and the report says so.
3. Consistency check (../spec/PLAN_STATE.md §5): compare README checkboxes
   with state.json task statuses and completed_count; compare [x] tasks
   that carry a commit with git log --oneline -20; note a checkpoint whose
   task is [x], a blocked entry on a [x] task, or a task_count that
   differs from the number of task files. Every disagreement is a finding
   (which tasks, which direction, markdown is authoritative) — never an edit.
4. Targeted detail only. Read the last completed task's Completion & Log and
   the current [ ] task file's title/goal; run git status. Do not read every
   task file or every gate record.
5. Compute totals and progress %.

Enabled addons (any generation, read-only). Run python3 ../shared/config.py enabled --plan <dir> once per repository: it prints the
addon keys the repository's .dwp/config.json (over ~/.dwp/config.json)
enables, one per line, and any fail-closed warning on stderr
(../spec/CONFIG.md). Report them as one line — addons enabled: none is
an ordinary answer, never a finding; the methodology works alone. Never
write the file from this flow.

Step 3 — Generate Status Report

Single plan: header with the resolved plan basename and its actual location;
standard (and whether pre-approved for unattended
execution); goal; progress (total / completed / pending / %); completed tasks;
pending tasks; current status (last completed, next task, checkpoint note,
uncommitted work, recent commits); enabled addons (one line);
blocked (reason, since, needs) if set;
consistency findings if any, with the suggested action (resume to
reconcile, refine to fix structure); notes from the README; last task log
summary; whether an Executive Report was requested/produced.

All plans: a one-line-per-plan summary (progress, status, blocked?, last
activity), then the single-plan detail block for each.

Step 4 — Additional Information (optional)

Offer deeper detail for any plan: all task files and status, git diff for
uncommitted changes, full last-task completion log, the gate records of one
task, any blockers.

Step 5 — Quick Actions

Suggest: resume (/dwp-resume <plan>), execute (/dwp-execute <plan>),
refine (/dwp-refine plan <plan>), or open a specific task file.

Status Classifications

Not started (all [ ], no commits) · In progress (mixed, recent activity) ·
Complete (all [x]) · Blocked (state.json.blocked set or the current task's
log has a blocker note) · Stale (no activity for a long time — optional) ·
Inconsistent (any Step 2.3 finding — reported alongside the classification).

Important Notes

• Read-only: never executes or modifies plans; git status is reported, not
  committed. Cross-reference the README task list with state.json and git
  commits for accuracy; the markdown is authoritative when they disagree.
• Cheap by design: the compact projection plus the README index answer the
  question; task files and logs are read only for the targeted detail above.

Error Handling

• Plan folder doesn't exist → report; list available plans; ask to select.
• README missing, or README says Plan Status: materializing → report a partial
  materialization; read manifest.json (intended title and task_count) and
  the README task list when present and list which intended files exist and
  which are missing; suggest /dwp-refine (complete or discard) or
  /dwp-create. Never report it as executable.
• state.json unreadable or invalid → report it as a finding; fall back to the
  README; suggest /dwp-resume (which regenerates it).
• No plans exist → report "No plans found in .dwp/plans/"; suggest
  /dwp-create.