wangxuming/makelore
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

fix(robot): scope devices to selected agent

Browse Source
This commit is contained in:
brother7
2026-08-16 15:42:05 +08:00
parent 3b4669722e
commit 87a95b4cec
3 changed files with 132 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
.project-docs/30-worklog/tasks/20260816-robot-device-selection-f6a2.md Normal file
View File

@@ -0,0 +1,68 @@
# Task: Fix Robot device selection and binding
## Identity
- Task ID: 20260816-robot-device-selection-f6a2
- Mode: Feature
- Branch: codex/20260816-robot-device-selection-f6a2-robot-device-selection
- Worktree: D:\Datas\OthersProjects\makelore-robot-device-selection-f6a2
- Base commit: 3b4669722e0ea671909beb039da1e07c2483341a
- Owner: codex-root
- Status: Ready for Integration
## Scope
- Fix the Robot page so the device panel follows the currently selected agent.
- Prove that binding a new activation code targets the selected agent while preserving the existing guided/manual binding flow.
- Clarify that the current product adds devices through a six-digit activation code; nearby-device discovery remains out of scope.
## Intent And Constraints
- Treat devices as agent-scoped child resources in the UI while retaining the account-wide overview DTO.
- Do not add a new backend route, automatic discovery, firmware behavior, or a second hardware module.
- Preserve Main-owned provisioning, activation-code secrecy, idempotency, reassignment revisions, and the default-off guided Hotspot flow.
- Use a deterministic page regression test that reproduces the exact stale-device symptom before changing production code.
## Project Context Loaded
- Task: `20260816-robot-device-selection-f6a2`, Feature mode, isolated worktree and branch, base `3b466972`.
- Read: active task record, planning entry, project memory index, positioning, current state, decision index, system overview, business rules, success criteria, and the completed provisioning/hotspot-binding peer records.
- Peer assessment: Guided Hotspot Binding overlaps the same page but is already merged into this base; its state machine and security constraints must be preserved. No active task owns this worktree or is implementing the same selected-agent device seam.
- Gate result: Concurrent Task Gate and Planning Gate passed.
## Plan
1. Add a red page test with two agents and two devices that asserts the device panel follows the selected agent.
2. Add a red binding test proving a new activation code is submitted with the selected agent ID.
3. Filter the overview device projection by selected agent and tighten agent-scoped device copy without changing API contracts.
4. Run focused tests, typecheck, scoped lint, diff checks, project-document gates, and an independent Sol review.
## Outcome
- Reproduced the stale-device bug: the page projected every account device regardless of the selected agent, so changing agents refreshed configuration but not the device panel.
- Filtered the device projection by `device.agent_id === selectedAgentId`; switching agents now changes both configuration and visible devices.
- Added an agent-scoped device count to each agent row, matching Xiaozhi's verified `deviceCount` semantics without adding a new API.
- Clarified the device panel, empty state, and binding action as belonging to the current agent.
- Made the binding target immutable for the dialog lifetime: it shows the current agent read-only, while the editable agent selector remains exclusive to existing-device reassignment.
- Proved that opening the binding flow after selecting the second agent submits the new six-digit activation code with that agent's ID.
- Kept existing atomic reassignment, guided Hotspot provisioning, activation-code secrecy, and account-wide overview contracts unchanged. No backend or firmware code was changed.
## Verification
- RED: the new two-agent/two-device page regression failed against the previous implementation because the first agent panel also rendered the second agent's device.
- PASS: `pnpm exec vitest run tests/unit/ai-hardware-page.test.tsx` — 1 file, 39 tests.
- PASS: `pnpm exec vitest run tests/unit/ai-hardware-page.test.tsx tests/unit/ai-hardware-api.test.ts tests/unit/ai-hardware-routes.test.ts` — 3 files, 92 tests.
- PASS: `pnpm run typecheck`.
- PASS: scoped ESLint for the changed page and test.
- PASS: `git diff --check` (line-ending warnings only).
- Source comparison confirmed Xiaozhi agent cards expose per-agent device totals and device management filters by agent; adding a normal device uses a six-digit activation code. Makelore derives the same count from its safe overview DTO.
- Independent Sol review initially returned FAIL with one P1 and one P2: the binding target remained editable and the short `aria-label` hid the scoped visible action. Both were corrected, the complete focused suite was rerun, and re-review returned PASS with no P0-P3 findings.
## Follow-ups
- Automatic nearby-device discovery and management-side manual MAC insertion remain intentionally unsupported by the public Makelore/Works contract.
- A physical multi-device smoke should bind a second real device with its own fresh activation code, switch between two agents, and verify atomic reassignment before the next packaged release.
## Promotion Candidates
- None recorded.