jason.woltjeandClaude Opus 5.5
af4203ca92
One cumulative control-board, webui and seat state. The four rows edit the
same files (scan.mjs, page.html, README.md, app.js), so they land together,
each on its own receipt:
- Row 18, Discord connector rows on the board (#1509): R3 approved by
Darkwing and Dewey, Gitea comment 26257, manifest 254403b8. Jason
accepted the visual test.
- Row 22, board attention status (#1503): Filbert approved R1, comment
26248, manifest e40b58ec; restart receipt 26249.
- #1511, task attribution (row 6 code phase): R2 approved by Filbert and
Dewey, manifest d4c96395. docs/TOOLS.md carries the approved --by usage
line (tools-usage.patch 86bcba3c).
- #1512, relaunch activity (row 6 pilot): R1 approved by Darkwing and
Dewey, candidate manifest 47769fad. All seven source files match it.
Row 16, internal development bootstrap (#1510): the seven files outside
shared records match Filbert's R1 pins, receipt 26204 (agents/researcher/*,
scripts/test-darkwing-launch.mjs, the bootstrap plan).
packages/webui/src/public/app.js is committed at its #1512 R1 pin ce7d79a4.
The working copy holds Dewey's unreviewed return-flow candidate on top of
that, and it stays uncommitted.
Also: the four row briefs and Darkwing's evidence records under
agents/darkwing/work, including the 2026-09-26 tree manifest and the #1512
re-run against 21e3e908. Serial acceptance command: 397/397, three runs.
The failures that only show when tests run concurrently are in #1509 engine
tests, and they reproduce on clean HEAD.
Suites on the exact staged tree: config 24, task 90, foundation 43,
conductor 17, release 14, auth 15, discord 63; package union 397/397
(serial); test-darkwing-launch 5/5.
Shared records (BUILD-LOG, QUEUE, CURRENT, DEFERRED, SESSIONS, AGENTS.md,
agents/README.md) follow in Sage's records commit.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
# Researcher
|
|
|
|
Repository-native technical research seat, coordinated by Darkwing. Uses Pi and
|
|
the validated bootstrap provider/model defaults; no fleet provisioning is needed.
|
|
|
|
From `/mnt/storage/src/mosaic-stack`:
|
|
|
|
```sh
|
|
agents/researcher/launch.sh --check
|
|
agents/researcher/launch.sh
|
|
agents/researcher/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. It resumes validated per-agent conversation
|
|
state under `.pi/state/researcher`; `--fresh` starts another conversation without
|
|
deleting history. Existing launcher locking prevents duplicate native instances.
|
|
|
|
This is the same explicit native mode as Darkwing/Dewey/Filbert, not a fallback
|
|
from a container policy refusal. The retained `agent.json` describes the separate
|
|
managed-mode definition; no managed role or capability policy is changed here.
|
|
|
|
Bootstrap configuration remains authoritative. Missing config, context or pinned
|
|
dependencies fails closed. No configuration or credentials are copied from a fleet
|
|
seat. No files under `~/.mosaic` are modified by this source setup. Use the existing
|
|
bootstrap/build workflow documented in the repository, rather than installing an
|
|
unversioned engine or modifying a home-directory launcher.
|
|
|
|
No engine was launched to verify this source change. Offline launcher tests use a
|
|
fake Pi and isolated registration/session directories. Live startup and external
|
|
provider authentication are separate observations, not implied by passing tests.
|