context-reconstruct

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). 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> when serving a task (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): 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. 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