Flow console

Enter the console passphrase to continue.

Simple Bible - Flow console

Evening flow

Generated per user at open time. Each emotion family keeps its own active master prompt; the hosted intro page states the family in its payload's group, and Default is the fallback.

How an evening flow is made

One AI call. The reader’s check-in and the three texts you own become two messages; the model returns the screens the app renders and one ledger line it remembers. Each part below has its own card.

Reader's check-in hosted intro page Master prompt the method Flow generation prompt how it is written Output rules shape + limit SYSTEM MESSAGE Master prompt + Flow generation prompt USER MESSAGE Past days (ledger) + Check-in answers + Output rules Model one call Screens the app renders Ledger line remembered
You own the three boxes on the left with a border. The check-in comes from the reader.

Master prompt

The prompt document the generator runs. Versioned, with one active per emotion family — the reader's picked emotion selects the family; Default is the fallback.

Flow generation prompt

Part two of the system message.

Flow generation prompt

Goes in the system message, straight after the master prompt. The master prompt decides what the devotional says; this decides how it is written — the voice, and the screens-and-blocks markup the app renders.

If the active master prompt already carries the output format inline, it is used on its own and this text is not appended. The line below tells you which is happening.

See the finished system message

The active master prompt and this text, joined and labeled, exactly as the model receives them. Edit the master prompt above; edit this half here.


                

Output rules

The last thing in the user message.

Output rules

Goes at the very end of the user message, after the reader's answers. The last thing the model reads before it writes: how the output must be shaped, and the hard screen limit for this run. It is repeated here because models drift from the format late in a long answer.

Keep {{screenBudget}} where this run's screen limit belongs — it is replaced with the real number at generation time.

See the finished user message

Exactly what the model receives as the user message. The [bracketed] parts change every generation; the screen limit shown is real.


                

Model + cost

Pick the brain the test generation below runs on, see what a run should cost before you spend it, and correct the price table without a deploy.

Production default
Loading…
This test run
—

The selector alone changes nothing on the server — it rides along with the next test generation as a one-off override. Only the save button above changes what real users get.

Projected cost — estimate, before you run

Run history — this session only

Price table

USD per 1,000,000 tokens. Leave a cell blank when a provider does not bill that dimension (OpenAI has no separate cache-write charge). Saving marks the table verified — that badge is what every cost number on this page is qualified by.

Evening intro — hosted page

The live page at /intro/evening/v1/, in the app’s frame. The header is the app’s, not the page’s. Tap through to the end: its submit payload lands on the right, and generating below runs the real devotional from it. The backend treats answers as opaque — only schemaVersion, introVersion, screenCount, group and completedAt are interpreted.

Generate + simulate a devotional

Runs the live master prompt on the captured payload — one AI call, it can take a while — then wraps the result into the tap-through flow. Nothing is saved: no ledger, no flow, no user state.

A testing aid: paste prior days' ledger lines to exercise day-2+ behavior — the day number should increment and the mirror should differ (every prior mirror is excluded).

Generating your devotional… this can take a while (one AI call).

Generated devotional

Tap through the real flow — including the card-30 figure prompt feeding the card-31 prayer (the one orange token replay).

What this run cost

Ledger line — machine memory, never shown to the user

Warnings

Raw generated script (pre-wrap)

                    

Morning season

Hand-authored, the same for every reader, delivered exactly as published per date. No AI writes morning content - the only model call in the morning slot is the personal prayer at the end of an episode, and it runs on the spec at the bottom of this page.

Season

Loading...

Publishing writes each episode to an immutable versioned file and points its authored date at it. Re-publishing an episode whose content has not changed does nothing. An episode whose art has not been uploaded to Storage yet is refused rather than shipped with broken images.

Next 14 days

What the app serves each morning. A day with no pointer of its own falls back to the most recent published episode before it - which is why an unpublished gap repeats yesterday rather than showing nothing.

Episodes

In reading order. Open one to read every screen exactly as it is stored.

The date defaults to the episode's authored date. Changing it publishes this episode to a different day.

Screens

Prayer prompt

NEVER PUBLISHED - authoring only

The per-episode prompt that runs when the reader submits their answer. It is absent from the published file's field whitelist, so it cannot reach a device: the app never sees this text, only the prayer it produces.


                  

Source

Prayer product spec

Goes at the top of the system message of every morning prayer, ahead of the episode's own prompt. All 38 episode prompts end "Classify: normal / crisis / empty, then follow the product spec rules for that path". This document is those rules - stored once here instead of copied into 38 prompts.

Seeding writes the copy shipped with the backend (from docs/ceo_docs/morning-prayer-product-spec-draft.md). Your current text is kept in the revision trail either way.

See the bundled spec