--- name: achievements-system description: Project-AGNOSTIC bootstrap and cross-machine sync of the permanent achievement-history mechanism (docs/handoff/achievements/ + the root CLAUDE.md rule + the local .claude/ACHIEVEMENTS_INDEX.md pointer). ESTABLISH sets the system up from zero on a project that doesn't have it yet (new project, or this project on a machine seeing it for the first time). SYNC regenerates the local, gitignored index pointer on a machine where the SAME project is already checked out (the achievement .md files travel via git automatically — only the local pointer + read-in-context step needs redoing per machine). Every install first asks whether the skill should be installed only for the current project or globally for all Claude Code projects. Self-updating and self-activating (v2) - AUTO-UPDATE + AUTO-SETUP run first on every invocation and right after install or re-install - they bring every installed copy up to the latest version, detect the repo's state and run ESTABLISH, SYNC or a rule upgrade automatically. Invoke on "install the achievements-system skill", "set up the achievements system", "establish achievement history for this project", "sync/migrate achievements to this machine", or when a session notices CLAUDE.md lacks the achievement-history rule but the user wants it. --- # achievements-system (v2) — self-updating bootstrap + cross-machine sync for the permanent achievement log Two related but distinct jobs, matching the two ways this mechanism needs to reach a machine: 1. **ESTABLISH** — the project has never had this system. Nothing to sync; you're creating it. 2. **SYNC** — the project already has this system (it lives in git, so `git clone`/`git pull` already brought `docs/handoff/achievements/*.md` and the CLAUDE.md rule to this checkout) — but the **local, gitignored** index pointer (`.claude/ACHIEVEMENTS_INDEX.md`) does not travel with git and needs regenerating on every new machine, and the current session needs the 3-5 most recent achievement files actually read into context per CLAUDE.md's own instruction. Each mode also exists as a **standalone, directly-nameable file** — `docs/handoff/ achievement-establish.md` and `docs/handoff/achievement-sync.md` — self-contained procedures with the same steps as the two sections below plus their own paste-ready multiprompt, for when you want to name and run one directly ("run achievement-sync.md") rather than relying on this skill being auto-invoked by phrasing. Keep both in sync with this file's ESTABLISH/SYNC sections if either changes. **ESTABLISH is responsible for creating these two files on a project that doesn't have them yet** — see ESTABLISH step 1a below; they are part of what "bootstrapping the system" means, not optional extras you only get by copying them from elsewhere by hand. Both modes are project-agnostic: nothing below is hardcoded to any specific repo. Auto-detect the target project the same way `session-handoff` does. ## AUTO-UPDATE + AUTO-SETUP (run FIRST on every invocation, and immediately after install or re-install) Idempotent — safe to re-run. Whoever installs, re-installs or starts this skill ends up on the **latest version**, with the achievement system working in the current repo, without having to pick a mode by hand. 0. **AUTO-UPDATE.** Run the update script below as `sh update.sh achievements-system` (write it to a temp file in your scratchpad). It brings every existing copy of this skill — global install, project install, the repo's tracked `docs/handoff/achievements-system-skill.md` mirror, a root-level `achievements-system-skill.md` — up to the highest `skill-version` among them. It never downgrades and never creates copies in new places. - If it reports a newer version than the file you are following, re-read that `SKILL.md` and follow it instead. - Commit any updated tracked mirror with explicit paths. - An install or re-install onto a machine that already has the skill updates it **in place, at the scope it already has** — ask the "Install scope" question only when no copy is installed at either scope. Never replace a higher `skill-version` with a lower one. 1. **Detect the repo's state** with the detector script below (run from the repo root). It prints one `STATE=` line. 2. **Act on it:** - **`no-repo`** — nothing to activate. Report that the skill is installed and activates inside a git repo. - **`ESTABLISH`** — no rule and no records → run **ESTABLISH**. - **`BACKPORT-RULE`** — records exist but `CLAUDE.md` lacks the rule → add the rule (ESTABLISH step 2), then run **SYNC**. - **`SYNC`** — the rule exists, but the index is missing or doesn't list every record → run **SYNC**. - **`READY`** — everything is in place → just read the 3-5 most recent records (the rule's startup step). 3. **Upgrade what's older than this version, in any state where the rule exists:** - **Rule section:** if `rule_version` is `unanchored` or lower than this skill's rule version (**2**), replace the rule section in `CLAUDE.md` with ESTABLISH step 2's template. That means the whole section from `## STRONG PERMANENT RULE — achievement history` up to the next `## ` heading, or up to the end anchor. The template includes its `` anchors. Keep the project's one adapted clause, and keep everything else in `CLAUDE.md` untouched. - **Procedure files:** if `procedures_version` is lower than this skill's `skill-version` (or the files are missing), regenerate `docs/handoff/achievement-establish.md` and `achievement-sync.md` (ESTABLISH step 1a). 4. **Commit** everything changed, with explicit paths, and report what was detected and done. ```sh #!/bin/sh # skill AUTO-UPDATE (shared by session-handoff, achievements-system, resilient-agent-handoff) - idempotent. # Usage: sh update.sh . Brings every EXISTING copy of the skill on this machine/repo up to # the highest skill-version found among them. Never downgrades, never creates copies in new places. name=${1:?usage: update.sh } if [ -n "${USERPROFILE:-}" ]; then home="$(printf '%s' "$USERPROFILE" | sed 's|\\|/|g')/.claude"; else home="$HOME/.claude"; fi root=$(git rev-parse --show-toplevel 2>/dev/null || true) ver() { v=$(tr -d '\r' < "$1" 2>/dev/null | sed -n 's/^$/\1/p' | head -1); echo "${v:-0}"; } tmp=$(mktemp) printf '%s\n' "$home/skills/$name/SKILL.md" > "$tmp" if [ -n "$root" ]; then printf '%s\n' "$root/.claude/skills/$name/SKILL.md" "$root/docs/handoff/$name-skill.md" \ "$root/handoff/$name-skill.md" "$root/$name-skill.md" >> "$tmp" fi best=; bestv=-1 while IFS= read -r f; do [ -f "$f" ] || continue v=$(ver "$f") if [ "$v" -gt "$bestv" ]; then best=$f; bestv=$v; fi done < "$tmp" if [ -z "$best" ]; then rm -f "$tmp"; echo "$name: no installed copy found"; exit 0; fi updated=0 while IFS= read -r f; do { [ -f "$f" ] && [ "$f" != "$best" ]; } || continue if [ "$(ver "$f")" -lt "$bestv" ]; then tr -d '\r' < "$best" > "$f.new" && mv -f "$f.new" "$f" && updated=$((updated + 1)) && echo "$name: updated $f -> v$bestv" fi done < "$tmp" rm -f "$tmp" echo "$name: latest is v$bestv at $best ($updated older copies updated)" ``` ```sh #!/bin/sh # achievements-system AUTO-SETUP detector (v2) - read-only; prints the repo's state for the agent to act on. root=$(git rev-parse --show-toplevel 2>/dev/null) || { echo "STATE=no-repo"; exit 0; } cd "$root" if [ -d docs ] || [ ! -d handoff ]; then base=docs/handoff; else base=handoff; fi dir=$base/achievements rule=0; grep -qF 'STRONG PERMANENT RULE — achievement history' CLAUDE.md 2>/dev/null && rule=1 rulev=$(tr -d '\r' < CLAUDE.md 2>/dev/null | sed -n 's/^$/\1/p' | head -1) records=0; missing=0; index=0 [ -f .claude/ACHIEVEMENTS_INDEX.md ] && index=1 for f in "$dir"/*.md; do [ -f "$f" ] || continue records=$((records + 1)) if [ "$index" = 0 ] || ! grep -qF "$(basename "$f")" .claude/ACHIEVEMENTS_INDEX.md; then missing=$((missing + 1)); fi done pv=$(tr -d '\r' < "$base/achievement-establish.md" 2>/dev/null | sed -n 's/^$/\1/p' | head -1) [ -f "$base/achievement-sync.md" ] || pv= if [ "$rule" = 0 ] && [ "$records" = 0 ]; then state=ESTABLISH elif [ "$rule" = 0 ]; then state=BACKPORT-RULE elif [ "$index" = 0 ] || [ "$missing" -gt 0 ]; then state=SYNC else state=READY; fi echo "STATE=$state dir=$dir records=$records rule=$rule rule_version=${rulev:-unanchored} index=$index index_missing=$missing procedures_version=${pv:-missing}" ``` ## Install scope — ask the user first, on every install Before writing this skill's `SKILL.md` anywhere (ESTABLISH step 0, SYNC step 0, or a plain "install this skill" request), ask the user this one question — unless they already said which in their request: > Install the achievements-system skill **only for this project**, or **globally for all Claude > Code projects** on this machine? | Choice | Skill file is written to | Effect | |---|---|---| | **This project only** | `/.claude/skills/achievements-system/SKILL.md` | Available only in sessions opened in this repo. Travels with the repo if `.claude/` is tracked. | | **Globally** | `/skills/achievements-system/SKILL.md` | Available in every Claude Code project on this machine, including ones that don't have the system yet. Do NOT also write the project-level copy, or the skill is listed twice. | - **Already installed at either scope?** A re-install is an update: AUTO-UPDATE refreshes the existing copy in place, and the scope question is skipped. - **Already installed at the other scope?** Say where it is and ask whether to move it. Delete the old copy only with the user's OK; never leave both. - **Can't ask?** In a non-interactive run, default to **this project only**, the least invasive choice, and report that in the summary. - **Scope covers only the skill file.** The achievement system itself (the `CLAUDE.md` rule, `docs/handoff/achievements/`, `.claude/ACHIEVEMENTS_INDEX.md`) is always per-repo, because the log is that repo's committed history. A global install does NOT switch the rule on in other projects; run ESTABLISH in each project that should have it. - **The tracked mirror is committed either way.** Still commit `docs/handoff/achievements-system-skill.md` in the repo (see next section), so the skill can be reinstalled on other machines. - **``** below means whichever of the two locations was chosen. ## Traveling this skill itself across machines **Check whether `.claude/` is gitignored in the target repo** (`grep -n '\.claude' .gitignore` or `.git/info/exclude`). If it IS (common — matches this project's own convention), this `SKILL.md` file does NOT sync via `git clone`/`git pull` on its own, exactly like `session-handoff`'s own skill file has the same problem and solves it the same way: mirror a copy into the tracked bundle directory, `docs/handoff/achievements-system-skill.md`, and have ESTABLISH/SYNC on a new machine install FROM that tracked copy rather than assuming `` is already present. Whenever you edit this skill, re-copy it to the tracked location in the SAME commit (`cp -f "" docs/handoff/achievements-system-skill.md`) so the two never drift. If `.claude/` is NOT gitignored in a given target repo and the skill was installed project-only, this mirroring step is unnecessary (the skill already travels on its own) — do it anyway only if the project already mirrors `session-handoff` the same way, for consistency. With a **global** install the skill lives outside every repo, so the mirror is always required. ## Auto-detect (run first, either mode) - **Claude home:** Windows Git-Bash `"$USERPROFILE/.claude"`; macOS/Linux `"$HOME/.claude"`. - **Existing skill install:** check both `/skills/achievements-system/SKILL.md` and `/.claude/skills/achievements-system/SKILL.md` — feeds the "Install scope" question. - **Repo root:** `git rev-parse --show-toplevel`. If not a git repo yet, `git init` first (ask the user, per this session's standing "confirm before init" caution) — the achievement log is only meaningful as committed, append-only history. - **Bundle dir:** `/docs/handoff/achievements/` (use `/handoff/achievements/` only if the project has no `docs/` dir convention at all — match whatever `session-handoff` chose for this same repo, since both skills should agree on one location). - **Root CLAUDE.md:** `/CLAUDE.md`. May not exist yet (ESTABLISH) or may exist without the rule section (an older checkout, or a project that adopted `session-handoff` but never this skill). - **Local pointer:** `/.claude/ACHIEVEMENTS_INDEX.md` — gitignored by convention (check `.gitignore`/`.git/info/exclude` for a `.claude/` entry; if `.claude/` is NOT ignored in this repo, the pointer travels via git too and SYNC's regeneration step becomes a no-op safety check rather than a real gap). ## ESTABLISH (bootstrap from zero) 0. **Ask the install scope, then ensure the skill file itself exists at ``.** First ask the "Install scope" question above (project only vs. globally), unless the user already answered it, and resolve `` from the answer. Do not assume the skill is already installed just because you're currently running its instructions (you may have been handed this content via a multiprompt, a copy-paste, or a different project's mirrored `docs/handoff/achievements-system-skill.md`, none of which guarantee it is installed at either scope on this machine). Write the FULL, exact content of this skill file to `` (you already have it in context, since you're executing it — write it out verbatim, not a summary). This is what lets the `Skill` tool auto-invoke `achievements-system` by name/phrasing in future sessions — in THIS repo only, or in every project if installed globally — and it's the source step 1a's `docs/handoff/achievements-system-skill.md` mirror gets copied from. Do this even on a repo where `.claude/` turns out not to be gitignored — the file still needs to physically exist either way. 1. `mkdir -p "/docs/handoff/achievements"`. 1a. **Write `/docs/handoff/achievement-establish.md` and `/docs/handoff/ achievement-sync.md`** — this is a NEW repo's first time getting this system, so these two files will not exist there yet. If you have a source copy handy (e.g. you were handed this skill by copying it FROM another project's `docs/handoff/achievements-system-skill.md`, and that project's `achievement-establish.md`/`achievement-sync.md` are also reachable), copy those two files verbatim — they're already fully generic (no project-specific content, just ``-style placeholders). If no source copy is reachable, WRITE them fresh yourself: each is a self-contained restructuring of this skill's own ESTABLISH section (for `achievement-establish.md`) and SYNC section (for `achievement-sync.md`) below — a short "why this file exists" paragraph, the numbered steps in that section (verbatim command blocks included), and that section's own paste-ready multiprompt reformatted to say "Read and execute docs/handoff/achievement-establish.md [or -sync.md] in full" rather than "load the skill and run its ESTABLISH/SYNC mode" (the standalone file's whole point is not needing the skill loaded first). Keep them project-agnostic — no repo name, no specific paths beyond ``-style placeholders — so they're equally valid if copied to a THIRD project later. This step is not optional: without it, only THIS repo's copy of the system is directly nameable/runnable; the next new project you bootstrap would silently lack that convenience. 2. **Add the rule to root `CLAUDE.md`** — create the file if missing (with a one-line project description above the rule, inferred from the repo's README/package manifest/directory names — ask the user if genuinely unclear), or append the section if the file exists but lacks it. Use this exact section (adapt only the two bracketed notes, keep everything else verbatim — the wording is load-bearing, other sessions parse it as an instruction): The `begin`/`end` anchor comments are part of the template (rule version **2**): they let AUTO-SETUP find and upgrade this exact section in later versions. Keep them exactly once each. ```markdown ## STRONG PERMANENT RULE — achievement history (read this every session) Every positive achievement (a shipped feature, a fixed bug, a verified milestone, a completed integration) gets a **permanent, timestamped, append-only record** — never overwritten, never deleted. [This is separate from any rolling session-handoff snapshot, which captures *current state* for cross-machine continuation — omit this bracketed clause entirely if the project has no session-handoff-style skill installed;] the achievement log captures *history*: what was done, HOW (the real method/algorithm/approach), what findings and problems/errors came up and how they were resolved — with enough real detail that a future session could reconstruct what happened and why, not just that it happened. - **Location:** `docs/handoff/achievements/`. - **Filename:** `YYYY-MM-DD_HHMMSS_short-slug.md` (UTC or local — be consistent within one file; the shell `date +"%Y-%m-%d_%H%M%S"` command gives you the stamp). - **When to write one:** after any substantive achievement — a shipped engine/feature, a real bug found+fixed, a completed integration, a verified milestone. Not every trivial edit; use judgment the same way commit-message granularity is judged. Batch a work session's related achievements into one file if they landed together, rather than one file per tiny step. - **Scope = the delta since the LAST record, not a fixed time window.** Each new record covers everything achieved since the most recent existing file in `docs/handoff/achievements/` (check its filename timestamp / read its content to see what it already covered) — not "the last N hours." A fixed-hour catch-up is only for a one-time backlog catch-up when the mechanism is first adopted or has gone stale; steady-state cadence is strictly incremental. - **What each record must contain** (enough to restore the session, not just a headline): 1. **What was achieved** — the concrete deliverable. 2. **How it was done** — the real method/algorithm/architecture, specific enough to redo it. 3. **Systems/algorithms/papers involved** — name them precisely. 4. **Findings** — anything non-obvious discovered along the way. 5. **Problems/errors hit and how they were resolved** — the real failure mode + real fix, not glossed over. Honest gaps/limitations that remain are part of this, not omitted. 6. **Verification performed** — what was actually run/tested/measured, with real numbers where applicable — real measured results over inflated claims. - **Commit it.** These files are real project history — commit them. **On every session startup**, read the **3-5 most recent files** in `docs/handoff/achievements/` (sort by filename — the timestamp sorts naturally) to pick up recent context before starting work. A pointer/summary also lives at `.claude/ACHIEVEMENTS_INDEX.md` for quick local reference (session-local, not necessarily committed) — but `docs/handoff/achievements/` is the canonical, permanent, committed record. ``` 3. **Create the local pointer** `/.claude/ACHIEVEMENTS_INDEX.md`: ```markdown # Achievements index (local pointer — canonical record is docs/handoff/achievements/) This file is a quick local pointer to the permanent, committed achievement history at `docs/handoff/achievements/` in the repo. Read the 3-5 most recent files there on session startup (sorted by filename — timestamps sort naturally). This file itself may or may not be committed depending on `.claude/`'s gitignore status in this repo; the real record always lives in `docs/handoff/achievements/`. ## Most recent achievement files (refresh this list after adding a new one) ``` (Empty list if this is a genuinely fresh project — the first real achievement written appends its own entry here per the rule's own maintenance convention.) 4. Ensure `.claude/` is gitignored if the project intends the pointer to stay machine-local (matches this skill's own SYNC-mode assumption); if the project instead wants the pointer to travel via git (simpler, no per-machine regeneration needed, at the cost of a small amount of git noise on every achievement), leave it tracked — either is valid, ask the user's preference if the project has no existing convention either way. 5. Optionally (recommended): save an `achievement-history-rule` memory via this Claude instance's own memory system (type `feedback` or `project`, whichever the memory system's own criteria picks) summarizing the rule, so a future session on this project recalls it as a standing pattern even before re-reading CLAUDE.md. Mirror the structure of this project's own existing `achievement-history-rule.md` memory if one is visible in context. 6. Commit `CLAUDE.md` + `docs/handoff/achievement-establish.md` + `docs/handoff/ achievement-sync.md` (from step 1a) + the (now-existing, possibly empty) `docs/handoff/ achievements/` directory (git doesn't track empty dirs — add a `.gitkeep` or wait for the first real achievement file) + this skill's own mirrored copy, `docs/handoff/ achievements-system-skill.md` (`cp -f "" docs/handoff/achievements-system-skill.md` first, per "Traveling this skill itself" above) — all four `docs/handoff/*` files together are what makes the system fully self-transportable to the NEXT new project someone bootstraps from this one. Do NOT commit `.claude/ACHIEVEMENTS_INDEX.md` if `.claude/` is gitignored in this repo. ### ESTABLISH multiprompt (paste into a fresh Claude Code session on the target project) ``` Set up this project's permanent achievement-history system from zero: 1. Load the achievements-system skill (copy it from 's docs/handoff/ achievements-system-skill.md if this project already mirrors it there, or from an existing install, or ask me for it if none exists). First ask me whether to install it ONLY FOR THIS PROJECT (.claude/skills/achievements-system/SKILL.md) or GLOBALLY FOR ALL CLAUDE CODE PROJECTS (/skills/achievements-system/SKILL.md), install it there, then run its ESTABLISH mode. 2. Infer a one-line description of this project from its README/package manifest for the top of CLAUDE.md if CLAUDE.md doesn't exist yet. 3. Ask me only if genuinely unclear: (a) should docs/handoff/achievements/ live there or somewhere else per this project's existing doc conventions, (b) should .claude/ be gitignored here. 4. After setup, confirm: CLAUDE.md has the rule section, docs/handoff/achievements/ exists, .claude/ACHIEVEMENTS_INDEX.md exists, and (if applicable) everything real is committed. 5. From now on, follow the rule exactly as written in CLAUDE.md for the rest of this session and all future ones. ``` ## SYNC (same project, new machine, system already exists in git history) Use this when `git log` on this checkout already shows achievement-record commits, or CLAUDE.md already has the rule section, but `.claude/ACHIEVEMENTS_INDEX.md` is missing/stale on THIS machine (fresh clone, or an old clone that predates recent achievement files). 0. **Make sure the skill is installed on this machine.** If it isn't installed at either scope, ask the "Install scope" question (project only vs. globally) and copy `docs/handoff/achievements-system-skill.md` to the chosen ``. If it is already installed, globally or in this repo, leave it where it is. 1. Confirm the achievement files really are here: `ls -t docs/handoff/achievements/ | head -5` (or equivalent). If this list is EMPTY despite CLAUDE.md having the rule, this checkout is missing commits the rest of the team/other machines have — `git fetch && git log --oneline origin/ -- docs/handoff/achievements/` to check, and `git pull`/checkout the right branch rather than proceeding as if the project were achievement-history-free (do NOT re-run ESTABLISH over real missing history — that would silently paper over a sync problem instead of surfacing it). 2. **Regenerate `.claude/ACHIEVEMENTS_INDEX.md`** from what's actually on disk: list all files in `docs/handoff/achievements/`, sort by filename (timestamps sort naturally), and write the same pointer-file structure as ESTABLISH step 3, with a one-line summary per file for AT LEAST the 5 most recent (more is fine, this file is a local convenience index, not itself achievement history — keep entries to one line each, point back to the real file for detail). 3. **Read the 3-5 most recent achievement files in full** right now, in this session, per CLAUDE.md's own "on every session startup" instruction — this is the step that actually matters for THIS session's context, more than the pointer file itself. 4. If CLAUDE.md on this checkout is missing the rule section entirely (a real gap, not just a missing local pointer — e.g. this branch predates the rule's adoption on another branch), offer to backport it from ESTABLISH step 2's template, or from another branch/checkout that has it. 5. Nothing else needs "migrating" — the achievement `.md` files themselves are already real, committed git history; this mode's whole job is regenerating the local artifact that DOESN'T travel with git, plus doing the context read-in a fresh machine would otherwise skip. ### SYNC multiprompt (paste into a fresh Claude Code session on the new machine, same project) ``` This project already has the permanent achievement-history system (docs/handoff/achievements/, committed in git) from other machines' sessions — I just checked it out here for the first time. 1. Load the achievements-system skill: if it isn't already installed on this machine, ask me whether to install it ONLY FOR THIS PROJECT (.claude/skills/achievements-system/SKILL.md) or GLOBALLY FOR ALL CLAUDE CODE PROJECTS (/skills/achievements-system/SKILL.md), then copy docs/handoff/achievements-system-skill.md (it should already be in this checkout since docs/handoff/ is committed) there, then run its SYNC mode. If that tracked copy is missing too, ask me for the skill file directly. 2. Regenerate .claude/ACHIEVEMENTS_INDEX.md from what's actually in docs/handoff/achievements/ on this checkout. 3. Read the 3-5 most recent achievement files in full right now and summarize back to me: what they cover, and anything that changes how you'd approach the work I'm about to ask for. 4. Confirm CLAUDE.md's achievement-history rule section is present; if not, flag it rather than silently skipping the rule. 5. Follow the rule for the rest of this session and all future ones. ``` ## Relationship to `session-handoff` - `session-handoff`'s bundle already carries a brief pointer to this mechanism (see its own "Achievement history" section) — that's sufficient cross-reference, this skill does NOT need to duplicate `session-handoff`'s rolling-snapshot machinery (`SESSION_HANDOFF.md`/`TASKS.md`). Achievement records are permanent history; `session-handoff` is current-state-only. Run both skills on a genuinely new machine if the project uses both (`session-handoff` IMPORT first for the rolling state, then this skill's SYNC for the permanent log) — they don't conflict, and `session-handoff`'s own auto-update hook already re-copies achievement-adjacent memories, so order rarely matters in practice. - If a project only wants ONE of the two mechanisms, this skill is fully usable standalone — nothing here depends on `session-handoff` being installed. ## Notes - Generic by design: the only project-specific things are auto-detected (repo root, doc-dir convention, `.gitignore` status of `.claude/`) or inferred from the live project (a one-line description for a fresh CLAUDE.md). Reuse this skill for any repo. - The committed `docs/handoff/achievements/*.md` files are ground truth; `.claude/ ACHIEVEMENTS_INDEX.md` is a convenience index only, always safe to regenerate/discard/rebuild from what's actually on disk. - Never edit or delete an existing achievement file to "fix" it after the fact (append-only, per the rule itself) — if something in an old record turns out to be wrong, note the correction in a NEW record rather than rewriting history.