kc-journey-progress

Refresh local task progress once, then optionally draw that observation. Resolve this plugin root from this skill location. Use its existing canvas setup from ../kc-journey-map/references/canvas.md; Node >=22.13 and the plugin dependencies are required. The optional reader also requires spacedock on PATH.

node <plugin-root>/lib/journey-progress.mjs <journey.yaml> --workflow-dir <workflow-dir>
node <plugin-root>/lib/journey-progress.mjs <journey.yaml> --workflow-dir <workflow-dir> --draw <room> --pages story-map,journey-board

Omitting --pages draws the story map. Refresh-only prints JSON. JOURNEY_API selects the existing canvas endpoint. Exit 1 accompanies unverified observations, an orphan (a task that names this journey but a release and story the map does not hold, listed under orphans with its slug, short id, release and story; a closed task naming a story since removed from the map stays listed until its fields are cleared), or a failed draw; exit 2 reports invalid arguments/input. A failed draw retains the computed observation in the error output, without claiming that it was drawn.

Declare the required work in its existing tasks

Each opted-in task has scalar journey, journey-release, and journey-story matching explicit journey/release/story IDs in the journey file. Positional IDs and duplicate story IDs cannot establish completion. Legacy sprint is ignored. One existing member task carries the complete declaration:

journey: example-journey
journey-release: first-release
journey-story: inspect-result
journey-required-tasks: '["task-identity", "another-task-identity"]'
journey-mapping-complete: true

The task scope owner confirms that nonempty list is exhaustive and includes the declaring task, updating that same declaration when required scope changes. Other members carry the tuple, without duplicating the declaration. Full stored IDs come from spacedock status --workflow-dir <dir> --resolve <slug> --archived --json (stored_id), not display prefixes. In a workflow whose README declares id-style: slug, a task without a stored id is identified by its slug: list slugs, which the same command returns as id with an empty stored_id. A task that does carry a stored id is listed by that id in either workflow. The reader does not write this metadata.

lib/progress.mjs requires one confirmed declaration, unique full IDs, exact matching membership, and readable required records. Missing/extra tasks, partial or conflicting declarations, unavailable reads and detected drift are unverified. Archived tasks participate; literal done completes a task, and reopening it reduces the next explicit refresh. Work omitted from both the declaration and metadata cannot be discovered; this is a scope assertion, not authenticated approval.