Skip to content

v0.2.1: visual paths in Markdown progress (experimental)

Pre-release
Pre-release

Choose a tag to compare

@jaredchu jaredchu released this 16 Oct 13:54

v0.2.1: a visible path through the work

Experimental prerelease, October 16, 2026.
Bundle: context-docs 0.2.1, unchanged adopt-context-docs 0.1.10 and
standard 0.1.1. GitHub prerelease.
Previous bundle: v0.2.0.

What changes

A progress visualization now asks for a compact text tree, arrow path or nested
Markdown checklist that shows how the work contributes to the documented goal.
A flat status table alone is insufficient.

  • Branch parallel completion conditions; show ordering only when supported.
  • Put each blocker beside the work it stops, with its prerequisite and next action.
  • Keep unapproved proposals outside the required completion path and mark unknowns.
  • Link each item and relationship to its source. Keys inside a fenced diagram
    need real clickable Markdown links outside it.

The synthetic example shows one passed check and
one blocked check, with the missing input and next step nested beneath it.
Markdown remains authoritative; no viewer, tracker or runtime is added to the
skills. The website preparation displays that same canonical example on both
public pages and retains SEO titles without em dashes.

Existing projects and upgrades

Ordinary maintenance preserves an existing view's format. An explicit
visualization request can reshape that view within its existing section or file,
preserving owner edits and record locations. Once a visual path exists, authorized
maintenance refreshes it from relevant new facts; an identical repeat makes no edits.

No re-adoption or document migration is required. Existing maintenance rules,
adoption dates, context paths, local-only boundaries, ignore rules, logging
settings and saved history stay in place. Audits remain read-only.

Installed v0.2.0 skills retain their earlier guidance until separately upgraded.
Follow the upgrade guide, preserving local
customizations and complete packages. Adoption 0.1.10 already routes to its sibling
core; its package and the standard are unchanged. Release preparation does not
upgrade installations or alter project setups.

Evidence and limits

  • The artifact review
    records Opus 5.5's initial review, one focused follow-up and Sol's dispositions.
    Its dated pre-smoke scope and original file identities are retained.
  • A focused candidate smoke
    ran one guided create case per native client using copied core 0.2.1. Both
    outputs show parallel completion branches, a blocked prerequisite and next
    action, with clickable source maps. All 18 Codex and 14 Claude view/context
    link occurrences resolve; only the two permitted fixture Markdown files change.
    Each case finished within its 180-second cap, with no retry.
  • Codex requested gpt-6.1-sol; its responding identity was not exposed. Claude
    reported claude-opus-5-5. Sol scored both outputs against frozen criteria;
    these are author-scored synthetic cases, not independent usability evidence.
  • The full manual suite is unrun. These cases do not test refresh, identical
    repeat, adoption, audit, local-only storage, Git/journal history or implicit
    loading. They establish no general reliability, privacy, stall-detection
    accuracy or target-user benefit. Earlier studies and their gaps are unchanged.

The preparation record records local mechanical checks,
package identities, website previews and preservation separately from the earlier
native outcomes. No new model trial is part of release preparation.

Publication

Published from 0c897c007b0b2cdb66b23107875820b84e73b42b after its Actions passed. The website is deployed from the same commit; all eight checked live HTTPS resources return HTTP 200 and match the build. See the publication and verification receipt. Installed skills, existing setups and saved studies are preserved.