Weekly Study Publisher (cron 30e4401322b9) — audit

Verdict: ✅ the weekly studies ARE published and live; ⛔ the cron's copy leg is a permanent silent no-op that has been reporting "ok" for 3 fires; ⚠️ nothing is generating studies, so the "weekly" cadence has been dead for 9 days.

1. The job is real, enabled, and green

2. ⛔ Both endpoints of the copy leg are dead

study_publisher.py reads and writes paths that no longer exist:

Evidence from the job's own output directory — the transition is visible:

2026-10-02  [Sync] Found 3 Weekly Studies on LAB
            [Sync] ✓ 2026-08-30 / 2026-09-06 / 2026-09-17 synced
            [Sync] Found 1 Monthly Studies on LAB   → ✓ 2026-09-monthly-study
            [Study Publisher] ✓ All studies synced
2026-10-09  [Sync] No Weekly Studies found on LAB
            [Sync] No Monthly Studies found on LAB
            [Study Publisher] ✓ All studies synced        exit 0
2026-10-16  (identical no-op)                             exit 0

A live re-run today reproduces it: exit 0, "✓ All studies synced", zero files copied. This is the exact failure mode the card warned about — a copy leg whose source is empty is indistinguishable from a working one. Worse, the false "✓ All studies synced" is delivered to Young's Telegram, so the false success is a signal he receives.

3. ✅ The studies are published anyway — by the canonical lane

The real publisher is the docs lane, and it works:

LAB vault /home/lab/SolOS/vault/Pulse/weekly-study/
  → forge v5 (build_site.py; keeps includes "weekly-study")
  → solos-docs git repo content/Pulse/weekly-study/
  → git push → GitHub youngframeworks/solos-docs
  → prod solos-docs-pull.timer (10 min) → git reset --hard → nuxi build → restart
  → docs.youngle.au/pulse/weekly-study/<slug>   (gated: 302 → auth.youngle.au)

Verified, not assumed:

• all 5 studies byte-identical LAB↔prod after forge's transform (forge_render mirrors conv(): frontmatter strip + markup normalise + .strip()+"\n")
• all 5 return HTTP 200 from the docs service (127.0.0.1:8091)
• the forge landing lists all 5; solos-docs-publish.timer and solos-docs-pull.timer both active (last prod pull 2026-10-21 15:41, ok)

4. ⛔ Do NOT "fix" the copy leg — it would be destroyed

The obvious repair (repoint the script at prod docs-site/content/Pulse/weekly-study/) is actively wrong. docs-publish.sh mirrors the repo tree with:

rsync -a --delete /tmp/site_build/Pulse/ "$REPO/content/Pulse/"

Reproduced locally: a file written by a second writer into that destination is deleted on the next publish cycle (every ~5–10 min). So a repaired copy leg would write files, print "✓ synced", and have them removed minutes later — a new and more confusing silent failure. The forge lane is the single legitimate writer.

Correct remediation: retire the copy leg; do not re-point it.

5. ⚠️ The real gap is upstream: nothing generates studies

• No cron on the laptop (tam/eva/eve/default) or LAB (echo/min/mira/nova/sol) creates weekly or monthly study files.
• Newest study is dated 2026-10-12, i.e. 9 days old; Friday 2026-10-16 fired with nothing new, and Friday 2026-10-23 will too unless a study is authored.
• So "Weekly Study Publisher" is currently a publisher of nothing. The copy-leg bug masked this: the job looked green every week regardless.

6. ⚠️ Content regression: 4 legacy studies are 404

The 4 studies the Oct-2 run synced (3 weekly + 1 monthly) are not on the site:

404  /pulse/weekly-study/2026-08-30-weekly-study
404  /pulse/weekly-study/2026-09-06-weekly-study
404  /pulse/weekly-study/2026-09-17-weekly-study
     (and no monthly-study section at all)

They survive only in the LAB archive Docs/Fleet/05-archive/reference-tree/SolOS Legacy/solos/{Weekly,Monthly} Studies/ — and forge v5 excludes 05-archive entirely, so they cannot publish from there. Whether they should be restored is an owner decision, not a bug to fix blind.

7. Card-body inaccuracies (corrected)

• "Publishes the weekly study to Pulse via pulse_publish.py" — false. study_publisher.py imports only subprocess/sys/os/datetime; it never calls pulse_publish.py, which is the brief publisher (--date/--brief/--all-since).
• "Publishes to Pulse" — the studies land on the gated docs site (docs.youngle.au, auth-gated by design). The public site (pulse.youngle.au) carries zero studies: its /api/articles lists 13 articles, none a study. Whether studies should be public is Young's call.

8. The fix artifact

/home/eva/.hermes/profiles/tam/scripts/study_publish_verify.py — a read-only verifier that replaces the copy leg's false success with a real signal:

• every LAB study must exist on prod, byte-identical after forge_render, and return HTTP 200
• source gone / source empty / not published / drift / not live → exit 1 with the precise reason (the cron then delivers a real alert)
• stale-but-published → exit 0 with a one-line status (working lane, no new content) — a read-back, not a false alarm
• silent on a fully fresh success (watchdog convention)

Proof: --selftest covers 5 outcomes (5/5 pass) and three live fault injections on the real hosts each fail loudly — including a re-creation of the original bug (STUDY_LAB_VAULT=/home/lab/.solos/docs/vault/solos → SOURCE GONE, exit 1) where the old script said "✓ All studies synced", exit 0.

Install (owner lane — the job is eva's cron): copy to /home/eva/.hermes/profiles/eva/scripts/study_publish_verify.py, then point both study jobs at it. Both jobs share study_publisher.py, so the monthly card (t_7085cfca) is fixed by the same change.

Open decisions (not mine to make)

1. Retire the copy leg vs. repoint to the verifier — recommend retire/replace; re-pointing the copy is the one option ruled out by §4.
2. Should the 4 orphaned legacy studies be restored to the live site?
3. Should studies appear on the public pulse.youngle.au, or stay docs-gated?
4. Who owns producing the weekly study, so the Friday cadence is real?

🎯 Tam's Read

The publisher is green because it does nothing — the studies publish fine through the forge lane, so the only thing this cron can still contribute is an honest check; re-pointing its copy leg would get its files deleted by rsync --delete, and the actual gap is that no study has been written in 9 days.