Sync

sync brings every derived view current at once. Heavier than briefing pulse, lighter than running each skill by hand. Run it when you have been away, when you want to start fresh, or when something feels stale.

Why the order matters

Compile feeds the wiki state that lint operates on. Lint's auto-fix touches the same articles the dashboard's link rewriter needs clean. Flywheel runs after the wiki is clean, so it reads a current memory index and the day's compiled summaries, and before scan and dashboard refresh, so both views reflect post-flywheel task state. Out of order, you re-reconcile.

When compile processed anything, it also refreshes the memory index's Open Questions: the gaps and contradictions loaded into every session. Without that pass, a gap you filled weeks ago keeps getting flagged.

What flywheel does

Flywheel is a cross-project work session framed by your north-star roadmap. Inside sync it does five things:

• Catches up on the sessions since its last run. It reads every daily summary written since its previous report, adds one thread note to each task those sessions moved, and lists up to five work streams no task tracks, with an offer to file one.
• Sets stalled tasks aside. A task that was already overdue at the last run and hasn't been touched since gets a decision instead of another "still unchanged" line. Sync asks it at the end.
• Advances, updates and closes the rest, and flips a roadmap milestone's status only on evidence from this run.
• Archives closed tasks into tasks/archive/, every run.
• Saves a flywheel report in reports/briefings/, every run, so the next run knows where to start and the morning brief can pick up the trail.

What needs attention

After the flywheel, sync scans the board for overdue work, work due in the next 14 days, stale tasks, and blockers sitting under higher-priority tasks. It checks whether the plugin has a pending upgrade, whether a planning or review cadence or a helpdesk routine on a queue profile's schedule has come due, and whether the home has a north-star roadmap yet. With the GitHub pack set up, it counts what GitHub is waiting on in the configured repo, from numbers alone, never a comment's text: replies owed (and how many are new since your last GitHub sweep), re-reviews, reviews you started and left pending, and your PRs that conflict with main, as a GitHub line under Attention. When any are owed, the closing interview offers the sweep. With a helpdesk configured, it counts each support queue's last 24 hours (by status and tag, unassigned, newly opened) as a 🎫 Support line per queue, from numbers alone, never ticket text. With the Slack pack, a 🔔 Slack block lists the replies you owe, the threads in your shared channels where someone outside the workspace has waited an hour or more, and channels you've joined that the channel map doesn't list, from who, where and how long, never message text; new channels become an offer to sort them into the map. A queue whose profile names an App Store app adds the day's reviews by star, and new reviews since the last complete read become an offer to run helpdesk reviews. A task handed off to a GitHub issue is checked against its repo's open issues, and once the issue has closed the closing interview offers to close the task (done when completed, cancelled when not planned); sync never closes it itself, and a repo it can't read says so rather than reporting the issue still open. It also takes a quick inventory of the brain and prints it as a 🧹 Brain line: stale and dormant tasks, quiet projects, memory lines gone false, outdated articles, broken pins (named, since the dashboard drops them silently), and surfaces unchanged for 60 days. Nothing is asked from that line; it keeps decay visible between monthly reviews.

The closing interview

Only when sync surfaced something to act on (an overdue item, a stalled task, a due cadence skill, a pending upgrade, a concrete next move) does it end with questions. On a clean bill, the status block is the end.

1. Self-review first, on its own, when the monthly review is due: run it now, tomorrow, or skip this month. Skips are counted. See Self-evolution.
2. One question per stalled task: push it a week, park it (lower priority and no date, so it stops coming back), mark it blocked with a reason, or cancel it.
3. What to tackle next. Pick one or several, then act on them now, in order, or queue each as a task. While the home has no roadmap.html, building one is always the first option; it stands in for a due goals year when this year's goals aren't set, since the build runs that interview first. See Daily rhythm.

Progress and reminders

In Claude Code, a band above the prompt shows the run as it goes: the step it is on out of thirteen, the elapsed time (with the average run once it finishes), and counters for what it is clearing. The closing report quotes counted numbers from the same source rather than adding them up itself. See Mods.

Between runs, the sync notice does the reminding. It appears in the session banner three days after the last sync, with what is waiting to compile. At five days, in the Claude Code terminal, it moves above the prompt with a button that runs sync; at eight it also raises a toast at session start. Sync stamps the time when it refreshes the dashboards, and that stamp resets the notice.

Saving a snapshot

When the home has history turned on, sync saves twice. It starts by saving the home as it stands, in one commit, before anything in the run writes to it: that holds whatever changed since the last sync, and it is the point to go back to if the run goes wrong. It ends by saving what the run changed, as a few ordered commits (knowledge, projects, reports, state) rather than one lump, so the run reads as a clean diff of its own. It only saves a history that stays on this computer: a home connected to a remote, not on its main line, or mid-merge is skipped with a one-line note, and so is a history whose setup has not finished its first snapshot.

Chaining a briefing

sync morning or sync evening runs the matching briefing after the maintenance pass. With no argument, sync picks: a forgotten morning brief still runs in the afternoon instead of silently becoming an evening one.

The session radar runs just before the briefing, so the briefing's first moves include the decisions your sessions are waiting on. The status block above it stays a full log of the run; the briefing is the part to read.

The status block reads from artifacts on disk (projects/TASKS.md, .state/lint.md, knowledge/memory/index.md), not from per-tool return values, so the summary reflects what actually landed.