Preparing your ritual…
Preparing your ritual…
Questions
GYST is a ledger for the work only you can decide. An agent can read your week and prepare the record. Only you can commit it. Everything below is what that boundary means in practice.
What GYST is, what it asks of you, and who can see it.
GYST — get your stuff together — is a daily and weekly ritual ledger. Each day you record what moved, what got in the way, and the one thing you are committing to next. Each week you read the pattern those days made, and decide something about it.
It is deliberately not a task manager. Nothing here tracks your work for you. It keeps an honest record of what you said you would do and what actually happened, so that the weekly review has something real to read.
You score the commitment you made last time, say what moved today, name a blocker if there was one, and choose the single commitment you are carrying forward. Optional context is there for the days that need it. It is built to take a few minutes.
GYST reads only the days you have already committed in the current ISO week and surfaces bounded findings — a commitment that keeps not landing, a blocker that keeps recurring, a win you buried, a key date approaching, work logged outside your priorities. You add observations, set the arrow to up, steady, or down, record the decision in your own words, and set up to five dated priorities.
Early in the week the view is thin on purpose. On Monday nothing has closed yet, so there is nothing to read. The findings fill in as the week does.
A ritual has two states. A draft can be edited, re-saved, and rewritten as often as you like — by you, or with an agent’s help. A committed record is closed and immutable, and it is what every later week is read from.
Committing is a separate human control on the page, and the boundary is enforced three deep: no commit tool exists in the agent surface, a unit test in this repository fails if one is ever added, and the database itself enforces ownership, required fields, atomic close, and post-commit immutability.
No. Open the demo on the home page signs you in anonymously behind a Cloudflare Turnstile check and seeds a private fictional ledger: a full committed prior week, the patterns in it, and today left open to conduct.
Every visitor gets a separate ledger, so what you commit never changes what the next visitor sees. There is no shared demo login. The data is fictional and is generated relative to the current week, so it is never stale and is never anyone’s real history.
Only you. Every table carries row-level security scoped to its owner, with operation-specific policies rather than one blanket rule. The agent tools read through the same owner-scoped session your browser is already using — there is no shared view, no admin view, and no path from one account to another’s rows.
Yes, from Account in the header, on a permanent account. You can export the committed ledger as portable gyst-portable-v1 JSON or as readable Markdown, take a full backup that also includes drafts, or permanently delete the account, which removes the rows you own and revokes your sessions.
Export is deliberately not a WebMCP tool. A WebMCP agent can read the ritual it is helping with; it cannot pull your archive. An agent that drives your browser is a different matter — see the caveat in the last section.
Only if you ask it to. From Schedule in the header you can turn on daily and weekly reminders in your own timezone, and pause or resume them whenever you want. Delivery runs in a small stateless worker that calls four reminder routines and nothing else — claim what is due, check the claim, record the send, record a failure. It never touches your ledger tables.
No, and that is a design rule rather than a fallback. The ordinary form is the product and stays fully usable on its own. WebMCP is progressive enhancement layered on top: if there is no agent in your browser, every page still works exactly as it reads.
Yes — AGPL-3.0-only. It is Next.js on Vercel, with Supabase as the only durable ledger and a Cloudflare Worker for reminders. Read the source.
What the site hands an agent, and what it deliberately withholds.
WebMCP lets a website hand a set of typed tools straight to the AI agent running in the browser, instead of leaving that agent to infer the page from pixels and clicks. The page registers tools on document.modelContext; the agent discovers them, reads each name, description, and input schema, and calls them directly.
It is a draft standard from the W3C Web Machine Learning Community Group. The accessor moved from navigator.modelContext to document.modelContext in the 2026-05-27 draft; GYST uses the current one.
Twenty-two. Not one of them can commit, delete, or export: they read, they navigate, or they write to a draft.
The ritual tools are scoped to their route and exist only while you are on it. On each ritual page the WebMCP agent assistance panel lists the tools that page offers, labels each one read only or draft only, and reports how many actually registered in that tab.
Because a permission prompt is a confirmation, not a guarantee. Agent clients ask their user to approve consequential actions, which helps — but it is enforcement in the wrong place, and it is the place most exposed to a prompt-injection attack.
GYST removes the capability instead. There is no commit, delete, export, history, or SQL tool in the registered surface at all, and a test in this repository fails if one ever appears. A misbehaving or hijacked agent cannot commit your week, because there is nothing for it to call.
Only the bounded context for the page it is on: today’s daily context, or the current ISO week. There is no arbitrary query, no history walk, and no export. The read tools run under your own session, so a signed-out tab returns nothing.
Every field a draft tool touches is marked Agent updated — review on the page, and a running panel lists the most recent calls, which fields each one changed, and that none of them were committed. Rewrite a field in your own words and its marker clears, because that field is yours again.
It can write a draft — that is the point — so treat the draft as a proposal. The tool descriptions instruct it to record only what you stated, and every input is bounded by type, enum, length, and item count, with oversized input rejected outright.
The real protection is the boundary itself: nothing enters the ledger until you read the draft and commit it. The review markers exist so you can see at a glance which words are not yet yours.
The assistance panel says plainly that agent assistance is unavailable in this browser, and the ordinary draft form stays fully available. GYST ships no polyfill of its own — it uses the browser’s native support where it exists, and degrades cleanly where it does not.
What this was built for and where to find the entry.
The OpenAI WebMCP Challenge, hosted on Devpost with Google Chrome, Cloudflare, Shopify, Vercel, Render, and Netlify as partners. Submissions closed on 2026-09-03 at 1:00 p.m. PT and judging runs through 2026-09-21, scored on usefulness, originality, execution, thoughtful use of WebMCP, and the quality of the human-agent experience.
Open the home page in a WebMCP-enabled browser and click Open the demo. That signs you in anonymously and seeds a fictional ledger belonging only to your session. You land on the daily ritual; the weekly review is one click away, and is where the tool surface is most interesting.
On that page, expand the assistance panel to see the seven tools, ask the agent to read before it writes, then watch the review markers appear as it prepares the draft — and note that it has to ask you to commit.
None of it. The seeded week belongs to a fictional persona and is generated relative to the current week at the moment you open it. No personal history appears in the demo or the video.
Claude, ChatGPT, Gemini, and what to do when no tools appear.
WebMCP support is young and moves quickly. This is where it stood when it was last checked, on 2026-08-31.
Whichever you use, the honest test is the page itself: open the daily or weekly ritual and read the assistance panel. It reports how many tools actually registered in that tab.
Claude in Chrome drives the page the ordinary way — it reads what is rendered and clicks and types like a person would. That works here, because the rituals are ordinary forms. Open the daily or weekly page, ask Claude to read the week and fill in the draft, then read it yourself and commit.
What you do not get that way is the WebMCP layer: no schema-bounded draft writes, no Agent updated — review markers, and no change log, because those are produced by the tools rather than by typing into fields.
One caveat worth understanding. An agent driving your browser is acting as you, so the “no commit tool” guarantee does not restrain it — it can press the commit button the same way it presses any other. Tell it explicitly to stop at Save draft and leave the commit to you. That difference is the whole argument for WebMCP: a tool surface can withhold a capability, and a pair of hands on your browser cannot.
To get the real tool surface with Claude, install a WebMCP bridge extension that exposes document.modelContext to the page, then reload the ritual and check the panel count.
This is the path the tools were built for.
We are aware of no announced WebMCP support in Gemini, so expect no tool surface. The ordinary form works fine, and a Gemini agent that drives Chrome for you can conduct the ritual by reading and typing — under the same caveat as Claude in Chrome. It can press commit, so tell it to stop at the draft.
The pattern that works is two turns: make it read first, answer the question it cannot answer for itself, then let it write. Start with this on the weekly review.
It will come back with the patterns in your week and — the useful part — the one fact it does not have. Answer that in your own words, then hand it the second prompt.
Then read the draft on the page, rewrite anything that does not sound like you, and commit it yourself.
None of this blocks the ritual. If the tools never appear, fill in the form and commit as normal.