merge: enable guided Robot onboarding by default
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
|
||||
Accepted
|
||||
|
||||
Implementation status: implemented; the capability remains disabled by default until all pilot release gates pass.
|
||||
Implementation status: implemented and enabled by default. Exact environment value `NIANCODE_AI_HARDWARE_GUIDED_HOTSPOT_BINDING=0` disables the guided path as an operational rollback.
|
||||
|
||||
## Date
|
||||
|
||||
@@ -39,9 +39,9 @@ V1 is a Renderer-guided, Main-gated workflow:
|
||||
- Binding continues to use the existing `bindAiHardwareDevice(activationCode, agentId, { operationId })` cloud contract.
|
||||
- `bound` means account Binding succeeded. It does not prove the Robot is currently online or protocol-ready.
|
||||
|
||||
The guided path is controlled by a Main-owned `guidedHotspotBinding` capability. It is `false` by default. Public builds with the capability disabled retain the existing direct six-digit Binding flow.
|
||||
The guided path is controlled by a Main-owned `guidedHotspotBinding` capability and is `true` by default. Electron Main derives the packaged default from `NIANCODE_AI_HARDWARE_GUIDED_HOTSPOT_BINDING !== '0'`; an exact `0` disables the path without changing the binary. Disabled builds and Renderer capability-read failures retain the existing direct six-digit Binding flow.
|
||||
|
||||
The planned Host API surface is deliberately small:
|
||||
The implemented Host API surface is deliberately small:
|
||||
|
||||
- `GET /api/works/ai-hardware/provisioning-capabilities` has no body/query and succeeds with the standard Host envelope `{ success: true, data: { guided_hotspot_binding: boolean } }`.
|
||||
- `POST /api/works/ai-hardware/provisioning-portal/open` accepts the exact body `{}`, has no query, and succeeds with `{ success: true, data: { opened: true } }`.
|
||||
@@ -50,21 +50,21 @@ The planned Host API surface is deliberately small:
|
||||
|
||||
## Security And Recovery Rules
|
||||
|
||||
- The current firmware hotspot and portal are open/plain HTTP. V1 is an internal pilot only; product copy must warn the user not to perform the flow in an untrusted public environment.
|
||||
- The current firmware hotspot and portal are open/plain HTTP. Default-on accepts that compatibility risk but does not make the channel authenticated; product copy must warn the user not to perform the flow in an untrusted public environment.
|
||||
- Wi-Fi SSID/password entry stays in the firmware portal. Makelore must not collect, log, persist, or proxy Wi-Fi credentials.
|
||||
- Cancel, back, and application restart never imply that Wi-Fi changes on the Robot were reverted. The user is guided to reconnect and restart provisioning if needed.
|
||||
- A same-process ambiguous Binding retry reuses the same operation ID. An invalid/expired/consumed activation code clears both code and retained operation ID; the next freshly issued code gets a new operation ID.
|
||||
- Main must project `ai_hardware_activation_code_invalid` as non-retryable even if an upstream response incorrectly marks it retryable.
|
||||
- After application restart, Makelore cannot correlate an earlier code or Binding outcome from the current overview DTO. It must not replay the old code or operation ID; the user obtains a fresh code or stops.
|
||||
|
||||
## Release Gates
|
||||
## Default-On Acceptance And Remaining Verification
|
||||
|
||||
The capability may be enabled only after all of the following are evidenced:
|
||||
The user explicitly chose default-on on 2026-08-16 while retaining the current firmware behavior. The open SoftAP/plain-HTTP channel remains a known residual risk; choosing the product default is not evidence that the physical flow or its security has passed. Before claiming complete hardware compatibility or end-to-end provisioning acceptance, all of the following still require evidence:
|
||||
|
||||
1. The exact shipped Robot component/image is confirmed to use the audited Hotspot portal flow and fixed portal address.
|
||||
1. The exact shipped Robot component/image uses the audited Hotspot portal flow and fixed portal address.
|
||||
2. The deployed activation issuer emits exactly six ASCII digits accepted by the existing Works Binding validator, with documented freshness and consumption behavior.
|
||||
3. Focused Renderer/Main route tests, Electron E2E through the real Host API seam, and a physical-device smoke all pass.
|
||||
4. The public/default configuration remains disabled until the open SoftAP/plain-HTTP risk is explicitly accepted for the intended pilot population.
|
||||
3. Electron E2E through the real Host API/native-opener seam and a physical-device smoke pass; focused Renderer/Main route tests already cover default-on, exact `0` rollback, fixed portal ownership, local-before-cloud behavior, and error redaction.
|
||||
4. Release/support instructions retain the exact `=0` rollback and do not describe V1 as authenticated discovery, automatic Wi-Fi delivery, automatic claim, or proof of online readiness.
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
| ID | Decision | Status | Date | Applies To | Detail |
|
||||
|---|---|---|---|---|---|
|
||||
| ADR-001 | AI 绘画采用 Workspace / Conversation / Task 分层状态与服务端持久 Conversation Session | Accepted | 2026-08-11 | AI 绘画客户端、Main 适配器、Works Square API | `adr-001-ai-design-conversation-ownership.md` |
|
||||
| ADR-002 | Robot V1 采用 Main 门控的引导式热点配网并衔接现有六位 Binding | Accepted / implemented, default off | 2026-08-16 | Robot Renderer、Host API、Electron Main、现有固件热点入口 | `adr-002-robot-guided-hotspot-binding-v1.md` |
|
||||
| ADR-002 | Robot V1 采用 Main 门控的引导式热点配网并衔接现有六位 Binding | Accepted / implemented, default on | 2026-08-16 | Robot Renderer、Host API、Electron Main、现有固件热点入口 | `adr-002-robot-guided-hotspot-binding-v1.md` |
|
||||
|
||||
## Superseded Decisions
|
||||
|
||||
|
||||
Reference in New Issue
Block a user