Questions you'll actually have

No. That's the whole point — Harriot handles git and GitHub on your behalf, on a branch scoped to you, and Christopher merges it. You never need to touch either directly.

She can't push straight to main, can't touch any repo you weren't specifically invited to, and can't merge her own pull requests — every change waits for Christopher's review. If she's ever unsure whether something's in scope, the plan is for her to ask rather than guess.

Whatever your own Anthropic API usage runs — Harriot's thinking is billed to the key you provide, not to Christopher's subscription. There's no separate fee for Harriot herself. See the sustainability doc for the full breakdown.

Nothing goes live without Christopher reviewing it first, so a bad suggestion never reaches the real site. You can also just say so in the same conversation and ask for something different before it's even proposed as a pull request.

Not the real backend — the workspace is honestly labeled: real, working UI with the intelligence behind it simulated for now. This site and the groundwork behind it are real and already built; see the roadmap for exactly what's left.

Yes — this repo is meant to be forked. The exclude-list sync means almost everything syncs to the public mirror by default; only governance/agent-config files and anything credential-adjacent are held back. See the sustainability doc for what that actually means for someone forking this.

Right here — the "⬢ git" link in the footer of every page goes straight to the public repo. This site itself is plain HTML/CSS/JS in docs/, no build step, so what you see rendered is close to exactly what's in the repo.

The real backend (not built yet) will run on Claude — whichever Anthropic API key the visitor supplies. This site you're reading right now doesn't call any model at all; the workspace's chat is a client-side simulation, honestly labeled as such.

That's the design goal, not a hope. Harriot's first real assignment is helping Kenney edit iamoneself (live at its public preview ) and david-amaringo (live at its public preview ) — two sites that matter to real people, not throwaway test repos. Every change lands on a branch scoped to the person who asked for it, never touches main directly, and waits for Christopher's review before it's live. Care isn't a value statement here, it's the actual mechanism.

No — this is the visible tip. The front end you're looking at is real and done; the actual harness underneath (login, API key handling, a Claude Code agent that reads and writes real files) is the much larger mass still below the waterline. See the roadmap for what's still submerged.

GitHub Pages, for free — no server Christopher has to babysit. The real backend's hosting hasn't been decided yet; see sustainability for the current stack and what's still open.

That's the actual point of building this as a separate, forkable framework instead of one-off logic bolted onto iamoneself — fork the repo, point it at your own codebase, bring your own API key.

Yes — check the "Current phase" line on the home page or the roadmap's own status markers for what's genuinely current, since this page doesn't auto-update itself.

Push to the private repo's main → a GitHub Actions workflow strips private paths and force-pushes the rest to the public mirror → GitHub Pages rebuilds automatically. No manual deploy step, no server to restart.

Structurally, no — a static site costs nothing to run and nothing to leave idle. The real cost, once the backend exists, is whatever API usage an actual conversation burns — paid by whoever's using Harriot, for what they actually asked for. See sustainability.

She's scoped, not general-purpose — bound to specific invited repos, a specific review gate, and a specific person's approval before anything ships. A generic chatbot answers questions; Harriot is designed to make an actual, reviewable git change.

Plain pattern matching — a handful of regular expressions checking your message for keywords, each producing a pre-written, realistic-looking response. It's the same "true if it matches, true if it doesn't fall through" logic as a light switch, not anything resembling understanding. See how it works for the actual code's shape.

It's a genuinely open question, not a decision yet — plain HTML/CSS/JS has been the right fit for a front-end surface with no backend to talk to, but a real chatbot admin panel (streaming responses, a file-tree explorer, a conversation-tree builder) is a much better fit for React/Next.js's component and real-time ecosystem. Christopher's considering a Next.js front end paired with a Django backend once the real harness gets built — see roadmap, how it works, and sustainability for the trade-offs as currently understood. Nothing here has committed to it yet.

No — and that's deliberate, not a missing feature. GitHub Pages' terms allow donation links but not sites built around commercial transactions; nothing Harriot touches is set up to process a sale.

Plain HTML/CSS/JS, no build step, no framework — deliberately boring so anyone can open a file and read exactly what it does. See how it works for the shape of it.

Not on this site. It's static HTML with no backend to send data to — there's nothing here to phone home to even if it wanted to.

In the real workflow: you, Harriot, and Christopher (as the reviewer on the resulting pull request) — nobody else has a reason to be in that loop.

The review-gate is the test — a human (Christopher) looks at every diff before it merges. There's no separate staging environment yet; the PR review is what catches a bad change.

It stays wrong only in a pull request, never on the live site — that's the entire purpose of the review step in how it works Part two.

Closely enough that it's the real safety net, not a rubber stamp — see the "What if I don't like a change" answer above; the same review step covers Christopher's own read of it.

Not built yet, so not yet tested for real — but the intent is a clear error telling you the key failed, not a silent hang. Worth holding Christopher to once the backend exists.

This site already works on mobile — try the "Force mobile view" toggle in Settings to see it from a desktop browser. The real workbench should too, once it exists; nothing about the design assumes a desktop-only visitor.

No plans to — she's a UI over a Claude Code harness for a specific set of invited repos, not a general-purpose service other software would integrate against.

Magic link → API key → describe a change in plain English → review the proposed diff → approve → Christopher merges. See how it works for the full walkthrough of each step.

Not decided — this is exactly the kind of thing the Next.js/Django consideration above would settle, since a gateway is usually how you keep an API key server-side instead of shipping it to a browser.

By using this preview you agree that Harriot will not coach your waterpolo team, officiate your fantasy football league, or perform your taxes — she is, at time of writing, scoped to exactly two websites and a sense of humor. Everything else in this FAQ is the actual, honest scope. This entry is the joke; the rest isn't.