Mini Mainframe

Reads

billing events, customer plan and start date, past reminder drafts

Done when

A failed payment closes when the retry succeeds or the customer cancels

Runs on

a script on my always-on desktop

Ask first
- Which billing events matter? (default: cancellations, failed payments, recovered payments)
- What should a failed payment produce? (default: a line in the digest and a draft nudge email the person sends themselves)
- Where should it arrive? (default: a chat message in the morning)
- How many days of events on the first run? (default: 7)
- Which time zone is "yesterday"? (default: the person's)

Needs
- A source of billing events with customer, plan, amount, event type and time. Most billing tools export this or send event emails; a mailbox that receives the billing tool's notifications works if there is no API.
- The customer's plan and start date, for tenure. If unknown, leave tenure off the line.
- Chat-only version: forward the day's billing emails to the assistant and ask for the same summary. Drafting nudges still works.
- Access sentence: "It reads billing events and customer plan details. It does not see card numbers, and it never charges or refunds anything."

Build
1. Read: each morning, fetch events from the previous local day for the event types in scope. New means an event id not in the seen list.
2. Decide (grouping): one line per customer, latest event wins. A failed payment that recovered the same day appears only under Recovered. A cancellation within 30 days of signup is marked "early".
3. Decide (nudge): for each failed payment with no nudge drafted in the last 7 days, write a short plain email in the person's voice asking them to update the card, naming the plan and amount. No discounts, no urgency wording.
4. Deliver: one message with sections Cancelled, Failed, Recovered, in that order, and the drafts saved unsent where the person writes email. The routine sends nothing to any customer. A day with no events sends nothing. Store seen event ids so a re-run is silent.
5. Cost: one model call per failed payment for the draft, none for the digest itself; under 30 a month for a small customer base.

Check
- Run against a past day you remember: the lines match what the billing tool shows for that day.
- Run twice for the same day: the second run sends nothing.
- First real run: the message at the usual time, and "no events" in the log on quiet days.

In my version
- A script on the Mac mini reading the billing API, Telegram for the digest, drafts in Apple Mail. Tenure from the customer's first invoice date.

Reads

new support tickets, the help docs, past replies I sent

Done when

Closes when I send a reply or close the ticket

Runs on

an assistant on a schedule

Ask first
- Which inbox or help desk holds tickets? (default: the one customers write to)
- Should the draft be a note on the ticket, or a draft email? (default: whichever the help desk supports; else a draft in the person's mail)
- Which topics must never get a draft? (default: billing disputes, refunds, security reports: flag only)
- How many past replies may it learn from? (default: the last 200 sent replies)
- Hours it runs? (default: 8am to 8pm, the person's time)

Needs
- A source of incoming tickets with the customer's message and the ticket's state. A shared mailbox works.
- The product's help docs or FAQ as text, for grounding. Without them, the draft says what it would need to know and asks one clarifying question instead.
- Past replies the person sent, for voice. Without them, plain and short.
- Chat-only version: paste a ticket and ask for a reply in your voice; keep three of your past replies pinned in the chat.
- Access sentence: "It reads new tickets and your past replies to customers. It writes drafts only; it never sends."

Build
1. Read: every 30 minutes within hours, list tickets created or reopened since the last run that have no reply from the person and no draft note yet.
2. Decide (scope): if the ticket is about a banned topic, write a one-line note "flagged: billing, reply yourself" and stop. Test: does the customer ask for money back, dispute a charge, or report a vulnerability? Draft: "export is missing a column". Flag: "charged twice this month".
3. Decide (draft): give the model the ticket, the three closest help doc sections by keyword, and the five most similar past replies. Ask for a reply under 120 words that answers or asks one question, with a confidence of high, medium or low and the doc section it leaned on. Low confidence drafts open with a question, never a guess.
4. Deliver: save the draft as a private note on the ticket, or as an unsent draft in the person's mail if the help desk has no notes. Never send. Mark the ticket id as drafted so it is not redone.
5. Cost: one model call per new ticket; a small product sees 100 to 300 a month.

Check
- Take five closed tickets, hide the reply, run with saving off: compare the drafts to what was sent.
- Run during quiet hours: no drafts, one log line.
- First real run: open the help desk after the next half hour and see a note on the newest ticket.

In my version
- Runs on the Mac mini from a launch daemon. The help desk is a shared mailbox with labels, the docs are the public help site saved as text, 200 past replies in a local folder.

Reads

error tracker events, uptime checks, job logs, site analytics

Runs on

a script on my always-on desktop

Ask first
- Which sources? (default: error tracker, uptime monitor, the logs of your own scheduled jobs, analytics)
- What is "odd" traffic? (default: more than three times that hour's average over the last 4 weeks, or 300 or more requests from one address)
- When should it arrive? (default: 30 minutes before you usually start)
- One message always, or only when something broke? (default: always, so a missing message is itself a signal)

Needs
- Any readable source of errors and uptime for the person's product. If there is none, the person's own job logs and a single ping check are enough to start.
- A line from each scheduled job saying it finished, written somewhere the routine can read.
- Chat-only version: paste the error tracker's morning email and the uptime email into the assistant and ask for the same four lines.
- Access sentence: "It reads error counts, uptime checks, your job logs and visit counts. It does not read customer data and cannot change anything."

Build
1. Read: at the scheduled time, collect since local midnight: error events grouped by issue, uptime check results, the last line of each job log, and hourly request counts.
2. Decide (new): an issue is new if its fingerprint was not seen in the last 30 days. A job has failed if its log has no finish line in the last 24 hours. Traffic is odd by the thresholds asked above. Keep: an issue first seen at 01:10 with 14 events. Drop: a known issue at its usual two events.
3. Decide (headline): ask the model for one line naming the single thing to look at first, or "all quiet" if nothing is new, failed or odd.
4. Deliver: one message with four sections and the headline. Send it even when quiet. Record the last run time so a missed morning covers the gap on the next run.
5. Cost: one model call a day, about 30 a month.

Check
- Run it now for the last 8 hours with a known issue in the tracker: that issue shows as new or known correctly.
- Stop one job's finish line on purpose: the next run lists that job as failed.
- First real run: the message at the chosen time. If it is missing, the routine itself is what broke.

In my version
- A script on the Mac mini reading an error tracker, an uptime service, launch daemon logs and a privacy-first analytics tool. Telegram, 6:30am Lisbon time.

Reads

open invoices, payments received, past reminders drafted

Done when

Closes when the invoice is paid or I mark it written off

Runs on

a script on my always-on desktop

Ask first
- Reminder days? (default: 7, 21 and 35 days overdue, one message each)
- What happens after the last reminder? (default: a line to the person, no action against the customer)
- Tone? (default: friendly first, plain second, firm third; never threatening)
- Who is exempt? (default: customers on a payment plan or in a dispute, from a list the person keeps)
- Where do drafts go? (default: unsent drafts in the person's mail)

Needs
- A list of open invoices with customer, amount, due date and a contact email. An export or a spreadsheet works.
- A record of which reminders were drafted, kept by the routine itself.
- Chat-only version: paste the overdue list once a week and ask for the reminder drafts; keep a note of which were sent.
- Access sentence: "It reads your invoice list and the reminders it has written. It never sends email and never changes an invoice."

Build
1. Read: each morning, load open invoices and payments received. An invoice is overdue by whole days past its due date in the person's time zone.
2. Decide (stage): for each overdue invoice not on the exempt list, pick the reminder stage whose day count has been reached and not yet drafted. Days are a floor, so a missed morning catches up the next day. Never draft two stages for one invoice in one run; the later one wins.
3. Decide (text): ask the model for an email under 80 words in the stage's tone, naming the invoice number, period, amount and a way to pay. Stage three includes one sentence that service pauses in 14 days.
4. Deliver: save each draft unsent, and send one chat line listing them. Record invoice id and stage as drafted. Nothing reaches a customer until the person presses send.
5. Cost: one model call per draft, usually under 20 a month.

Check
- Set the date forward in a test run with drafts going to a scratch folder: each test invoice gets the right stage once.
- An invoice paid yesterday produces no draft today.
- First real run: the chat line arrives, or the log says nothing overdue.

In my version
- A script on the Mac mini reading invoices from the billing API and an exemptions file; drafts in Apple Mail; the daily line in Telegram.

Reads

school emails, the family calendar, the family note

Done when

A form or reply item closes when we tick it in the note

Runs on

an assistant on a schedule

Ask first
- Which senders count as the school? (default: any address on the school's domain, plus the class app's notification address)
- Where should the note live? (default: a shared note app both parents open; else an email to both)
- What counts as urgent? (default: due within 3 days)
- Which children and classes? (default: all)
- How far back on the first run? (default: 14 days)

Needs
- Read access to the mailbox that receives school email. A forwarding rule to a dedicated mailbox is enough.
- A shared note or document the routine can append to. Fallback: one email to both parents at 5pm.
- Chat-only version: forward the day's school emails to the assistant and ask for the three headings.
- Access sentence: "It reads only emails from the school addresses on the list. It does not read anything else in the mailbox."

Build
1. Read: at 5pm, fetch emails from listed senders received since the last run. Include the text of attached letters.
2. Decide (items): for each email ask the model to extract items as action (needs a reply, form, payment or thing to bring), date (an event on a day), or FYI. Every action needs a due date; if none is stated, use the event date minus one day, or "ask" if there is no date. Test: does a sentence ask the parent to do something by a time? Keep: "return the consent form by Monday". Drop: "we enjoyed sports day".
3. Decide (duplicates): an item already in the note with the same date and similar wording is not added again.
4. Deliver: write the day's block to the note with checkboxes for actions. Send a ping only if an action is due within the urgent window. Record email ids handled.
5. Cost: one model call per school email, about 40 a month in term time.

Check
- Forward a made-up school email with a form due in two days: the note gets the action and a ping arrives.
- Run on a day with no school email: nothing added, no ping.
- First real run: the note has a dated block that evening.

In my version
- The Mac mini's assistant reads a school label in my mail, writes to a shared note both of us see, pings Telegram. Two children.

Reads

last night's sleep data, the week's training plan, recent runs

Runs on

a script on my always-on desktop

Ask first
- Where does sleep data come from? (default: whatever the person's watch or ring exports; else they type last night's hours)
- Sleep floor and heart-rate margin? (default: under 6h30, or resting heart rate 4 or more above the 7-day average, downgrades the day)
- What is the week's plan? (default: the person writes it as one line per day in a file the routine can edit)
- What does a downgrade become? (default: an easy run of the same length, 45 minutes at most; a rest day stays a rest day)

Needs
- A readable sleep record with hours and resting heart rate per night. If only hours exist, use hours alone.
- A plan file: seven lines, one per day, in plain words.
- Recent runs are optional; they only inform the swap.
- Chat-only version: tell the assistant hours slept and the planned session each morning; it applies the same rule.
- Access sentence: "It reads your sleep and heart-rate record and your plan file. It does not read anything else about your health."

Build
1. Read: at 5:30am, read last night's sleep summary and the plan line for today.
2. Decide (swap): apply the floor and margin. If either trips, downgrade today to easy and move the hard session to the next day that is currently easy, never into the long run and never making two hard days in a row. If no slot exists this week, drop it and say so.
3. Decide (wording): the message names the session, the reason in numbers, and what moved. Keep: "intervals moved to Sat". Drop: any advice beyond the swap.
4. Deliver: send the message; rewrite the plan file with the swap and a note of why. If the person replies "keep", restore the original line for today. Remember which days were already swapped so a day is downgraded once.
5. Cost: no model call needed for the rule; one a day if the wording is generated, about 30 a month.

Check
- Feed a test night of 5 hours with a hard day planned: the message downgrades and the file shows the moved session.
- Feed a good night: the message repeats the plan unchanged.
- First real run: the 5:30 message, and a changed or unchanged line in the file.

In my version
- Sleep from a ring's export on the Mac mini, plan file in my notes folder, Telegram. Floor 6h30, margin 4 beats.

Reads

my saved phrases note, past drill results

Done when

A phrase retires after three correct answers on different days

Runs on

an assistant on a schedule

Ask first
- Which language and which variety? (default: the one the person is learning; ask European or Brazilian, or the equivalent)
- Where do new phrases come from? (default: a note the person adds to; fallback: the assistant asks for three new phrases each Sunday)
- How many questions and when? (default: 10 at 8pm)
- Retire rule? (default: three correct answers on three different days)

Needs
- A note of phrases with the person's own meaning in their language. Free text, one phrase per line.
- A results store kept by the routine: phrase, dates asked, right or wrong.
- Chat-only version: this is already a chat; the person says "drill me" at 8pm and pastes the note.
- Access sentence: "It reads one note of phrases and its own results file. Nothing else."

Build
1. Read: at 8pm, load the phrase note and the results. New phrases are lines not yet in the results store.
2. Decide (pick): choose 10 in this order: missed yesterday, then fewest correct answers, then new, then random. Never the same phrase twice in one drill. Fewer than 10 phrases: ask what there is.
3. Deliver: send one question at a time and wait for the reply; mark it right, close or wrong with a one-line correction and a more native phrasing when one exists. After 10, send the score, the repeated misses and any retired phrases. Store every answer with the date.
4. If no reply in 30 minutes, end the drill and record nothing for the unanswered ones.
5. Cost: one model call per answer, about 300 a month.

Check
- Add two test phrases and start a drill at any time: they appear; answer one wrong: it leads the next drill.
- A phrase answered right on three test days disappears from the list.
- First real run: the 8pm message arrives.

In my version
- European Portuguese, phrases in a note on my phone that syncs to the Mac mini, the assistant speaking through the Telegram bot.

Reads

pull requests merged this week, their descriptions and labels, the last published changelog

Done when

Closes when the draft is published or marked skip

Runs on

a coding agent on my always-on desktop

Ask first
- Which repositories? (default: the ones that ship the product)
- Where should the draft go? (default: a draft file next to the published changelog; fallback: an email to the person)
- What marks a change as customer-facing? (default: a label the team already uses; else the model's call using the test below)
- Voice sample? (default: the last three published entries)

Needs
- A list of pull requests merged in the window with title, description and labels. A mailbox of merge notifications works as a fallback.
- The last published changelog entries, for style and to avoid repeats.
- Chat-only version: paste the week's PR titles and ask for the two lists.
- Access sentence: "It reads merged pull requests in these repositories and your published changelog. It writes a draft file only."

Build
1. Read: on Friday, list pull requests merged since the last draft's date. First run: 7 days.
2. Decide (visible): ask the model per PR whether a customer could notice it. Keep: "add CSV export of hidden columns". Internal: "bump queue library". Unsure goes to Internal with a question mark.
3. Decide (wording): one bullet per visible PR, under 20 words, starting with what the customer can now do, no ticket numbers, no engineer names. Group as New, Improved, Fixed.
4. Deliver: write the draft file with the Internal list at the bottom. The routine publishes nothing. Record the merge date reached.
5. Cost: one model call per PR plus one for the draft, about 40 a month.

Check
- Run for a past week with the file going to a scratch folder: compare to what was published then.
- A week with no merges writes nothing and logs no changes.
- First real run: the draft file exists on Friday evening.

In my version
- One product repository, labels "user-facing" and "internal", the draft written into the marketing site repository; I publish on Monday.

Reads

a list of public pricing pages, last week's saved copy of each

Runs on

a script on my always-on desktop

Ask first
- Which pages? (default: the public pricing pages of up to 10 companies the person names)
- What counts as a change? (default: any number, plan name or limit changing; ignore wording-only edits)
- Where should it arrive? (default: a weekly chat message)

Needs
- A way to fetch a public web page and keep its text. Pages behind a login are out of scope.
- A folder for weekly copies, kept by the routine.
- Chat-only version: the person opens each page monthly and pastes the text; the assistant compares with the last paste it was given.
- Access sentence: "It fetches public pages only. It does not log in anywhere."

Build
1. Read: each Monday, fetch every page in the list and keep the visible text. A page that fails to load is reported as "could not read" and its last copy is kept.
2. Decide (diff): compare with last week's text. Ask the model to list differences that change a number, a plan name, a limit or a feature's presence, with old and new. Keep: "Team 29 -> 35". Drop: a reworded tagline.
3. Deliver: one message with a line per changed page, plus one line saying which pages did not change. Save this week's copies dated. Silent only when every page loaded and none changed.
4. Cost: one model call per changed page, under 10 a month.

Check
- Edit last week's saved copy of one page by hand and run: the message reports the fake change.
- Run twice in one day: the second run reports no change.
- First real run: Monday's message, or a logged "all unchanged".

In my version
- Seven pages, fetched with a headless browser on the Mac mini, copies in a dated folder, Telegram.

Reads

the shared family album, the family calendar, the family note

Runs on

a script on my always-on desktop

Ask first
- Which album? (default: a shared album the family already adds to)
- How many photos and who picks? (default: 6, chosen by the routine for faces, variety and sharpness; the person swaps any)
- Who are the recipients and what language? (default: the person fills these in; the routine only drafts)
- What may the note mention? (default: events from the family calendar and the family note, nothing from work)

Needs
- Read access to a photo album with dates. If there is no shared album, the person drops photos in a folder during the week.
- Something that says what happened this week: a calendar, a note, or the person answering one question on Sunday.
- Chat-only version: the person sends six photos and three lines to the assistant; it writes the note.
- Access sentence: "It reads one album and your family calendar for the past week. It writes a draft and sends nothing."

Build
1. Read: on Sunday, list photos added in the last 7 days and the week's family calendar entries and note lines.
2. Decide (photos): drop blurry and near-duplicate shots; prefer photos with faces across different days; stop at the chosen number. Keep: one shot from each of four days. Drop: twelve of the same cake.
3. Decide (note): ask the model for under 80 words in the person's voice from the calendar and note only, saying which photo shows what. Nothing invented: if the week has no entries, the note is two lines and says the photos speak for themselves.
4. Deliver: save an unsent draft with the photos attached, resized to under 2 MB each. The person adds a line and sends. Record the photos used so next week starts fresh.
5. Cost: one model call a week.

Check
- Run on a past week with the draft addressed to yourself: six photos, a note that mentions only real calendar entries.
- A week with no new photos: no draft, a chat line saying so.
- First real run: the draft is in the drafts folder on Sunday evening.

In my version
- A shared album synced to the Mac mini, note in Portuguese, the draft in Apple Mail with two recipients I type in.

Reads

a card statement export, app use on my machines, last month's list

Done when

A flagged item closes when I cancel it or mark it keep

Runs on

a script on my always-on desktop

Ask first
- Where do charges come from? (default: a card statement export; a spreadsheet works)
- What counts as recurring? (default: same merchant, similar amount, in two consecutive months)
- What counts as unused? (default: no sign of use in 60 days, from app launches, logins or emails from the service)
- Where should the note go? (default: a note the person reads, and one chat line)

Needs
- Last month's charges with merchant, amount and date. No bank connection needed if the person exports a statement.
- Any usage signal: a list of recently opened apps, or the mailbox's recent emails from each service. Without any, everything is "use unknown" and the list still arrives.
- Chat-only version: paste the statement; the assistant lists recurring charges and asks which were used.
- Access sentence: "It reads a statement export and which apps opened recently. It does not log in to any bank and cancels nothing."

Build
1. Read: on the 1st, load last month's charges and the stored list from the month before.
2. Decide (recurring): group by merchant; recurring if seen last month and the month before within 20% of the amount. New if seen this month only and the merchant's email mentions a trial or plan.
3. Decide (unused): for each recurring charge, look for use in 60 days: an app launch, a login email, or a receipt that is not the charge itself. None found: flag it.
4. Decide (draft): for each flagged item, a two-line cancel email naming the service and asking to end the plan at the period's end. Saved unsent.
5. Deliver: the note with Unused, New and Kept sections and totals; one chat line with the counts. Store this month's list.
6. Cost: one model call per flagged item, under 10 a month.

Check
- Run on last month's statement: the recurring list matches what you know; one known-unused tool is flagged.
- Mark an item keep and run again: it is not flagged again.
- First real run: the note on the 1st.

In my version
- A statement export from my bank app dropped in a folder, app launch dates from the Mac mini's own records, note in Apple Notes, Telegram line.

Reads

the pull request diff, the repository's conventions file, the test results

Done when

Closes when the PR merges or is closed

Runs on

a second coding model, run by CI

Ask first
- Which repositories and branches? (default: the product repositories, PRs into the main branch)
- Should it ever block a merge? (default: only when the diff contains something that looks like a key or password)
- Which areas are sensitive? (default: billing, auth, data deletion: always mentioned when touched)
- Comment or approval? (default: one comment, never an approval)

Needs
- A CI system that runs a job on each pull request and can post a comment. Without one, the person pastes the diff into the assistant.
- A conventions file in the repository, or three sentences from the person on what they care about.
- Chat-only version: paste the diff and ask for the same three sections.
- Access sentence: "It reads the diff and the conventions file. It cannot merge or push."

Build
1. Read: on PR open or update, take the diff and the conventions file, plus test results if they have finished.
2. Decide (findings): ask the model for up to five findings ordered bug, missing test, duplication, style, each with file and line. A finding in a sensitive area is marked. Test for a bug: would the code do something other than what the PR title says for at least one input? Keep: a cap that never triggers. Drop: a naming preference not in the conventions file.
3. Decide (secrets): scan the diff for key-shaped strings; if found, mark the check failed and say where, without quoting the value.
4. Deliver: one comment, replacing its own earlier comment on the same PR. Record the commit reviewed so a re-push reviews each commit once.
5. Cost: one model call per PR commit, about 50 to 150 a month for one developer.

Check
- Open a PR with a deliberate off-by-one and a fake key: the comment names the bug and the check fails on the key.
- Push a whitespace-only change: one comment, no findings.
- First real run: the comment on the next PR within five minutes.

In my version
- A CI workflow calling a code-review model on each PR, conventions in a file at the repository root, blocking only on secrets.

Reads

site analytics, billing totals, the signups table

Runs on

a bot I message

Ask first
- Which numbers? (default: visits, signups, paid conversions, revenue; the person names the sources)
- Where do you want to ask? (default: the chat app you already have open)
- Who may ask? (default: only the person; the bot ignores anyone else)

Needs
- Read access to each number's source: an analytics tool with an API or export, a billing summary, a database or spreadsheet of signups.
- A chat bot the person can message. Fallback: a command the person runs that prints the same answer.
- Chat-only version: the person pastes today's analytics email and asks; comparisons need last week's paste too.
- Access sentence: "It reads counts and totals. It cannot see individual customers' details and cannot change anything."

Build
1. Read: on a message from the allowed person, parse the question for the metric, the period and the comparison. Unknown metric: reply with the list it knows.
2. Decide (periods): fetch the metric for the period and the comparison period; "this week" means Monday to today; "vs last" means the same weekdays a week earlier. Round to whole numbers; show the difference with its sign.
3. Deliver: one reply with figure, period, comparison and one line on the biggest contributor if the source has it. Never more than five lines.
4. Cost: one model call per question for parsing, usually under 60 a month.

Check
- Ask "signups yesterday" and compare with the source's own dashboard.
- Ask for a metric it does not have: it lists what it knows.
- Message it from a second account: no reply.

In my version
- A Telegram bot on the Mac mini reading a privacy-first analytics API, the billing API and the app's database. Allowed user: me.

Reads

my notes for the piece, past documents of the same kind

Runs on

a chat assistant

Ask first
- Which kinds of document come up most? (default: updates, job ads, outreach emails, policy edits)
- Voice sample? (default: three past pieces the person is happy with)
- Any lines that must always appear? (default: none; ask for a signature or legal line if so)

Needs
- Three past examples per kind of document, pasted once and kept in the assistant's project or notes.
- Chat-only version: this routine is already chat-only.
- Access sentence: not needed; nothing is connected.

Build
1. Read: the person names the kind and gives notes in any form.
2. Decide (draft): match the kind to its examples; keep the person's structure and length; use only facts from the notes, marking any gap as [fill in] rather than inventing. Keep: a figure from the notes. Drop: any claim not in the notes.
3. Deliver: the draft in the chat, with a one-line list of gaps at the end. The person pastes it where it goes.
4. Cost: one model call per draft.

Check
- Give notes with one missing figure: the draft shows [fill in] there, not a number.
- Give the same notes twice: the structure matches the examples both times.

In my version
- A chat assistant project holding past investor updates, two job ads and my outreach template.