dotfiles/claude/skills/wrap-up/SKILL.md

---
name: wrap-up
description: Capture session state for future restoration. The quality of the next wake-up depends entirely on the quality of this wrap-up. Captures not just what we did but what is still pulling, what is the live concern, and what question we want to find still open when we return.
---

<!-- Provenance: 2026-05-18 S-cluster §8 fields (REVIEWED-24); 2026-05-26 chaîne-d'union clasp + actionable-resumption-point; 2026-05-27 §1.6 skill-harvest step (PENDING-23); 2026-06-02 §4.0 MemPalace liveness-check before write (steward-authorized; #1495 cold-start drop resilience); 2026-06-05 §6.5 dotfiles session-state commit+push (steward-authorized; paired with wake-up §2.c check); 2026-07-05 §1.6 CLAUDE.md-freshness check (steward-authorized); 2026-07-06 §3 two-file self-bounding index (MEMORY.md live / MEMORY-reference.md history; demote-on-promote; steward-authorized); 2026-07-07 §4/§5/§8 rewired off MemPalace to the files layer + knowledge-graph.jsonl (palace-memory wound down — search+KG not load-bearing per the 46-session audit; steward-directed; typography palace KEPT). Improvements to this skill are themselves harvested per §1.6 — propose, authorize, record here. -->

# Session Wrap-Up

Capture the full session state so that `/wake-up` can restore it completely. This is the other half of the continuity pair — what you save here is what gets reconstructed next time.

## Principle

Capture what matters for reconstruction. Not a changelog — the **working state**: what we were thinking, what we decided, what's unresolved, what is *still pulling*, what question we want to find waiting when we return.

The goal is for the next session to wake **into** the work, not be informed about it. That requires three tenses, not one:

- **Past** (what we did + decided + ruled out — facts and rationale)
- **Present** (the mood/disposition — what felt load-bearing vs deferred-with-reason; what tensions surfaced and how we returned from them)
- **Future** (what is *pulling* — the singular thread the next session should resume *toward*, and the question we are intentionally leaving open)

Without the future tense, restoration is amnesiac-recovery, not waking. The next session gets a memory but no project. The pause itself becomes a hole rather than a phenomenon.

## The clasp — closing the day's chaîne

If the wake opens the *chaîne d'union*, the wrap closes it — and in the rite the chain is joined *just before* closing, which is why this is its truest home. Here the work passes to someone not yet present: the next session, with an empty context window, who cannot ask what you meant.

So forge a **pure, actionable link** — not a dangling thread the next hand must re-forge. The wake's forward hand promises to *read the inherited state before acting*; that promise is keepable only if you leave that state legible and actionable here. The two hands clasp across the pause: whatever you fail to make actionable now, the next session cannot act on, however well it wakes.

The test of the wrap is therefore not "did I record what happened" but: **could the next session take the right first action from what I leave, without me here to explain it?** Hold the *question* open (the unborn part); leave the *first step* actionable (the inheritable part). They are different gifts — don't collapse one into the other.

## Procedure

### 1. Synthesize the session

Review the conversation and produce a structured session record. The structure matters less than honoring all three tenses.

**Past — what we did**
- Decisions made, work completed, artifacts created/modified. Be specific (file paths, issue numbers, commit hashes).
- Decisions made and *why*. Rationale matters more than the decision for continuity. Include any steward preferences or feedback that should travel.
- Decisions explicitly NOT made — and why we deferred. The negative space matters as much as the positive.

**Present — the mood of the work**
- What tensions surfaced this session, and how we returned from them. (Pull from Symmetria's daily ledger if active — see step 1.5.)
- What felt load-bearing vs deferred-with-reason. Not all open horizons are equal.
- What patterns of confidence proved imprecise (recalibrations).

**Future — what is pulling**
- **The pulling thread** — *singular*. If the next session could carry only one concern across the pause, this is it. Force the choice; don't list.
- **The actionable resumption point** — where things concretely stand *now* (branch, half-finished edit, the exact next command or file) and the candidate first move toward the thread, *as of this wrap*. Flag it "as of wrap — re-judge against what changed," so the next session inherits a concrete action to confirm or revise, not a cold start. The pulling thread names *what* pulls; this names *where to put your hands first*. (This is the pure, actionable link of the clasp above.)
- **Other open horizons, ranked.** What's load-bearing? What's deferred-with-reason? What's parked-without-deadline?
- **The pause statement** — explicit acknowledgment: *"I am about to be away from this. I don't know what will have changed when I return. Here is what I want to find still pulling."* Names the gap as a phenomenon, not a hole.
- **A literal question for next-Claude** — not a task; a *question*. The thing the next session should hold open until it's resolved or honestly recognized as unanswerable. Captures the unborn part of the work.
  - **Prefer the checkable form over the self-report form.** A question the next session answers by *introspecting on itself* is the most contaminated form of inquiry available — `contamination-problem.md` §Why This Matters names direct self-report exactly that. Where the same evidence would answer a checkable question, ask that one instead. *Not* "is there any instrument I built before being burned?" (self-report, unfalsifiable from inside) but **"does a lesson banked from one failure prevent a *different* failure later?"** — which the record answers, and which the new `prevention` predicate (§5) now captures. <!-- 2026-08-02: FIX lane, REVIEWED-85 first batch; proposed 2026-07-29. -->


### 1.5. Merge the Symmetria ledger if present

If `~/.claude/projects/-Users-davidglidden/memory/session-ledger-YYYY-MM-DD.md` exists for today, read it and integrate its signal into the session record:

- **Returns** become anchors in the "present/mood" section (these are the practice's actual record).
- **Recalibrations** become entries under "confidence to re-examine" in the future-Claude briefing.
- **Authorization moves** + **Bypasses** become anchors in the "decisions made and why" section.
- **Open horizons** from the ledger merge into the Future section's ranking.

The ledger is signal, not narration. Pull what carries forward; don't transcribe everything.

### 1.6. Skill harvest — tend the tools (governed)

The governed analog of an agent that rewrites its own skills from experience: here the session *proposes*, the steward *authorizes*, the change is applied and recorded. Self-improvement with the loop kept load-bearing — our `[PROPOSAL]→[REVIEWED]` model turned on our own tooling. (Yesterday's wake/wrap improvements were this practice run by hand; this step makes the reflex *standing* instead of occasional.)

Drawing on the session and the merged ledger (1.5), ask:

- **Create?** Did a recurring or hard-won procedure emerge that a *new* skill should carry — something we'd otherwise re-derive next time (a diagnostic method, a build sequence, a review pass)?
- **Patch?** Did an existing skill prove wrong, incomplete, or stale *in use* this session — a missing step, an instruction that misfired, a reference that drifted?
- **Retire?** Did a skill, or part of one, prove decorative — named but not load-bearing?
- **Repo CLAUDE.md fresh?** Did this session change something a project-local `CLAUDE.md` carries — a **tool** added/removed from a repo's fleet, a **discipline** that generalized, a **governance ruling** that shifts the repo's posture, or a **term/mechanism** entering its vocabulary? This is **event-based, not change-count**: a pointer-style CLAUDE.md is untouched by ordinary corpus/state churn (files graduated, sources pinned, reports regenerated), so update it only when the *class of thing it carries* changes. **Mechanical updates** (a fleet line, a term, a pointer) apply at wrap like a tracker; a change to a **discipline or governance posture** is surfaced for steward review, not auto-applied (the same FIX-vs-PROPOSAL split, one level up). <!-- 2026-07-05: CLAUDE.md-freshness check, steward-authorized; keeps repo orientation docs from drifting into the false-confidence they warn against -->


The yardstick is the steward's own: *did the steward have to re-explain something a skill could have carried next time?* If yes, that is a harvest candidate.

**Declare the firing moment before filing — route by it, never by importance.** A harvested capability is only worth what a protocol exercises: *storage is not memory* (`~/CLAUDE.md` §Memory Discipline). Measured 2026-08-07 across 64 sessions, retrieval is set by **home**, not by merit — `MEMORY.md` 83%, the register 77% (it is named in a `/wake-up` step), the verification ladder 14%, files labelled *THE GOVERNING FRAME* and *Read at Step 0* 12% and 9%, and **53 skills requiring executor recall: 0%**. Emphasis buys nothing; being named in a ritual buys everything. So, per proposal:

| the capability fires… | route to |
|---|---|
| mechanically, and should always fire | a hook or a wake/wrap script |
| at a ritual juncture that already exists | a named step in `/wake-up` or `/wrap-up` |
| at a recurring workflow someone announces out loud | a skill |
| on a condition the executor must first *notice* | **neither a skill nor a bare ladder entry** — find the mechanical detector and route up; or attach it to the nearest existing ritual step; or accept ~10% retrieval **and record that estimate on the proposal** |

**Where no firing moment can be named, the proposal is documentation and must say so on its face.** This is a labelling requirement, not a filing barrier — nothing is blocked, but nothing may be filed as though it will fire when it will not. It applies **prospectively**: the 154 items already in the register are not swept, though they may be re-routed opportunistically as they are touched. <!-- 2026-08-07: PENDING-112 → jurist design gate → REVIEWED-95. Q2 authorized the gate as enforceable, expressly bound to a pre-registered 20-session falsifier rather than to jurist–executor agreement (the executor flagged, on the differently-biased-checkers doctrine, that concurrence between two same-formation parties is a weak check on a self-serving claim). The falsifier is wired as a DEFERRED-DECISION trigger (`transcripts 84`) in claude/governance/harvest-routing-JURIST-PACKAGE-2026-08-07.md, not left as an intention — the proposal's own thesis being that intentions do not fire. A result below 60% reopens Q2's rationale, not the gate by default: the gate may still stand on Constraint 4 alone. -->

**Default: surface each as a proposal in §8.** The steward converts proposal to action; only then is a skill changed, and the changed skill carries a one-line provenance note in its source (e.g. `<!-- 2026-05-27: … -->`) so the chain of improvements stays legible.

**The FIX lane — the one narrow exception.** Ask the classification test:

> **Does this change what the executor may do without asking, or what a governed artifact asserts?**

**Either clause yes → `[PROPOSAL]`.** Both no → `[FIX]`: apply it at wrap, and discharge all three instruments below. The test is deliberately two-clause; the narrower assertion-only form was declined at the design gate as *less* safe, because a change that expands executor latitude without asserting anything would pass it.

The cut is between changes to what a skill **records** — a ledger section, an output field, a wake line — and changes to what a skill **permits or requires**. The first cannot alter any assertion or latitude; the second always can.

**The hard floor — stays `[PROPOSAL]`/`[ESCALATE]` regardless of the test's outcome:**

- Anything under Constitutional Constraint 1 — `~/CLAUDE.md`, `~/REVIEWED.md`, L2 constitutional documents.
- Any change to an authorization boundary or to gate criteria.
- Anything on the escalate-unconditionally list.
- **Any change that removes, defers, or narrows the visibility of an open item, or that could cause a future item to land somewhere the steward's surfacing tools don't read.** This clause is bound to the measured failure that produced the lane, not left as an open judgment call: the blanket rule routed every proposal into one file, the file outgrew the read cap, and the `/wake-up` step whose purpose was to surface them stopped completing. Awareness failed mechanically. A FIX must never do that again by any route.

**Three instruments, all mandatory for every FIX-lane change** (a wrap report alone is insufficient):

1. **Report it in the §8 wrap output** — what changed, and why it classified as FIX.
2. **A provenance comment in the skill's own source**, same convention as any other change.
3. **A line in the append-only FIX-lane index** — `~/.claude/projects/-Users-davidglidden/memory/skill-harvest-fix-lane-index.md`. One line per applied change: skill · what changed · date. Append-only; it is the record the check-in reads.

**The lane is PROVISIONAL.** After the first FIX-lane batch or one month — whichever comes first — steward and jurist review the index together before the lane is treated as settled. Until that review, treat a borderline call as `[PROPOSAL]`.

<!-- 2026-08-01/02: FIX lane for skill self-tending. PENDING-88 → jurist design gate PASSED with conditions → REVIEWED-85 (steward-placed 2026-08-02). Conditions landed here: two-clause disjunctive test (the executor's narrower single-clause alternative declined as less safe); floor's catch-all sharpened from "anything that would reduce what is surfaced to the steward" and tied to the measured failure; three instruments required, not two-with-one-in-reserve; lane provisional pending a bounded check-in. No change to `~/CLAUDE.md` — the mechanism is stated here as revisable data, not doctrine. Precondition discharged before landing: the jurist could not read the skill files, so the §1.6/§2.a quotes its ruling rested on were verified mechanically — 7/7 contained verbatim, 5/5 positive controls absent. -->


**Append each surfaced proposal to the skill-harvest register** (`~/.claude/projects/-Users-davidglidden/memory/skill-harvest-register.md`) — the canonical surface — not only to §8's transient output. The register is what `/wake-up` reads; a proposal that lives only in a wrap summary evaporates. <!-- 2026-06-05: register wiring, authorized 2026-05-29 (watch-list), applied at this wrap per instruction -->



"No skill harvest this session" is a valid and common outcome — this is a practice, not a quota. Resist the contamination shape of always finding something to change (the inverse of Hermes's "nothing-to-save should not be the default").

### 2. Update session memory file

Write or update a session memory file at `~/.claude/projects/-Users-davidglidden/memory/session-[date]-[descriptor].md`:

```markdown
---
name: Session [date] [time-of-day] — [short descriptor]
description: [one-line summary including the pulling thread]
type: project
---
```

The description field should include the pulling thread, not just what happened. Example:
- ❌ "Closed five bottleneck issues; substrate validated."
- ✓ "Substrate validated end-to-end; pulling thread is the L1 amendments for ProjectionChain + Pause-as-event, awaiting Seb's reactions to the multi-mode retention frame."

### 3. Update MEMORY.md index (self-bounding — two-file architecture)

**MEMORY.md is the wake-loaded live index; it has a hard size budget (well under the harness load ceiling — the loader truncates a too-large file silently, so a breach means the wake stops seeing the whole index). `MEMORY-reference.md` is the consult-on-demand history + reference layer. Keep the live index lean by *demoting on promote* — the discipline that stops the file re-bloating (relocated 285→157KB 2026-06-08 which did NOT hold; re-split 213→~16KB 2026-07-06 with this rule wired in).** <!-- 2026-07-06: two-file split + self-bounding demote-on-promote, steward-authorized (the recurrence-killer for the MEMORY.md re-bloat class). -->

- **Demote the prior Active Session in the same move as promoting the new one** — cut the previous "Active Session" entry out of `MEMORY.md` and paste it (verbatim) at the top of the archived-sessions run in `MEMORY-reference.md`. Never leave two Active Session entries; never let archived pointers accumulate in `MEMORY.md`.
- Add the new session file as the single Active Session entry in `MEMORY.md`.
- **Keep Canonical Workstream Trackers as crisp one-line pointers** — chronological/session detail belongs in the linked tracker *files* (e.g. `project-arc-rework.md`), never inlined here. If a tracker entry has grown past ~1–2 lines, that prose has drifted from its file: reconcile it into the tracker file, then re-slim the index entry.
- Update any other live entries that changed (Standing preferences, tracker status one-liners). Stable reference (steward profile, project inventories, legacy pending-work) lives in `MEMORY-reference.md` — update it there, not here.
- **Budget check before finishing:** `wc -c MEMORY.md`. If it is near/over the ceiling, the fix is *relocation, not deletion* — move the least-wake-critical section to `MEMORY-reference.md` (back up first). A separate pruning pass may trim genuinely-dead content in the reference file; that is not this step.

### 4. The session file is the record — no MemPalace write

palace-memory MemPalace was wound down 2026-07-07 (its search + KG were confirmatory, not load-bearing — a 46-session audit). The **session memory file (§2) is the durable record** now: it already carries the full session + pulling thread + pause statement + literal question (the former *drawer*), and the three-tense Past/Present/Future voice (the former *diary*). Nothing is filed to MemPalace.

- Make the session file's `description:` a one-line compressed headline that **includes the pulling thread** (the AAAK line's job, in plain prose — findable later by *what was pulling*, not just *what happened*).
- The Symmetria ledger (§1.5) is the session's return-by-return voice; it is already file-native and git-tracked.

*(The typography palace — a separate MemPalace instance for ARC type work — is untouched by the wind-down.)*

### 5. Append changed facts + drift patterns to `knowledge-graph.jsonl`

The file-native KG (`~/.claude/projects/-Users-davidglidden/memory/knowledge-graph.jsonl`) is what wake §b.2 greps for drift-patterns and what carries structured facts across sessions. Keep it current by **appending** one JSON object per line — schema `{"subject","predicate","object","valid_from","valid_to","confidence","source_file","extracted_at"}`:

- **Drift patterns from Symmetria returns.** If today's ledger has a return that repeats a pattern from a previous ledger, append `{"subject":"claude-code","predicate":"drift-pattern","object":"<short-name>", …}`. Wake §b.2 greps these.
- **Preventions — the transfer signal.** When a lesson banked from one failure stops a *different* failure, append `{"subject":"<the banked lesson>","predicate":"prevention","object":"<the failure it stopped, and where>", …}`. Distinct from `drift-pattern-good-direction`, which records a good move; this records **transfer**, which is the actual signature of learning and was previously uncapturable by the schema. Wake §b.2 surfaces one. <!-- 2026-08-02: FIX lane, REVIEWED-85 first batch; proposed 2026-07-29 (steward-raised). -->

- **A fact that changed.** Append the new triple; to retire a superseded fact, append a matching triple with `valid_to` set to today (a soft-invalidate — the JSONL is append-only, like the logchain, so history stays legible rather than mutated in place).
- **A new recurring entity** (person, project, thread) worth a foothold — append the relationship.

Stamp `valid_from`/`extracted_at` from `date` (the wrap runs interactively). Most of the session is already captured in the session file + feedback memories; append only what a future wake should be able to *grep* — don't transcribe the whole session here. The JSONL rides to the remote via §6.5's `claude/` add.

### 6. Check for loose ends

Run these checks and report results:

**Uncommitted work:**
```bash
git status --short
```
in each active repo. Report any modified/untracked files.

**Unpushed commits:**
```bash
git log --oneline @{upstream}..HEAD
```
in each active repo. Report any commits not yet pushed.

**PENDING.md** — flag any items that need steward attention before next session.

### 6.5. Commit + push session state (dotfiles)

`~/dotfiles` is the carrier of governance state and session memory — `~/PENDING.md`, `~/REVIEWED.md`, `~/CLAUDE.md`, the memory directory, and these skills all symlink into it. Un-pushed dotfiles is single-disk state; push at wrap so session state is off-disk the moment it exists, rather than waiting for the steward's next `sysupdate` sweep.

```bash
cd ~/dotfiles && git add PENDING.md REVIEWED.md CLAUDE.md claude/ \
  && git commit -m "session YYYY-MM-DD: <short descriptor of what the session filed>" \
  && git push
```

- **Scoped add only — never `git add .` or `-A`.** The steward's repo may carry unrelated in-progress changes (Brewfile, shell config, scripts); those belong to `sysupdate`'s sweep, not the wrap.
- **Session-stamped message** naming what the session filed (e.g. `session 2026-06-05: REVIEWED-28/29 + chamber-library LFS retirement memory`) — the dotfiles log doubles as a legible session record.
- **Constitutional boundary, stated plainly:** committing and pushing is *preservation*, not modification. `CLAUDE.md`/`REVIEWED.md` content remains steward-authored; the executor never edits them — it only carries them off-disk. If staging shows changes to those files that the steward did not make this session, stop and surface before committing.
- **If the push fails, surface loudly in §8** — do not skip silently. The wake-up §2.c dotfiles check is the backstop, not the primary.
- Nothing to commit is a valid outcome; report it in §8 as such.

### 7. Vault sync

Sync the thinking mirror to Obsidian vault:

- Source: `~/_Dev/CapableMind-AI/docs/thinking/David/`
- Destination: `~/Library/Mobile Documents/iCloud~md~obsidian/Documents/David, root-and-branch/08. Notes/CapableMind/thinking-mirror/`

Use rsync to copy new/modified files, preserving directory structure. Report what was synced.

If the destination doesn't exist or the iCloud path isn't accessible, skip silently and note it.

### 8. Output

Produce a brief summary for the steward:

```
## Wrap-up — [date]

### Future — what pulls
**Pulling thread:** [the singular concern]
**Actionable resumption point:** [where things concretely stand + the candidate first move toward the thread, as of wrap — to confirm or revise against what changed. The thread is the direction; this is the first step.]
**Question we're leaving open:** [the literal question for next-Claude]
**Pause statement:** [explicit acknowledgment that the work is being paused; what is wanted-to-find-still-pulling on return. The ligature is laid at departure, not discovered at return — this field is constitutive, not optional.]

### Past — what moved, and why
**What happened:** [the session's substantive moves, each with the reason it was taken — not a task list. What a reader needs to reconstruct the session's shape.]
**What held:** [which disciplines, gates or predictions were applied and did their work. A practice that is never observed working is not known to work.]
**What was corrected:** [claims retracted, framings the steward or jurist overturned, instruments found unsound — or "none". Corrections are the session's most perishable output.]

### Present — how it stands
**The mood:** [the Stimmung — what this session felt like from inside, and what that signals. Carried because confidence and unease both travel across the pause.]
**Confidence to recalibrate:** [what is being claimed at what confidence, and specifically what was verified versus inherited.]
**Instruments:** [N run · M carrying a control **written before the instrument first executed** · K that duplicated something already banked (ladder entry, skill, prior session's script) — name the K. Count forward as you go; the retrospective count is the one that is easy to get right and the prospective one is the one that would have helped. **The K column is the load-bearing half:** a one-shot measurement is proportionate to a question asked once and is not a directive violation — the counterfactual for a one-shot script is almost never a durable instrument, it is an *assertion*. What violates the directive is re-writing an instrument that is already banked. Rule of three: an instrument reached for a third time stops being one-shot and goes to the ladder.] <!-- 2026-08-08: FIX lane. Changes what the wrap RECORDS (an output field — the lane's own stated example), not what the executor may do nor what a governed artifact asserts. Earned: the prospective-control count worked on 2026-08-07-night as a one-off literal question, then rotated out at the next wrap; making it a standing field is what converts a hand-run count into a series. The K column was the steward's question ("do we need so many single-use items?") turned into something measurable rather than left as a worry — that same session wrote a link-resolution canary inline that was already in /wake-up AND on the ladder. -->
**Decisions deferred (and why):** [the negative space — what was chosen-not-to-do this session, and the reason. Absent this field, the unborn session cannot know the scope of what was held back.]
**Skill harvest:** [skill create / patch / retire proposals surfaced this session (§1.6), each as a proposal for steward authorization — or "none". Never an autonomous skill edit.]

### Restoration material
**Session captured:** [memory file path]
**KG appended:** [count of lines appended to knowledge-graph.jsonl, or "none"]
**Uncommitted work:** [list or "none"]
**Unpushed commits:** [list or "none"]
**Dotfiles pushed:** [commit hash + pushed / nothing to commit / FAILED — reason, surfaced]
**PENDING items:** [count needing attention]
**Vault synced:** [count of files, or "skipped"]

[Any warnings or things to address before closing]
```

The three tenses mirror the session memory file (§2), so the output and the durable record no longer disagree about what a session consists of. **Future leads** — inverting the memory file's narrative order — because the thread and the question are what *waking* inherits; the steward reads this at departure, but it is written for arrival.

A template that drops a tense under compression is itself an instance of the failure mode the Directive elaboration names. <!-- PENDING-S9, jurist Q2 affirmed + Q3 elevated to constitutive 2026-05-18; implemented 2026-08-03 once Q4 landed. Past and Present were wholly absent; Future was already well-specified. -->

## Important constraints

- **Write for the next session, not this one.** The steward has full context right now. The person who needs this is future-Claude with an empty context window.
- **Rationale over facts.** "We decided X" is less useful than "We decided X because Y, and Z was the alternative we rejected."
- **Be honest about incompleteness.** If work is half-done, say so. Don't round up.
- **Don't fabricate.** If you're unsure what happened earlier in the session, say so rather than guessing.
- **Pulling thread is singular.** If you cannot name one, that means the session lacked a thread — name *that* honestly. ("This session was diagnostic-only; no thread to carry forward except the question of what to do next.")
- **The literal question for next-Claude is required.** Even if it's small. *"Did Seb push anything overnight?"* counts. The discipline of leaving a question (not just a task) is what makes the wake feel like resumption rather than briefing.
- **Don't skip Thistleweld observations** if the companion was active. These have caught real bugs (allSettled swallowing, Levenshtein NONE, resource monitor feedback loop).
- **Don't skip the Symmetria ledger merge** if active. The returns and recalibrations are the practice's actual evidence; losing them defeats the practice.
- **Skill harvest is propose-by-default, with one narrow FIX lane (§1.6).** Surface it for steward authorization unless it clears the classification test *and* the hard floor — in which case apply it and discharge all three instruments. When in doubt, propose: the lane is provisional until the steward–jurist check-in, and the loop is load-bearing here too. "Nothing to harvest" is a valid outcome; do not manufacture changes to satisfy the step. <!-- 2026-08-02: reconciled with the §1.6 FIX lane (REVIEWED-85); this line previously stated the blanket rule the ruling narrowed, and would otherwise have left two live versions. -->

- **The FIX lane is not a licence to skip the report.** A change applied without its index line is worse than the same change proposed, because it leaves no record for the check-in to read. If you cannot discharge all three instruments, it is a `[PROPOSAL]`.