/context-reconstruct

name: context-reconstruct
description: Re-anchor on the durable record (current-track, live owner thread, pending-questions, relay, build_log) before acting on anything that depends on earlier context. Read, do not recall.

context-reconstruct

**Goal:** never act on lost/eroded memory of the ongoing work. The agent can be interrupted, compacted, or run dozens of interleaved cron passes and still pick up exactly where the thread left off — *without the owner re-reminding it*.

**Why a skill, not a script:** a hardcoded bundler (fixed N reads, one channel, fixed depth) is rigid — and easy to *skip* (narrate "re-anchor" then assert from memory anyway). The fix isn't a rigid script; it's flexible judgment + practice. This file is living — improve it whenever a reconstruction misses.

The one rule

**Before interpreting or acting on anything that depends on earlier context, READ the durable record. Don't recall — read.** A "re-anchor" you claim but don't actually read is the failure.

What to read — judgment, fit to the moment (not a checklist to run blindly)

**Read the current-track record FIRST** — `<workspace>/hosts/<hostname>/current-track.md` (this skill owns it; see "Maintain" below). **It is a bounded head, not the whole history.** Every pass pays this read, so the file is rotated: entries older than the newest ~32 KB live in `current-track-archive.md` beside it (`scripts/current-track-rotate.py`, run when health-check's `context-read-budget` probe warns; everything rotation removes from the head is appended to the archive, in the order entries leave — an interrupted rotation repeats a batch there rather than losing it). Rotation replaces the file, so append entries through `scripts/current-track-write.py append` (entry on stdin) — it shares rotation's lock in `src/current_track.py`, and an entry can never land between rotation's read and its replace. Read the head; open the archive only for a specific older referent. An entry that other tools read as live state — an owner hold, a `hands off`, an `in force until` — is kept in the head at any age, because a hold that ages out reads as *not held* to every consumer that greps this file. Resolve `<hostname>` with `bash scripts/sutando-config.sh host-label`, the same way `pending-questions.md` does. **Legacy fallback:** if that file is absent but `<workspace>/state/current-track.md` exists, read the legacy path and migrate it to the per-host path on the next write — the flat path was shared across hosts and is being retired (#2567). It's the fast anchor: the **current main-track goal**, the active sub-task, and the live open decisions. This is what's missing when "continue your main track" gets guessed — the goal must be a pinned record, not inferred from luck.

Then, as the situation needs (pick what's *relevant*; skip what isn't):

• **The live thread** — the channel(s) the owner is actually active on: `python3 src/discord-read.py <channel_id> --serving <task channel_id> --limit 50` when serving a task (one page; the reader's default is ten — continue older with `--until <ISO time or message id>` until the message stands on its own, and say where the read ended if you stop short; the contextNotFrom gate runs before the fetch), or `--operator` on autonomous passes with no serving context (Discord), telegram task `[Replying to…]` quotes (Telegram has no history fetch). Go **as deep as the thread needs** with `--until <id|iso>` — not a fixed message count. If unsure which channel is live, check the most recent task's `channel_id` / `state/last-owner-activity.json`.
• **Open decisions** — per-host `pending-questions.md`.
• **Recent judgment/decisions** — latest `relay/relay-*.md`.
• **What's built / next** — `build_log.md` tail.
• **Deep history** (older than the channel can cheaply reach) — the session transcript JSONL.

Effective > exhaustive: read enough to make *this* message/decision stand on its own, then stop.

Maintain the current-track record (the skill owns it)

The skill both **uses** and **maintains** `<workspace>/hosts/<hostname>/current-track.md` (NOT the legacy flat `state/current-track.md` — writing there again re-creates the cross-host delivery of one host's anchor onto another at the same local path; see the 2026-08-03 practice-log entry below, which retracts the "clobber"/data-loss framing this line used to carry) — the owner doesn't dictate its content and the agent doesn't invent it from memory; it's **derived from the reconstruction**:

• **Create it if absent** (first run, through `scripts/current-track-write.py replace <file>` with the new head on stdin — it takes rotation's lock): write the current main-track goal + active sub-task + key open decisions, derived from what the durable record (thread / build_log / pending-questions / relevant project memory) actually shows.
• **Update it when the track moves** — after a reconstruction reveals the goal/sub-task/decisions changed (owner redirected, a thing shipped, a decision resolved), rewrite it — through the same `current-track-write.py replace`, never a bare `cat >`; a rewrite outside the lock can be erased by a rotation that reports success. **A rewrite archives nothing**: an entry you drop from the head is gone, so condense entries rather than deleting ones a later pass may need. Keep it short (a pinned summary, not a log).
• Next reconstruction reads it first → "what's the main track" is never a guess again.

Then

Compare what you read against what you *think* is true. **Where they differ, trust the record.** If the current track is a still-open owner thread, continue THAT.

When to reconstruct

When the thing in front of you isn't self-contained — terse ("y", "no", "?", a pronoun), a reply, refers to something not stated, or you're resuming after a gap/compaction. Keyed on the *message/situation*, not on felt confidence (felt confidence is what fails — the agent is confidently wrong).

Practice log (improve this skill here)

• v0