santos/dev: crew family, Pareto crewing and the Model Pool, custom connections

.gitignore

@@ -37,3 +37,4 @@ internal/manual/pages.pack.gz
 # at the root is what the next lane's `git add -A` sweeps up: two of these were
 # committed that way on #1173 and had to be taken back out.
 .furrow/
+bench/idle-surface/runs/

FINDINGS.md

@@ -0,0 +1,45 @@
+# Unread config key notice findings
+
+## Task
+
+Carry the unread top-level `config.json` keys computed by `config.Load` into the existing one-time conversation notice in both hosted and `--no-host` chat. The notice must name the keys, use the existing `notices.json` mechanism, stay silent for a correct flat config, and show again only for a previously unseen changed key set. Production code is intentionally out of scope for this findings commit.
+
+## Single-source transport path
+
+The only key classification remains the computation currently inside `warnUnreadProfileKeys` in `internal/config/config.go:361-388`. Refactor it to return its sorted `[]string`, and make the existing log format that exact returned value. No downstream code may inspect config keys or reconstruct the set.
+
+Retain that value from the existing `config.Load` call in `openV3ProcessWith` (`cmd/codeaf/chatv3_process.go:128-154`) on the process/launch data. From there the two paths are:
+
+- `--no-host`: `openV3ProcessWith` -> `v3Process` -> `openV3Launch` / `v3Seam.bundle` -> the existing launch notice input -> `tui3.Options.Notice` -> the existing dim conversation note consumed by `internal/tui3/app.go:2870-2917`.
+- Hosted: `openV3ProcessWith` during `bootEngine` (`cmd/codeaf/engine.go:563-613`) -> `remote.Engine` -> a dedicated unread-key field on `remote.Welcome` (`internal/remote/wire.go`) populated by `welcomeLocked` (`internal/remote/server.go:1149-1162`) -> `hostEntryNotice` / `hostOptions` (`cmd/codeaf/chatv3_host.go`) -> `tui3.Options.Notice` -> the same existing dim conversation note.
+
+The hosted wire field is required because the engine and surface are separate processes. Neither stderr, the per-profile chat log, nor `host.log` reaches the conversation.
+
+The displayed sentence should use the existing conversation-note surface and plain wording such as: `config.json keys are not read: models; models fell back to defaults.` The names come directly from the transported sorted list.
+
+## Notice gate
+
+Use the existing `noticeBoard` and `noticeLedger` persistence in `internal/tui3/notice.go` and `internal/tui3/notice_ledger.go`, with `maxShown=1`. Keep a stable display row id, `unread-profile-config-keys`, and use this dynamic ledger gate id:
+
+`unread-profile-config-keys-<sha256hex>`
+
+Compute the full lowercase SHA-256 hex digest from `encoding/json.Marshal` of the already sorted shared list. This is deterministic and unambiguous for arbitrary key strings, matches the notice id shape, and does not introduce a second unread-key computation. Gate eligibility, per-session shown state, show, and retire by the dynamic gate id while rendering by the stable row id. An empty list arms no notice. The same set remains retired across launches; a new set gets a new gate and shows once; returning to an already retired set stays silent.
+
+The ledger must be opened for the profile whose config was loaded. In hosted mode, do not silently gate an engine-profile warning against an unrelated client profile.
+
+## Focused verification plan
+
+1. Extend the focused config test around `TestWarnUnreadProfileKeys` to prove the shared function returns a sorted list and the log formats that same result: `go test ./internal/config -run TestWarnUnreadProfileKeys -count=1`.
+2. Add focused remote wire/server coverage proving the sorted unread list survives `Engine -> Welcome` serialization and receipt.
+3. Add focused notice-board tests proving: empty input is unarmed; the first display is persisted; restart with the same gate is silent; a changed list displays once; returning to an old list is silent; and the rendered conversation note names the keys.
+4. Add focused command-path tests for both `--no-host` launch transport and hosted `hostOptions` transport.
+5. Exercise the acceptance case with a built real binary and a real engine plus client, never `quietAgent` or another fake agent: nested `{"models":{"tiers":{"reflex":"..."}}}` shows a notice naming `models` once; a correct flat config shows nothing; a second launch is silent; changing the unread set shows once again in hosted and `--no-host` modes.
+6. Run only focused `go test -run` commands while implementing, then leave the coordinator's prescribed pre-PR gates to the coordinator.
+
+## Implementation step
+
+Implement the shared return value first, then transport it on `v3Process` and `remote.Welcome`, and finally arm the existing notice board with the hashed dynamic gate. Focused tests will cover config classification, wire transport, local and hosted option assembly, and ledger behavior. No downstream layer will read or classify `config.json`.
+
+## Change-note step
+
+This lane owns the user-visible change note after the implementation. The note will be `kind: fixed` on `surface: [chat, engine]`, because the load diagnostic added in pull request 1223 did not reach either chat path and the fix carries the same shared unread-key result through both the hosted engine/client boundary and `--no-host` into the existing conversation notice. Its invalidation will distinguish the old logger-only behavior from the once-per-profile notice, including the changed-key-set rule. No pull request number is assigned yet, so the note filename and `pr` value require reconciliation after the coordinator opens the pull request.

Makefile

@@ -91,6 +91,7 @@ furrow:
 # then to PATH — which is what it does here.
 build: furrow embed
 	go build -tags=$(MANUAL_TAG) -trimpath -ldflags="-s -w $(BUILD_STAMP)" -o $(BINARY) ./cmd/codeaf
+	go build -trimpath -ldflags="-s -w $(BUILD_STAMP)" -o bin/plandb ./cmd/plandb
 
 debug: furrow embed
 	go build -tags=$(MANUAL_TAG) -trimpath -ldflags="$(BUILD_STAMP)" -o $(BINARY) ./cmd/codeaf
@@ -185,6 +186,9 @@ test-touched-preflight:
 		exit 2; \
 	fi
 
+# A directory under its own go.mod is another module — a bench fixture the
+# task door edits, not a package of this one — and `go test ./that/dir` from
+# here answers "does not contain package". The walk skips those.
 test-touched: test-touched-preflight
 	@set -eu; \
 	base="$${BASE:-origin/dev}"; \
@@ -197,6 +201,12 @@ test-touched: test-touched-preflight
 		done | sort -u)"; \
 		pkgs=""; \
 		for dir in $$dirs; do \
+			nested=0; walk="$$dir"; \
+			while test "$$walk" != "." && test "$$walk" != "/"; do \
+				if test -f "$$walk/go.mod"; then nested=1; break; fi; \
+				walk="$$(dirname "$$walk")"; \
+			done; \
+			if test "$$nested" = 1; then continue; fi; \
 			if ls "$$dir"/*.go >/dev/null 2>&1; then pkgs="$$pkgs ./$$dir"; fi; \
 		done; \
 	fi; \

bench/bashloop/BASHLOOP-DO-DOOR.md

@@ -0,0 +1,141 @@
+# The do door — the six cells through `codeaf do`, and what stopped them
+
+*2026-09-17. The companion report to the task-door grid — the same six cells,
+the same two arms, the same pinned model (`deepseek/deepseek-v4-flash`), the
+same fixtures, graders and reading discipline, driven through the product's
+adaptive-run door instead of the engine's task door.*
+
+**The headline first: the grid was not spent, because the arming gate failed.
+On the do door the two arms are the same arm by every observable the door
+itself keeps — no belt fingerprint appears in arm B's workers — and the brief's
+own law says two identical arms are not a comparison. What ran is the arming
+probe: a c1 pair and a c5 pair, both arms, n=1 each. Their rows are below. The
+other four cells are recorded as not run, at the stage that stopped them.**
+
+## The door, the flag, the dry run
+
+The driver carries `-door task|do` (default `task`). Door `do` launches the
+built binary as a subprocess, the rig's own shape
+([bench/deepswe/run.sh](../deepswe/run.sh)):
+
+```sh
+codeaf do -w <fixture> -model deepseek/deepseek-v4-flash -plan-model deepseek/deepseek-v4-flash \
+  -db <home>/graph.db -keep -timeout 1800s -yes-spend -json < <brief>
+```
+
+with `CODEAF_HOME` and `HOME` on the throwaway home and `CODEAF_TASK_BELT`
+unset for arm A, `=bash` for arm B — the only byte that differs between the
+arms. The dry run prints every invocation for both doors; the driver's tests
+prove the two doors' blocks and that the arms differ only in the belt variable
+(`driver_test.go`).
+
+The door's exit ladder, in its own words: **0** done · **1** could-not-run ·
+**2** ran-not-finished · **3** limit-stopped · **4** needed-answer · **124**
+the driver's wall fired first. `stdout` is one JSON envelope; `stderr` is the
+stream, kept as `run.log` beside each row.
+
+## The rows that ran (the arming probe)
+
+Read off the door's own store, the home's `graph.db` — cost and models from
+`usage` (the door's per-call ledger, the same per-response accounting the task
+door's `v3/usage.jsonl` keeps), steps from the transcript's finished tool calls
+(the task door's `took` unit), the diagnostics from the tool results, the
+family shape from `nodes`:
+
+| cell | arm | n | pass | rate | ending (exit) | med steps | med $ | med wall | invalid | trunc | idiom | parts | changed |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| c1 | A | 1 | 1 | 1.00 | done (0) | 5 | $0.0053 | 110s | 0 | 0 | 0 | 0/0 | 29 |
+| c1 | B | 1 | 1 | 1.00 | done (0) | 21 | $0.0188 | 265s | 0 | 0 | 0 | 0/0 | 31 |
+| c5 | A | 1 | 0 | 0.00 | ran-not-finished (2) | 87 | $0.0400 | 487s | 0 | 0 | 0 | 0/0 | 43 |
+| c5 | B | 1 | 1 | 1.00 | ran-not-finished (2) | 93 | $0.0696 | 922s | 0 | 0 | 0 | 2/3 | 45 |
+
+Over the graded passes: arm A (n=1) — 5 steps · $0.0053 · 110s. Arm B (n=2) —
+medians 57 steps · $0.0442 · 594s. Both arms graded pass on c1 (the c5 grader
+passed arm B's work: suite green, 2 of 3 parts landed as their own work, one
+node failed — `task-2-x2`, read straight off the `nodes` table). Arm A's c5 ran
+the four packages green and still graded no: the family never left one pair of
+hands, and the run ended exit 2. The wall column is the envelope's own seconds
+(`wall_source=node`); the driver's backstop never fired.
+
+The cells not run, with the stage that stopped them:
+
+| cell | arm | reading |
+| --- | --- | --- |
+| c2, c3, c4, c6 | A and B | not run — the grid was withheld at the belt-arming gate (below); spending four cells on one arm would have been the wrong answer the brief names |
+
+## The arming gate, and how it was checked
+
+The fix this branch carries (`36a689926`) arms the belt on the do door's run
+leaves: `orchestrate.go`'s `newChild` now builds its `Config` with
+`bashBelt: bashBeltAsked()` (`InTask` was already true, and
+`Config.mayBashBelt` is `InTask && bashBelt`). The task door's workers take the
+same flag at `task_run.go`'s worker construction. That wiring is real, and it
+is where the task door's arming is enough — its workers do the work themselves.
+
+The do door is built differently: a run leaf's file work is done by the
+subharness's own executor, not by the leaf agent's own hands. So the probe
+looked for the belt in the three places the brief names, using only the door's
+own records:
+
+1. **The worker's own trace** — the store's `transcript` table, per node. Both
+   arms' workers called the same executor toolset: c5 arm A `sh`×73, `edit`×5,
+   `read`×4, `share`×2, `write`×3; c5 arm B `sh`×80, `edit`×6, `read`×2,
+   `share`×1, `write`×4 (c1 the same shape, smaller). Arm B carries **zero**
+   calls of a bash-belt hand (`bash` — the belt's own shell, `branchBash` — is
+   a different name than the linear executor's `sh`), and the belt's tool
+   composition (`bashBelt()`: branch bash, document, jobs, manual)
+   appears nowhere.
+2. **The composed page** — per-node first-turn `prompt_tokens` off
+   `usage_turns`: arm A 4640/6468/6667, arm B 4663/6714/6552/6771 (c1's three
+   and four nodes). Within a percent either way. The belt swaps whole pages
+   (`bashworker.md` in place of the fan-out page, belt facts into the frame);
+   a page swap that moves nothing measurable is not there.
+3. **The belt's own diagnostics** — the one-action envelope's rejections
+   ("no action executed") and the plan CLI's name (`plandb`, which the
+   bashworker page teaches): **zero** in every transcript body and event
+   payload on both arms. On the task door arm B's rows carried 1–17 invalid
+   actions each; here the envelope never armed, which is itself the fingerprint
+   of absence.
+
+One behavioral divergence between the arms did show — c5 arm B spliced a
+family (2 of 3 root children done) where arm A stayed single-handed and graded
+no — but nothing in that run's trace names the belt, and at n=1 a family-shape
+difference is run noise as far as the switch is concerned. The belt cannot be
+credited with it and the grid cannot be built on it.
+
+**Verdict: the belt does not reach the do door's workers.** The flag arms the
+leaf's `Config` and stops there: the leaf's file work is executed by the
+subharness executor, which is built without the belt, and the leaf's own prompt
+is composed without the belt's pages. This is the DeepSWE finding one seam
+deeper — the switch now reaches the process *and* the leaf `Config`, and still
+arms nothing the door's records can see. `planSeed`'s store never seeds on this
+door either (it runs from `TaskGraph.admit`; the do door registers and does not
+admit), so the plan-CLI path has no purchase here either.
+
+## The two sentences the brief asks for
+
+The do door does not change the task-door verdict, because it cannot re-measure
+it: with the belt invisible on this door, both arms are one arm, and the honest
+do-door reading is "unmeasured", not "agree" or "disagree". The doors diverge
+structurally — the task door builds workers at `newTaskAgentOn` whose toolbelt
+and pages the belt composes, while the do door builds run leaves at
+`orchestrate.go`'s `newChild` and hands the actual work to the subharness's own
+executor, so the belt stops at the leaf's `Config` and nothing downstream of
+that seam ever reads it.
+
+## Where the readings live
+
+Raw, beside this report, in `bench-results/bashloop-do-door/` — per results
+root (`bashloop-do-pair2` = the c1 pair, `bashloop-do-c5probe` = the c5 probe,
+`bashloop-do-pair` = the first pair, run before the store reader existed, whose
+rows read hollow: `steps=0 $0.0000`, the defect that forced the reader): the
+driver's `bashloop.csv`, each run's JSON envelope (`do.json`), its stderr
+stream (`run.log`), and the home's own `graph.db` and `logs/calls.jsonl`.
+On the Spark the full run directories (fixtures and all) are
+`/home/santosh/work/bashloop-do/bench-results/`.
+
+The first pair also earned the one driver change this report rides with: the
+do door keeps its numbers in the store, not in the `v3` ledger-and-journals
+layout the task door writes, so `door.go` reads the store read-only (same
+helpers, same units, one new reader) and the row now carries the family shape
+the c5 grader needs.