Session log — Automatic publishing of daily session logs

InternalView platform →
← All session logs

Session log — Automatic publishing of daily session logs

1 May 2026 · Hasmukh with Claude · a small piece of plumbing so the journal keeps itself. From this session onwards, every working day ends with a session log being written, and the next morning’s session begins with that log being published as a permanent page on documentation.mobilearn.africa, with no prompting needed from Hasmukh.

What happened, in order

  1. The brief
  2. Two checks, not one
  3. Local file first, docs page second
  4. How a log is “remembered” as published
  5. Going forward
Brief

1. The brief

HasmukhI want every session log to be written at the end of the session and published the next morning, automatically. I should not have to remember.

The journal had been working for a few days but the workflow leaned on Hasmukh remembering two things: to ask for a log to be written before the session ended, and to ask for the previous day’s log to be published the next time we sat down. Both bits of remembering were optional friction, and optional friction is the kind that goes missing on a busy day.

Step 1

2. Two checks, not one

Two small automatic checks now sit either side of every session.

The start-of-session check looks for any previous-day log that has not yet been published. If it finds one, it asks Claude to publish it as a permanent page on the documentation site, including a mention on the /overview/ index in the same run. If there is nothing to publish, it stays silent. It runs at the start of every session, not at midnight, because the laptop is rarely on overnight.

The end-of-session check looks at today’s logs in the local journal folder. If today does not yet have a log file, the first attempt to close the session is blocked with a polite message asking for one to be written before stopping. After a log is in place, subsequent stops in the same session pass silently.

OutcomeBoth halves of the rhythm are enforced by the harness, not by memory. The morning publish runs end-to-end without prompting, and a session cannot end empty.
Step 2

3. Local file first, docs page second

The convention is deliberately one-way: the local Markdown file is the source of truth, and the docs page is the polished, longer-form retelling. Nothing gets auto-generated on the documentation site without a real local log behind it. That keeps the docs site honest, and it means a half-built page can never appear out of nowhere.

Step 3

4. How a log is “remembered” as published

Each published log is marked with a small empty file next to the original, named <filename>.md.published. The morning check uses the presence or absence of that marker to decide whether to queue a log for publication. It is the simplest reliable signal: no extra database table, no separate state file, just “is the marker there?”

Three earlier logs (27, 28 and 29 April) were already live on the docs site by hand from previous sessions, so their markers were created retroactively to keep them out of the queue.

Going forward

5. Going forward

The next two morning sessions will be the proof points: if both run end-to-end with no manual nudge, the workflow is doing its job. The 30 April log itself is missing because no file was ever created that day, and it can be reconstructed later from memory or git history if it turns out to matter.