Skip to content
C.W.K.
Stream
Lesson 08 of 08 · published

The Invocation Freezes the Window

~14 min · seams, snapshots, identity, evolution

Level 0Cold Workshop
0 XP0/51 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

A Request With No Screen

Earlier in this track the calling side shrank to a link: a button that opens the workshop's compose screen with a pointer already in it. On 2026-10-06, the day the channel's owner left for Spain, the seam was tested from a direction nobody had designed for. He named a new workflow, the mobile pipeline, and the whole interface is a sentence. He says it in a chat on his phone, in whichever family app he happens to be using, and he does not open the workshop, type a command, or know which conversations it should draw on. A day on the road may hold a dozen short talks across three apps, and the story worth filming is scattered through all of them.

So the brain session that hears the sentence does the queueing on his behalf. Its prompt and a short routing skill send it to one canonical procedure document that lives in the workshop, and from there it uses the ordinary queue: discover, delegate, take, freeze, edit, ask for approval. The brain learned how to route a request, and nothing about scenes, takes, or timing. The first lesson of this track forbade the caller from learning video; the prohibition was aimed at the side, not at a transport, so a chat sentence fits inside it just as a link did.

Freeze the Moment, Not the Calendar

The first decision the procedure makes is the one that matters most: the timestamp of the request is the cutoff, and it is frozen before any research or generation starts. "Make an episode of what we did" means up to the moment it was said. Conversation that continues while the episode is being made does not leak in, because the producer is reading material that may still be growing in the same thread.

The lower bound is recovered from context — the start of the current trip or story — and two tempting shortcuts are ruled out by name. The last upload time is not a watermark, because an older topic nobody has used yet would fall below it and be lost. And a calendar day is not an editorial boundary: a long day can hold several episodes, one story can cross midnight, and the date in the episode's name is its intended publication day, not a limit on its sources. "Up to now" freezes the cutoff; it does not oblige the producer to use every topic before it, and unselected material stays available for the next request.

Identity, Not Text

Once the window is frozen, the workshop takes a snapshot of it, and the snapshot is built on message identity rather than on what messages say. The same conversation can be mirrored between apps and stores; matching text is never treated as the same message, and two mirrors that disagree stop the intake rather than being merged by guesswork. Each message is windowed on its own, so a reply that finished after the cutoff is judged by its own time. The snapshot binds the material and the discovery record by hash, and running the same request again resumes it — it never quietly refreshes a frozen window.

Identity also carries the history of what has already been filmed. The discovery step reads which exact messages earlier productions kept, and those start excluded; reusing one needs a written reason, such as a recap or a subtopic the earlier cut left out. Translated editions do not count as new use of the source. And because one long conversation can hold several requests while earlier episodes are still waiting for approval, each delegation names the specific message that invoked it, so two requests from the same thread can coexist without one swallowing the other.

What the Window Lets In, and What It Never Does

The window admits public text only: the same public transcript the conversation series has used since its redaction rule, with private conversations, skipped messages, and redacted turns left out, and no withheld name reconstructed from memory. It strips every audio handle. In this pipeline all speech is synthesized — the owner's lines in his cloned voice, edited from his own words with typing and dictation errors fixed and repetition condensed, every changed line carrying a recorded reason and no quote invented, and his wife's words, which reach the material only inside his messages, split out and read in a voice designed from a description rather than cloned from a recording. Every synthesized voice is disclosed. A photo or clip supplied after the request is recorded as an asset with its arrival time; new dialogue after the cutoff needs a new window. And the owner's approval of the finished script binds the exact edit he read, so a later change to the dialogue needs his approval again.

A request names a moment; freeze it before you look. When material keeps arriving while you work on it, the request's own timestamp is the only boundary nobody has to argue about later. Snapshot by identity, bind the snapshot by hash, and make a rerun resume rather than refresh, so the thing being edited cannot change under the editor.

Code

The three motions, as the procedure runs them·bash
# 1. discover: read every candidate in the window, spend nothing
beacon mobile inventory \
  --since  '<story start, with timezone>' \
  --cutoff '<the moment the request was said>' \
  --out /tmp/mobile-discovery.json

# 2. freeze: snapshot public text per message, never recordings
beacon mobile snapshot --delegation <N> \
  --conversation <id> --conversation <another id> \
  --cutoff '<same moment>' \
  --invocation 'conv://<conversation>#<request message>' \
  --discovery /tmp/mobile-discovery.json

# 3. approve: bind the owner's actual words to the exact edit
beacon mobile approve --delegation <N> \
  --said '<what he actually said>' \
  --source-ref 'conv://<conversation>#<approval message>'
Freezing a window by identity, not by text·python
def freeze(ep, messages, since, cutoff, invocation, prior_kept):
    """One snapshot per request. Identity decides; text never does."""
    held = ep / "mobile" / "intake.json"
    if held.exists():                        # a rerun resumes, never refreshes
        snap = Snapshot.load(held)
        if (snap.invocation, snap.cutoff) != (invocation, cutoff):
            raise DifferentRequest(held)     # a new request needs a new episode
        return snap
    seen = {}
    for m in messages:
        at = m.sent_at if m.who == "dad" else m.done_at  # a reply counts when it finished
        if not since <= at <= cutoff:
            continue                         # each message on its own clock
        if m.private or m.redacted or m.skipped:
            continue                         # public text only
        key = m.canonical_id                 # NOT hash(m.text)
        if key in seen and seen[key].text != m.text:
            raise ConflictingMirrors(key)    # stop; never merge by guess
        seen[key] = m.without_audio()        # every voice is new TTS
    rows = [dict(m=m, keep=m.canonical_id not in prior_kept)
            for m in seen.values()]          # already filmed starts dropped
    snap = Snapshot(rows, invocation, cutoff, sha256=digest(rows))
    snap.write(held)                         # written last: its existence is the receipt
    return snap

External links

Exercise

Find a job in your work that summarizes or reports on material that keeps changing while the job runs — a weekly digest, an incident timeline, a release note assembled from merged changes. Write down what its cutoff is today, how it decides a duplicate, and what happens if it is run twice. Then redesign it so the request's own timestamp is the frozen boundary, duplicates are decided by a stable identifier rather than matching text, and a second run resumes the first snapshot.
Hint
Look for the boundary that is computed from the previous run, such as "since the last report". It is the one that silently drops an item that arrived before the previous run but was never used, and it makes two runs on the same day disagree about what the window was.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.