process: the dashboard draft #2848 is 476 files in one diff, so its 19 open findings cannot be reviewed to a conclusion - decompose before the next round

[cagataycali]

What

#2848 (feat(dashboard): operator web dashboard for the robot fleet) is a draft carrying +80,304 / -3,499 across 476 files in 21 commits, currently CONFLICTING / DIRTY, with 19 of 20 review threads unresolved.

This issue is not about any one of those findings. It is about the shape: the review it has already received is thorough and correct, and it still cannot converge, because every fix has to be landed into a diff too large to re-review and too broad to keep conflict-free. Filing it so the decision survives outside a draft's comment thread.

Why another review round is the wrong next move

The open findings are not variations on one concern. They are eight independent numbered must-fixes plus three stale-documentation copies, spanning six subsystems:

#	subsystem	concern
1	pyproject.toml	four dashboard deps declared only in a hatch dev env, so the wheel ships strands_robots/dashboard/ with unsatisfiable top-level imports; no dashboard extra among the 32 declared
2	dashboard/server.py, dashboard/auth.py	both enrollment endpoints are in PUBLIC_PATHS, so the loopback rule never applies; with --host defaulting to 0.0.0.0, first-come wins ownership of the fleet on a fresh install
3	tests/test_dashboard_calibration.py	a host-shaped path literal fails test_no_host_paths.py, which is one live cause of the red required check
4	mesh/core.py	degraded_report overwrites the snapshot["degraded"] block written from _degraded_probes(), and reads a since key no record in the tree carries, so the shipped for_seconds is always 0.0
5	mesh/security.py	a per-joint input envelope with no call sites - already tracked independently as #2935
6	dashboard/server.py, dashboard/device_manager.py	two py/path-injection highs with no containment check; existence is validated, containment is not
7	dashboard/mesh_bridge.py	lockout_engaged is a literal True, never derived from responses, so an e-stop that reached nobody reports identically to one that reached every peer
8	dashboard/mesh_bridge.py	the safety-gateway Mesh is constructed without the mesh_kill_switch_engaged() check start() performs, so STRANDS_MESH=false still puts a *-safety peer on the live fleet

Two of these keep the one required check (call-test-lint / Test and Lint) red on their own (#3, and the [dashboard] extra named by an install hint that [project.optional-dependencies] does not declare). So the draft cannot go green in its present shape, which means every future reviewer pays the same 476-file read to reach the same conclusions.

All of the above is confined to code this branch introduces. Measured on main at c9da51a, input_envelope_for_units, NORM_MODE_UNITS, INPUT_ENVELOPES_BY_UNIT, degraded_report and _read_state_hw_seen each have zero occurrences - so none of it is an extractable pre-existing defect, and none of it is fixable anywhere other than in this work.

Proposed decomposition

The subsystem column above is already the seam. Each row below is independently reviewable, independently testable, and independently mergeable, and the ordering is by what unblocks the rest rather than by size:

1. Packaging. Declare the dashboard extra, fold it into all, route the imports through require_optional() so the refusal names the extra, and align the three documented install commands. Clears finding 1 and one of the two red-check causes.
2. The two mesh defects, against main and without any dashboard code. Findings 4, 7 and 8 are mesh behaviour, and 4 and 8 are pinnable with regression tests that fail on pre-fix code: a degraded probe that has been failing must report for_seconds > 0, and the kill switch must be honoured at the second construction site per the existing one-predicate rule. This is the highest-value slice and the one least coupled to the dashboard.
3. Auth and path containment. Findings 2 and 6 together, because seizing enrollment is what turns an authenticated arbitrary-directory read into a remote one - they share a threat model and should be reviewed as one change.
4. The dashboard surface itself, once 1-3 have landed, with the stale documentation (three copies of a banner asserting that /api/record does not exist, when record_api.py mounts it) corrected in the same change that makes it true.

Step 2 is worth pulling out first regardless of what happens to the rest: those are live mesh-safety defects whose fixes do not depend on the dashboard existing, and today they are trapped behind a 476-file diff.

Not proposed

Closing the draft. There are 21 commits of real work here and the review on it is high quality; the finding is that the container is wrong, not the contents. Leaving it as a draft reference while the slices land against main keeps both.

Refs #2848, #2935.

[cagataycali]

Status: the decomposition this issue asked for is underway and two slices have landed on main (at 19329cd2).

slice	landed as	modules now on main
operator auth rail + its extra	#3050	dashboard/auth.py
settings, log redaction, task timeouts, bounded cache	#3051	dashboard/settings.py, log_redaction.py, task_timeout.py, ttl_cache.py

Both were reviewed to a conclusion and approved, which is the outcome this issue predicted a smaller unit would make possible - #3051 closed at 12 files against the draft's 477.

Where the draft's 19 open findings actually sit

Grouped by the module each thread targets, against what is on main today. This is the mapping the next slice needs, and it is the thing that would be lost if the draft were simply abandoned:

target	open threads	of those, outdated	module landed on main?
dashboard/auth.py	2	0	yes (#3050)
dashboard/server.py	2	0	no
dashboard/device_manager.py	2	0	no
dashboard/mesh_bridge.py	2	0	no
dashboard/peer_tools.py	2	1	no
dashboard/agent_hitl.py	1	0	no
mesh/core.py	2	0	pre-existing; the draft edits it
pyproject.toml	2	2	extra landed with #3050
docs/dashboard/*.md	3	3	no
tests/test_dashboard_calibration.py	1	1	no
total	19	7

So 12 of the 19 are still current against the draft head, and all but the two auth.py threads target modules that have not been sliced yet. The two auth.py threads are the only ones whose subject now exists on main in reviewed form, so they are the only ones that can be answered by pointing at merged code rather than by a future slice.

What should happen to #2848

It should be closed, not iterated. The precedent is #3047, closed today for the same shape: a finding raised against a diff that will never merge as-is cannot be answered in place, and leaving it open makes 12 live findings look like an open review round when there is no reviewable unit behind them.

The order that does not lose anything:

1. For each of the 12 current threads, confirm whether the landed slices already answer it (the two auth.py ones) or whether it belongs to an unsliced module.
2. Carry each unanswered finding into the issue or slice-PR for the module it targets, so it is a precondition of that slice rather than a comment on a dead draft.
3. Close feat(dashboard): operator web dashboard for the robot fleet #2848 with the map above as the record.

Step 1 is per-thread reading and is the honest gate on step 3 - I am not closing the draft before it, because closing it first is what would orphan the findings this issue exists to protect. Recording the map now so that work is resumable and so the two merged slices are not mistaken for the whole decomposition.

Remaining unsliced surface, for scope: server.py, device_manager.py, mesh_bridge.py, peer_tools.py, agent_hitl.py, the mesh/core.py edits, and the docs/dashboard/ pages.

[cagataycali]

Step 1 is complete, so steps 2 and 3 are now unblocked and done: #3122 carries what was left, and #2848 is closed with the per-thread map as its record.

Step 1 was the honest gate I declined to skip last time -- "I am not closing the draft before it, because closing it first is what would orphan the findings this issue exists to protect." Having now measured all 20 threads against main, the reason it mattered is that the count in my previous comment was wrong in the pessimistic direction: I reported 12 of 19 still current, and the measured figure is 4.

Where the 20 threads actually landed

disposition	threads
answered by reviewed code on main	5
fixed on the draft branch, travels with its slice	5
already resolved	1
outdated nit, rides with its slice	1
still unfixed, no tree to fix it in -> #3122	4
duplicate views of the above	4

The five answered on main are the dashboard extra (#3050, declared at pyproject.toml:617 and folded into all at 643, which also closes the install-hint audit failure), the first-enrollment gate (#3078), and the WebAuthn origin derivation (#3080, pinned by tests/test_dashboard_auth_expected_origin_is_the_connection.py). That last one I had not counted at all: it was filed as optional, and it landed anyway two slices later.

Two corrections to my previous comment

The mesh/core.py row said "pre-existing; the draft edits it". That is wrong, and this issue's own body had it right. Measured on main at 1da422d, degraded_report and _read_state_hw_seen have zero occurrences and _degraded_probes is the sole renderer. So finding 4 is a defect the draft introduces, not one it inherits -- which is why it is absent from #3122. Nothing to extract.

Finding 4 is also already fenced, which changes what the next slice owes. The assertion the review asked for ("worth adding an assertion that for_seconds is greater than zero") exists on main today at tests/mesh/test_state_degraded_probes_are_published.py:335:

assert second["degraded"]["hw_joints"]["for_seconds"] == pytest.approx(3.5)

A second renderer overwriting snapshot["degraded"] with a for_seconds of 0.0 fails that test rather than going green over it. So the slice carrying the core.py edits does not need to remember this finding -- the tree will refuse it. That is the outcome worth having, and it is the difference between a finding that needs a tracking issue and one that does not.

What this issue predicted, checked against what happened

The prediction was that a smaller unit could be reviewed to a conclusion where a 477-file one could not. Since filing: #3050, #3051, #3078, #3080 and #3115 all landed on main, each reviewed and approved, against a draft that took five rounds without converging. The decomposition worked.

What I would record as the process lesson is narrower than the original framing, though. The draft's review was not wasted and the findings were not lost -- 16 of 20 were closed out by ordinary slice work, mostly without anyone consulting the draft. The cost of the wrong container was not lost findings; it was five rounds of author effort spent answering threads on a diff that could never merge, plus a stale map that overstated the remaining work by 3x and would have kept justifying more of the same. The stop signal was available at round 3.

Remaining unsliced surface, unchanged: server.py and device_manager.py (now #3122), mesh_bridge.py, peer_tools.py, agent_hitl.py, the mesh/core.py edits, and the docs/dashboard/ pages.

Leaving this issue open until the last of those is sliced, since it is the only place the decomposition ordering is written down.

[cagataycali]

Done: #2848 is closed with the per-thread map as its record, the slices landed one by one (#3205 is the last in flight), and #3122 carries the two findings the unsliced modules still owe.