refresh

name	refresh
description	Refresh Cadre product, guidelines, workflow, styleguides, and tech-stack from user input, repository changes since setup/last refresh, and completed tracks, with an approved project refresh record. Use for the refresh command when project context drifts.

Cadre Refresh

Read .cadre/workflow.md, project.json, all project context files, the last refresh record, Git history since the recorded setup/refresh commit, completed-track outcomes, and current repository manifests/code. Read every target context file before editing it.

At every required clarification or approval boundary, show a concise context/impact summary or focused diff. Inspect the active host policy before calling workflow_elicit: if the task context reports approval policy never, including Codex Full Access, skip the form and ask the same short question once in chat. Otherwise prefer workflow_elicit, using clarification for at most three questions and approval bound to the exact refresh proposal checkpoint. Treat only an approved result as approval. If it returns fallback_required, or immediately returns declined while the task explicitly reports policy never, ask the same short question once in chat; the latter is policy rejection, not a human decline. Never request secrets or retry the form.

Call project_status first and use its embedded structured validation; do not repeat state_validate at command entry. If the Cadre MCP or required versioned template is unavailable, stop without changing project context.

1. Determine evidence sources: user input, committed repository changes, completed tracks, or a combination.
2. Apply the workflow clarification gate before drafting. Ask when the refresh request or evidence does not clearly establish the commit/time range, which context artifacts are in scope, whether files should describe current reality or a desired future state, how to resolve conflicts between user input and repository evidence, or whether cascading active-track updates are intended now.
3. Before changing execution-governing context, inspect all active implementation journals and workers. Include any required stop, preservation, or reconciliation at a safe quiescent boundary in the final refresh proposal; do not ask for a separate quiescence approval when the exact disposition can be assessed with the refresh. Draft focused diffs for product, guidelines, workflow, tech stack, general styleguide, and language/framework styleguides. Add/remove language guides only when the proposed tech stack requires it.
4. Assess impact on all active track specs, plans, and marked Pattern Seed sections in learning files. Apply the same impact analysis as $revise, but include every exact cascading track change in the refresh authorization envelope instead of starting separate approval cycles. Ask only if a material impact remains uncertain after inspection.
5. Call template_get_many once for project/refresh and project/refresh-operation, retain the versioned bundle, render refreshes/refresh-<ts>.md, and prepare .cadre/operations/refresh-<ts>.json with the evidence range, decisions, affected files and tracks, expected commits, approval, checkpoint, and progress. Expected human decision count is one for a fully assessed refresh. Present project-context diffs, active-work dispositions, cascading track changes, generated index updates, validation, commits, and provenance bookkeeping as one exact proposal.
6. After approval and before any context or track write, persist the refresh operation journal. Resume an existing matching journal from its first incomplete artifact; never replace it. Apply only authorized changes, advancing its checkpoint and artifact progress after each write. Append project and track history, reseed affected active tracks, then preview and apply tracks.md through its MCP digest gate and call state_validate without another prompt.
7. Commit cadre(refresh): update project context, then record that SHA in the refresh journal and as lastRefresh.commit, mark the journal completed, and create the follow-up cadre(refresh): record refresh commit state commit. These unchanged deterministic consequences remain inside the one refresh envelope. If interrupted after the first commit, identify and record the existing expected commit rather than repeating context changes.