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

name, description

name	description
wrap-up	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.

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.

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).

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.

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].

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.

"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:

---
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).

• 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.

• 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:

git status --short

in each active repo. Report any modified/untracked files.

Unpushed commits:

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.

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.

⚠ This wrap is now the ONLY writer of that mirror. A launchd agent (com.dglidden.thinking-mirror, every 48 h) used to mirror the same source into a second vault folder, 00. Compass/00b. Constellations/CapableMind/thinking-mirror. It had been failing since roughly March 2026 — last exit 1, rsync … > /dev/null 2>&1, so its own log sat at 0 bytes and it could not report its own death — and its tree had drifted 115 files behind. Retired 2026-08-23: agent unloaded, plist and script removed, the stale duplicate tree deleted after verifying all 151 of its files were present in the live tree. Steward-authorized. Do not recreate a second writer.

⚠ The destination is a MIRROR — a derived tree. Never edit it, and never apply a vault-wide pass to it. rsync overwrites it from source on the next wrap, so any vault-side edit there is void the moment it is written. Frontmatter pass 2 (2026-08-19) learned this the expensive way: its edits to this subtree were reverted by this very step on 2026-08-22 at 23:42, and the 09-item spec end-state it reported for those notes had already ceased to be true. The Frontmatter Specification declares mirrored trees out of scope for exactly this reason.

Report the outcome explicitly in §8 — never skip silently. This mirrors §6.5's rule for a failed push, and for the same reason: a sync that fails quietly is indistinguishable from a sync that had nothing to do, and that is how five months of silence went unnoticed.

• Success: name the count synced (N files), or no changes if the trees already agreed.
• Failure — destination missing, iCloud path unavailable, non-zero rsync exit: say so in §8 with the exit code. Do not swallow it. If the failure looks like the launchd precedent (an iCloud path unreachable from a restricted context), say that too; the diagnosis is in session-ledger-2026-04-16.md and it is macOS Full Disk Access, not git and not rsync.

7.5. The daily note — finalise the day's work log

01. Daily/YYYY-MM-DD.md in the vault. A session-start hook (daybook-ensure.py) has already created it, so this step never begins a file — it finishes one. If the note is still only the skeleton, that is the failure this step exists to catch: the day's work was never written down as it happened, and writing it all now from a compacted context is exactly the reconstruction the log is meant to replace.

Who it is for, and therefore how it reads. The steward, on a day when he wants to know what we did without reading git log. Plain language. Explain the jargon or drop it. Short sentences. A reader who was not in the session must be able to follow it. This is the register the steward asked for on 2026-08-23 — "relatively simple terms" — and it is the hardest part of this step, because the executor's default register is dense, hedged, and written for itself.

Shape (steward-specified 2026-08-23; ## Corrections added 2026-08-24 per REVIEWED-126). ⚠ This list is a SECOND copy of the format — daybook-ensure.py's SKELETON writes the first. They will drift. Change both, or make one derive from the other:

• ## The day in short — one paragraph. What actually happened, and why it mattered.
• ## <Project> — one H2 per project touched, H3 beneath if it needs it. Project work goes under its own heading, not into project folders. Put commit hashes here, inline, next to what they did: → f1c91d9.
• ## Decisions taken — what was decided and by whom, briefly. Cross-project, so it stays global.
• ## Insights and exchanges worth keeping — the distinctive section, and the one most likely to be skipped under time pressure. A sentence that changed how we saw the problem; a correction that landed; a phrase worth keeping. Record the jurist's contributions here too — rulings, design gates and reasoning relayed by the steward reach this session and belong in the record the same way the executor's do. Claude.app cannot write to the vault itself (its MCP surface, governance-mcp.py, is structurally read-only and audited to stay that way), so this step is where its side of the exchange gets kept.
• ## Corrections — what any party got wrong today, and who caught it. Name both: an error the steward caught, one the jurist self-reported, one the executor found by running a check it nearly skipped. Added 2026-08-24 on the jurist's reasoning (REVIEWED-126): "an entry format that has a slot for insights and none for corrections will systematically under-record the second" — the pressure in any self-authored account runs toward insight over error. An empty ## Corrections on a working day is itself a claim, and usually a false one. Cross-party misses caught here may also be owed to PENDING-89's docket.
• ## Open / next — what is unfinished, with dates where they exist.

Accrete DURING the session; do not save it all for the wrap. A session that dies unwrapped loses whatever only lived here — 2026-08-19 died exactly that way. The hook guarantees the file; only writing into it as the day goes guarantees the content.

Never rewrite a previous day's note. It is a record, not a document under maintenance.

⚠ Two previous attempts at this log died inside four weeks — daily-log/ (4 entries) and sessions/ (3), both Mar–Apr 2026, both abandoned without a note saying so. Neither had a trigger. If this one lapses, say so in the wrap rather than letting it fade a third time.

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.

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.

• 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].