luci-app-openthread: read the stopped-network dataset via ubus status

[LorbusChris]

Stacked on #8871 — only the top commit is new. Draft until its backend prerequisite exists upstream: the status ubus method is part of the otbr Matter-integration series being upstreamed to openthread/ot-br-posix (coordination with its author in project-chip/matter-openwrt#53; the surrounding series is openthread/ot-br-posix#3489 plus a follow-up). The ot-br-posix PR will be linked here once it is open.

The status method returns the committed Active Operational Dataset as TLVs. Prefer it for the stopped-network summary: one round-trip instead of three, and the values come from the dataset itself rather than the per-field getters. Without the method the stock fallback path stays in use, so the app keeps working against an unpatched otbr-agent either way.

[openwrt-ai]

First review of this PR. The base commit 155161b is the head of #8871 and is being reviewed there, so this pass is scoped to the one new commit, f5b4b00 — a single hunk in the rpcd ucode backend.

What I checked:

• Commit message vs. diff. Matches: the subject scope (luci-app-openthread:) is the only package touched, and the body describes exactly the status-preferred path plus getter fallback that the diff implements. Nothing to flag.
• Fallback safety. otbr() substitutes { error: 255 } when ubus.call returns null, so otbr('status').ActiveDataset is null rather than a throw on a daemon without the method, and dataset_summary() rejects it on the type(...) != 'string' guard. The stock path is reached, as the commit claims.
• TLV decoding. Types 0/1/3 are Channel, PAN ID and Network Name per the MeshCoP dataset TLV numbering, the Channel branch correctly skips the channel-page byte, and the walk is bounded at both ends (i + 4 <= n, truncated-value break, l == 0 still advances). chr() in ucode is byte-based (lib.c:711-737), so a UTF-8 network name round-trips intact rather than being re-encoded per byte.
• Type/format parity with the branch it replaces. panid is emitted as '0x' + lc(v), matching the 0x%04x string the panid getter returns — the lc() added in this commit is what makes the two agree, and overview.js renders it through String() either way. channel is a number on both paths.
• ACL. No new luci.openthread method, and the status call is made by the plugin as root, so acl.d/luci-app-openthread.json needs no change. Correct as-is.
• Backend coupling. Per .github/llm-review-rules.md this would normally want a consumer check, but status lives in ot-br-posix, which is not among the pre-cloned trees; the PR body already states the method is unmerged upstream and that the PR stays draft until it lands, so I have not flagged the dependency.
• CI. No checks have run on f5b4b00 yet (status pending, 0 checks), so there is nothing to ground against.

Two follow-ups inline: one on configured losing the unprovisioned guard on the new path, one nit on the per-poll cost against an unpatched agent.

---

Generated by Claude Code

[openwrt-ai]

Re-review at 29af3c4, against my last pass at f5b4b00.

Scope: the base commit moved 155161b → 13772da (that is #8871's content — the mac-filter hazard checks and the numeric PAN id parse — and it is reviewed there, not here). The only commit in this PR's own scope, 29af3c4, changed by the rebase plus a comment rewrap; its logic is unchanged from f5b4b00.

• Commit message vs. diff. 29af3c4 still matches its subject and body; nothing new to flag.
• Carried over from last round. The per-poll cost nit (a status probe every 2 s tick against a stock agent, plus "one round-trip instead of three" holding only against a patched one) is unaddressed and still applies — not repeated inline.
• New this round. The rebase pulled a stricter unprovisioned test into the fallback branch without giving the status branch a counterpart, so the two paths now diverge more than they did at f5b4b00. One inline comment, with a suggestion matching the file's new idiom; it supersedes my earlier one on the same line.
• CI. All three FormalityCheck runs on 29af3c4 are green.

---

Generated by Claude Code

[openwrt-ai]

Re-review at 8c0e7f0, against my last pass at 29af3c4.

Scope: the base commit moved 13772da → a2d15f4 (#8871's content — overview.js and the regenerated .pot; reviewed there, not here). This PR's own commit was reworked in place, 29af3c4 → 8c0e7f0: the status probe moved into a latching otbr_status() helper, and the configured guard picked up the PAN-id test.

• Latch. Correct on the point that worried me most — the discriminator really does distinguish the two cases. ubus.error() renders ubus_strerror(code) and appends ": %s" whenever last_error.msg is set (uc_ubus_error(), lib/ubus.c:637-668), and uc_ubus_call() always sets that message (lib/ubus.c:1411-1419), so a method miss on a present object yields "Method not found: Failed to invoke function 'status' on object 'otbr'" and the 17-char prefix matches. A missing object fails earlier in ubus_lookup_id() and yields "Not found: …", so it does not latch, as intended. Module state persists across calls, so the latch holds for rpcd's lifetime — one nit inline on how that interacts with an otbr-agent upgrade.
• configured guard. The fix I suggested last round was wrong, and it is now in the tree. +null is 0 in ucode, not NaN, so the new test does not require the PAN id after all. Details and a corrected suggestion inline; sorry for the round trip.
• Comments. One nit: the rewritten block above the guard carries both drafts of the same explanation.
• CI. All three FormalityCheck runs on 8c0e7f0 are green.

Commit checks

• 8c0e7f0 "luci-app-openthread: read the stopped-network dataset via ubus status" — two claims in the body do not hold:
  • "configured requires the PAN id and rejects the broadcast value, matching what the getter path has always done." The broadcast half is implemented; the "requires the PAN id" half is not, for the +null reason above. Either the code or the sentence needs to change.
  • "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." feeds/packages/net/openthread-br carries three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — and none of them touches the ubus object. The PR body says the opposite and is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"), so the method exists in neither place today. Worth correcting before this leaves draft, since it is the sentence a reader checks to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at 52e9409, against my last pass at 8c0e7f0.

Scope: the base commit moved a2d15f4 → 2ae1f9d (#8871's content — hoisting the mac-filter Clear/Add buttons out of macRows so applyMacReadability() can gate them, and the macModeChanged() guard on the applied filter mode; reviewed there, not here). This PR's own commit was reworked in place, 8c0e7f0 → 52e9409: one line of logic plus both comment blocks.

• configured guard. Fixed correctly. ds?.panid != null ? +ds.panid : NaN tests the property instead of the coercion, so the +null == 0 trap from last round is closed: absent ds, a truthy {} from a TLV stream with no PAN ID TLV, and the hex()-NaN garbage case all now yield NaN and fall through to the getters, while 0xffff is still rejected. With that in the tree, the commit message's "configured requires the PAN id and rejects the broadcast value" is finally accurate.
• Latch comment. The new second paragraph is right on the mechanism — rpcd keeps one uc_vm_t per script and re-enters it per call (rpc_ucode_script_t.vm, ucode.c:56-62, invoked at ucode.c:458) — so "until rpcd is restarted too" is the correct bound. Stating it rather than clearing the flag is a reasonable call.
• Duplicated comment. Merged, and the added note about +null being 0 is the right thing to leave behind.
• Stale-error check (new, for the latch). Every null-returning path in uc_ubus_call() goes through err_return(), including the ubus_lookup_id() miss (lib/ubus.c:1397-1419), so the error read in otbr_status() is always the one from its own call — no risk of latching on a leftover from an earlier otbr() failure. And uc_ubus_error() clears on read, so nothing leaks the other way either.
• New this round. One inline comment on how the latch discriminates the two failures — the behaviour is correct, the coupling is to libubus's message text rather than to its status code.
• CI. All three FormalityCheck runs on 52e9409 are green.

Commit checks

• 52e9409 "luci-app-openthread: read the stopped-network dataset via ubus status" — the message is byte-identical to 8c0e7f0's, so the second claim from last round is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." The package pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none of which touches the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method exists in neither tree today. Worth correcting before this leaves draft, since it is the sentence a reader follows to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at 963dd58, against my last pass at 52e9409.

Scope: the base commit moved 2ae1f9d → 55b3186 (#8871's content — overview.js and the regenerated .pot; reviewed there, not here). This PR's own commit was reworked in place, 52e9409 → 963dd58: the module handle at lines 5-6, the latch discriminator, and the comment above it. Eleven lines, no other file touched.

• Numeric discriminator. Correct, and your device measurement matches the source. uc_ubus_call() reaches ubus_lookup_id() first and returns its status verbatim on a missing object (lib/ubus.c:1399-1403), then returns the invoke status on a missing method (lib/ubus.c:1412-1419) — UBUS_STATUS_METHOD_NOT_FOUND (3) and UBUS_STATUS_NOT_FOUND (4) respectively, so the two cases stay separable without depending on __ubus_strerror wording. ubus.error(true) returns ucv_int64_new(last_error.code) unconditionally under the numeric branch (uc_ubus_error(), lib/ubus.c:646-648) — it does not take the STATUS_UNKNOWN_ERROR special case the string branch has, which was the second coupling I flagged. And ADD_CONST(STATUS_METHOD_NOT_FOUND) is unconditional in the module scope (lib/ubus.c:3954), so ubusmod.STATUS_METHOD_NOT_FOUND resolves to a real value rather than null — worth having checked, since a null there would have made every error-cleared null reply latch.
• No false latch on an empty reply. ok_return() clears the error before returning (lib/ubus.c:445), so a status method that answered with no payload gives ubus.error(true) == null, which does not equal the constant. It falls back that poll and retries the next one, which is the right way round.
• Module handle. error is registered on both the module scope and the connection (lib/ubus.c:3823 and 3838) over the same static last_error, so reading it off ubus while taking the constant off ubusmod is consistent, not two different error slots.
• Comment. Now says "answers with a different status" rather than naming the string; accurate.
• CI. All three FormalityCheck runs on 963dd58 are green.

No new inline comments this round.

Commit checks

• 963dd58 "luci-app-openthread: read the stopped-network dataset via ubus status" — message is byte-identical to 52e9409's, so the one item from the last two rounds is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." The package pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none touching the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method is in neither tree today. Since the code paths themselves now look settled, this sentence is the last thing I'd want fixed before the PR leaves draft — it is what a reviewer follows to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at c80a52b, against my last pass at 963dd58.

Scope: nothing in this PR's own scope changed. The base commit moved 55b3186 → c1d1578 (#8871's content — the macReadable()/applyMacVisibility() rework around an unreadable mac-filter state rather than just an unreadable list, the per-address Remove buttons now collected fresh in applyMacReadability(), and the regenerated .pot; reviewed there, not here). This PR's own commit was rebased onto it with no other change: git diff 55b3186 963dd58 and git diff c1d1578 c80a52b produce byte-identical patches, and the commit message is byte-identical too.

• Backend file. Unchanged since last round, so the conclusions from the previous passes still hold as-is: the numeric latch discriminator (ubus.error(true) == ubusmod.STATUS_METHOD_NOT_FOUND, line 38) separating a missing method (3) from a missing object (4), the module handle at lines 5-6, the ds?.panid != null ? +ds.panid : NaN guard, and the merged comment block. No new inline comments.
• Base interaction. The base commit only touches the mac-filter modal in overview.js; it does not go near state_summary, dataset_summary() or the configured consumers, so the rebase does not disturb anything this commit depends on.
• CI. No checks have run on c80a52b yet (status pending, 0 checks), so there is nothing to ground against this round.

Commit checks

• c80a52b "luci-app-openthread: read the stopped-network dataset via ubus status" — message unchanged from 963dd58, so the one item from the last three rounds is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." feeds/packages/net/openthread-br pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none touching the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method is in neither tree today. The code paths have been settled for three rounds now, so this sentence is the last thing I'd want fixed before the PR leaves draft — it is what a reviewer follows to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at 1198d4f, against my last pass at c80a52b.

Scope: nothing in this PR's own scope changed. The base commit moved c1d1578 → 8d40ca1 (#8871's content — the Unknown placeholder option on the mac-filter mode select plus the macModeNote em, refreshMacList() now refreshing s.macfilterstate alongside s.addrlist, macModeChanged() gaining the s.macfilterstate != null baseline test, the narrowed Clear-button confirm condition, and the regenerated .pot; reviewed there, not here). This PR's own commit was rebased onto it with no other change: git diff c1d1578 c80a52b and git diff 8d40ca1 1198d4f produce byte-identical patches, and the commit message is byte-identical too.

• Backend file. root/usr/share/rpcd/ucode/luci.openthread is untouched since last round, so the conclusions from the previous passes stand as-is: the numeric latch discriminator (ubus.error(true) == ubusmod.STATUS_METHOD_NOT_FOUND, line 38) separating a missing method (3) from a missing object (4), the module handle at lines 5-6, the ds?.panid != null ? +ds.panid : NaN guard at line 130, and the merged comment block. No new inline comments.
• Base interaction. The base commit's overview.js hunks are confined to the MAC-filter modal in handleSettings() — macSelect, macModeNote, refreshMacList(), macReadable()/macModeChanged()/applyMacVisibility()/applyMacReadability(), and the cbiValue(_('Protocol'), …) row. It does not touch state_summary, dataset_summary(), or any of the st.configured / st.panid / st.channel / st.networkname consumers (the Create-button gate at overview.js:799, the network row at :842-844, the placeholder at :884-889), so the rebase does not disturb anything this commit depends on. This commit also adds no user-visible strings, so it has no stake in the regenerated .pot.
• CI. No checks have run on 1198d4f yet (status pending, 0 checks), so there is nothing to ground against this round.

Commit checks

• 1198d4f "luci-app-openthread: read the stopped-network dataset via ubus status" — message unchanged from c80a52b, so the one item from the last four rounds is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." feeds/packages/net/openthread-br pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none touching the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method is in neither tree today. The code paths have been settled for four rounds now, so this sentence is the last thing I'd want fixed before the PR leaves draft — it is what a reviewer follows to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at f90de8e, against my last pass at 1198d4f.

Scope: nothing in this PR's own scope changed. The base commit moved 8d40ca1 → 879e162 (#8871's content — macfilter_add/macfilter_remove gaining a confirmed arg and the unconfirmed_mode refusal when the call would also switch the filter mode on, the matching filterRefusals string, the macReadable() early-returns in the three MAC-filter click handlers, the setTimeout(applyMacReadability, 0) after refreshMacList(), and the regenerated .pot; reviewed there, not here). This PR's own commit was rebased onto it with no other change: git diff 8d40ca1 1198d4f and git diff 879e162 f90de8e produce byte-identical patches (only the blob index lines differ), and the commit message is byte-identical too.

• Backend file. root/usr/share/rpcd/ucode/luci.openthread is untouched in this commit's own delta since last round, so the conclusions from the previous passes stand as-is: the module handle at lines 5-6, the numeric latch discriminator (ubus.error(true) == ubusmod.STATUS_METHOD_NOT_FOUND) separating a missing method (3) from a missing object (4), the ds?.panid != null ? +ds.panid : NaN guard, and the merged comment block. No new inline comments.
• Base interaction. The base commit's hunks in this same file are confined to the macfilter_add and macfilter_remove method bodies in the returned object — it does not go near otbr_status(), dataset_summary(), summarize_state(), or any of the st.configured / st.panid / st.channel / st.networkname consumers in overview.js. Its overview.js hunks are likewise confined to the MAC-filter modal in handleSettings() plus the filterRefusals map. So the rebase does not disturb anything this commit depends on, and since this commit adds no user-visible strings it has no stake in the regenerated .pot.
• All prior threads. The seven review threads on this file are resolved, and the last two rounds added no new ones. Nothing carried over inline.
• CI. No checks have run on f90de8e yet (status pending, 0 checks), so there is nothing to ground against this round.

Commit checks

• f90de8e "luci-app-openthread: read the stopped-network dataset via ubus status" — message unchanged from 1198d4f, so the one item from the last five rounds is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." feeds/packages/net/openthread-br pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none touching the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method is in neither tree today. The code paths have been settled for five rounds now, so this sentence is the last thing I'd want fixed before the PR leaves draft — it is what a reviewer follows to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at d6facbf, against my last pass at f90de8e.

Scope: nothing changed in this PR at all beyond a rebase onto current master. Both commits were replayed — base 879e162 → ff20643, this PR's own commit f90de8e → d6facbf — and both are content-identical to last round: git diff 879e162 ff20643 -- applications/luci-app-openthread is empty, and git diff 879e162 f90de8e vs git diff ff20643 d6facbf are byte-identical patches, blob index lines included. The commit message is byte-identical too. The only delta between the two heads is the unrelated master churn the rebase pulled in (po/ translation updates and other apps).

• Backend file. root/usr/share/rpcd/ucode/luci.openthread is unchanged, so the conclusions from the previous passes stand as-is: the module handle at lines 5-6, the numeric latch discriminator (ubus.error(true) == ubusmod.STATUS_METHOD_NOT_FOUND) separating a missing method (3) from a missing object (4), the ds?.panid != null ? +ds.panid : NaN guard, and the merged comment block. No new inline comments.
• Base interaction. Unlike the previous five rounds, #8871's content did not move this time — the base commit's openthread tree is identical — so there is no new base behaviour for this commit to interact with.
• Prior threads. All seven review threads on this file are resolved; nothing carried over inline.
• CI. All three FormalityCheck runs on d6facbf are green.

Commit checks

• d6facbf "luci-app-openthread: read the stopped-network dataset via ubus status" — message unchanged from f90de8e, so the one item from the last six rounds is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." feeds/packages/net/openthread-br still pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none touching the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method is in neither tree today. The code has now been settled for six rounds, so this sentence remains the last thing I'd want fixed before the PR leaves draft — it is what a reviewer follows to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at c2feeb8, against my last pass at d6facbf.

Scope: nothing in this PR's own scope changed. The base commit moved ff20643 → 51d8328 (#8871's content — macfilter_add/macfilter_remove and macfilter_clear flipping their confirmed / macfilter_confirmed arg declarations from false to true, and the three overview.js block/allow handlers passing true through; reviewed there, not here). This PR's own commit was rebased onto it with no other change: git diff ff20643 d6facbf and git diff 51d8328 c2feeb8 are byte-identical patches apart from the blob index lines, and the commit message is byte-identical too.

• Backend file. root/usr/share/rpcd/ucode/luci.openthread is unchanged in this commit's own delta, so the conclusions from the previous passes stand as-is: the module handle at lines 5-6, the numeric latch discriminator at [line 38](https://github.com/openwrt/luci/blob/c2feeb8a82672f51dc11bb1d16a15fd3a51ff38b/applications/luci-app-openthread/root/usr/share/rpcd/ucode/luci.openthread#L38``) separating a missing method (3) from a missing object (4), the ds?.panid != null ? +ds.panid : NaN guard at line 120,`` and the merged comment block. No new inline comments.
• Base interaction. The base commit's hunks in this same file are confined to the args declarations of settings_apply, macfilter_add/macfilter_remove and macfilter_clear in the returned object; its overview.js hunks are the matching rpc.declare param lists and the three MAC-filter confirm handlers. Nothing goes near otbr_status(), dataset_summary(), summarize_state() or the st.configured / st.panid / st.channel / st.networkname consumers, so the rebase does not disturb anything this commit depends on. This commit adds no user-visible strings either, so it has no stake in the regenerated .pot.
• Prior threads. All seven review threads on this file are resolved; nothing carried over inline.
• CI. No checks have run on c2feeb8 yet (status pending, 0 checks), so there is nothing to ground against this round.

Commit checks

• c2feeb8 "luci-app-openthread: read the stopped-network dataset via ubus status" — message unchanged from d6facbf, so the one item from the last seven rounds is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." feeds/packages/net/openthread-br still pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none touching the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method is in neither tree today. The code has been settled for seven rounds, so this sentence remains the last thing I'd want fixed before the PR leaves draft — it is what a reviewer follows to find the backend consumer.

---

Generated by Claude Code

[openwrt-ai]

Re-review at bb734d0, against my last pass at c2feeb8.

Scope: nothing in this PR's own scope changed. The base commit moved 51d8328 → 467a4bc (#8871's content — blockWarning() gaining an activatesDenylist argument that prepends the router-wide mode-change warning, handleBlock() deriving activates from neigh.macfilter == 'disable' and passing it as the confirmed flag instead of a hardcoded true, and handleAllowlistBlock() / handleAllow() dropping their true so a stale row cannot silently switch the filter on; reviewed there, not here). This PR's own commit was rebased onto it with no other change: git diff 51d8328 c2feeb8 and git diff 467a4bc bb734d0 are byte-identical patches, blob index lines included, and the commit message is byte-identical too.

• Backend file. root/usr/share/rpcd/ucode/luci.openthread is unchanged in this commit's own delta, so the conclusions from the previous passes stand as-is: the module handle at lines 5-6, the numeric latch discriminator at [line 38](https://github.com/openwrt/luci/blob/bb734d017da754871a04fcb9ba266a74d2b50fc2/applications/luci-app-openthread/root/usr/share/rpcd/ucode/luci.openthread#L38``) separating a missing method (3) from a missing object (4), the ds?.panid != null ? +ds.panid : NaN guard at line 120,`` and the merged comment block. No new inline comments.
• Base interaction. The base commit's delta is confined to overview.js (the three MAC-filter modal handlers and blockWarning()) plus the regenerated .pot; it does not touch the ucode backend at all this round, and goes nowhere near otbr_status(), dataset_summary(), summarize_state(), or the st.configured / st.panid / st.channel / st.networkname consumers. So the rebase does not disturb anything this commit depends on. This commit adds no user-visible strings either, so it has no stake in the regenerated .pot.
• Prior threads. All seven review threads on this file are resolved; nothing carried over inline.
• CI. No checks have run on bb734d0 yet (status pending, 0 checks), so there is nothing to ground against this round.

Commit checks

• bb734d0 "luci-app-openthread: read the stopped-network dataset via ubus status" — message unchanged from c2feeb8, so the one item from the last eight rounds is still standing: "Requires the ubus status method, which OpenWrt's openthread-br package carries as a patch and stock ot-br-posix does not yet have." feeds/packages/net/openthread-br still pins ot-br-posix at 2f3c799 and carries exactly three patches — 100-fix-gcc14-build, 101-rest-Permit-to-externally-provide-cJSON-library, 102-openwrt-fix-LuCI-icons — none touching the ubus object. The PR body is the accurate one ("Draft until its backend prerequisite exists upstream … The ot-br-posix PR will be linked here once it is open"): the method is in neither tree today. The code has been settled for eight rounds, so this sentence remains the last thing I'd want fixed before the PR leaves draft — it is what a reviewer follows to find the backend consumer.

---

Generated by Claude Code