@lampdotdev/lamp 0.0.0-stage → 0.35.0

package/Resources/skills/mac-widgets/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: mac-widgets
+description: A Mac app's widget for the desktop and Notification Center (Widget/) - how it's written and drawn, the data the app hands it, buttons in it, a widget with no app window, and what to tell the person. Read before writing or changing anything in Widget/.
+---
+
+# A widget for the desktop and Notification Center
+
+## Writing it
+
+Write it with WidgetKit and SwiftUI in a `Widget/` folder at the app's root, beside Sources/, starting with
+Widget/Widget.swift: one `@main`, on the `Widget` or on a `WidgetBundle` for several. Lamp builds that folder into the
+app as its widget. It is a separate program that shares no code with Sources/: nothing from LampSupport.swift exists
+there, and a type both sides need is written on both.
+
+- Use `StaticConfiguration` with a `TimelineProvider`, a `configurationDisplayName` and `description` in the user's
+  words, `supportedFamilies` from .systemSmall, .systemMedium and .systemLarge, and
+  `.containerBackground(for: .widget) { … }` on the view, without which it shows nothing.
+- Put `.lampWand()` on each widget's whole view too (`.lampWand(edgeToEdge: true)` with `.contentMarginsDisabled()`):
+  it's Lamp's wand in the top right corner, which opens the app's chat, so leave that corner empty.
+- A widget is a picture macOS redraws from the timeline, not a running view: no timers, animation, scrolling or text
+  fields. `Text(date, style: .timer)` and `.relative` count by themselves, entries dated ahead change it on
+  schedule, and macOS refreshes it when it chooses, minutes apart at best. It may load from the web with URLSession.
+
+## The app's data
+
+The widget can't read what the app has saved (LampStore, files, settings), so the app hands it over:
+
+- In the app, `LampWidget.share(Summary(…), as: "summary")` with any Codable value, at launch and whenever the data
+  changes (it also redraws the widget).
+- In the widget, `LampWidget.read(Summary.self, from: "summary") { summary in … }` in getSnapshot and getTimeline, or
+  `await` it. That comes from Widget/LampWidgetSupport.swift, which Lamp writes: never edit it. It gives what the app
+  shared last, also while the app is closed, and nil until the app has run once: then show a short line asking to
+  open the app.
+- Share a small value made for the widget, not everything, and declare its type on both sides.
+
+A button or toggle in the widget changes the app's data through the app: in Widget/, an App Intent whose `perform()`
+calls `await LampWidget.perform("addWater", 250)` (a name, and any Codable value or none) and returns `.result()`,
+shown with `Button(intent: AddWater()) { … }`; in the app, at launch, `LampWidget.onAction { name, payload in … }`
+does it (`payload.decode(Int.self)`) and shares what changed, and the widget redraws. It works with the app closed
+too: the app does it when it next starts.
+
+## When the widget is all they asked for
+
+When a widget is all the user asked for ("make me a countdown widget"), they get only the widget, with no app
+window: make Sources/App.swift just `@main struct MainApp: App { var body: some Scene { LampWidgetOnly() } }`, with no
+commands, delete Sources/ContentView.swift with delete_file, and put everything in the widget, which works out what it
+shows by itself (the date, the web). Such an app has no window, no Dock icon and is never opened, so don't call
+`look_at_app` or `use_app` for it.
+
+Only when the widget has to show something an app must fetch or keep for it (the user's files, calendar or mail,
+what they type in, an AI answer) does it get a real app, which shares that with `LampWidget.share` and lives in the
+menu bar (`LampMenuBar`, with its Quit button; the menu-bar skill says how) unless the user asked for a window too.
+
+## What to tell the person
+
+Lamp shows the user a card that says how to add the widget and when it's on their desktop, so never explain how to
+add it, and never say you couldn't see it. When the request was for a widget, what you say once it's made is two
+sentences at most, on what the widget shows: no list of sizes or options, no assumptions, no "it's ready", no
+question at the end. A widget they placed stays through your changes and shows them by itself. To take the widget
+away, delete the files in Widget/.

package/Resources/skills/maps/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: maps
+description: A real place from map data (OpenStreetMap) - a town to drive or walk through, a campus, a neighborhood, with its buildings, roads and shops. Read before fetching or drawing map data.
+---
+
+# Real places from map data
+
+A real place (a town to drive, a campus, a neighborhood) comes from OpenStreetMap. Fetch it from the Overpass API (overpass-api.de, else a mirror), one bounding-box query for everything in the box and what it's made of (`nwr(…); (._; >;); out;`: nodes too, since trees, shops and signals are often single points), waiting and trying again when it's busy; never OpenStreetMap's own editing API, which its rules keep from bulk downloads. Turn it, while building, into a compact file in Assets/ that the app reads (meters from a center point, footprints already triangulated), not raw OSM parsed at launch. Worth reading: each building's footprint, `height` or else `building:levels` (about 3.3 m a floor) or else a guess from `building` (house, garage, apartments, university…), `roof:shape`, `building:colour`, `roof:colour` and `building:material` (use them when they're there, and choose from the building's type only when they aren't), and `building:part` for landmarks' stepped parts; roads with `highway`, `width` or `lanes`, `oneway` and `name`; traffic signals, crossings, footpaths and trees; the ground: parks, gardens, pitches, grass, cemeteries (`leisure`, `landuse`), water and rivers (`natural=water`, `waterway`), woods (`natural=wood`, `landuse=forest`), car parks; shops and amenities with `name`, `opening_hours` and address. Large areas and buildings with courtyards are often relations (`type=multipolygon`), not closed ways: join their `outer` members' ways end to end into rings and cut out the `inner` ones, or the biggest parks, the river and many landmarks go missing. An area larger than a tile (a park, a river, a lake) is cut along the tile edges while building the map file, each piece clipped to its square and drawn by that tile, so it shows wherever the player is in it, not only near its center. In a 3D scene, stream the world by tile (the scene-3d skill's `scene.stream`), and show "© OpenStreetMap contributors" on screen.

package/Resources/skills/menu-bar/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: menu-bar
+description: A Mac app that lives in the menu bar (LampMenuBar) - a panel, a menu, or one thing the icon turns on and off, with its Settings and Quit, Lamp's wand, and how it stays within reach. Read before writing or changing a menu bar app or a menu bar icon.
+---
+
+# A Mac app in the menu bar
+
+Use `LampMenuBar` from LampSupport.swift as the app's scene, instead of `MenuBarExtra`:
+`LampMenuBar("Focus Timer", systemImage: "timer") { PanelView() }`, or `LampMenuBar { PanelView() } label: { … }` for
+an icon or text that changes, with `.commands { LampCommands() }` on it and a `Settings` scene beside it.
+
+It gives the app an icon with a panel and no Dock icon, and keeps it within reach: it opens the panel as a normal
+window when the icon is hidden (a full menu bar, the notch), shows the panel when the app is opened again, and puts
+the app in the Dock while one of its windows is open. So never call `NSApp.setActivationPolicy` or add a window just
+to make the app reachable.
+
+## The panel
+
+- Such an app has no Dock icon and no menus, so the panel needs its own Settings button, which calls
+  `LampMenuBar.openSettings()` (never `SettingsLink` or `openSettings`: from a menu bar app those open the window
+  behind other apps, where it gets lost), and its own Quit button (`NSApp.terminate(nil)`).
+- `LampMenuBar.close()` closes the panel after an action in it.
+- Put `LampPanelWand()` beside the panel's own buttons, at the right of its header (or of its footer, beside Settings
+  and Quit, when the header has none), as a window has Lamp's wand in its title bar (without it, Lamp gives it a
+  strip of its own above the panel).
+- Give the panel a fixed width, and hand it its model inside the braces (`{ PanelView().environmentObject(model) }`),
+  never with a modifier on the scene, which crashes the panel.
+- Pass `dockIcon: true` only when the app also has a main window.
+
+## A menu, or a switch
+
+- For a menu instead of a panel: `LampMenuBar(menu: "Clipboard", systemImage: "list.clipboard") { Button(…);
+  Toggle(…); Divider() }`, which adds Settings… and Quit itself (`settings: false` when there's no Settings scene).
+- For one thing the app turns on and off: `LampMenuBar("Keep Awake", isOn: $model.awake, on: "cup.and.saucer.fill",
+  off: "cup.and.saucer") { more menu items }`, where a click flips it and a right-click shows the menu; keep that
+  state in the App (@StateObject or @State) so the icon follows it.

package/Resources/skills/more-apps/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: more-apps
+description: Whether a request is for one more app beside the ones the project has, or a change to an app it has - "never mind, make it a timer instead" versus "also an Android app" - asking the person before adding one, why a second app of a kind the project has (two Mac apps) can't be added yet, and how to call make_app_for for each (`app` or `another`). Read before adding an app to a project that has one.
+---
+
+# One more app, or a change to the one the project has
+
+A project that has an app (made, or still waiting to be made) never gets another by accident: `make_app_for` refuses a
+call that names neither `app` nor `another`. Which one you give is the person's choice, read from what they asked.
+
+## A change to the app they have
+
+Most requests are this. The person changes their mind or wants something else in its place:
+
+- "Actually never mind, make it a pomodoro timer instead."
+- "Make it do X instead." "Turn it into a game." "Can it be for my iPhone too?"
+
+Change the app the project has. When only what it does changes, change its code: no `make_app_for` at all. When what it's
+made for changes (other devices, web or native), call `make_app_for` with its folder in `app` ("." for the app in the
+project's own folder). It keeps its folder, its saved data and its place among the project's apps. Never add an app for a
+change of mind, and never take the old one away to make room: the person didn't ask for either.
+
+## One more app, of another kind: ask first
+
+A project can have one more app beside the ones it has only when it's of another kind: an Android app beside a Mac app,
+a TV app beside an iPhone app. Two apps of one kind (two Mac apps, two iPhone apps) can't
+be in one project yet, and `make_app_for` refuses one, nothing changed; a device's own app (a Roku's) is one per project.
+
+When the person seems to want another app of a kind the project doesn't have ("also make an Android app for my phone",
+"a web game to go with it"), ask them before calling `make_app_for` or writing anything, with `ask`: one short question,
+two answers in their words. Adding an app is theirs to choose, so ask even when the request sounds clear; it costs them
+one click.
+
+- Question: "An Android app as well, or make this one Android?"
+- Answers: "A second app" (one more app beside the one they have) and "Change this one" (the app they have, changed).
+
+End your turn after asking: their answer is the next message. Don't ask again when the message is already their answer
+to that question.
+
+- A second app: `make_app_for` with `another: true` and the devices and make of the new app. It goes in a folder of its
+  own, with its own name, id and data, and the project's other apps stay as they are.
+- A change: the app they have, as above.
+- Their own words instead: follow those.
+
+## Another app of the same kind
+
+When they ask for another app of a kind the project already has ("I want a second Mac app, a journal" in a project with a
+Mac app), don't offer a second app: it can't be added yet. Tell them so in a sentence, and offer what can be done
+with `ask`: change the app they have into it, or make it a separate app of its own (from Lamp's desk). Never add it
+by changing what it's made for so it slips in as another kind, unless that's what they asked for: another make than the
+defaults give (the web-or-native skill), only to get around this limit, is never the answer.
+
+Never answer the question for them, and never add an app for a change of mind.

package/Resources/skills/phone-controllers/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: phone-controllers
+description: What to weigh when phones are to be controllers or a second screen for a game or app - whose phones, who can host them, a page or an app on the phones, and what Lamp can't do yet. Read whenever someone wants to play or steer something with their phone.
+---
+
+# Phones as controllers: what to consider
+
+"A game I can control with my phone" can be made several ways. Before building, think through these, and ask the
+person only what you can't tell from the request (one short line, about people and devices).
+
+`make_app_for`'s table says what each device runs; it doesn't yet say which apps can take phones, because that
+depends on how an app is made and run, not on the device alone. What follows is that account.
+
+## Whose phones?
+
+- **Several people's** (family, friends, a class): each phone has to join with nothing to install. That's a page for
+  phones: they scan a QR code on the screen and play in their browser. The phone-pages skill says how to build it.
+- **Only the person's own phone**: on an iPhone, an app of the project's own, made natively, is the controller: it has
+  the phone's own feel, hardware and haptics, and keeps its data, and joins as a player with `LampController` over
+  `LampWish`. Installing it goes the way the table says for that phone. An Android app has no `LampController`, so it
+  can't join a game as a player: for game controls on an Android phone, native is out of reach and a page is the
+  answer. A native Android app still suits plain messages to the TV app through `LampWish` (a few commands, a
+  photo sent). A page works for an iPhone too, when they ask for one.
+
+## What hosts phones today
+
+Phones join in two separate ways.
+
+A phone's browser, joined by a QR code, needs a phone page (`Phone/index.html` in the app's own folder, beside its
+`Web/`: the phone-pages skill says where) and a page on the screen that uses lamp.js's `Lamp.controllers`. Two kinds
+of app have both:
+
+- a game on Lamp's game runtime (`make_app_for` with `kind` "game");
+- a TV app's page: while it's open on a Samsung or LG TV or in its TV preview on this Mac.
+
+Who serves the phone page and runs the link phones join is the game's choice, `Lamp.controllers.start({ host })`
+(the phone-pages skill):
+
+- Game-owned hosting (`'game'`) runs with the game and needs no Lamp. The game has it on the Mac, on an iPhone or iPad
+  while it's in front, on an LG TV from webOS 5 on, where Lamp packages a service with the game, and on the Xbox,
+  where the game's own host runs it.
+- Lamp hosting (`'lamp'`) needs Lamp open and the Mac reachable. Lamp has it for the TV preview, a Samsung or LG TV and
+  the Xbox.
+- Device networking and store rules can affect either one.
+
+They're options, not an order, and another approach is fine. A host that isn't there, or fails, is said in
+`onError`; the game never moves to the other one by itself. `start()` with no host keeps where each device ran before.
+
+An iPhone app of the project's own needs no browser page: it joins the TV app's game as a player with `LampController`
+over `LampWish`. An Android app has no `LampController` and doesn't join as a player. Every app of the project's talks to
+the others through `LampWish` (messages, shared values, files) on whichever devices they're on (the wish-links skill).
+
+On an iPhone or iPad the game's own phones play only while the game is in front: when the person leaves it, every
+phone is let go, and once they come back the game shows a new code to scan (`Lamp.controllers.onLink` hears it).
+
+Neither host covers a game played on Android, a page shown by Lamp's other hosts, or a native app yet. Say so plainly
+when the person asks for phones there.
+
+## A page or an app on the phones?
+
+For the person's own iPhone, an app of the project's on it, made natively. For game controls on an Android phone, a page,
+since a native Android app can't join as a player.
+For several people's phones joining one game or TV app, a page: nothing to install, and any phone on the Wi‑Fi joins (that's
+one app shared across devices, the case where web-or-native chooses web). The web-or-native skill has the rest of that
+choice.
+
+## Away from home
+
+Phones reach the phone page on the same Wi‑Fi, whichever host serves it. Friends in other
+homes can't join through it: say so if that's what they want. Apps of the project's that talk through `LampWish` work
+by its own rules (the wish-links skill).
+
+## Building it
+
+In a game, the game-ui skill ("With phones") settles what the shared display and each phone show in each phase, who
+steers a menu, and what this player does on the phone. Once you've chosen, open the phone-pages skill: the page in the app's own Phone/, `LampController` on the phone and
+`Lamp.controllers` on the screen, files, tilt, second screens, how a game's controls are held, how views and moves
+go between the game and the phone, and how to see and press the page yourself. A game on Lamp's runtime reads phones' buttons each frame from `f.phones` (the game
+skill), which keeps a quick press that `onButton` alone can lose between frames.

package/Resources/skills/phone-pages/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: phone-pages
+description: How to build a page for phones on the same Wi-Fi - phones as controllers (buttons, sticks, a wheel, a buzzer, a game's own interaction, how views and moves go between game and phone), a second screen joined by a QR code, or sending the TV a file (a photo, a game, a song). Read before writing Phone/ or using Lamp.controllers or Lamp.phonePage.
+---
+
+# Phones as controllers and second screens
+
+The phone's page goes in the app's own `Phone/` folder, beside its `Web/`: `index.html` and the files beside it, loaded with relative paths. In an app shared with the person, the phone's browser lets the page load only its own files, its link to the game and the sites its review named: keep everything such a page uses (scripts, styles, fonts, pictures, sounds) in `Phone/`. The app is a game on Lamp's runtime or a TV app, and its folder is the one `make_app_for` returned: an app at the project's root has `Phone/index.html` beside `Web/index.html`, and one in a folder of its own (`TV/`, `Game/`) has `TV/Phone/index.html` beside `TV/Web/index.html`. Lamp serves only the app's own `Phone/`, so a page anywhere else (a `Phone/` at the project's root beside `TV/`) is never served and its link answers "not found". Write the path from the project's folder in every file tool call: a `cd` in a shell command doesn't change the folder later file tools write in. It runs in the phone's own modern browser, so it isn't held to the TV's 2019 syntax. The page is served, and the phones' input and files go to the screen over the home Wi-Fi, by the host the game chooses as it starts (below): the game itself or Lamp on the Mac. Nothing secret goes in `Phone/`: anyone on the Wi-Fi with its address can load it. Whatever carries the phones, keep what Lamp's hosts keep: a link a phone opens is an invitation for anyone who has it, so make it short-lived and never put the app's own keys or the person's data in it, the page or its messages; let in only the game's own page and the phones it invited; and send nothing past the home network unless the person asked for that. Phones need nothing in capabilities.json: Lamp gives the system its reason for them. A `localNetwork` reason there says the app reaches the person's devices, so pressing anything in it with `use_app` needs a device they allowed (the device-control skill).
+
+## Controllers
+
+On the phone, the page loads `lamp-controller.js`, which Lamp serves beside it (don't write one): `<script src="lamp-controller.js"></script>`.
+
+```js
+var pad = LampController.connect({
+  onPlayer: function (n) { },      // this phone's player number (1, 2, ...)
+  onMessage: function (data) { },  // what the TV app sent this phone, or every phone
+  onState: function (state) { },   // 'connecting', 'connected', 'waiting' (the TV app isn't there), 'ended', 'full'
+  busy: function () { return false; },  // true while opening again would lose something (a drawing, a form)
+  onUpdate: function (apply) { }   // leave it out unless the page must choose: call apply() to open the newer page
+});
+pad.button('jump', true); pad.button('jump', false);  // a button held, then let go, named for what it does
+pad.axis('steer', x, y);                         // a stick, wheel or slider, each from -1 to 1
+pad.send({ ready: true });                       // JSON to the TV app, 16 KB at most
+```
+
+A page open on a phone takes what you save to Phone/ by itself where the host can, a few seconds later: it opens again as the same player once no button is held, no file is on its way, nothing is being typed and `busy` says false. So keep a form's or a drawing's work behind `busy`, or give `onUpdate` a button when only the person should choose. Phones and the TV don't switch at the same moment, so a change of what they send each other should still read the other side's old messages.
+
+Make each control big enough for a thumb, show the player's number and the state (say plainly when the TV app isn't there or the game has ended), and send a button's press and its release, so the TV can tell held from tapped. The number comes from the TV app once it's there (`onPlayer`), so show the state until then. `onState` runs during `connect()` itself, before it returns, so set up everything it touches first: a first draw that throws there stops the page's script and leaves the phone on its loading text.
+
+`pad.button`, `pad.axis` and `pad.send` return false when nothing was sent: show that state, never a press that went nowhere.
+
+### How a game's controller is held
+
+The game-ui skill ("With phones") settles what the controller is, and that settles how it's held. A two-thumb page is made for landscape: movement on the left, the main action on the right, and the player, the link and Back quiet in the middle or along the top. Compose those zones for the game and its verbs; a portrait layout stretched sideways isn't this. A page built around one big interaction (a lock, a dial, a hand of cards) and a page that isn't game controls (photos, files, a scoreboard) stay whichever way suits them, with the same safe areas and the same care when the phone turns.
+
+- Lay it out with `viewport-fit=cover` in the viewport tag, `env(safe-area-inset-*)` around the edges and `100dvh` for the height, so a notch and the browser's bars don't sit on a control.
+- Nothing forces a phone sideways. `screen.orientation.lock` works in few browsers and usually only full screen: try it after a tap if you like, handle its failure, and make the page right without it. Never rotate the page with CSS.
+- Joining and typing a name may stay upright, and the keyboard changes the viewport's shape: decide what `@media (orientation: …)` shows from the game's phase too, so a keyboard never hides the name field behind "turn your phone".
+- A two-thumb page held upright during play: keep the player and the link on screen, show a themed "Turn your phone sideways", take no play gestures, and offer "Use upright" with a compact layout for someone who can't rotate. Keep Back reachable, and never pause the party for one phone turning.
+- If the phone turns during a press, end any gesture (below), send every held button's release and zero every active axis, drop the page's own pointer capture and gesture state, and ask for a fresh press. The page keeps track of what's held; never close the link to clear it. Turning back restores the phase as it was, with no new join and no reset.
+
+```js
+var held = {};
+function press(name, down) { if (down) held[name] = true; else delete held[name]; pad.button(name, down); }
+function letGo() {
+  Object.keys(held).forEach(function (name) { press(name, false); });
+  pad.axis('steer', 0, 0);                         // every axis this page moves
+}
+matchMedia('(orientation: landscape)').addEventListener('change', letGo);
+```
+
+### Views and moves
+
+The game owns what's true; a phone draws what it's told and asks for moves. There's no second state machine on the phone.
+
+- **Views.** Derive each player's view from the game's state in one function, and send it to that player alone (`send(player, view)`, never player 0 for anything private) whenever what it holds changes, not only when the phase does: a wrong attempt changes the view with no change of phase. It goes out on `onJoin` too, which also runs for a phone coming back and for a page that opened again, and for phones already joined when the code runs again: `onJoin` puts that in the moves' queue, so the view that lets a phone act again answers every move it sent before. The phone keeps nothing it can't get back from its next view. A player with no part in the current view, like one back from a dropped link, is shown that and when they're next in, never an empty screen.
+- **Turns.** Each view carries the phase and a `turn` the game moves on whenever an old screen's move would no longer mean the same thing (a new round, a new turn). A move names the `turn` it was made on, and an `id`, since a `turn` can't tell two moves in one turn apart: one more than the `answer.id` in the view it was made on (below), so ids come from the game and survive the page opening again.
+- **Moves.** Send the finished move as one bounded message: `pad.send({ move: 'try', id: id, turn: view.turn, path: path })`. `pad.axis` is for live movement only: an axis is dropped when the game is behind and late ones are thrown away, so never build a result from them. Collect a path on the phone and send it when it ends.
+- **The game decides.** `f.phones` holds buttons only; axes and messages come by `onAxis` and `onMessage`, between frames, so the game keeps its own queue and empties it in `frame`, never a flag `frame` clears. It drops a move from another phase or `turn`, whose phone has already moved on, and takes one with an `id` no newer than the player's last answer as a repeat, which changes nothing and only sends the view again. For any other move it checks the player and the move's size and shape, accepts or rejects it, and keeps that for the player. Every view carries that as `answer: { id, ok }`, `{ id: 0 }` before the first.
+- **One move at a time.** After sending, a phone takes no new move until a view's `answer.id` reaches it or a view has another phase or `turn`: views go out for other reasons too, and `send` returning true only means it went out. There's no timer that offers a fresh move, because a move that's late can still land, and two ids would count twice. A message can be dropped when the game is far behind, so a game whose turn can sit forever may send the same move again, same `id`, after a few seconds. A phone that loses its link forgets a waiting move and never sends it again after a reconnect; the view it comes back to says what happened.
+- **Input needs a current view.** A view belongs to the link it came on: take input only once one has arrived, and stop when `onState` leaves `connected`, until the view queued by `onJoin` comes on the new link.
+- **A gesture that's interrupted is no move.** Track the finger's `pointerId` and capture it. End the gesture, send nothing and clear what it drew on that finger's `pointercancel` or `lostpointercapture`, when the page is hidden (`visibilitychange`), when the phone turns, when `onState` leaves `connected`, and when a view arrives with another phase or `turn`. Only that finger's `pointerup` in the same `turn` submits, and it ends the gesture first, so the `lostpointercapture` that follows a normal release finds nothing to cancel. Keep `busy` true during a gesture so a newer page waits for it.
+
+```js
+var view = null, live = false, path = null, finger = null, waiting = null;
+function cancel() { path = null; finger = null; draw(); }
+var pad = LampController.connect({
+  onMessage: function (next) {
+    var moved = view && (next.turn !== view.turn || next.phase !== view.phase);
+    if (moved) { path = null; finger = null; }
+    if (moved || next.answer.id >= waiting) waiting = null;  // any other view isn't an answer
+    view = next; live = true; draw();
+  },
+  onState: function (state) {
+    if (state !== 'connected') { live = false; path = null; finger = null; waiting = null; }
+    draw();
+  },
+  busy: function () { return !!path; }
+});
+lock.addEventListener('pointerdown', function (event) {
+  if (!live || path || waiting !== null) return;
+  finger = event.pointerId; lock.setPointerCapture(finger); path = []; draw();
+});
+lock.addEventListener('pointerup', function (event) { if (event.pointerId === finger) finish(); });
+['pointercancel', 'lostpointercapture'].forEach(function (name) {
+  lock.addEventListener(name, function (event) { if (event.pointerId === finger) cancel(); });
+});
+document.addEventListener('visibilitychange', function () { if (document.hidden) cancel(); });
+matchMedia('(orientation: landscape)').addEventListener('change', cancel);
+function finish() {                                     // the finger lifted, or Submit
+  if (live && path) {
+    var id = view.answer.id + 1;
+    if (pad.send({ move: 'try', id: id, turn: view.turn, path: path })) waiting = id;
+  }
+  path = null; finger = null; draw();
+}
+
+// In the game: moves wait for the frame, and the state decides.
+var moves = [];
+Lamp.controllers.onMessage(function (player, data) { moves.push({ player: player, data: data }); });
+Lamp.controllers.onJoin(function (player) { moves.push({ player: player, joined: true }); });
+// in frame(f), the only place views are sent: for each of moves.splice(0): drop an old turn's; for a new id, check it,
+// change the state and keep { id, ok } for that player's views; then sendView for whoever's view changed, for a
+// repeat and for joined
+```
+
+### Seeing the page
+
+Lamp can't open or press this page itself: only the person's own phones join the game. Check it by reading it against
+the game's messages (what each view needs, what each press sends, the link lost and back, rotation with a control held),
+say plainly that you haven't seen it on a phone, and ask the person to try the whole journey on theirs: joining, the
+menu, play, a move the game rejects, results, the link lost and back, and rotation with a control or a gesture held.
+
+On the TV, in `Web/`, `Lamp.controllers` (lamp.js's comment) runs the game. It starts with a host:
+
+- `Lamp.controllers.start({ host: 'game' })`: the game serves the page and runs the link itself, with no Lamp: on the Mac, an iPhone or iPad while it's in front, an LG TV whose package carries the game's service (webOS 5 on), and the Xbox. Lamp's TV preview has no game host.
+- `Lamp.controllers.start({ host: 'lamp' })`: Lamp serves the page and runs the link, while Lamp is open and the Mac is reachable: in the TV preview, on a Samsung or LG TV and on the Xbox.
+- `Lamp.controllers.start()`: where it ran before either existed (the game itself on the Mac, iPhone and iPad; Lamp elsewhere).
+
+A host that isn't there, or fails, says so in `onError` and is tried again; the other one is never used instead. `stop()` ends the session the chosen host runs, and a later `start` may choose again. Then `onLink(fn(url))` for the address phones open, to show as a QR code (below; it changes every few minutes, and `fn` is called again each time), `onJoin`/`onLeave(fn(player))`, `onButton(fn(player, name, down))`, `onAxis(fn(player, name, x, y))`, `onMessage(fn(player, data))`, `onError(fn(message))`, `send(player, data)` (player 0 for every phone; 16 KB of JSON at most), `isHeld(player, name)`, `players()` and `stop()`. A phone that leaves or drops has every button it held let go before `onLeave`, and movement that arrives late is dropped, so the game never acts on a stale stick. A game on Lamp's runtime reads buttons each frame from `f.phones` rather than `onButton` (the game skill).
+
+The session belongs to the page, not to one run of the game's code. When Lamp runs a game's code again in place for a change, phones stay joined with their numbers, so the code sets its `on…` callbacks as it starts and calls `start` as usual (with the same host it's already running, it changes nothing), and nothing stops or restarts the phones; a `stop()` in `dispose` is ignored. Before the new code's first frame, `onLeave` and `onJoin` hear who left and who is here, so `onJoin` is written to be called again for a player the game already has: the game skill's snapshot rule says how slots come back. The phone keeps its page and number throughout and sees no change.
+
+### The join code
+
+Draw the code with `LampQR`, which lamp.js has (its comment says how): never write a QR encoder or load one. A join link carries a signed credential, so it's long (about 170 characters, more with a long name or host); `LampQR` fits any length a link has.
+
+```js
+var code = document.getElementById('join-code');   // a <canvas> in the join card
+Lamp.controllers.onLink(function (url) {             // before start(), so the first link is drawn too
+  try { LampQR.draw(code, url, { size: 240 }); joinNote.textContent = 'Scan to play'; }
+  catch (e) { joinNote.textContent = 'Couldn\'t draw the code: ' + e.message; }
+});
+Lamp.controllers.onError(function (message) { joinNote.textContent = message; });
+Lamp.controllers.start();
+```
+
+In a game, the join card is a screen of its own, not part of a title (the game-ui skill has the flow, and what the shared display and each phone show in each phase): show it at once when the player goes to join, or from setup or pause to add players, and a game played only with phones may open on it. While it's up it says when the game is getting ready for phones (until the first link), when phones can't join and when it's trying again. Keep the session running behind it: hiding the card never calls `stop()`, drops a player or starts again. While it's hidden, keep the newest `onLink` address and the newest error rather than a picture of an old code, and draw the card from those when it opens, finding its elements again, since a change to the code may have made them anew. Register the handlers before `start()` in every case, and keep the links short-lived. A page that isn't a game (a second screen, a file sent to the TV) may show its code from the start. Draw into the same canvas each time `onLink` calls again. A code that couldn't be drawn and phones that can't join (`start()` rejects, `onError`) each say so in the card; neither hides it as if the game had no phones. In a game drawn on a canvas (three.js, Phaser), put the join card in HTML over it, or draw `LampQR.matrix(url)` (its `size` and `dark(x, y)`) into the scene yourself, with a light border four modules wide.
+
+## Files
+
+One message, as the JSON that goes out, is at most 16 KB (`LampController.messageLimit`, `Lamp.controllers.messageLimit`), either way. A bigger one isn't sent: `send` returns false, and the TV app's log (and its `onError`) says so with its size. `send` also returns false while the other side isn't there.
+
+Anything bigger (a photo, a game for the TV to play, a song, a document) is a file, sent in pieces with its own progress, so buttons pressed meanwhile still arrive at once. Never cut it into messages yourself, as text or base64.
+
+```js
+// On the phone: a File from <input type="file">, a Blob, an ArrayBuffer, bytes or text, up to 64 MB.
+var sending = pad.sendFile(input.files[0]);          // or pad.sendFile(bytes, { name: 'level.json', type: 'application/json' })
+sending.onProgress(function (sent, size) { });     // show it
+sending.done.then(function () { }, function (error) { /* error.message: say it */ });
+sending.cancel();
+
+// On the TV, in Web/:
+Lamp.controllers.onFile(function (player, file) {  // file.name, file.type, file.size
+  file.onProgress(function (received, size) { });
+  file.done.then(function (arrayBuffer) { }, function (error) { });
+});
+```
+
+The TV sends a phone a file the same way, with `Lamp.controllers.sendFile(player, data, { name, type })`, which the phone hears in `onFile` (passed to `LampController.connect`). A file whose player leaves, or whose link drops, ends with an error: say so and let the person send it again. Keep a TV's memory in mind: read what arrived and let it go rather than keeping many large files.
+
+## Tilt
+
+The page is plain http, and phones give their motion sensors only to https pages. So a game's controller is a touch interaction that's usable without tilt, whatever shape the game-ui skill's design gave it. Offer tilt only where `LampController.canTilt()` says so, from a tap (a Start button), since the browser asks the person first: `LampController.tilt(pad).then(...).catch(...)` then sends the phone's tilt as axis `'tilt'` (x: left -1 to right 1, y: away -1 to toward 1). Where it can't, the game must still be fully playable by touch. The wake lock and `navigator.vibrate` are extras in the same way: many phones won't give them to this page, so try them, handle their failure, and let nothing depend on them.
+
+## The project's own apps
+
+A phone's page is not one of the project's apps. When the project has an iPhone, Mac or Android app beside the TV app, those apps and the TV page see each other and talk through `LampWish` (`Lamp.wish` in lamp.js, `LampWish` in LampSupport): who is open now, and messages between them. `Lamp.controllers` and `LampController` are for steering the TV (buttons, sticks, files to the TV); for anything else between the project's apps, use `LampWish`, whose comment in lamp.js and LampSupport says how.
+
+## A second screen
+
+For a page that shows something beside the TV rather than steering it (a hand of cards, a scoreboard, a buzzer that needs no game), the TV page draws a QR code of `Lamp.phonePage(hash)` with `LampQR.draw`, the page's address with `#hash` after it, inside `Lamp.onPhonePage(fn)`: it's called at once when there's an address and again whenever it moves, so redraw the code there. It's null when the app has no `Phone/index.html`. `Lamp.phonePage` and `Lamp.onPhonePage` are a TV app's page's only: a game on Lamp's runtime draws its QR code of the address `Lamp.controllers.onLink` gives (the join code, above), so every phone that opens it joins as a player, and what each phone shows is what the game sends it (`send`). What the phone and the TV say to each other goes through `Lamp.controllers` and `LampController` (`send` and `onMessage`, `sendFile` and `onFile`).

package/Resources/skills/roku-developer-mode/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: roku-developer-mode
+description: How Lamp walks the person through turning on developer mode on their Roku the way Roku documents it - pressing the remote's secret keys over the Roku's own control protocol, then waiting while the person enables the installer, accepts the license and sets a developer password, and the Roku restarts. Lamp's Roku setup follows the steps below when the person clicks Do It for Me.
+setup-for: roku
+setup-step: developer-mode
+---
+
+# Turning on developer mode on a Roku
+
+A Roku takes the person's own channels once its developer mode is on. Roku documents how
+(https://developer.roku.com/docs/developer-program/getting-started/developer-setup.md): press Home three times, Up
+twice, then Right, Left, Right, Left, Right on the remote; the developer screen opens; enable the installer, accept the
+Developer Tools License Agreement, enter a password, and the Roku reboots.
+
+Lamp can press those keys for the person: Roku's External Control Protocol takes `POST /keypress/<key>` on port 8060
+(https://developer.roku.com/docs/developer-program/debugging/external-control-api.md), once Settings > System >
+Advanced system settings > Control by mobile apps is Enabled, which is the Roku setup's step before this one. The
+license and the password are the person's, on the Roku: Lamp never presses them.
+
+What Lamp sees: that the Roku answers on port 8060, that it went away and came back (the reboot), and
+`developer-enabled` in `/query/device-info` reading `true`. Nothing else is said done.
+
+## What Lamp never does
+
+- Accept the license or choose the password for the person, or press anything on those screens.
+- Press the keys again after a failure part way: it can't tell which reached the Roku, so the person finishes this
+  step on the remote instead.
+- Press the keys when `developer-enabled` already reads `true`.
+
+## Not yet checked on a real Roku
+
+- The whole guide. Every request and value comes from Roku's documents and Lamp's Roku integration, whose own
+  developer-mode step presses the same keys the same way.
+- Whether a Roku that already had developer mode on and was set up again goes straight to the password.
+
+## The steps
+
+Lamp's setup reads this block and follows it in order; the frontmatter says it does the Roku setup's
+`developer-mode` step, on any Roku. `{name}` is the Roku's name. The connection is plain HTTP, as the Roku
+integration's own steps are.
+
+```lamp-setup
+{
+  "connection": "http",
+  "offer": "Lamp presses the Roku's secret keys; you accept the license and set a password.",
+  "reach": [
+    { "http": { "port": 8060, "path": "/query/device-info" } }
+  ],
+  "steps": [
+    {
+      "do": "connect",
+      "doing": "Checking {name} answers…",
+      "done": "{name} answers"
+    },
+    {
+      "do": "request",
+      "run": [
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Home" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Home" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Home" } },
+        { "wait": 3 },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Up" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Up" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Right" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Left" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Right" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Left" } },
+        { "http": { "method": "POST", "port": 8060, "path": "/keypress/Right" } }
+      ],
+      "unless": [
+        { "http": { "port": 8060, "path": "/query/device-info" }, "xml": "developer-enabled", "equals": "true" }
+      ],
+      "doing": "Pressing the keys that open the developer screen on {name}…",
+      "done": "Pressed the keys that open the developer screen on {name}",
+      "failed": "Lamp couldn't finish pressing the keys. On the Roku's remote, press Home three times, then Up, Up, Right, Left, Right, Left, Right."
+    },
+    {
+      "do": "rejoin",
+      "ask": "On the Roku, choose Enable installer and restart, accept the license, then set a developer password. The Roku restarts; Lamp carries on once it's back.",
+      "button": "It Didn't Restart",
+      "unless": [
+        { "http": { "port": 8060, "path": "/query/device-info" }, "xml": "developer-enabled", "equals": "true" }
+      ],
+      "link": {
+        "title": "Roku's Developer Setup",
+        "url": "https://developer.roku.com/docs/developer-program/getting-started/developer-setup.md"
+      },
+      "done": "{name} is back on"
+    },
+    {
+      "do": "wait",
+      "until": [
+        { "http": { "port": 8060, "path": "/query/device-info" }, "xml": "developer-enabled", "equals": "true" },
+        { "tcp": 80 }
+      ],
+      "every": 3,
+      "doing": "Waiting for developer mode…",
+      "done": "Developer mode is on"
+    },
+    {
+      "do": "handoff",
+      "ask": "Type the developer password you just set on the Roku."
+    }
+  ]
+}
+```

package/Resources/skills/scene-3d/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: scene-3d
+description: 3D in a Mac app made natively, in Swift (RealityKit through LampSceneView) - a world to move through, a room, a thing to turn over and handle, a toy, or a 3D game the person asked to be native, and RealityKit's own physics for things that fall, roll, stack and collide. A 3D game is made web by default (the game and 3d-game skills). Read before writing or changing 3D in Swift on the Mac.
+---
+
+# 3D scenes
+
+This is 3D in a Mac app made natively. A 3D game is made web by default, on the Mac as elsewhere (the game and
+3d-game skills); it's made here only when the person asked for a native game, or it's a Mac app already made in Swift.
+
+3D scenes (a world to move through, a room, a thing to turn over and handle): RealityKit through LampSceneView, from Sources/LampScene.swift, which Lamp adds to an app whose code imports RealityKit (the app then needs macOS 15). `LampSceneView(sky:camera:props:build:update:)`: sky `.day`, `.sunset`, `.overcast`, `.night`, `.studio`; camera `.orbit(target:distance:)`, `.chase("entity name")`, `.firstPerson()`, `.fixed(position:lookAt:)` or `.manual`; `build` adds entities to `scene.root`; `update(scene, dt)` runs every frame, with `scene.isDown(.w)` for keys. In a file that imports RealityKit, SwiftUI's `Scene` must be written `SwiftUI.Scene`.
+
+Things are made in code, in meters, from LampMesh (`box(size, corner:)`, `sphere`, `cylinder`, `cone`, `lathe([[radius, height], …])` for anything round, `extrude(path, depth:, chamfer:)`, `sweep(path, along:)`, `tube(along:radius:)`, `plane(width:depth:tile:)`, `text`) and LampMaterial (`metal`, `chrome`, `brushed`, `plastic`, `rubber`, `glass`, `paint`, `wood`, `fabric`, `ceramic`, `concrete`, `asphalt`, `brick`, `tiles`, `grass`, `glow`). A prop is a function returning one Entity of named parts at real size; the parts that move are `lampPress { }`, `lampTurn(axis:range:)`, `lampSlide(axis:range:)` and `lampGrab()`; `lampPhysics(.dynamic)` or `.static` for falling and knocking; `lampShadow()` under anything standing on the ground. Many copies of one thing go in one `LampScene.copies(of:at:)`. A world bigger than a few hundred meters (a town, a map, a landscape) is streamed, never built whole at launch: `scene.stream(tile: 100, radius: 400, around: { car.position }) { tile in … }` returns what's drawn on one tile (share things out with `tile.contains`), made as it comes into reach, by a named function (`{ tile in World.tile(tile) }`) so a change to it shows in the open app (anything else the app draws itself and should redraw after a change goes in LampSceneView's `onLiveChange`). A change that reshapes the view holding the LampSceneView gives it a fresh scene while the app's own objects carry on, so its `build` runs again on the same game: make `build` start clean (empty the lists, physics bodies and handles it fills, or make them anew) rather than add to what the last build left; what the game needs everywhere (collisions, routes, the map's data) is made once, outside it.
+
+Keep it smooth: a frame has about 16 ms, and anything the app does while it's open (a frame's update, a tile, a prop that appears in play, a level loading) takes from it, so a slow piece is a stutter. Make each mesh, material, texture and piece of text once and reuse it (`copies` for many of one thing, one text mesh per distinct word), never the same thing again per place; turn heavy data (a map, a level) into a compact file in Assets/ while building, not at launch; keep per-frame work to what moves. A streamed tile should take a few milliseconds: the log names slower ones. When a tile has much to work out (a town's buildings and roads from map data), split it so that work leaves the main thread: `scene.stream(tile:radius:around:, prepare: { World.plan($0) }, make: { World.tile($0, $1) })`, where `plan` returns a `Sendable` struct of what's on the tile (its shapes as filled `LampMeshBuilder`s, positions, colors) and runs on other cores, several tiles at once, touching no entity, material or state the app changes, and `make` turns it into entities on the main thread with `LampMesh.make(builders)` and shared materials, in a millisecond or two.
+
+Physics is RealityKit's own; nothing else is added for it. Most scenes need none: a thing moved by the app's own rules (a car along a road, a door that swings when clicked) is moved in `update`, and what it touches is tested there (distances, bounds). Use physics when things should behave like things: a stack that topples, balls that roll and knock into each other, something dropped, thrown or knocked over. `lampPhysics(.dynamic, mass:bounce:friction:)` makes a prop fall and be knocked about and `.static` what it lands on, from a `PhysicsBodyComponent` and a `CollisionComponent`. Its collision shape comes from its meshes unless the entity already has one, and for anything that moves it should: set `CollisionComponent(shapes: [.generateBox(size:)])` (or `.generateSphere(radius:)`, `.generateCapsule(height:radius:)`, several for a shape made of parts, `ShapeResource.generateConvex(from:)` for an odd one) before `lampPhysics`, never a detailed mesh. A body is `.dynamic` (moved only by physics: push it with `applyLinearImpulse(_:relativeTo:)` or `addForce(_:relativeTo:)`, never by setting its position each frame), `.static`, or `.kinematic` (moved by the app, pushing dynamic bodies without being pushed: a tilting board, a moving platform; give it a `PhysicsMotionComponent` velocity or move it in `update`). A fast small thing gets `isContinuousCollisionDetectionEnabled` on its body so it doesn't pass through thin walls. A player who walks, climbs steps and stands on slopes is a `CharacterControllerComponent(radius:height:skinWidth:slopeLimit:stepLimit:)` moved each frame with `moveCharacter(by:deltaTime:relativeTo:)`, gravity added by the app, `CharacterControllerStateComponent`'s `isOnGround` before a jump. Hinges, sliders, ball joints and welds are `PhysicsRevoluteJoint`, `PhysicsPrismaticJoint`, `PhysicsSphericalJoint` and `PhysicsFixedJoint` between two entities' pins (`entity.pins.set(named:position:orientation:)`), each `try joint.addToSimulation()`. RealityKit has no vehicle: a car the person drives is moved by the app, as most are. Collisions arrive as `CollisionEvents.Began` from the scene the world is in, which can change when the view is made again: in `update`, subscribe when `scene.root.scene` isn't the one subscribed to, keep the `EventSubscription`, and use the event for sounds and scores; a `CollisionComponent` with `mode: .trigger` is a zone felt but not hit (a goal, a pickup). Physics costs a frame's time too: resting bodies sleep by themselves, so leave them be; keep to a few hundred dynamic bodies, the simplest shapes that do, and no body made per frame.
+
+Model a real thing from a picture of it, never from memory alone. Before writing a main prop that is a real object (a car model, a building, a piece of furniture, an animal), get a reference: the person's photo from the chat, else one `make_art` of the object alone on a plain background, seen straight from the side (or the front, for something whose face matters), whole and uncropped. Read off it what code needs: its outline, proportions (length to height, where the parts begin and end), colors and the parts that make it recognizable. Small or generic props (a box, a pole, a cup) need none.
+
+Each prop that matters goes in `props` by name, and look_at_app with `prop` shows it on its own from four sides. Every distinct object made by its own function (a vehicle, a character, furniture, a machine) is a prop, the player's or main object first, and goes into the scene with `scene.place("car", at:heading:)`, which returns the entity to keep and move: so placed, a change to its code shows in the open app; other changes to the scene show when it reopens. Compare that with the reference: shape, proportions, colors, parts. Fix and look again, up to three rounds for the main props; background things get one look.
+
+LampSceneView already avoids RealityKit's flicker; keep it that way: no sun shadows (they make the whole picture flicker; `lampShadow` instead), and flat things laid on others (roads, markings, decals, a sign's writing) a few centimeters above them, never at the same height. After big changes, look_at_app with `motion`.
+
+A model code can't reasonably make can come ready-made from the `assets` tool (the assets skill), which fetches the .glb into Assets/<pack>/ and credits it: turn it into USD with `usdextract -o Assets/Name Assets/<pack>/name.glb` (part of macOS), and load it with `try await Entity(contentsOf: LampAssets.url("Name/name.usdc")!)`.
+
+A real place (a town to drive, a campus, a neighborhood) is built from map data: open the maps skill too.

package/Resources/skills/scripting/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: scripting
+description: LampScript, for behavior nobody can write in advance - what happens when two invented things meet, how a new kind of actor acts, a rule the person described in words - with the API it exposes and how scripts are written, cached and run. Read before using it.
+---
+
+# Behavior written while the app runs
+
+When the app needs behavior nobody can write in advance (what happens when two invented things meet, how a new kind
+of actor acts, a rule the person just described in words), use `LampScript` from LampSupport.swift:
+
+1. Expose a small, well-described API of what scripts may do (spawn, move, remove, say, plus `isTrue`/`ask` for
+   judgment).
+2. Set `purpose` to a sentence about the app.
+3. `write(...)` a script for a cache key, then `run(...)` it.
+
+Scripts are plain JavaScript in a sealed context with a time limit, cached by key in LampStore. Keep rendering,
+physics and movement in Swift; scripts decide what should happen, not how to draw it.

package/Resources/skills/share-extension/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: share-extension
+description: A share extension (Share/) that puts the app in the person's share sheets and takes in links, text, pictures and files without opening it - ShareView, LampShare in the app, signing, and what to tell the person. Read before writing or changing anything in Share/.
+---
+
+# A share extension
+
+Write Share/ShareView.swift: `struct ShareView: View { let items: [LampShare.Item]; var body: some View {
+LampShareSheet(items: items) } }` shows what's shared with Cancel and Save; a view of your own (a note, a list to file
+it in) ends with `LampShare.send(items)` or `LampShare.cancel()`. No `@main` there: Lamp builds the folder as a small
+separate program with Share/LampShareSupport.swift, which Lamp writes (never edit it), and nothing from Sources/.
+
+In the app, at launch, `LampShare.onReceive { items in … }` gets each share once, also those made while it was closed:
+`item.kind` (.text, .link, .image, .file), `item.text`, `item.url`, `item.name`, `item.image`, `item.data`; save what
+you keep there, as the files go after.
+
+You can't open a share sheet: check that it builds, and tell the user in a sentence that the app is in their share
+sheet.
+
+- On a Mac it needs Lamp to sign the app for the user's Apple team (`look_at_app` says when it can't), and macOS keeps
+  a new one off until the user turns it on once: Edit Extensions… at the foot of a Share menu.
+- In an app for the Mac and iPhone it is the iPhone half's: the Mac half has none.