Owner's guide

Operating your LifeOps

You own a LifeOps instance. Your Claude builds and runs it. You tell it what you want in plain words. You never write code, read code, or memorize commands.

The rulebookYour Claude works from a written rulebook

Your Claude's testing, deploying, data handling, and the moments it stops to ask all come from rules written in this repository. You don't maintain them. When you want something different, you say so. Your Claude rewrites the rule, and the change holds in every future session.

You can change any of it. Say what you want changed, your Claude writes it down, and written rules hold.

What to sayAsk for what you want, in plain words

The exact words don't matter. Your Claude reads your intent. These are the common requests.

Seeing where things stand

Connect my calendar.You do this one yourself, in the app: Settings → Account → Calendar, one button through Google's own permission page. You then tick which of your calendars appear — all of them, not just the primary — and set the life area each one falls under. Your meetings arrive as tasks on the Day. If the button says the instance isn't registered with Google yet, that one-time registration is your Claude's job; the deployment manual has it.

Set up a LifeOps for someone else.One LifeOps holds one person, so a second person means a second deployment. Your Claude follows the deployment procedure it keeps, and the new instance starts empty with its own address, its own login, and no access to yours.

My name is spelled wrong. / Change the email on my account.The name and email are backend account fields, set when it was provisioned, and the app has no screen for them. Your Claude corrects them on the backend and the app shows the fix on its next load.

Make this task repeat every Tuesday and Thursday.Your Claude sets the task to repeat, and a fresh one appears on each day you named. Daily, weekly, monthly on the same day of the month, and named weekdays like Tuesday and Thursday are the whole vocabulary today, so there is no every-other-week. The app itself has no control for this yet.

What changed recently?It reads the changelog and tells you in plain language.

What are you working on? What's on the board?It reads the board, the tracked list every task is on, and tells you what's claimed, what's queued, and what's waiting on you.

Is everything healthy?Today this reaches a toolchain check, which confirms the machine your Claude works on has every tool installed. It runs no tests and never looks at your live app. Making the question reach the real checks is issue #191 on the board.

Directing the work

I want the app to do X.It files the idea as an issue on the board, in your words, where it stays until it ships.

Review the board and tell me the plan.It rereads every open issue, answers your comments, sets priorities, and presents the plan. Building waits for its own authorization, the phrase underneath.

Work through everything you can.Saying it authorizes the work: your Claude works the board in priority order and stops only when everything left is waiting on you or parked.

Your apps

Redeploy the web app. / It looks broken, roll it back.It deploys or reverts, then checks the result is live.

Build me a new version of the phone app.It produces an installable build through the store channels. That is the slow path: about fifteen minutes to build, then Apple’s processing, then you tapping Update in TestFlight.

Push today’s changes to my phone.Most changes are JavaScript, and those reach the app already on your phone in about a minute, with no build and no store. The app picks the update up the next time you open it, so the open that downloads it still shows the old version. Anything native still needs a full build, and no build on your phone can take an update until one carrying the updater ships. Releases and upgrades has the split.

I want to try the app on my phone right now.It runs the newest version straight to your phone, with nothing to install. Your phone has to reach your Claude's computer, so both need to be on the same network.

Change my web password.You can do this one yourself, in the app: Settings → Account → Change password. Asking your Claude works too. Either way it takes effect right away, and devices already signed in stay signed in.

Log every device out.It rotates the session secret on the backend, and every signed-in device everywhere is signed out at once.

Quality and checks

Run the tests. / Run the end-to-end tests against my real app.It runs the suite locally, and runs the full end-to-end tests against your live app when you ask.

Run a parity check.It compares the phone app and the web app screen by screen, following the written parity checklist, and reports any difference. One script does part of it by machine: the two apps deliberately keep fifteen files identical, among them the Day layout, the clock, the swipe rules and the API contract, and it fails if any pair has drifted. The rest of the checklist is read by hand.

Staying current

Is there a new version? What's in it?Your LifeOps is a fork of a maintained base, and every change to the base is in its plain-language changelog. Numbered releases are the designed way updates arrive. None has been cut yet.

Upgrade us to the newest version.It reads the notes, applies the update, re-runs every check, and can roll back cleanly. The design leaves your data untouched. The procedure is written and first runs once a release exists to pull.

Ending your day — the closeout

That's it for tonight. / Gotta run.You don't ask for cleanup. Say you're done in any words and the closeout runs: loose ends filed, the board tidied, checks green, background processes stopped, and a summary written. If a session ends abruptly, a closed laptop or a dropped connection, the next one finishes the closeout before doing anything else. The Working in Claude Code guide covers it.

When something's wrong

The app won't load. / I can't log in. / This looks wrong on my phone.Describe it as you would to a person. Your Claude investigates, fixes, tests, and tells you what happened. Every fix ships with a test that catches that bug, so it stays fixed.

I think I lost data.It investigates before changing anything, then checks the backend's nightly database backups, which cover the past several weeks, and the offsite copies when offsite storage is configured. It tells you exactly what it found. Restoring is hand work your Claude does on those backup files rather than a tool it runs.

ProtectionsA few rules make your Claude pause or refuse

When your Claude asks or declines, one of these is why.

Personal data stays out of the code.

A scan blocks any push that contains a credential-shaped string, or the base owner's names, emails, and home coordinates — outside the guides, where the owner's own name is deliberately allowed. The identity half is a fixed list rather than a general detector, and adding your own names and addresses to it is a step of setting up your fork. The written rule is to remove flagged data rather than weaken the list.

Every change ships tested.

It passes checks on your machine and again on an independent server before it counts.

Deploys are deliberate, and a saved change is not a live one.

A change is written into your project the moment your Claude makes it, but that is not the same as it running in your live app. Deploying is a separate, deliberate step, and it counts only after your Claude opens the live site and confirms the change is there. If it ever says something shipped, it has looked.

Releases and upgrades happen only on your word.

Your Claude prepares the release and tells you. You decide when your system changes versions.

"Verified" means a human looked.

Its own tests passing is machine-checked, and your Claude looking at the live app is "checked live". It says "verified" only after a person has seen it.

Some things only you can provide.

Account sign-ups, passwords, store credentials. When it needs one, it asks you plainly, once, with exactly what it needs.

Changing rulesAny rule here is yours to change

You change any behavior in this guide the same way: say what you want, your Claude writes it into the rulebook, and it holds in every future session, not just the chat you said it in.

Disable the automatic parity check.It edits the rulebook so the check stops, and records that you turned it off and when.

I want deploys to happen automatically when code changes.It changes the deploy policy, writes down the new one, and adjusts its own routine to match.

Stop asking me about X. / Always ask before Y.The rule changes in writing, so it holds everywhere.

When your Claude behaves in a way you don't like, tell it to change the rule instead of working around it.

NamesEach name is a real tool or account

Your Claude mentions these. Each one says what it is and what, if anything, it needs from you.

GitHub: Holds the code and the board. Every task, bug, and plan is an "issue" there, and every change stays on record. You never have to look, and everything your Claude claims to have done is checkable there.
Railway: The cloud host in the default setup. It runs your web app and the backend that holds your data. You own the account and pay its small hosting bill. Your Claude operates it.
Expo: The toolkit your phone app is built with. One codebase becomes both an iPhone and an Android app.
Expo Go: A free preview app for your phone. It runs the newest version straight from your Claude's computer, with nothing to install, whenever your phone can reach that computer. It's the try-it-now path.
EAS: Expo's build service. It turns the code into a real, installable app. Needs your Expo account
TestFlight: Apple's way to put app versions on your iPhone before the App Store. You get an invite, tap install, and updates come there.
Store accounts: Apple Developer (about $99/yr) and Google Play, needed only to ship the app to real phones through official channels. Among the few sign-ups only you can do
The backend: The private server that holds all your data: journal, tasks, everything. The apps only read and write it. It's yours alone, and nothing in it flows to anyone else.
Tokens & passwords: A token is a long secret string that is your identity to the backend. Your web login is a username and password you choose, stored scrambled on your own backend rather than written down anywhere. Your Claude creates, stores, and rotates the tokens; the login is yours, and Your login covers how it gets set.
BlockNote: The rich-text editor, the Notion-style writing surface. It is the body of a document, the long text on a stream, and the note on a task — the same editor each time, with its toolbar hidden on a note so the box stays as plain as it looks.

Your videos & photosWhere a recording lives, and who can see it

A recorded video, a voice memo or a photographed page is the most sensitive thing this system holds. Here is exactly where those files go, what protects them, and which outside services touch them and why.

One outside service can receive a recording, and only if you switch it on. With Transcribed recordings on in Settings → Features, a video or a voice memo you post is sent to ElevenLabs to be transcribed. The transcript then goes to Anthropic, which writes the title and summary; the file itself never does. The two halves run on two different keys and bill separately: the ElevenLabs key stored in Settings → Keys, billed by the minute of recording, and the Anthropic key stored beside it, billed like every other AI job. With the feature off, or with no key stored, the recording is never sent anywhere.

Where the file goes:

An upload that fails still keeps the recording: The take is written to your phone's own storage, or your browser's, before the upload starts. A failed upload used to leave the only copy inside the page you were looking at, so closing the app or reloading the tab destroyed it. Now the next time you open the journal the take is there, with the same Retry beside it. Once the entry exists on the server the local copy is deleted.
A private storage bucket, never a public one: Where this deployment has a media bucket configured, the file uploads over an encrypted connection to a private Cloudflare R2 bucket it owns. Nothing in that bucket has a public address. There is no URL anyone can guess, share, or index. Where it has no bucket, the file stays on the backend's own disk beside the databases, which no one outside the deployment can reach at all.
Filed under your account alone: Every object is keyed under your account's prefix, and only one account exists on your LifeOps — one person, one deployment (see Your login). The backend refuses cross-account reads anyway, defense in depth under that one-account design.
Viewed through expiring links: When a page shows your video, the backend mints a signed link that works for about an hour and then expires. A link copied out of the app stops working on its own. Anyone without your login never gets a link at all.
What deleting removes today: Deleting an entry removes the entry’s row and touches storage not at all, so the recording stays in the bucket with nothing pointing at it. That is a known gap. The private bucket and the expiring links protect the orphaned file the same as any other.
Encrypted at rest: Cloudflare encrypts everything stored in R2. The realistic protections against a stranger are the private bucket and the expiring links. The encryption protects the files if the storage provider's own disks are lost or stolen.

Which outside services touch a video, and what they get:

Compression happens at home: The backend compresses a recording to browser-playable quality with ffmpeg on your own server, and the original is deleted only after the smaller file is confirmed in storage. That work happens entirely inside your deployment.
ElevenLabs hears the recording, when you switch it on: With Transcribed recordings on in Settings → Features and a key stored for it, the audio is sent to ElevenLabs and comes back as a transcript. Every other AI job sends words; this one sends the file, which is why it has a switch of its own. With the feature off, or with no key stored, the recording is never sent.
Anthropic reads words, never pictures: Two jobs touch a recording. Filing sends the entry’s text and your life areas, and gets back one area. Write-up sends the transcript that came back from ElevenLabs, and gets back a title, a summary and a cleaned-up read-through. Both get words only, never the video and never a frame of it, and each has its own switch in Settings → AI. Photos are different: nothing reads them at all today. A photographed page is stored, shown to you, and touched by no AI unless you later ask for that.
Nothing else: No analytics, no thumbnailing service, no third-party player. The video streams straight from your bucket to your screen.

What this is not: end-to-end encryption. Your Claude and the backend can read the files they store. That reading is what lets area filing and the app itself work. The honest description is: private by architecture, readable by your own system, sent to the two named services above for the features named here, and to nothing else. Recording transcription is the only job that sends a file. Every other one sends words. Three more AI jobs are planned, issues #261 through #263 on the board, and each arrives with its own switch before it runs. If that boundary should move, it is one sentence to your Claude, and this page changes with it.

Your loginYou choose the username and password that open the app

One account opens this deployment. It is stored on your own backend, scrambled so that even someone reading the database cannot recover it, and changing it takes effect straight away with nothing to redeploy.

You set it yourself, in the app. A fresh deployment's login page asks you to choose the username and password, and saving them claims the account. Changing the password later is in Settings › Account. Pick something long: twelve characters is the minimum, and a short phrase you can remember beats a short scramble you cannot.

A new deployment has no login at all: There is no way to sign in until you set one. A system holding your journal must never ship with a default password that someone else already knows.
Changing it does not sign you out: Sessions already open stay open. After a lost laptop or a shared computer, say "Log every device out". Your Claude rotates the session secret, and every device everywhere is signed out at once.
Wrong guesses get blocked: After five failures the login locks for fifteen minutes. If you lock yourself out, wait it out or ask your Claude to set a new password, which clears the lock.

A forgotten password takes one sentence to fix. There is no reset email and no recovery question — you are the only person here to send one to. Ask your Claude to set a new one. It reaches the backend directly and never needs the old password.

Getting orientedOne sentence gets you oriented

Say this

"Read the operating guide and tell me where everything stands."

You get back what's deployed and where, what changed lately, what's in progress, what's waiting on you, and what it recommends next.