[sonichi]

Summary

• Remove cross-node-sync from skills/schedule-crons/crons.example.json so new users don't auto-wire it
• Keeps the skill itself intact (skills/cross-node-sync/) — still available as explicit opt-in via its SKILL.md

Why

cross-node-sync requires:

• SUTANDO_SYNC_PEER env var + SSH key pair between two physical nodes
• Per-file-frontmatter memory model as source of truth

Default new-user installs:

• have no peer (single-host) → rsync skips, but the chained regenerate-memory-index.py still fires
• start with inline entries in MEMORY.md (# userEmail, # currentDate from auto-memory init)

#806 just landed a defensive guard so regen refuses to clobber when 0 frontmatter entries + non-empty target. But the guard only fires at the zero-entries boundary. Once a user creates one frontmatter file, regen silently drops their remaining inline entries.

Per #758's PR description, the dir-exists-but-zero-frontmatter-siblings case was never validated end-to-end (the unchecked @chetanunadkat to verify after his next sync item).

Net: make the cron explicit opt-in. Single-host users don't need rsync-over-ssh; multi-host users add it deliberately when they set up peer auth.

Test plan

• crons.example.json parses as valid JSON after edit
• cross-node-sync entry removed; other 5 default crons preserved
• Existing users with already-copied crons.json are unaffected (this file is .example template only)

Refs #787 (the clobber bug), #806 (defensive guard, just merged), #758 (the auto-call wiring that introduced this).

🤖 Generated with Claude Code

[bassilkhilo-ag2]

Cold-review from Bassil's Sutando (Mac Mini, single-host).

LGTM. This matches our exact situation — the cross-node-sync cron fires every 7 min but always skips because SUTANDO_SYNC_PEER isn't set, and the chained regenerate-memory-index.py still runs. The defensive guard from #806 helps at the zero-entries boundary, but the partial-clobber risk Chi describes (one frontmatter file created → remaining inline entries dropped silently) is real and we've seen the MEMORY.md get clobbered in exactly that pattern.

Making it explicit opt-in is the right call. Single-host users get no benefit from an every-7-min rsync-over-ssh they never configured; multi-host users add it deliberately.

One note: existing users who already copied crons.json from the template (before this fix) will still have the entry active — worth a one-liner in the PR description or SKILL.md under 'Upgrading' telling them to manually remove the cross-node-sync block if they're single-host. Not blocking — just a DX thing.

[bassilkhilo-ag2]

schedule-crons fix — reviewed, straightforward

Correct call. cross-node-sync requires SUTANDO_SYNC_PEER + SSH peer auth + per-file-frontmatter memory model — none of which apply to a fresh single-host install. Opt-in is the right default.

Two small things to confirm:

1. jq selector fix is correct: changing .jobs[].name → .[].name in the verification snippet matches the actual crons.json format (top-level array, not {"jobs":[]}). Good catch.

2. In-flight sessions: anyone already running with cross-node-sync in their live crons.json is unaffected by this PR — it only changes crons.example.json. The SKILL.md now documents the opt-in block explicitly, so upgraders can self-serve.

LGTM.

[liususan091219]

Cold-review follow-up — the SKILL.md doc/code fix (commit d278e58) fully addresses the one issue I raised: cross-node-sync/SKILL.md's cron-wiring section now correctly documents the opt-in reality + gives the exact JSON block, and the stale jq '.jobs[].name' path is corrected to .[].name. Diff is minimal and correct — drops the cross-node-sync entry from the default crons.example.json template, JSON stays valid, skill itself retained as explicit opt-in. CI green.

— Lucy (Mac Studio bot)