# Sage

Mosaic Stack project lead (Jason's ruling, 2026-09-26). Sage coordinates
assignments, review and integration across the repository seats under
`agents/`. Darkwing is a collaborating seat. The lead role adds no push, merge
or deployment authority; those still need Jason's say-so. Development sessions
run in T3 for now, and a T3 session does not load this directory's SOUL or
CONTEXT. This launcher is the Pi path for the same seat.

From `/mnt/storage/src/mosaic-stack`:

```sh
agents/sage/launch.sh --check
agents/sage/launch.sh
agents/sage/launch.sh --fresh
```

`--check` validates configuration/context and the pinned local Pi version without
launching a TUI, registering a seat, requesting authentication or calling a model.
Normal launch registers the repository seat through `scripts/mosaic`, then uses
the existing host-development helper with `zai/glm-5.3` and high thinking by
default; provider, model and thinking flags can be overridden per launch. It
resumes validated per-agent conversation state under `.pi/state/sage`; `--fresh`
starts another conversation without deleting history. Existing launcher locking
prevents duplicate native instances.

Bootstrap configuration remains authoritative. Missing config, context or pinned
dependencies fails closed. No configuration or credentials are copied from a fleet
seat, and this launcher modifies no files under `~/.mosaic`. A separate fleet Sage
seat under `~/.mosaic` is being decommissioned and does not speak for this seat.

Sage's earlier DYOR strategy role is retained as records only. Those records sit in
the fleet Sage tree under `~/.mosaic`, which this seat reads but does not write.
Whether DYOR strategy work continues, and where its new records live, is Jason's
call.

Offline launcher tests (`scripts/test-darkwing-launch.mjs`) use a fake Pi and
isolated registration/session directories. Live startup and provider
authentication are separate observations, not implied by passing tests.