v1.9.1 to v2.0.0

- description: "Refresh project context and verify recovery, current skills and session ownership. Use for checkpoints, drift or compaction recovery, and refresh-and-report after ecosystem upgrades. Supports existing and fresh sessions without repeating completed project work."

- version: "1.9.1"

- # Synthesis Checkpoint — Mid-Session Refresh & Drift Recovery

-

- ## Refresh-and-report mode

-

- When asked to refresh after an ecosystem upgrade or report session readiness,

- load this skill from the current verified installed root, then follow

- [references/refresh-and-report.md](references/refresh-and-report.md). This mode

- uses a deterministic local inspector and optional campaign feedback. Project

- feedback destinations follow explicit registry successor links; the reporting

- session keeps its project identity and execution restrictions. It ends

- after reporting and grants no project implementation or repair authority.

- Ordinary checkpoints use the protocol below and do not send campaign feedback.

-

- Current skill text and a native runtime reload are distinct evidence. Never

- equate an old in-context skill body with a failed current startup, or copying

- new files with proof a running harness reloaded them.

-

- ## The Problem

-

- LLMs are stateless at the model level. Across a long conversation, an LLM's sense of "what's true now" can drift from what's actually on disk and in git. Drift sources:

-

- - **Time drift.** The model has no clock. If the conversation started Tuesday and continues Wednesday, the model often still thinks it's Tuesday.

- - **State drift.** Project CONTEXT.md may have been edited (by user, by sub-agent, by another session) since the model last read it.

- - **Compaction drift.** When the context window approaches its limit, the harness may summarize older turns. Details disappear. The model often cannot detect that this happened.

- - **Cached-fact drift.** Facts the model read earlier in the conversation (last commit, last session date, last decision) may no longer be true.

- - **Coordination drift.** Another live root session may have claimed or changed

- the same source area since the last tool call.

-

- Self-discipline degrades with conversation length. Rules read at session start lose salience as turns accumulate. Even a model that "knows" to verify often skips verification under the weight of accumulated context.

-

- This skill is the recovery primitive. It is a tight, low-friction protocol the agent runs on demand or on a detected drift signal — and the act of running it restores ground truth.

-

- ## When To Invoke

-

- Invoke synthesis-checkpoint when any of these conditions fire:

-

- **Triggered by the user:**

- - User asks "where are we?" / "what's the status?" / "what's been done?"

- - User asks the agent to continue work after a pause

- - User says "remember to..." or "you forgot..."

- - User indicates the agent has drifted ("that's not right", "you said earlier...", "actually...")

- - User invokes this skill by name or by keyword (checkpoint, re-sync, refresh)

-

- **Triggered by the agent's own self-monitoring:**

- - Before generating any time-interval claim ("N days ago", "yesterday", "last session", "this week")

- - Before quoting any project status from cached memory

- - After at least 10 minutes between user turns when the client exposes message

- timestamps. Ten minutes is the default freshness boundary: long enough to

- avoid checkpointing ordinary back-and-forth, short enough to catch another

- client session changing shared state. If timestamps are unavailable, any

- resume/continue phrasing after an apparent pause triggers the checkpoint.

- - After ~25 substantive tool calls, regardless of perceived need

- - When the model says or thinks "I don't recall" about a recent decision

- - When a file read reveals content the model didn't expect (state drift signal)

- - When the user references a decision the model has no record of (compaction signal)

- - When resuming work on a project after working on something else in the same session

- - When the shared coordination board changes or another root session becomes active

-

- **Triggered automatically by lifecycle hooks:**

-

- - SessionStart runs an equivalent of this skill's initial steps.

- - Codex `PostCompact` reloads the active project and controlling plan.

- - Stop can detect long sessions and emit a re-sync reminder.

- - PreToolUse can inject verified time before time-sensitive operations.

-

- ## The Protocol

-

- Use the full protocol for session recovery, material drift and explicit refresh.

- During continuous work with a verified project identity, check the live facts

- needed for the next claim or mutation and update only changed recovery state.

- A timestamp question requires a current clock; it does not by itself require

- another project audit. A status claim still requires its actual current source.

- Read current ownership before writes. New contradictions trigger full recovery.

-

- Checkpoint work does not recursively trigger another checkpoint. Logging this

- checkpoint, answering its status question or publishing its record belongs to

- the same invocation. Reuse immutable source and retained evidence by reference;

- do not copy or re-review unchanged artifacts merely to make a new checkpoint.

- Then return to the next deliverable or the user's requested safe stop.

-

- ### Step 0 — Read cross-agent coordination

-

- If `~/.synthesis/coordination/active-sessions.md` exists, read it before any

- write. Confirm that this session's claimed area still covers the intended

- files, read new messages addressed to this session, and stop writes on any

- overlap. At normal execution checkpoints and task/phase changes, compare held

- areas with current needs: exact files for independent edits, directories when

- coordinated multi-file work requires them. Keep the smallest coherent area;

- expand and verify acceptance before additional writes, and narrow or release

- completed areas promptly after their required closure. Do not preclaim future

- work or automatically alter another session's claims. Use the

- `synthesis-project-management/scripts/coordination.py` helper and its

- [claim-scope protocol](../synthesis-project-management/references/parallel-agent-protocol.md#claim-scope-over-the-task-lifecycle).

- In read-only refresh-and-report mode, report needed scope changes without

- mutating claims.

-

- ### Step 1 — Verify current time

-

- ```bash

- date "+%Y-%m-%d %H:%M:%S %Z (%A)"

- ```

-

- Read the output. Set this as your authoritative "current time" anchor. Compare to whatever you previously believed about the current time. Note any difference larger than a few minutes — that's drift, and it means in-context time impressions are unreliable.

-

- ### Step 2 — Verify project state from disk

-

- Use this conversation's established project and its workspace's Git-tracked

- `projects/index.yaml`. A global active pointer is only a cache and must not

- silently switch an established conversation to another project.

-

- Before project prose, use the installed project-management resolver with

- `--no-fetch --no-coordination-refresh` and `GIT_OPTIONAL_LOCKS=0`. Do not request

- automatic fast-forward. A CONFLICT, FAIL or UNKNOWN result stops dependent reads

- and all project writes; report actual candidate locators and missing evidence.

- Do not choose a preferred checkout or run build/activation/migration to make

- the result appear successful.

-

- For the selected project, read:

- 1. `CURRENT_STATE.json`, when present, and `CONTEXT.md`.

- 2. The controlling plan and latest entry in `sessions/YYYY-MM.md`.

- 3. `REFERENCE.md` (full read on first recovery, section-skim on a repeated checkpoint).

-

- Missing required inputs stay explicit. File hashes, doctor checks and native

- receipts do not prove that the agent read or understood these project tiers.

-

- Note the "Last session" header in CONTEXT.md. Do not trust it as authoritative — it is a cache. Treat it as a starting hypothesis to verify in Step 3.

-

- ### Step 3 — Verify session evidence and Git publication separately

-

- Read the latest dated session entries under `sessions/`, including entries

- newer than the cached header. Compare their recorded workdays and outcomes

- with CONTEXT.md, structured state where present, and `index.yaml`.

-

- ```bash

- git log -10 --pretty=format:"%h %ai %ci %s" -- <project-path>

- git status --short -- <project-path>

- ```

-

- Git author/committer timestamps describe commits. They do not establish when

- the recorded session happened: overnight work, delayed publication, timezone

- boundaries, backdated authorship and bulk maintenance can all separate them.

- Never rewrite a recorded workday merely to match a commit date, and never

- infer uncommitted work from a date difference; inspect Git status for that.

-

- - Matching dated session records establish date agreement, not full semantic

- currency. Verify outcomes, current fields and source state as well.

- - A header or index date behind **or ahead of** the dated narrative is a record

- mismatch. Cite both records and reconcile against actual work evidence.

- - Missing, unreadable or invalid dated entries make session-date verification

- unavailable. State that limit; a commit timestamp cannot fill the gap.

- - Keep commit publication and upstream ancestry checks separate. A clean tree

- can still contain stale claims, and a valid session date can precede its commit.

-

- ### Step 4 — Cross-reference tasks and recent decisions

-

- Inspect the returned material-context coverage separately from structural health.

- Follow the [material-context protocol](../synthesis-context-lifecycle/references/material-context.md)

- to reconcile declared inputs, rationale, temporary conditions, uncertainty and

- amendments with actual retained spans. Restore unreachable associations without

- replaying the incident. Ordinary projects retain explicit coverage before

- NOT_APPLICABLE; hashes and supplied reviewer assertions cannot certify meaning.

-

- If the client provides an in-session task or plan surface, read it. Treat that

- as the third source of truth—ephemeral session memory to compare against disk

- and git.

-

- If there's a planning artifact (a plan file, a design doc, a checklist) referenced from CONTEXT.md — re-read it.

-

- ### Step 5 — Reconcile and report

-

- For a full recovery or explicit runtime-readiness report, if `synthesis-agent-conformance` is installed, run its

- `hook-live`, `catalog`, and `instruction-budget` modes against the current

- source/repository. The unqualified `hook-live` result is current global health.

- If the durable release or handoff record names accepted Claude and Codex

- session UUIDs, also run `hook-live` with

- `--claude-receipt-session-id` and `--codex-receipt-session-id`. Report the two

- scopes separately: a newer unrelated receipt can fail current health without

- revoking preserved accepted evidence, while an exact-session failure means the

- record can no longer be reverified from live artifacts. Never replace the

- current-health result with the selected historical result.

-

- Compare this task's own SessionStart receipt plugin version with current source

- and installed truth. A mismatch means this task has a stale startup registry.

- Save the durable checkpoint, then use a receipt-based recovery ladder:

-

- 1. Ask the user to restart the current agentic client and resume this same

- root conversation when that client can rehydrate an existing task.

- 2. After restart, require a genuine transcript-bound SessionStart event for

- the same root-session UUID, current plugin version, and enabled immutable

- plugin root; also confirm the loaded skill metadata matches installed

- truth.

- 3. Continue in the same conversation when all of those checks pass. The

- process restart is a genuine lifecycle reload even though the transcript

- identity is preserved.

- 4. Require a new Claude Code conversation or Codex task only when restart is

- unsupported, the same-session receipt is absent or mismatched, the

- transcript identity changes unexpectedly, or the loaded registry remains

- stale.

-

- Installing or copying a cache in place is not itself a reload. The evidence

- comes from the subsequent client lifecycle event, not from the installer.

-

- In one short paragraph in the next response to the user, state:

- - Today's verified date and time

- - The latest recorded session date and its dated evidence source; say when verification is unavailable

- - Where the agent's mental state diverged from disk/git, if anywhere

- - What the agent will do next, grounded in the verified facts

- - Current coordination claim and any conflict or new inter-session message

-

- Show this verification step in the response. It is the L4 visible-verification mechanism from the synthesis-context-temporal-continuity project — the user must be able to see that the checkpoint ran and what it produced.

-

- ### Step 6 — Update CONTEXT.md if it was stale

-

- If Step 3 reveals stale context, obtain an accepted exact-path claim using this

- conversation's verified native identity before editing or generating state.

- Use an isolated worktree and index when a concurrent root owns the same checkout.

- An ownership error does not make an active legacy seat terminal. Never infer

- administrative release authority from app closure, age or a typed reason.

- Without admitted authority, report the exact blocking seat and preserve the work.

-

- Under an accepted claim, make the verified correction, attribute it to this

- session and retain local continuity. Publish at the next authorized remote

- handoff or day-end. A missing structured-state file alone does not authorize a

- migration. Shared applicability distinguishes never-adopted ordinary projects

- from required state that is missing or unsafe. Release claims acquired solely for the checkpoint before pausing;

- narrow or release genuinely owned completed/paused work under the normal protocol.

-

- Before the checkpoint closes, ask: **What executable state or required input

- data still exists only in this session's scratchpad?** If a durable record

- cites its output, preserve the script and required inputs under

- resources/scripts/ before the checkpoint can close.

-

- ## Output Format

-

- The agent's response after invoking this skill should include something like:

-

- > **Checkpoint complete.** Verified facts:

- > - Today: 2026-05-27 10:49 EDT (Wednesday)

- > - Latest recorded session: 2026-05-25, from `sessions/2026-05.md`

- > - Latest project commit: 2026-05-26 12:47 EDT; this is publication evidence

- > - CONTEXT.md and the index agree with the dated entry; current claims were also checked

- > - No precise elapsed-session interval claimed: the entry supplies a workday, not an end timestamp

- > - In-progress task: [task summary from the client task/plan surface]

- >

- > Proceeding with [next action].

-

- If discrepancies were found:

-

- > **Checkpoint complete — drift detected.** Verified facts:

- > - Today: 2026-05-27 10:49 EDT

- > - CONTEXT.md said: "Last session: 2026-05-18 (PM)"

- > - `sessions/2026-05.md` records a later session on 2026-05-25

- > - Git records publication on May 26; that does not change the recorded workday

- > - Action: under an accepted claim, reconcile the stale header and current claims against the May 25 entry and source evidence.

-

- ## What Counts as "Substantive Work"

-

- Verify the relevant current facts BEFORE these kinds of work, not after. Use the full protocol when recovery or drift requires it:

-

- - Writing a session-log entry

- - Computing or claiming a time interval ("X days ago", "yesterday", "this week")

- - Quoting project status to the user

- - Making a planning decision based on "where we left off"

- - Generating a commit message that mentions dates or intervals

- After-the-fact verification catches some errors but lets stale facts propagate into outputs first. Verifying first is cheaper than correcting later.

- ## Relationship to Other Synthesis Skills

- This skill is the recovery primitive that other skills delegate to:

- - **synthesis-context-lifecycle** — references this skill in its Session Start Protocol and Mid-Session Refresh Protocol. The lifecycle skill defines the architecture of CONTEXT.md / REFERENCE.md / sessions/; this skill is the per-invocation drift-check.

- - **synthesis-daily-rituals** — references this skill in its day-start ritual. Day-start always runs a checkpoint before any project work begins.

- - **synthesis-project-management** — references this skill in its project-discovery protocol. When the user mentions a project, the agent runs a checkpoint on that project's files.

- These skills are independent. Each works standalone. But they are stronger when they all delegate the drift-check to this single skill, which guarantees a consistent protocol.

- ## Why This Works

- The synthesis project management system already has the durable layer (CONTEXT.md, REFERENCE.md, sessions/, git history). The failure mode is not lack of data — it's the agent's in-context memory drifting from that data over time. This skill's only job is to force a re-sync against the durable layer at the moments when it matters most.

- It is intentionally lightweight (~5 tool calls), intentionally codified (no variation between invocations), and intentionally visible (the user sees the verification step). All three properties matter:

- - **Lightweight** — runs without the agent rationalizing "this isn't worth the steps"

- - **Codified** — runs the same way every time, so users can recognize when it ran and when it didn't

- - **Visible** — users can spot when verification was skipped and intervene early

- This is the **NTP** of the synthesis project management system: periodic, authoritative-source-driven, automatic.