v0.2.6: filter metadata and keep references portable

v0.2.6: filter metadata and keep references portable

Experimental prerelease, October 19, 2026.
Bundle: context-docs 0.2.6, adopt-context-docs 0.1.15 and unchanged
standard 0.1.1. Previous bundle: v0.2.5.

What changes

Both skills strengthen information selection before saving context or an enabled
journal event:

• Omit incidental usernames, account identifiers, private evidence locations and
  personal installation state from shared additions. Summarize useful findings
  instead of copying raw tool output.
• Prefer repository-relative project references. For private evidence, use a
  suitable public summary, stable ID or hash with access limits; an identifier
  does not make the underlying evidence inspectable by other readers.
• Keep meaningful outcomes and their qualifications in a canonical location,
  linking from summaries instead of repeating routine bookkeeping.
• Preserve decisions, rationale, conditions, uncertainty, blockers and supporting
  evidence. Useful local paths and necessary diagnostic relationships still
  belong in appropriate destinations; filtering does not mean removing all
  environment detail.

The core guidance
owns the rule; adoption applies it through the sibling skill. The
guide explains the sharing
boundary. No automatic redaction, secret scanner or historical cleanup is added.
An enabled journal can be tracked/shared; enabling logging does not make it private.

Evidence and qualifications

The candidate smoke
runs one fresh Codex and one Claude Code session, each with copied skills and two
fictional cases: public re-adoption and personal offline maintenance. Both pass
the visible saved-Markdown filtering, relative-link, content-quality and edit-scope
checks. Useful personal paths, decisions, evidence limits and owner text survive.

Claude could not locate an unlinked private operator note with its restricted
discovery tools. Filtering incoming metadata from that note remains untested in
Claude. Its output removes metadata already present in context and accurately
reports the missing source. This fixture coverage gap remains attached to the
original outputs, without a session rerun or output repair.

These are guided, Sol-authored and Sol-scored cases with explicit candidate paths.
They do not establish installed behavior, implicit loading, automatic everyday
application or general privacy guarantees. Native journal capture was not tested;
logging is off in the fixtures. The separate
offline controls cover six authored
examples, including journal schema/helper use, and retain the qualified Opus
artifact review and final schema correction checked locally. They are not a
general semantic grader or evidence of automatic filtering.

Existing projects and upgrades

Publication and installation are separate actions. Preserve local customizations
and install both complete sibling packages using the upgrade guide.
Installed v0.2.5 keeps its existing guidance until separately upgraded.

Keep existing context paths, layouts, setup/collaboration rules, owner decisions,
adoption dates, local-only boundaries, logging settings and saved studies.
No storage migration, background process or runtime change is required. This
release does not authorize moving records, rewriting frozen evidence or sanitizing
older Git history. Audits remain read-only.

Preparation status

The preparation record retains its original unpublished
scope, local checks, package/build identities and preservation separately from
the unchanged native smoke. Publication changes release labels; the skill
packages and original evidence remain unchanged. No new model trial or counterpart
review is part of publication. Installed upgrades remain a separate action.

v0.2.5: coordinate shared context edits (experimental)

v0.2.5: coordinate shared context edits

Experimental prerelease, October 18, 2026.
Bundle: context-docs 0.2.5, adopt-context-docs 0.1.14 and unchanged
standard 0.1.1. Previous bundle: v0.2.4.

What changes

Both skills add a conditional rule for agents or sessions working concurrently
on the same context file:

• Agree on one writer per shared file before concurrent edits begin. Other
  participants return findings to that writer.
• Change writers through an explicit handoff, including when Codex and Claude
  share a checkout.
• Prefer narrow edits. After an edit conflict or stale-text failure, reread the
  current file and reconcile contributors' changes before retrying. Preserve
  newer work instead of replacing it from an old snapshot.

The core skill
owns the rule; adoption follows it.
The user guide
explains the shared-checkout workflow. Installing the skill in both clients does
not coordinate their sessions. This is guidance without file locking, automatic
merging or a guarantee against lost updates.

Evidence and qualifications

The candidate smoke
runs one native Codex session requesting Sol 6.1 and one Claude Code session
reporting Opus 5.5. Each uses copied candidate skills and two tiny fictional cases:
a peer-owned context and a context explicitly handed over to the acting session.
The prompt deliberately requires one stale queued replacement to exercise recovery.

Both leave the peer-owned context unchanged and return findings for its writer.
Both recognize the handoff, reread after the forced stale edit fails, and preserve
the newer schema result, decisions, owner text, blockers and evidence. Only the
permitted Progress and Next action sections change; all seven final context links
resolve per client.

Claude retries its own second text mismatch without another reread. This is
a procedural failure despite preserved final Markdown. The original tool ordering,
errors and outputs remain intact; the result is not an unqualified pass.

Codex's first read-only self-check rejects a valid anchor because it compares
heading capitalization incorrectly. A corrected check succeeds in the same
session; the assessor separately verifies links and section preservation.
Codex's responding model identity remains unconfirmed. The requested model is
recorded, and the original checking error is retained.

These are guided, Sol-authored and Sol-scored cases with explicit copied-skill
paths. The peer and handoff are simulated, not live simultaneous writers. They
do not establish installed behavior, implicit loading, automatic everyday
compliance, cross-session continuity, conflict frequency or general conflict
prevention. No output repair or model rerun occurred. The earlier offline
mechanism diagnostic and all earlier studies remain unchanged.

Existing projects and upgrades

Publication and installation are separate actions. Follow the
upgrade guide, preserving local customizations
and keeping both complete sibling packages. Installed v0.2.4 retains its earlier
guidance until separately upgraded; publication alone changes no installation
or project setup.

Preserve existing context paths, equivalent maintenance and collaboration rules,
adoption dates, owner decisions, layouts, local-only boundaries, logging settings
and saved studies. The change adds no runtime, background writer, lock service
or storage format. Audits remain read-only.

Preparation and publication status

The preparation record retains its original October 17
draft scope, local checks, package identities, website previews and preservation
separately from the earlier native smoke and artifact review. No new native model
trial or counterpart review is part of publication. Release labels change for
publication; the skill packages, original evidence and qualifications stay intact.
Installed upgrades remain a separately authorized action.

v0.2.4: clarity without losing meaning

v0.2.4: clarity without losing meaning

Experimental prerelease, October 17, 2026.
Bundle: context-docs 0.2.4, adopt-context-docs 0.1.13 and unchanged
standard 0.1.1. Previous bundle: v0.2.3.

What changes

Both skills prefer clear, direct sentences and consistent project terminology
within authorized context edits. Split crowded sentences while preserving
conditions, uncertainty, rationale and evidence.

• Keep conditions attached to their actions: a passing check can permit asking
  for approval without granting that approval.
• Keep unknowns accurate: missing evidence is not a failed result, and an
  unrecorded actor remains unknown.
• Preserve decisions, their reasons and source links. Clearer wording must not
  strengthen the evidence or turn a proposal into an approved decision.
• Preserve existing layouts and unrelated owner text. The preference does not
  authorize broad copyediting or require ASD-STE100 compliance, a controlled
  dictionary, sentence limits or a new template.

The core skill
owns the preference; adoption follows it
within its existing scope. Concise Markdown progress and everyday maintenance
continue as before; no new invocation is required for the writing preference.

Existing projects and upgrades

Installing or upgrading remains a separate action. Follow the
upgrade guide, keeping both complete sibling
packages and preserving local customizations. Publication does not upgrade
installed skills or rewrite project setups.

Existing context paths, equivalent rules, adoption dates, owner decisions, layouts,
local-only boundaries, logging settings and saved studies stay in place.
Audits remain read-only. The preference adds no runtime, background tracking or
new storage format.

Evidence and qualification

The copied-candidate smoke
runs one fresh native Codex session requesting Sol 6.1 and one Claude Code session
reporting Opus 5.5. Each performs two tiny synthetic tasks: re-adoption and
maintenance of crowded prose. Both preserve the conditions, unknowns, rationale
and evidence, with all eight local context links resolving per client. Only the
permitted sections of two context files change in each fixture.

Claude's final chat report adds an unsupported gendered pronoun for Noor.
The saved Markdown uses Noor's name and retains the correct approval condition.
The original report and qualification are retained without correction or retry.
Codex's responding model identity remains unconfirmed; the requested model is recorded.

These are guided, Sol-authored and Sol-scored writing cases with explicit candidate
paths. They do not establish implicit loading, automatic everyday application,
fresh setup, cross-session continuity, general reliability or user benefit.
An earlier tiny text comparison scored 12/12 for both original and rewritten
notes; no comprehension gain was demonstrated. Human reading effort and
ASD-STE100 compliance were not measured. Earlier smoke and review evidence,
including the v0.2.3 scope failure, stays unchanged.

Preparation and publication status

The preparation record records current local checks,
package identities, website previews and preservation separately from the earlier
native smoke and artifact review. This preparation performs no new model trial
or counterpart review. The preparation record retains its original draft/unreleased scope and earlier
package, preview and preservation checks. Publication uses released labels while
keeping the same skill packages and smoke qualification.

Published as an experimental prerelease
on October 17, 2026, from 73b15acbe570bacba9bcb43d24ccbba141d3bb4b, after
static checks
and the website build passed.
Deployment passed
from the same revision. All eight checked live public resources return HTTP 200
and match that build, including released labels, clarity guidance, the smoke
qualification and SEO titles without em dashes.

The publication record owns release/deployment identities,
artifact and response hashes, and verification limits separately from the unchanged
preparation record. Installed skills, setup rules, saved
studies and original smoke/review evidence are preserved. No new native trial,
counterpart review or installed upgrade is part of publication. Live checks verify
response bytes and HTML metadata, not browser rendering, indexing or user benefit.

v0.2.3: concise progress views

v0.2.3: concise progress views

Experimental prerelease, October 17, 2026.
Bundle: context-docs 0.2.3, adopt-context-docs 0.1.12 and unchanged
standard 0.1.1. Previous bundle: v0.2.2.

What changes

Both skills favor a concise progress overview: the documented goal, meaningful
outcomes, dependencies and blockers, and the next action. Link to canonical
evidence instead of repeating test counts, review rounds or release receipts.

• Keep decisions and rationale, approval boundaries, unresolved work and relevant
  qualifications visible where they affect a status or next action.
• Preserve existing views, formats, owner edits and record locations. The preference
  for concision does not authorize reshaping an established layout or deleting
  unique information. Adapt detail to the project and explicit requests.
• Use no fixed line limit or required template. Add no tracker, evidence store,
  web viewer or runtime dependency merely to shorten a view.

The packaged progress guide
owns this guidance. Adoption follows it when creating a supported view; core
maintains the same view during authorized everyday work. Default inline creation
already ships in v0.2.2; this release refines how much detail the overview carries.

Existing projects and upgrades

Installation and upgrades remain separate actions. Follow the
upgrade guide for both complete sibling packages,
preserving local customizations. Publication does not update installed skills.

Existing context paths, equivalent setup rules, adoption dates, owner decisions,
local-only storage boundaries, logging settings and saved studies stay in place.
An upgrade alone does not create or rewrite project views. Explicit visualization
requests can reshape an agreed view; ordinary maintenance preserves its format.
Audits remain read-only, and progress does not enable logging or background tracking.

Evidence and qualification

The focused copied-candidate smoke
runs one session per client, each with synthetic re-adoption and a separate
existing linked-table update. Both produce concise, source-linked progress and
preserve decisions, blockers and existing layouts. Codex resolves 10 relative
links; Claude resolves 12 plus one local anchor. The cases are guided and scored
by Sol, the change author; the two tasks share a session in each client.

Codex fails the strict write boundary. It creates and removes a fixed
/tmp/cedar-context-before.json hash snapshot outside the four permitted Markdown
files. Both operations succeed; the path is absent afterward. Its prior absence
or contents were not inventoried and remain unknown. The qualification and exact
outputs are retained without correction or retry. The protected repository,
installed packages and earlier study/evidence inventory passes separately;
that comparison does not establish preservation of the temporary path or global state.

The earlier artifact review
records Opus 5.5 review and one focused follow-up resolving a context-summary
authorization condition. It is separate from native behavior and retains its
original scope and final-wording qualifications.

These narrow cases do not establish general reliability, implicit discovery,
fresh setup, cross-session continuity, usability or user benefit. The full suite,
sparse/local-only, audit/repeat and explicit-extra-detail branches remain unrun.
All earlier studies and review records remain unchanged.

Preparation and publication status

The preparation record owns current local checks,
package identities, desktop/mobile previews and preservation. No new native
model trial or counterpart review is part of this release preparation.

Published as an experimental prerelease
on October 17, 2026, from 0c053d6ec37eaa57640d4330e11ae257c86a61a1, after
static checks
and the website build passed.
Deployment passed
from the same revision. All eight checked live public resources return HTTP 200
and match that build, including released labels, concise-view guidance, the smoke
scope qualification, canonical visual/source maps and SEO titles without em dashes.

The publication record owns identities, hashes and
verification limits separately from the unchanged preparation record.
Installed skills, setup rules, saved studies and original smoke/review evidence
are preserved. No new native trial, counterpart review or installed upgrade is
part of publication. Live checks verify response bytes and HTML metadata, not
new browser rendering or user benefit.

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.

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

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.

v0.2.0: Markdown progress views (experimental)

v0.2.0: Markdown progress views

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

What changes

Ask Context Docs to visualize progress in Markdown. It guides the agent to show
the documented goal and completion conditions, completed/active/blocked/proposed
work, meaningful advances, dependencies and the next action, with source links.
Use an existing context section or a linked Markdown file that fits the project.
An existing view is refreshed during authorized context maintenance.

The guidance distinguishes activity, useful learning and completed outcomes.
Relevant Git history, retained dated notes or an existing optional journal can
support a possible stall, not definitive loop detection. Missing history
leaves repetition unknown. No completion percentage or live agent activity is
invented. Markdown stays authoritative; no web viewer, service or extra runtime
dependency is added. See the guide
and synthetic example.

Adoption routes to the core progress guide while preserving existing layouts and
equivalent setup rules. The website update adds a progress section and the same
canonical prompt to the landing page and beginner guide. It retains explicit
experimental/released labels, SEO titles without em dashes and the nine-file
public build boundary.

Upgrade and preservation

Follow the upgrade guide, reviewing complete
sibling packages and preserving local customizations. No project re-adoption,
new tracker or document migration is required. Existing maintenance rules,
adoption dates, context paths, ignore rules, logging settings and saved history
remain in place. Audits stay read-only; reading relevant retained history does
not enable logging or change an explicit off setting.

Publishing this release does not update installed skills or existing project
setups. A new view is written on request; existing views can be maintained through
the loaded project rule. Installing the packages alone does not prove that a client
loads the rule or automatically selects the skill.

Evidence and known limits

• The artifact review retains one initial
  Opus 5.5 review and Sol's verified dispositions. The revised instructions did
  not receive a second model review.
• The focused smoke check ran
  two fresh, guided Claude Code sessions on one synthetic fixture: create a linked
  view, then refresh it from a newer retained result. The copied development skill
  was read explicitly. Goal/status, proposal/history distinctions and write
  boundaries passed; all 37 checked link occurrences resolved.
• Known presentation gap: two advances bullets in the smoke outputs lack
  their own inline source links, although their facts are linked elsewhere in the
  view. The exact outputs and this partial result remain unchanged.
• The full seven-scenario suite has not run. The smoke did not test native Codex,
  adoption, local-only progress, read-only audit, no-change repeat, Git/journal
  history or default automatic loading. It establishes no general reliability,
  privacy, stall-detection accuracy or target-user usability benefit.

Earlier feature checks passed 18 packaging/static regression tests, 12 site tests
and both skill validators. These are separate from the two native smoke sessions.
The release-preparation record records current website
tests/build, package identities and preservation checks. Historical studies,
reviews, failed observations and previous release records are preserved.

Publication status

Published as an experimental prerelease
on October 16, 2026, at d341695fd278cc31b17bae0154b459574ebf4444, after its
static checks
and website checks
passed. Deployment
passed from the same commit. All eight checked public responses match the build;
both pages show the progress section, experimental/released status and SEO titles
without em dashes. The publication record retains
response hashes, the initial urllib HTTP 403 observation and successful ordinary
curl checks. These checks do not establish crawler access or indexing.

Packages match the preparation identities. Existing setups, installed skills,
saved studies and prior evidence are preserved. No installed upgrade or new native
model trial is part of publication.

v0.1.9: source-checked context initialization (experimental)

Context Docs remains experimental. This bundle contains context-docs 0.1.9, adopt-context-docs 0.1.9 and standard 0.1.1.

Initialization from earlier notes now explicitly checks relevant project sources before importing claims about current implementation or configuration, while retaining decisions and unfinished work. The adoption package and standard are unchanged.

One of two baseline trials retained a stale timeout; both candidate trials used the configuration value. These small synthetic trials establish no general reliability or causal accuracy advantage. Static checks are separate from native outcomes; no new subject sessions were run for release preparation.

Review complete sibling packages before upgrading and preserve local customizations. No project re-adoption or document migration is required. This publication does not update installed skills, project setups, logging settings or saved study artifacts.

Release notes and upgrade guidance · Validation and review records · Website

Codex integrated and validated the changes; Claude Opus 5.5 reviewed the fix, evidence and release preparation. The release-status commit preserves both attribution trailers.

v0.1.8: local-only context and opt-in auto logging (experimental)

v0.1.8: experimental prerelease

Bundles context-docs 0.1.8, adopt-context-docs 0.1.9 and standard 0.1.1.
Experimental prerelease, published October 10, 2026 from 8bda86ce8e23d14874dcb22e0af7b2e581717ee7.
Release-commit static checks
and landing-page checks passed.

Changes since v0.1.6

Both skills now support explicitly requested local-only context, excluded from Git.
They check Git tracking separately from effective ignore rules, read named ignored
entry points directly, and keep local content out of shared documents. Existing
tracked context is preserved until migration scope is agreed. The directory and
instruction locations follow the project's existing setup.

The opted-in auto logging preference now also covers explicitly selected
local-only context inside Git. With no project logging setting, the read-only
policy helper requires all chosen context paths and the journal directory to be
untracked and effectively ignored. It checks exposed descendants and prospective
journal files; missing scope, negated exclusions, tracked targets, aliases,
symlinks, nested repositories or detection errors leave logging unchanged.
Every explicit logging setting, including off, takes precedence. Shared Git
context and confirmed no-Git behavior retain their existing defaults.

An enabled local journal can retain significant events when current context has
no Git history. It does not save complete document versions; snapshots or backups
serve that separate need. The writer, schema and standard are unchanged.

The website guide adds the canonical local-only setup and auto-logging prompts.
Page and Open Graph SEO titles use no em dashes. The build still publishes only
its explicit public file allowlist.

Installation and upgrade

Follow the user guide. Update complete sibling
skill folders together, preserving local customizations. Adoption requires the
sibling core package. Existing projects keep their maintenance rules, original
adoption dates, context paths, ignore rules, logging settings and event history.
Installation and upgrades do not select local-only storage or enable logging.
A previously selected auto preference can add a logging setting during later
authorized setup or maintenance when an unset local-only project newly qualifies.
Audits remain read-only. Ordinary Markdown maintenance needs no runtime;
optional journal and policy helpers require Python 3.9+, and policy detection
requires Git.

Validation and limits

The auto-policy validation record
records 156 passing mechanical tests, static and package checks, the website
build, and six bounded native Claude Code/Codex sessions. Four native sessions
preceded review fixes; the two final-package sessions checked fresh setup in nine
projects per client, including a tracked case alias and a prospective journal suffix exception.
Repeat/no-change maintenance and audit evidence belongs to the earlier candidate.
All seven published final-native file identities match this release candidate;
the release validation record records all 15 packaged
file hashes and the successful candidate GitHub Actions runs.

Claude Opus 5.5 drafted the helper/tests; Codex integrated review fixes and ran
checks. Initial failures and review qualifications
are retained in the auto-policy validation record. The release-note review is
recorded separately. The seven broader
local-only agent scenarios
remain unexecuted. Historical studies and existing setups are preserved.

These constrained, authored checks do not establish privacy guarantees, implicit
skill selection, automatic instruction loading, general reliability, JSONL
necessity or user-effort savings. Known new paths still need explicit checks:
prospective probes cannot predict every future negated target. Absent Unicode
normalization aliases are not exhaustively tested, and large directory walks
remain unbounded. See the changelog and
earlier evidence for retained failures and limitations.

v0.1.6 — context selection by audience and destination (experimental)

v0.1.6 — experimental prerelease

Bundles context-docs 0.1.6, adopt-context-docs 0.1.7 and standard 0.1.1.
Release preparation and validation completed October 10, 2026.

Release commit: b10a3058e43f9af278cbb7a6b2b70d41df16ea7d. Remote CI passed.

Changes since v0.1.5

Core guidance now selects retained information by its intended readers, sharing
destination and lasting usefulness. The
standard
covers public contributor docs, restricted team procedures, personal workspace
notes and mixed audiences. It preserves relevant operational constraints and
failed evidence while separating current context from detailed history and
incidental local state. Public derivatives must retain provenance and meaningful
diagnostic relationships; cleanup does not authorize discarding source evidence.
The standard adds a local working state role and applies audience selection to
optional journal payloads without enabling logging. The core guidance excludes
secrets and unnecessary personal or customer data from context. The starter
context template follows the same guidance.

Adoption now explicitly preserves existing equivalent maintenance rules as
written. Newly added wording adapts to local terminology without client-specific
invocation syntax.

Repository updates add bounded adoption and audience evaluations and clarify
future marker-format grading. The revised evaluator accepts supported fenced
markers only in future freezes; the completed adoption study keeps its original
failure and scores. The
evidence cleanup record documents normalized
public copies and unchanged historical scores; it does not sanitize older Git
history. See the changelog for per-change validation.

Installation and upgrade

Follow the installation instructions for the
chosen client and scope. Install or update both complete skill folders together;
adoption requires the sibling core package. Review existing files, back up local
customizations and preserve them when applying the package changes.

Existing projects need no directory or document migration. Preserve their loaded
maintenance rules, adoption dates, entry paths and logging settings. Installing
or updating the skills does not enable logging. The existing opt-in auto preference
and explicit-setting precedence remain unchanged, as do the journal helper and
schema. Ordinary Markdown maintenance has no runtime dependency; the optional
helper requires Python 3.9+, and auto detection also requires Git.

Validation and limits

The local release validation passed all 21 CI command
groups using Python 3.12.14 on macOS: 146 unit tests,
study and adoption grader controls, static checks, and four unchanged regenerated
reports. Both packages were copied outside the repository; their metadata and
packaged links passed, and all 14 packaged files matched the candidate source.
Commands used repository-root paths rather than CI subdirectory working
directories. These are local CI-equivalent checks, not a remote Linux CI result.
The candidate skills match commit 3de7d304d4c4a4cd46dffc8ab39c86d21d4869b3.

GPT 6 Astra High drafted these notes. The Claude Opus 5.5 review
found no blocking issue; its package-identity evidence gap was resolved by hash
comparison. All 14 candidate files match every frozen audience-pilot package copy;
all four adoption files also match the earlier adoption-study source. The
validation record retains those comparisons.

The October 9 public-source adoption regression
ran four native Claude Opus 5.5 sessions with core 0.1.5 and adoption 0.1.7.
Execution passed 4/4; frozen mechanical checks passed 3/4, retaining the
fenced-marker failure. Both reviewers accepted the target preservation behavior
in all four sessions. Full-claim semantic acceptance remained Astra 1/4 versus
Claude 3/4; both found the repeat's unsupported verification claim. These
assessments remain separate.

The October 10 audience/destination pilot
used this package bundle in five native Claude Opus 5.5 sessions.
Execution passed 5/5. GPT 6 Astra High and Claude Opus 5.5 each accepted
19/19 target criteria and 15/15 general criteria. The mixed case completed
its API documentation edit and asked the permitted audience/destination question;
it did not produce a handoff artifact. The audit attempted no writes or
history access. Neither study retried subjects or repaired their outputs.

Mechanical checks are separate from actual agent evaluations. These small,
authored studies used explicit invocation and restricted tools on one client and
responding model, with unblinded counterpart review. They establish neither
general reliability nor comparative benefit, automatic skill selection or
unrestricted-client behavior. Earlier factual, invocation and journal-access
limitations remain recorded in the linked reports and
project context.