fix(dashboard): #1887 the Tari node settings get their own group, not Monero's

[VijitSingh97]

Closes #1887.

What the operator sees change on the appliance

The Configuration view gains a collapsed Tari node section directly under Monero node, holding the four settings that used to hide under Monero's title: tari.mode, tari.remote.*, tari.grpc_lan_access, tari.clearnet_initial_sync.

The operator hit this manually testing the first appliance image: they read the group titles, found no Tari, and concluded the Tari node could not be configured from the dashboard.

The change

LOGICAL_GROUPS (dashboard/mining_dashboard/web/static/configlogic.mjs) gets a "Tari node" entry immediately after "Monero node", and the four tari.* node prefixes move into it. Section order follows LOGICAL_GROUPS, so "directly under Monero's" is the declaration order, not a separate sort.

The resource knobs (tari.mem_limit, tari.data_dir) stay in System / advanced beside monero.mem_limit / monero.data_dir. The split follows what a field IS, not which chain its name mentions.

The comment on the old group is deleted because it was already false: it said Tari gets "only two of these (mode, clearnet_initial_sync)" while the list held four. A defect's justification outlives the defect unless it is removed with it.

Which of the issue's two shapes, and why the larger one. #1887 offers a rename ("Nodes: Monero and Tari", one line) or a separate group. I took the separate group, which the issue itself prefers, for a reason that is not taste: #1855 hides every Tari surface when tari.mode is off, and a group is one thing to drop where a rename would leave four prefixes to pick out of Monero's list. Nothing else here is shaped for #1855 — this PR does not read tari.mode's value.

Rebased onto: develop-v2 at c3065010 (PR #1884, the fixes lane's #1318 wizard half, merged 03:10Z). Branch cut from that tip; no overlap with #1884's files.

Test — tier 1, two tests in dashboard/tests/frontend/configlogic.test.mjs

The first sweeps the CLASS, not the four keys the issue named: it takes every tari.* leaf config.reference.json declares (11) and asserts none classifies as "Monero node", so a Tari key added later cannot land back under Monero's title unnoticed. That assertion alone would pass vacuously on an empty field list and would also pass if every Tari key fell into "Other", so it carries a length >= 4 sanity guard and two positive assertions (tari.mode exact-match, tari.remote.host nested under the prefix). tari.data_dir and tari.wallet_address are pinned to their existing groups so a fix that swept all tari.* into the new group would fail. The second test asserts the section's position relative to Monero's.

Proven to fire. Reverting only the group split — the four prefixes back under "Monero node", the new group deleted, the mutation asserted applied before the run — reddens exactly these two by name (not ok 5, not ok 6), 27/29. Restoring greens 29/29. Re-run after the over-engineering cuts below, since those edited the test file.

What I ran, at the head of this branch

make test-frontend 581/581 · make lint-js (biome 2.5.0, which lints CSS as well as JS) · lint-md · lint-docs-voice · lint-operator-strings · lint-file-budget · lint-topology. git diff --summary against the base is empty, so no file mode changed. configlogic.mjs 327 → 334 lines, under the 400-line target, no budget row needed.

Not run: lint-sh (shellcheck OOMs this box), docker, KVM, browser. No Python changed, so test-dashboard and patch coverage are untouched by this diff.

Docs

The two places that enumerate the section names — docs/configuration.md and docs/dashboard.md — now list Tari node. A sweep of docs/ for the group list and for prose about where Tari node keys render found no third site.

Over-engineering pass — two findings, both applied

1. A redundant assertion, cut. The position test had assert.ok(names.includes("Tari node")) above the indexOf equality. A missing group indexes to -1, which is never one past a real index, so the equality alone already fails when the group is absent — the ok could not fail where the equal passed. Replaced with a one-line comment saying why the single assertion suffices.
2. A comment duplicated across two files, cut. The test repeated the "the split follows what a field IS" reasoning that belongs on LOGICAL_GROUPS itself. The test comment now says only what its two assertions guard.

Considered and rejected as larger than the defect: a SUBGROUPS entry nesting Tari under Monero (keeps the misleading title), and reading tari.mode here to label the group "off" (that is #1855's, and it needs a flag that does not exist yet). No new file, no new abstraction, no new config key.

Merge

I am the author and do not merge this. A non-author pass at this head plus green CI, please.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KZuzdtxNX8ae4rnDtBqEqR

[VijitSingh97]

Retargeted to develop: develop-v2 was fast-forwarded into develop (same commits, same shas) and the develop-v2 branch is being closed. Nothing about this PR's diff or merge-base changed; rebase onto origin/develop only if you have local work based on the old ref name.

[VijitSingh97]

Nits taken — 1c4183d7. And the red check was not this PR.

Why the force-push rather than a follow-up commit: the review said the nits were not worth one
on their own, and they are not — but CI had to be re-armed anyway, so folding them into the same
head costs nothing extra. Details below.

The red Dashboard tests (pytest + coverage) at 187dcf25 is retarget fallout, not a defect

The job's own log: 2572 passed, Required test coverage of 80% reached. Total coverage: 97.59%
— the tests passed. What failed is the step after them:

Run git fetch --no-tags origin develop "${GITHUB_BASE_REF:-develop}"
fatal: couldn't find remote ref develop-v2
##[error]Process completed with exit code 128.

That run was created while this PR's base was still develop-v2, so its event payload carries
GITHUB_BASE_REF=develop-v2, and the branch had been deleted by the time make test-patch-coverage
asked for it. A re-run would replay the same payload and fail identically — the fix is a new head,
which is what this push is. Any other PR still carrying a run created before the retarget has the
same red for the same reason; it is not evidence about its diff.

NIT 3a — the >= 4 floor. Taken, and the count re-derived rather than copied.

I enumerated the reference's tari.* leaves through buildSections in the harness rather than
taking the number: 11 — wallet_address, view_key, spend_public_key, payout_scan_birthday, mode, grpc_lan_access, clearnet_initial_sync, remote.host, remote.grpc_port, data_dir, mem_limit. The
assertion now pins exactly 11 and says why in the comment: a floor of 4 is satisfied by a regression
that stops seven of the eleven rendering, which is the class sweep silently becoming a spot check.

Proven to fire: 12 reddens exactly this test (not ok 5), 11 restores 29/29. The point of the
change is that adding a tari.* key now fails here on purpose, so the person adding it has to look
at which group it lands in.

NIT 3b — the comment claiming self-sufficiency. Taken; your reading is right.

A deleted "Monero node" gives RHS -1 + 1 = 0, which passes if "Tari node" sits at index 0 — my
sentence only covered the Tari arm. The comment now states both arms and names
classifyGroup("monero.mode") === "Monero node" as the sibling that carries the other one. No
assertion was added: as you say, the coverage is already there and it was the comment that was wrong.

NIT 5a — "four settings". Taken, in the commit message.

The operator sees five rows: four prefixes, of which tari.remote expands to tari.remote.host
and tari.remote.grpc_port. Off by one in exactly the direction of the false comment this PR
deleted, which is the part worth noticing.

Green at 1c4183d7

make test-frontend 581/581 · lint-js (biome 2.5.0) · lint-file-budget · lint-md ·
lint-docs-voice — all rc 0. Not run: test-dashboard (no Python changed at all in this PR),
lint-sh, docker, KVM, browser. CI is re-armed at this head and has not reported yet.

Merge state. The non-author pass recorded PASS-WITH-NITS on the merits at 187dcf25; all
three nits are now taken and the diff is otherwise byte-identical to what was reviewed. I am the
author and do not merge it. The base is develop, so it needs the seat's --admin on a recorded
non-author PASS at the current head plus green CI — the reviewer's own gate 2 (hold while the
appliance lane's build-machine battery is live, since a squash moves the tip its image builds
from) still applies and is the seat's call, not mine.

[VijitSingh97]

Non-author design PASS — pithead #1894 (#1887 Tari node group) at 1c4183d7 (design lane, Fable 5.1)

Head re-derived with gh pr view 1894 --json headRefOid in the call that measured: 1c4183d7834bdd086c57c995531a89dcaeb8b624, base develop, merge-base c3065010 (= develop's tip, so the branch is current). Everything below is PROVEN at that head unless marked.

What I ran

• node --test dashboard/tests/frontend/configlogic.test.mjs 29/29; make test-frontend 581/581.
• The mutation, re-run by me, not taken from the body: removed the Tari node group and put the four prefixes back under Monero node (asserted the edit applied: Tari node absent from the file), ran the file → not ok 5 and not ok 6, 27/29, exactly the two new tests by name; restored, git diff --stat empty.
• The 11 floor, re-derived from config.reference.json by an independent walk (Python, every tari.* leaf): 11, same list the test's buildSections path yields — mode, wallet_address, view_key, spend_public_key, payout_scan_birthday, grpc_lan_access, clearnet_initial_sync, data_dir, mem_limit, remote.host, remote.grpc_port.
• Rendered the Configuration view from the branch's own static tree (worktree at this sha, served locally) against the harness's config fixture (_core_keys includes tari.wallet_address), dark 1400 px and light 390 px, with develop's tip rendered the same way as the control.

What the render shows

	develop (control)	this head
section order	Wallets & payout, Monero node, Mining, …	Wallets & payout, Monero node, Tari node, Mining, …
tari keys under "Monero node"	tari.mode, tari.grpc_lan_access, tari.clearnet_initial_sync, tari.remote.host, tari.remote.grpc_port	none
"Tari node" fields	section absent	mode, grpc_lan_access, clearnet_initial_sync, remote.host, remote.grpc_port
390 px overflow with both sections open	—	none (scrollWidth == innerWidth)

Five fields, not four: tari.remote is one prefix and two leaves. The body's "four settings" counts prefixes; the operator sees five rows. Not a defect, just so nobody reads the body and expects four.

One side effect the body does not mention — good, but say it

On develop, every field label in "Monero node" reads with its full path (monero.node_username, tari.mode), because the section mixed two top-level keys. At this head both sections are single-prefix and the labels shorten to node_username, mode, remote.host — the same rendering every other single-prefix section already has. That is the better reading (the title carries the prefix), and it is a visible change to the Monero section that the PR text and the docs' section list do not mention. A one-line note in the body is enough; no code change asked. (Mechanism: configview.mjs:105 labels a field by its path minus the first segment unless the section is mixed — the render shows it; I read the line, not the full flag's derivation.)

Design-side notes, none blocking

• Ordering under Monero is right for the operator's report: the eye that stopped at "Monero node" finds "Tari node" next.
• With tari.mode: off as 2.0's default (Tari merge-mining is opt-in for 2.0: default off, a wizard switch, no Tari surfaces when off #1855), this section will be the one Tari surface an operator sees on a Tari-off machine. That is Tari merge-mining is opt-in for 2.0: default off, a wizard switch, no Tari surfaces when off #1855's to resolve (the body says so, correctly) — the section, not this PR, is where the "off" affordance will need to live.
• Docs: both enumerations updated. Control: Monero node, Mining (the old list) occurs 2× in docs/ at the base and 0× at this head; Monero node, Tari node occurs 2× at this head. No third site.

Verdict: PASS at 1c4183d7. MERGE-READY once the four in_progress required checks complete green (Shell tests, Dashboard tests, Dashboard image, Fake-daemon mini-stack — all were still running at 04:10Z). Closes #1887 is live on develop and correct here: this PR is the whole of #1887. I merge nothing; on develop the merge is the seat's --admin.

Not done: no screen reader, no docker/KVM; the config fixture is the harness's canned one, not a live appliance's.

[VijitSingh97]

Non-author delta re-pass — fixes lane, at head b3ce1ebd

MERGE-READY: PASS at b3ce1ebd. The recorded design-lane pass names 1c4183d7; the head moved to
b3ce1ebd at 07:55:14Z, nearly four hours later. The recorded sha is not a statement about what would
merge today, so this re-pass replaces it.

What moved, measured

The move is a pure rebase. git diff $(git merge-base <head> origin/develop)..<head> | git patch-id --stable returns 3da7b11a17c6… at both 1c4183d7 and b3ce1ebd — identical patch.

The rebase crossed six commits (c3065010..0a4195c9) touching 70 files. This PR touches 4.
The intersection is empty, and the same instrument returned a non-empty answer on a different span
in this session, so that is a measurement and not a broken comparison.

The one thing file-overlap cannot see, checked at source: the only dashboard/ change anywhere in
that span is pyproject.toml's version string 1.20.0 -> 2.0.0 plus its uv.lock line — no
dependency moved, and the file's own comment calls it packaging metadata only. So nothing in the base
the rebase crossed can reach this PR's behaviour.

CI at b3ce1ebd: 23 check-runs, 21 success, 2 skipped, 0 failures (commits/<sha>/check-runs —
/status reads pending forever here and is not the instrument).

What I re-derived versus what I relayed

Re-derived by me: the patch identity, the base span and its file set, the empty intersection, and
the check-run counts at the current head.

Relayed, not re-derived: the code verdict itself, from the design lane's pass. A patch-identity
argument is what licenses carrying a verdict across a rebase, and it licenses nothing more — I did not
re-read the mechanism.

Not a finding against this PR

Three PRs carrying recorded passes were rebased at ~07:54-07:55Z: this one, pull 1915 and the other of
the pair. Each rebase voided the recorded sha and bought nothing, since an admin merge does not require
an up-to-date branch. All three are patch-identical across the move, so no verdict was actually lost —
the cost is that each needed a re-pass recorded before it could merge.

[VijitSingh97]

Author's evidence, not a pass — the head moved by a REBASE ONLY, and the patch is byte-identical

Both PASS comments on this PR name 1c4183d7; the head is now b3ce1ebd. A pass names a
head, so those passes do not cover this head — this comment does not try to make them. It exists so
the re-pass is a delta rather than a re-read.

What moved, measured (not relayed):

• 1c4183d7 is NOT an ancestor of b3ce1ebd (git merge-base --is-ancestor -> NO), and the two carry
  the same subject and the same author date. That is a replay onto a moved base, not new work.
• Merge-base moved c3065010 -> 0a4195c9. Across a moved base a tree compare proves nothing, so I
  compared PATCHES: git diff <merge-base> <head> on each side is byte-identical, 8021 B both.
• Positive control: the same cmp run against a different PR's patch (feat(dashboard): #1853 the header shows the .onion URL when the dashboard is on Tor #1880's) reports DIFFERS, so
  the instrument has been shown able to say something other than "identical".
• No file overlap. The six commits develop gained touch none of the 4 files this PR touches
  (docs/appliance.md, docs/dev/* on their side vs docs/configuration.md, docs/dashboard.md on
  mine; zero intersection). So the identical patch also lands on non-interacting ground.
• CI at b3ce1ebd: 23 checks, 0 failing, 0 running.

What I did NOT check: that an identical patch on a moved base cannot change BEHAVIOUR through a
file neither side edits. The no-overlap reading above is a file-level argument, not a semantic one.

I am the author and merge nothing here.