# lists

Lists with items — create a list, add to it, check things off, delete them.

One SQLite store and one HTTP service, shared by three surfaces: a web app, an
iOS app, and the MCP tools. Every write goes through the service, so the three
cannot disagree about what a save means.

## Layout

| Path | What |
|---|---|
| `src/db.ts` | SQLite, `lists.db` in the bag's data directory (`BARRY_LISTS_DB` overrides) |
| `src/store.ts` | The data layer — the only place that writes SQL |
| `src/client.ts` | How the tools reach the service |
| `src/tools.ts` | MCP tools (re-exported by `tools.ts` at the root) |
| `server/src/index.ts` | The service: `node:http`, on loopback at the port `barry up` assigns |
| `web/` | The web app — hand-written HTML/CSS/JS, no build step |
| `lists-ios/` | The iOS app (XcodeGen; `project.yml` is the source of truth) |

## Running it

```sh
pnpm install
PORT=4885 BARRY_SECRET=dev pnpm start   # by hand; `barry up` assigns the port itself
pnpm test           # store + service
pnpm typecheck
```

The service requires `BARRY_SECRET`: `Authorization: Bearer <secret>` (or
`x-barry-secret`) on every `/api/` route, whatever address the request comes
from, since every hosting provider connects from loopback. `/health` never
takes auth, so a probe can tell "server down" from "wrong secret". It refuses
to start without a secret.

## The iOS app

```sh
cd lists-ios && ./scripts/test.sh          # build + unit tests on a simulator
barry ios build lists --simulator "iPhone 16 Pro"
barry ios build lists --device
```

On a device it reaches the service through whatever your installation's
`hosting.yaml` exposes it on (a private tunnel, say); the address and the
secret are both editable in Settings. How the service is reached from off this
Mac is installation policy, not this bag's: see `barry hosting status lists.web`.
A public route to it must be gated, since the origin's only auth is the secret.