v0.2.2: default inline progress adoption

v0.2.2: inline progress starts with adoption

Experimental prerelease, October 17, 2026.
Bundle: context-docs 0.2.2, adopt-context-docs 0.1.11 and unchanged
standard 0.1.1. Previous bundle: v0.2.1.

What changes

Adoption now directs the agent to create a simple inline progress path by default
when the context documents a goal and enough supported work, status or next-step
facts to make one useful. You do not need a separate visualization request first.

• Group ordinary status sentences into a small tree, arrow path or nested
  checklist within a suitable existing section, preserving headings and owner edits.
• Keep an existing task list, status table, diagram or designated progress section
  or linked file in its current location and format. When uncertain, retain the format.
• Keep facts authoritative in one place and link summaries to their evidence;
  do not create another independent tracker or duplicate task list.
• Skip a new view when the goal or supporting work is too sparse. Honor requests
  to omit a view or use a separate file; do not invent completion conditions.
• Maintain the view during authorized everyday context updates under the loaded
  maintenance rule. An unchanged repeat should make no edits.

The packaged progress guide
owns these rules. The website preparation explains default creation and everyday
maintenance on both pages, keeps the explicit prompt available as an optional
request and retains the canonical synthetic visual example.
Markdown remains authoritative; no viewer, service or extra runtime is added.

Existing projects and upgrades

An explicit adoption run may add a missing supported inline view to an
already-adopted project while preserving equivalent setup rules and its original
marker/date. Re-adoption is not required to continue maintaining an existing view.
An explicit visualization request can still reshape that view in place.

Installation or upgrade alone does not add a view to projects. Existing context
paths, owner edits, decisions, local-only storage/ignore boundaries, logging
settings and saved history stay in place. Audits remain read-only. No logging
or history scanning is enabled merely to display progress.

Installed v0.2.1 retains request-based initial creation until separately upgraded.
Follow the upgrade guide for both complete
packages, preserving local customizations. This preparation updates neither
installed skills nor existing project setups.

Evidence and limits

The default-adoption check record
retains three guided native Codex sessions on one already-adopted synthetic fixture:

1. Explicit re-adoption creates the missing inline checklist without a progress
   request, preserving the headings, source documents, owner notes and setup.
2. An ordinary result-recording task refreshes the same view without asking for
   progress, removes the obsolete blocker and retains the approval boundary.
3. Unchanged re-adoption with the clarified candidate makes zero edits.

Each completes once within its 180-second cap, without retry: 33.99, 20.22 and
18.79 seconds. Three relative file/anchor links plus the local next-action anchor
resolve in each of the first two context outputs. Codex requested gpt-6.1-sol,
medium; responding identity was unconfirmed. Sol, the change author, scored them.

The first two sessions use the initial candidate; the repeat uses the clarified
candidate. Opus 5.5's bounded artifact review and one focused follow-up resolve
material findings. A minor marker-scope clarification follows without another
review or native run. Exact candidate identities, unchanged outputs and reviewer
qualifications remain in the original record; this is not a full final-package
native evaluation or independent validation.

Fresh adoption that writes a new rule/marker, linked/nonvisual views, sparse
context, local-only storage, explicit no-view and audit cases remain unexecuted
natively for this change. No Claude native adoption trial tests the new default.
These guided cases establish no general reliability, implicit-loading guarantee,
privacy, stall-detection accuracy or target-user benefit. Earlier installed
v0.2.1 smoke results and all original studies retain their original scope.

The preparation record separates current local checks,
package identities, previews and preservation from those earlier native results.
No new model trial or counterpart review is part of release preparation.

Publication status

Published as an experimental prerelease
on October 17, 2026, at 7aa2d5d1b925a02ca5efd29bcee6eb76aee6e466, after the
release-commit static checks
and website build passed.
Deployment passed
from the same revision. All eight checked public resources return HTTP 200 and
match its build, including default-adoption and everyday-maintenance copy, the
canonical visual/source maps, released labels and SEO titles without em dashes.

The publication record retains hashes and verification
limits separately from the unchanged preparation record.
Installed skills, existing setups, saved studies and earlier evidence are
preserved. No installed upgrade, new model trial or counterpart review is part
of publication. Live GETs check bytes and HTML metadata, not fresh browser
rendering, crawler access/indexing or user benefit.