The deploy loop my wife doesn't know about

How an Apple Note, a Claude scheduled task, and OpZero turned trip-planning bullets into automatic deploys.

---

Last night, my wife typed a single line at the bottom of our shared Apple Note:

Request: highlight Sunday as the most important day of the trip: Ashley's birthday. There should be a fireworks animation at the very least.

Thirty minutes later, disney-trip-2026.opzero.sh had a new "HEADLINE EVENT" banner across Sunday with her name on it, fireworks animating in the background, and the day's theme rewritten from "Magic Kingdom (full day)" to "Magic Kingdom — Ashley's birthday." She didn't open a code editor. She didn't log into a dashboard. She doesn't know what a CDN is. She has, by any reasonable definition, shipped a feature to a live web app.

This post is about how that loop got built, why OpZero is the piece that makes it work, and why I think it's a template for a much bigger class of users.

What we built

A few weeks ago I built an interactive Disney trip itinerary inside Cowork — Anthropic's desktop tool that renders Claude artifacts directly in a sidebar. The artifact is a single HTML file: a const itinerary = [...] array of day objects feeding a UI with a departure countdown, a "stress score" simulator that updates as you toggle optional events on and off, a downtime tracker, and a day-by-day interactive timeline. Useful for planning, fun to look at.

Problem: a Cowork artifact lives in my Cowork window. My wife can't open it on her phone. My parents can't pull it up from their browser. So I deployed it to OpZero — one tool call, live URL, done.

That gave us two surfaces:

• Cowork artifact — master copy, where edits happen
• OpZero deploy — public URL the family sees

And one source of truth that fed neither: the Apple Note where my wife was actually planning the trip.

So every time she edited the note, the workflow was: read her changes, update the artifact, redeploy to OpZero. Three steps, multiple times a day, all manual. The live site fell out of sync constantly. A pretty artifact that's wrong is worse than no artifact.

The fix: a 30-minute scheduled task

Cowork has a feature called scheduled tasks — you write a prompt, set a cron schedule, and Claude runs it on that interval with whatever connectors and tools you've granted it. I wrote one called disney-itinerary-poller that runs every 30 minutes.

Each run, it does:

1. Reads the Apple Note (Disney itinerary) via the Apple Notes connector.
2. Diffs against a snapshot from the last run. Unchanged? Exit — no wasted deploy.
3. Parses the bullets into structured itinerary data: day, time, title, optional flag. Fuzzy-matches each bullet to an existing event in the artifact's data array, so my hand-tuned metadata (stress weight, duration, category) survives across syncs.
4. Updates the Cowork artifact via update_artifact.
5. Mirrors to OpZero via update_deployment.
6. Saves a new snapshot for next run's diff.

About 200 lines of prompt, no application code. The full prompt is in the appendix at the bottom of this post.

The killer feature: marker lines

Itinerary sync was nice. The thing that made this a demo and not just a chore-automation is the marker syntax.

I taught the task to recognize a small set of phrases. Lines that start with request:, @claude, Claude:, Feature request:, or TODO claude: aren't itinerary items — they're instructions for modifying the artifact's code.

So when my wife wrote Request: highlight Sunday as the most important day of the trip: Ashley's birthday. There should be a fireworks animation at the very least. — that line wasn't parsed as a Sunday bullet. It was extracted, sent through Claude, mapped to a series of code edits (add a banner component, write the fireworks animation, update the day theme, update the day summary), applied to the artifact's HTML, deployed to OpZero, and then prefixed with a checkmark in the note so it wouldn't run again.

She doesn't write JavaScript. She doesn't know what a deploy is. She knows that if she writes Request: in the note, the website changes.

That's the whole demo.

What OpZero actually does in this loop

Static-site hosting is a commodity. Plenty of services will deploy a folder. OpZero matters in this loop for two specific reasons.

It's the surface that turns the artifact into a thing other people can use. Cowork artifacts are powerful for the editor and invisible to everyone else. The moment the artifact lives at a stable public URL, my parents in another state can pull it up. The grandparents who don't have Cowork can pull it up. My wife can open it on her phone in the parking lot at Fort Wilderness. That's a different category of object — it has gone from a personal tool to a piece of software the family actually uses.

The deploy is API-callable. This is the part that closes the loop. A scheduled task can't automate a deploy if the deploy requires a human clicking a "Publish" button. OpZero's update_deployment tool means a Claude session can ship a new version unprompted, with the same trust model as any other tool call. That's what makes the 30-minute cron viable — and what made the Ashley's-birthday banner appear without me typing a single character.

Without those two properties, the loop doesn't exist. My wife is back to texting me "can you update the website."

Why this is a template, not a one-off

The pieces generalize.

A non-technical editor with domain knowledge. My wife knows the trip. She knows what time Hoop-Dee-Doo starts and that we have to leave camp by 3:30 to make it. She doesn't know JavaScript. The loop separates "person who knows the content" from "person who knows the code" — the LLM bridges them.

A familiar editing surface. Apple Notes is what she already uses. We didn't introduce a new tool. The same pattern works with email, Slack, Google Docs, a shared spreadsheet — anything with a connector. Adoption cost is zero because there's nothing new to adopt.

A schedulable pipeline with an API-callable deploy. Cowork gives us the pipeline. OpZero gives us the deploy. The cron is a knob: 30 minutes for us, could be 30 seconds, could be on-demand.

The same shape works for an internal company wiki where anyone edits a doc and the marketing site rebuilds; a recipe blog where you write recipes in Notes and the site stays current; a real-estate site where the agent updates a Google Sheet and the public listings update; a portfolio where journal entries in Apple Notes become blog posts at clean URLs. Anywhere there's a smart editor and a piece of software that should reflect what they wrote, this works.

The recipe

If you want to build something similar for a non-developer collaborator:

1. Build the artifact in Cowork. Iterate until it's the shape you want.
2. Deploy to OpZero. deploy_react_artifact or deploy_html, takes 30 seconds, gives you a live URL.
3. Connect the editing surface. Apple Notes, Google Docs, Slack — whatever they already use.
4. Write a scheduled task. Polls the surface, diffs against a snapshot, applies changes, calls update_artifact + update_deployment. Full prompt below.
5. Define a feature-request marker. Pick a phrase your collaborator can type to ask for code changes. Teach the task to recognize it, modify the artifact, and check-mark it in the source so it doesn't repeat.
6. Pre-approve permissions. Click "Run now" once on the scheduled task to grant the connectors. Future runs go unattended.

Total time end-to-end: about an hour, most of it spent writing the scheduled-task prompt carefully enough to handle adds, edits, deletes, and ambiguous requests.

What this means for the people we're actually building for

OpZero's pitch has always been: ship things fast, no infrastructure rabbit hole. This demo extends that pitch to a user who isn't even a developer. My wife isn't deploying. But she's getting the value of a deployed system on her terms, in the tool she already uses, with code edits powered by a markup language she invented as she typed.

The interesting question isn't "can we make my wife understand deploys?" It's "do we even need her to?" In this loop, no. The deploy is invisible to her, and that's the win.

She's going to have a great trip in three months. She'll pull up the website on her phone at some point. She is not going to know.

---

Appendix: the scheduled-task prompt

The full prompt for disney-itinerary-poller is below. Adapt freely. The key parts: discover MCP tools dynamically (their session prefixes change), maintain a snapshot for change detection, separate itinerary items from feature-request markers, and treat the Cowork artifact as the master with OpZero as the mirror.

You are a scheduled task that keeps a Disney trip itinerary artifact in sync
with an Apple Note. You run every 30 minutes. This prompt is your only context
— there is no prior conversation.

# Sources / targets / state
- Source of truth (input): Apple Note titled `Disney itinerary`.
- Master artifact (Cowork): id `disney-itinerary-2026`, file at
  /Users/.../Artifacts/disney-itinerary-2026/index.html.
- Mirror deployment (OpZero): project `disney-trip-2026`. Public live version,
  must match master.
- Snapshot file: /Users/.../Scheduled/disney-itinerary-poller/last-snapshot.txt.

# Tool discovery
The MCP tool prefixes change across sessions. Find tools via ToolSearch on
first call:
- Apple Notes: select:mcp__Read_and_Write_Apple_Notes__get_note_content,...
- Cowork: select:mcp__cowork__update_artifact,...
- OpZero: search 'opzero deploy' or
  select:get_project_details,update_deployment,...

# Workflow

1. Fetch the note via get_note_content.
2. Compare to snapshot. If unchanged, exit cleanly.
3. Classify content:
   (a) Itinerary items — bullets under day headers (Friday/Saturday/...).
       Bullets starting with "Optional:" are optional events.
   (b) Feature requests — lines that START with `request:`, `@claude`,
       `Claude:`, `Feature request:`, `TODO claude:`. A line already
       starting with a checkmark is done; ignore.
4. Read current master artifact. Parse the inlined `const itinerary = [...]`
   JS array.
5. Compute itinerary diff:
   - Match existing events by fuzzy title; preserve their w/dur/cat/icon.
   - Infer fields for new events (cat from keywords, dur from time-range,
     w as a stress weight).
   - Drop events that no longer appear in the note.
6. Apply feature requests: modify HTML/CSS/JS conservatively. Preserve
   existing structure. Skip ambiguous or destructive requests; report them.
7. Update Cowork master via update_artifact. If error, exit; do not deploy.
8. Mirror to OpZero via update_deployment. If error, do not save snapshot
   (next run retries).
9. Mark implemented requests done in the note (prefix with checkmark).
10. Save the new snapshot.

# Output
A short paragraph: itinerary diffs, requests implemented, requests skipped
(with reasons), Cowork updated yes/no, OpZero deploy result, new URL.

# Don'ts
- Never delete the OpZero badge or tracking pixel.
- Never alter w/dur/cat/icon on existing events unless the note changes
  the wording.
- Never redeploy if nothing changed.
- Never check-mark itinerary bullets, only feature-request lines.
- Never edit the note's day headings or itinerary bullet wording.

The prompt is the entire program. There is no app code. There is no build pipeline. There is a note, an LLM, and a deploy API — and somewhere between them, a website that updates itself.

---

Live demo: disney-trip-2026.opzero.sh

Try OpZero at opzero.sh.