p3
Skeleton

A phone browser tab, the server and one worker per session: the shape of every kit app. The tab is a client host (it serves nothing remote and reaches workers only through the server). The server owns the catalog. Each worker owns its session: the Durable records, the title, the transcript view.

The files

apps/p3/
  package.json              "@p3/app": exports ./v1, ./v1/server, ./v1/worker, ./v1/web; private
  start.ts                  base: startServer, prints the owner link
  worker.ts                 base: startWorker
  src/principals.ts         base: P3Principal
  src/api/v1/index.ts       base: shared API (Chord surface, defineFacet, Session, HostRuntime, KeepAlive)
  src/api/v1/server.ts      base: server API (Http, AppInfo)
  src/api/v1/worker.ts      base: worker API (Extensions, ModelProviders, HarnessNative, chord())
  src/api/v1/web.ts         base: web API (Sidebar, Screens, navigate, useRoute, React hooks)
  src/web/main.tsx          base: the page's entry: startPage, the two slots, the shell
  src/web/style.css         base: the shell's layout over the kit's theme variables
  plugins/harness/          worker.ts
  plugins/fake-model/       worker.ts
  plugins/sessions/         contract.ts, server.ts, worker.ts, web.tsx, messages.ts
  plugins/chat/             contract.ts, worker.ts, web.tsx, messages.ts
  test/                     the step's tests (chapter X)
  examples/00-skeleton.ts   a runnable walkthrough of the step

Every plugin passes the pluggability check: a third party could ship an alternative the same way. A different harness serves the same registries (one provider per registry, so it replaces harness, not joins it). Another model provider is another contributor to ModelProviders. Another session list or chat UI contributes to Sidebar or Screens. The catalog is the one part others build on by contract (SessionList), not replace: a plugin that wants other columns keeps its own table keyed by session id.

The start script is the tutorial's startTodo with p3's values. It is base code: a change restarts the server.

// apps/p3/start.ts
import { homedir } from "node:os";
import { join } from "node:path";
import { fileURLToPath } from "node:url";
import { startServer } from "@earendil-works/chord/app";
import { BACKGROUND_CONTEXT as context } from "@earendil-works/chord/context";
import { pageScripts } from "@earendil-works/chord/surfaces";
import * as v1 from "@p3/app/v1";
import { API, KINDS } from "./src/kinds.ts";
import type { P3Principal } from "./src/principals.ts";

const app = await startServer<P3Principal>(
	{
		name: "p3",                                            // ~/.p3 unless argv[2] names another directory
		dataDir: process.argv[2],
		root: fileURLToPath(new URL("./plugins/", import.meta.url)),
		listen: { host: "127.0.0.1", port: 8789 },             // p2 keeps 8788 (decision 3)
		api: API,
		kinds: KINDS,
		principal: { server: { kind: "server" }, worker: (address) => ({ kind: "worker", session: address.key }) },
		workers: [
			{
				kind: v1.Session,
				entry: fileURLToPath(new URL("./worker.ts", import.meta.url)),
				execArgv: ["--experimental-strip-types", "--no-warnings"],
				start: () => ({}),
				// Step 0 is the owner's alone; guests arrive with sharing (step 3).
				authorize: (principal) => principal.kind === "owner" || principal.kind === "server",
			},
		],
		web: {
			entry: fileURLToPath(new URL("./src/web/main.tsx", import.meta.url)),
			page: (request, assets) =>
				`<!doctype html><html><head><meta charset="utf-8"><meta name="viewport" content="width=device-width"><title>p3</title>${pageScripts(assets, request.nonce)}</head><body><div id="root"></div></body></html>`,
			paths: ["/", "/s/:id"],
		},
		base: [fileURLToPath(new URL("./src/", import.meta.url)), fileURLToPath(import.meta.url)],
		onError: (error) => console.error("p3:", error.kind, error.error),
	},
	context,
);
console.log(`Open ${app.ownerLink()}`);

// apps/p3/worker.ts
import { startWorker } from "@earendil-works/chord/app";
import { API, KINDS } from "./src/kinds.ts";

startWorker({ api: API, kinds: KINDS, onError: (error) => console.error("p3 session:", error) });

src/kinds.ts holds API ({ name: "@p3/app", versions: ["v1"], modules: { ... } }) and KINDS: server and worker on Node, web in the browser with React. The worker kind also lists @earendil-works/pi-ai and @earendil-works/pi-durable as host packages, so plugins import them by name and every plugin shares the process's one instance (decision 2).

The principal is the kit's minimum plus the worker:

// apps/p3/src/principals.ts
export type P3Principal =
	| { readonly kind: "server" }
	| { readonly kind: "worker"; readonly session: string }       // the worker's address key, session|<id>
	| { readonly kind: "owner" };

Multi-user stays possible without changing anything here: a later { kind: "user", id } variant is one more case in authorize and in the views' factories.

Signing in

The kit does it. Each start prints a one-time owner link, http://127.0.0.1:8789/_chord/owner#<token>, valid ten minutes; its page posts the fragment's token and gets the owner's cookie (400 days, renewed on use). Every other route and the /chord links endpoint answer 401 without a principal. Tests and command-line clients send the owner token file ~/.p3/owner-token as a bearer token. Remote access (Radius) and pairing stay as the kit has them; step 0 adds nothing.

Plugins import only @p3/app/v1 and its per-kind modules (and the host packages of their kind). The shared module re-exports the Chord surface p3 supports, the way example 61's does, plus p3's own small part:

// apps/p3/src/api/v1/index.ts (p3's own part)
export const Session = hostKind("session", { id: str({ pattern: "^[0-9a-f-]{36}$" }) });

/** Defines a facet of p3: its factories get p3's principals. */
export function defineFacet(setup: (host: FacetHost<P3Principal>, self: FacetSelf) => void) {
	return chordFacet<P3Principal>(setup);
}

export type { P3Principal } from "../../principals.ts";
export { AppInfo, HostRuntime, KeepAlive, WorkerInfo } from "@earendil-works/chord/app";   // HostRuntime, KeepAlive: decision 1

The worker module declares the three registries a session's worker is built around. It declares them only (their tokens); the harness plugin serves them.

// apps/p3/src/api/v1/worker.ts
import type { Provider } from "@earendil-works/pi-ai";
import type { Extension, Harness as DurableHarness } from "@earendil-works/pi-durable";

/** Durable extensions: one per contributing plugin (a writable when its tools change at runtime). */
export const Extensions = defineRegistry<Extension, readonly Extension[]>("p3.extensions", { version: 1 });

/** Model providers: one pi-ai provider per contributing plugin, composed into the session's `Models`. */
export const ModelProviders = defineRegistry<Provider, Models>("p3.model-providers", { version: 1 });

/** The session's open Durable harness, for objects that follow its views: `undefined` while none is open. */
export const HarnessNative = defineRegistry<Native<DurableHarness>, DurableHarness | undefined>("p3.harness", {
	version: 1,
});

/** A Chord call scope from any Durable context (design §24 Q6): `host.root(fn, context)` as the host. */
export function chord<R>(fn: (ctx: Ctx) => Promise<R>, context: Context): Promise<R> {
	const root = context.get(ChordRoot);
	if (root === undefined) throw new Error("chord(): no Chord host in this context (open the harness with one)");
	return root(fn, context);
}

ChordRoot is a context key of the API (createContextKey); the harness opens Durable with a base context holding the host's root under it, so every Durable phase context (a tool's, a hook's) inherits it. Step 0 has no tools, so nothing calls chord() yet; a test proves a Durable context from the harness reaches a Chord object through it.

The web module declares the page's two slots and a minimal router, and re-exports Chord's React hooks:

// apps/p3/src/api/v1/web.ts
/** A part of the sidebar: the session list in step 0. Ordered by plugin name. */
export type SidebarPart = { readonly name: string; readonly Component: ComponentType };
export const Sidebar = defineRegistry<SidebarPart, readonly SidebarPart[]>("p3.sidebar", { version: 1 });

/** A screen of the main area, by path pattern (`/s/:id`); the most specific match wins. */
export type Screen = { readonly path: string; readonly Component: ComponentType<{ readonly params: Readonly<Record<string, string>> }> };
export const Screens = defineRegistry<Screen, readonly Screen[]>("p3.screens", { version: 1 });

/** The page's path, followed (`popstate` and `navigate`). */
export function useRoute(): string;
/** Moves the page to `path` without a reload (`history.pushState`). */
export function navigate(path: string): void;

export { useHold, useHost, useMessages, usePageState, useRegistry, useWatch } from "@earendil-works/chord/react";

Sidebar and Screens are served by the page's own core facet in src/web/main.tsx (as example 61's Panels): the slots are base code, what fills them is plugins.

The harness plugin's worker facet serves the three registries and one host-lifetime object, Harness, which owns the Durable harness as a native.

// apps/p3/plugins/harness/worker.ts
import { createModels } from "@earendil-works/pi-ai";
import { Harness as DurableHarness } from "@earendil-works/pi-durable";
import { StoreStorage } from "@earendil-works/pi-durable/storage/store";
import { ChordRoot, defineFacet, HostRuntime, KeepAlive, local, withContextValue } from "@p3/app/v1";
import { Extensions, HarnessNative, ModelProviders } from "@p3/app/v1/worker";
import { durableRegistry } from "./registry.ts";

/** The session's harness: one per worker, alive as long as the worker. */
const Harness = local("p3.harness", { version: 1, params: {}, members: {} });

export default defineFacet((host) => {
	host.serve(Extensions, { compose: (table) => table.map(({ value }) => value) });
	host.serve(ModelProviders, { compose: (table, { report }) => modelsOf(table, report) });
	host.serve(HarnessNative, { compose: (table) => table[0]?.value.value });
	host.serve(Harness, (_params, self) => {
		const runtime = self.registry(HostRuntime);
		const extensions = self.registry(Extensions);
		const models = self.registry(ModelProviders);
		// Running agent work keeps the worker alive (Durable says when it needs a process: `onWake`).
		const busy = self.writable(0);
		self.contribute(KeepAlive, busy);
		const harness = self.open(
			async (context) => {
				const { store, root } = runtime.value;
				const storage = await StoreStorage.open(store, "p3.durable", context);
				const opened = await DurableHarness.open(
					storage,
					{
						models: () => models.value,                         // read at each use: a reload swaps it
						registry: durableRegistry(extensions, context),
						onWake: (wake) => busy.set(wake.active ? 1 : 0),
						onReport: (report) => reportDurable(report),
					},
					// Tools and hooks reach Chord through `chord(fn, context)` (§24 Q6).
					withContextValue(ChordRoot, root, context),
				);
				// The root conversation, created once with the first model offered.
				await opened.root(context, { agent: { model: defaultModel(models.value) } });
				return opened;
			},
			(opened, _reason, context) => opened.close(context),
		);
		self.contribute(HarnessNative, harness);
		// Paused until every plugin of the worker is loaded, so recovered work finds its extensions (§24).
		self.onLive(async (ctx) => {
			await runtime.value.whenLoaded(ctx);
			harness.value.resume();
		});
		return {};
	});
});

The pieces, and why each is there:

• self.open keeps Durable a native of exactly one object (natives only in objects). It opens after the registries are usable (they are declared dependencies), closes when the object ends. A reload of the harness plugin restarts the object: the old harness closes at the seal, the new one opens on the same store and recovers what was running, as after a crash.
• StoreStorage.open(store, "p3.durable", context) puts Durable's records in the session's Chord store, beside the kit's Files (chord.app.files:*), claimed under the owner name p3.durable. One store per session, one commit line: a fork or export of the session is one archive.
• durableRegistry(extensions, context) is Durable's RegistryReader over the composed Extensions value: a snapshot made once per composed list (createRegistry(), each extension installed), and subscribe observing the registry value so the scheduler reconsiders blocked tasks when a contribution arrives. The tool_search fallback (install Durable's tool_search extension when deferred tools exist and code mode does not) belongs here; step 0 has no deferred tools, so it arrives with MCP (step 4).
• HarnessNative hands the open harness to other objects of the worker (chat, sessions), which follow its views with self.follow. Its compose takes the first contribution: there is one harness per worker.
• Paused until loaded. Durable opens with scheduling paused. Resuming in onLive alone would race other plugins: an extension contributed by another host-lifetime object may go live after the harness, and a recovered tool call would find no tool. whenLoaded resolves once the kit's plugins.load of the worker has resolved, the moment p2's base code called resume().
• KeepAlive. The workers component stops a worker after five idle minutes, counting Chord references, jobs and the app's busy. A run the user walked away from has no references; without this count the worker would stop mid-run. Durable's onWake says whether the session needs a running process; the harness contributes that as a count.

Decision 1: how a plugin gets what only base code has {#decision-1}

Decision needed (Chord, the app kit). The harness needs three things the kit keeps to base code: the host's store (Durable's StoreStorage.open(store, ...) takes it), a root scope (host.root, for chord(fn, context)), and the moment the worker's plugins are loaded (to resume). It also must keep its worker alive while agent work runs, which the kit takes only as startWorker({ busy }) from base code. The design's own rule says base code serves "one small start-data facet serving process values (start data, the opened store) as core objects" (design §21, decision "The plugin model ... (8)"); the kit built AppInfo and WorkerInfo but never the store, because no kit app had an adapter owner like Durable's StoreStorage.

Recommended (A): two kit registries on every kit host. HostRuntime (chord.app.runtime), served by the kit with one value: { store, root(fn, context, options?), whenLoaded(context) }, the host's store, its host.root, and a promise that resolves once the kit's plugins.load resolved. KeepAlive (chord.app.keep-alive): host-lifetime objects contribute a number or a watchable of one; the kit adds their sum to the worker's busy counts. Both are generic (any kit app with an adapter owner or long work outside Chord needs them), small (a facet and a fold in startWorker, the same on startServer for HostRuntime), and keep the harness a plugin.

Alternatives. (B) startWorker takes app core facets (core: (host, store) => facets) and a ready(host, ctx) hook: p3's base code then opens the harness itself, as p2 does. It works, but the harness becomes base code (a change restarts the server) and every app with an adapter owner writes the same wiring again. (C) p3 skips startWorker and writes its worker on workerMain like p2: duplicates the kit's layout, store and telemetry wiring, the opposite of "use the kit".

Cost of A: about 60 lines in the kit (runtime.ts: the facet, the registries, the fold of KeepAlive into busy), its tests, the README and design §23 updated; a Chord decision recorded in packages/chord/docs/decisions.md on main, merged into p3.

// apps/p3/plugins/fake-model/worker.ts
import { fauxAssistantMessage, type FauxResponseFactory, fauxProvider } from "@earendil-works/pi-ai";
import { defineFacet } from "@p3/app/v1";
import { ModelProviders } from "@p3/app/v1/worker";

export default defineFacet((_host, self) => {
	const fake = fauxProvider({ provider: "fake", models: [{ id: "echo", name: "Echo" }], tokensPerSecond: 40 });
	// One reply per request, queued again each time: the faux provider answers from a queue.
	const echo: FauxResponseFactory = (context) => {
		fake.appendResponses([echo]);
		return fauxAssistantMessage(`You said: ${lastUserText(context)}`);
	};
	fake.setResponses([echo]);
	self.contribute(ModelProviders, fake.provider);
});

A facet's contribution: no object, no native (the provider is a plain in-process value fixed for the plugin's life). At 40 tokens a second a short reply streams for about a second, long enough to see it stream and to test a restart in the middle of it. The harness's root conversation picks fake/echo because it is the first model offered; with no provider at all the root's agent has no model and Durable records no_model on the first send, which the chat shows.

The sessions plugin owns the list of sessions. Its contract is shared (the page and the worker both hold it):

// apps/p3/plugins/sessions/contract.ts
export const SessionRow = obj({
	id: str(),
	title: str(),                                     // "" until the first message
	status: oneOf(["new", "idle", "working"]),
	created: num(),
	updated: num(),
});

/** The session catalog as one principal sees it: the owner lists and creates, a worker reports its own session. */
export const SessionList = remote("p3.sessions", {
	version: 1,
	params: {},
	hostAddress: () => Server(),
	variants: {
		owner: {
			state: { sessions: arr(SessionRow) },
			methods: { create: method(obj({ id: str({ pattern: "^[0-9a-f-]{36}$" }) })) },
		},
		worker: {
			state: {},
			methods: { report: method(obj({ title: opt(str()), status: opt(oneOf(["idle", "working"])) })) },
		},
	},
});

On the server, one host-lifetime store object holds the table and a live query of the newest 200 by updated; the views are what each principal may do with it.

// apps/p3/plugins/sessions/server.ts (abridged)
const Rows = defineTable("p3.sessions", {
	version: 1,
	columns: { id: str(), title: str(), status: str(), created: num(), updated: num(), incarnation: str() },
	key: ["id"],
	indexes: [["updated"]],
});
const NEWEST = query(Rows).orderBy((row) => row.updated, "desc");

const SessionStore = local("p3.sessions.store", {
	version: 1,
	params: {},
	members: {
		sessions: arr(SessionRow),
		create: method(obj({ id: str() })),
		report: method(obj({ id: str(), incarnation: str(), title: opt(str()), status: opt(str()) })),
	},
});

host.serve(SessionStore, (_params, self) => {
	const rows = self.table(Rows);
	const newest = self.query(rows, NEWEST, 200);
	return {
		sessions: self.derive([newest], ([list]) => list.map(publicRow)),       // mapShared: rows keep identity
		create: async ({ id }, ctx) => {
			const now = Date.now();
			// Idempotent: a retried create of the same id changes nothing.
			await self.tx(async (tx) => {
				if ((await tx.get(rows, { id })) === undefined)
					tx.put(rows, { id, title: "", status: "new", created: now, updated: now, incarnation: "" });
			}, ctx);
			return null;
		},
		report: async ({ id, incarnation, title, status }, ctx) => {
			await self.tx(async (tx) => {
				const row = await tx.get(rows, { id });
				// Unknown sessions are not listed; reports of an older worker incarnation are late and ignored.
				if (row === undefined || incarnation < row.incarnation) return;
				tx.update(rows, { id }, { incarnation, updated: Date.now(), ...(title === undefined ? {} : { title }), ...(status === undefined ? {} : { status }) });
			}, ctx);
			return null;
		},
	};
});

host.serve(SessionList, (_params, principal, self) => {
	const store = self.get(SessionStore, {});
	if (principal.kind === "worker") {
		const id = principal.session.slice("session|".length);
		return {
			variant: "worker",
			// The id comes from the principal the link stamped, the incarnation from Chord: neither is the caller's data.
			members: { report: (report, ctx) => store.report({ id, incarnation: ctx.incarnation, ...report }, ctx) },
		};
	}
	if (principal.kind !== "owner") throw forbidden("the session list is the owner's");
	return { variant: "owner", members: { sessions: store.sessions, create: store.create } };
});

Why each rule:

• A table, not a document. Anything listed, queried or paged is a table: a thousand sessions are a thousand rows, a change rewrites one row, and the live query sends the window's diff. A document holding the list would rewrite and diff the whole list on every status change.
• 200 live, the rest by page. The live query needs a limit. Step 0 shows the newest 200; a page({ after }) method for older sessions comes with archive and search.
• The incarnation fence. A worker that is stopping can report after its successor started (the idle stop, then a new hold within the drain). ctx.incarnation is the reporting host's incarnation, stamped by Chord from the link's handshake, never sent as data; incarnations are uuidv7, so a later start compares greater. A late "working" from the old process cannot overwrite the new one's "idle". (Design §25, "Reading without starting a worker".)
• The worker's id from its principal. The worker variant has no id argument: a worker reports only its own session, whatever its code sends.

The worker side: title and status

The title and the working state are the session's data, so the worker owns them and pushes what the catalog shows. The sessions plugin's worker facet serves SessionMeta:

// apps/p3/plugins/sessions/worker.ts (abridged)
const Meta = defineState("p3.sessions.meta", {
	schema: obj({ title: str() }), version: 1, initial: () => ({ title: "" }), persist: true, checkpointWhen: () => true,
});

host.serve(SessionMeta, (_params, self) => {
	const meta = self.state(Meta);
	const list = self.get(SessionList, {});                  // over the parent link: acts as this worker
	const harness = self.registry(HarnessNative);
	self.retryOn(harness);
	const view = self.follow((observer, context) => observeRoot(harness.value, observer, context, { min: 1, max: 1 }));
	const status = self.derive([view], ([v]) => (v.docs["pi.live"]?.run === undefined ? "idle" : "working"));
	// Pushed from where it changes: the first call reports the current status, later calls every change.
	self.on(status, async ({ value }, ctx) => {
		if (list.variant === "worker") await list.report({ status: value }, ctx);
	});
	return {
		title: meta,
		rename: async ({ title }, ctx) => {
			await meta.change((draft) => { draft.title = title; }, ctx);
			if (list.variant === "worker") await list.report({ title }, ctx);   // before the answer: the list is current
			return null;
		},
	};
});

observeRoot is a helper of the plugin: harness?.observeConversation(ROOT_CONVERSATION_ID, observer, context, window), undefined while no harness is open (the follow then fails the attempt transient, and retryOn wakes it when the harness's contribution arrives). A window of one entry keeps this observer cheap: it reads only docs.

The chat plugin's worker facet follows the root conversation's view once, in a shared store, and serves the per-principal Chat view (the pattern of design §6):

// apps/p3/plugins/chat/contract.ts
export const Chat = remote("p3.chat", {
	version: 1,
	params: { session: str() },
	hostAddress: ({ session }) => Session({ id: session }),
	variants: {
		owner: {
			state: { view: unknown() },                       // Durable's ConversationView, JSON
			methods: { send: method(obj({ text: str(), requestId: str() })), abort: method() },
		},
	},
});

// apps/p3/plugins/chat/worker.ts (abridged)
host.serve(ChatStore, (_params, self) => {
	const harness = self.registry(HarnessNative);
	const meta = self.get(SessionMeta, {});
	self.retryOn(harness);
	const view = self.follow((observer, context) => observeRoot(harness.value, observer, context, { min: 50 }));
	return {
		view,
		send: async ({ text, requestId }, ctx) => {
			const root = await harness.value!.root(ctx);
			if (meta.title.value.title === "") await meta.rename({ title: firstLine(text, 80) }, ctx);
			// Resolves once Durable committed the input: its entry is in `view` before this method answers.
			await root.submit({ type: "input", content: text, requestId, whenBusy: "followUp" }, ctx);
			return null;
		},
		abort: async (ctx) => {
			await (await harness.value!.root(ctx)).abort(ctx);
			return null;
		},
	};
});
host.serve(Chat, (_params, principal, self) => {
	if (principal.kind !== "owner" && principal.kind !== "server") throw forbidden("chat is the owner's");
	const store = self.get(ChatStore, {});
	return { variant: "owner", members: { view: store.view, send: store.send, abort: store.abort } };
});

• Followed, never copied. The transcript is Durable's; self.follow over observeConversation makes its view a Chord watchable without a second copy (decision "App authoring rules confirmed by the p2 audit"). Durable keeps one mount per conversation; chat's and sessions' observers share it.
• The streamed answer is the run's pi.live document in the view: each delta Durable commits is one view revision, one state message to the page. Nothing in p3 assembles a stream.
• requestId makes a retried send exactly-once (Durable's submission dedupe): the page makes one per message, so a send whose answer was lost in a reconnect and is sent again is admitted once.
• Answers that follow their state. send awaits the rename (whose push to the catalog the server commits before it answers the worker) and the submission (whose entry the follow publishes before submit resolves). So when the page's call settles, the user entry is in its view and the title is in its SessionList: the optimistic values are replaced by real ones, never by old ones.

The web entry is the tutorial's with a layout: a sidebar and a main area, each filled from a registry.

// apps/p3/src/web/main.tsx (abridged)
const core = defineFacet((host) => {
	host.serve(v1web.Sidebar, { compose: (table) => table.map(({ value }) => value) });
	host.serve(v1web.Screens, { compose: (table) => table.map(({ value }) => value) });
});

function Shell() {
	const sidebar = useRegistry(v1web.Sidebar) ?? [];
	const screens = useRegistry(v1web.Screens) ?? [];
	const path = v1web.useRoute();
	const match = bestMatch(screens, path);                       // most specific pattern wins
	return (
		<div className="shell">
			<nav>{sidebar.map(({ name, Component }) => <Component key={name} />)}</nav>
			<main>{match ? <match.Component params={match.params} /> : <Empty />}</main>
		</div>
	);
}

void startPage({
	connect: () => new WebSocket(`${location.origin.replace(/^http/, "ws")}/chord`),
	modules: { "@p3/app/v1": v1, "@p3/app/v1/web": v1web, react: React, "react/jsx-runtime": jsx },
	core: [{ name: "@p3/web", facet: core }],
	render: (host) => createRoot(document.getElementById("root")!).render(<HostProvider host={host}><Shell /></HostProvider>),
});

The look comes from the kit's themes (CSS variables); p3's own design (p2's look made great) is a later step's. The shell's CSS is base code, a plugin's CSS is the plugin's.

Creating a session

// apps/p3/plugins/sessions/web.tsx (abridged)
function SessionsPart() {
	const list = useHold(SessionList, {});
	const rows = useWatch(list?.variant === "owner" ? list.sessions : undefined) ?? [];
	const [shown, addRow] = useOptimistic(rows, (current, row: Row) => [row, ...current]);
	const create = () =>
		startTransition(async () => {
			const id = crypto.randomUUID();                       // the page names it: no round trip before showing it
			addRow({ id, title: "", status: "new", created: Date.now(), updated: Date.now() });
			navigate(`/s/${id}`);
			if (list?.variant === "owner") await list.create({ id }, BACKGROUND_CONTEXT);
		});
	return (/* "New session" button, then shown.map(row => <SessionLink row={row} />) */);
}

The row and the chat screen appear in the same frame. The chat screen holds Chat only once the catalog lists the id (it reads SessionList too), so no worker starts for a session the server has not committed; a message typed meanwhile is shown optimistically and its send waits in the reference's parked calls until the hold binds (design §7).

The chat screen

plugins/chat/web.tsx contributes Screens { path: "/s/:id", Component: ChatScreen }: the transcript from view.entries (user and assistant text; tool entries render as a placeholder until tools exist), the streaming answer from view.docs["pi.live"], a composer whose half-typed text is page state (usePageState, kept across a plugin reload), Send and Stop. Sending:

const [entries, addPending] = useOptimistic(view?.entries ?? [], (current, text: string) => [...current, pendingUser(text)]);
const send = (text: string) =>
	startTransition(async () => {
		addPending(text);
		setDraft("");
		await chat?.send({ text, requestId: crypto.randomUUID() }, BACKGROUND_CONTEXT);
	});

A rejected send leaves the draft empty and the pending entry gone; the screen shows the error under the composer with the text restored. The transcript shows the window (the newest 50 to 100 entries); scrolling back through older entries is a later step (Conversation.entries() pages, as Durable's ConversationTranscript does).

Step 0 is done only when the session survives each of these, tested end to end:

The build subagent works in its own worktree off branch p3, in the Chord code style (one concept per file, a doc line per export, tagged unions, no defensive checks of typed values), and delivers:

1. Decision 1 in the kit (if approved as A): packages/chord/src/node/app/runtime.ts, tests in packages/chord/test/node/app/, the kit README and design §23; on main first, then merged into p3.
2. The app: the files of chapter I, npm run check clean at the root and in apps/p3 (p3 gets its own check script and tsconfig like p2's).
3. Plugin tests with testPlugin: sessions on the server (create is idempotent; the owner lists, a worker reports only its own row; a report of an older incarnation is ignored; a non-owner is refused); chat on a worker with a stub harness (send submits once per requestId; the first send sets the title).
4. App tests (apps/p3/test/, the kit in one process, a client host over the links endpoint with the owner token, as example 61's step 7): create, send, the fake reply streams in at least two revisions; a second client sees the same list and transcript (page reload); applyChanges after editing the chat plugin keeps the transcript and a new send works; applyChanges after editing the harness plugin during a reply recovers it; app.close and startServer on the same data directory keep the list and the transcript and finish an interrupted reply.
5. A browser test (Chromium, CHROMIUM_BIN): the new row and the sent message are on screen in the frame after the click, before any answer (the server's answers delayed by a test hook in the transport).
6. apps/p3/examples/00-skeleton.ts: the walkthrough of the preface as a script printing each step (start, sign in, create, send, the streamed reply, a plugin reload, a restart), in example 61's format.
7. On the phone: started next to p2 with its own data directory and port; the owner's link opens it. Deploying it there goes through the phone dev session in an owner-started turn.

Two code reviewers (one adversarial, one against design.md and this spec) check the build; their fixes go in before the commit on p3.