Plan A Hardware SDK Change
- Read the request and inspect the current worktree without changing implementation files.
- State target runtime/transport, device family, protocol version, lifecycle phase, owning layer,
public compatibility surface, goals, non-goals, and unresolved decisions.
- Read the closest current code, tests, documentation index, and relevant
domain Skill. Use external sources only when local facts are insufficient.
- Identify exact files and symbols, dependency order, generated artifacts, firmware/submodule
coupling, error/retry/cleanup behavior, and security constraints.
- Produce ordered implementation tasks with an acceptance condition and executable validation for
each meaningful stage.
- Include a transport/device/protocol test matrix and identify verification that needs a physical
device or external system.
- Include containment or rollback for risky compatibility changes.
Return the plan in conversation by default. When the user requests a repository artifact, place it
in the closest current topic directory under docs/ and link it from that directory's index.
Planning authorizes analysis and plan creation only. It does not authorize implementation, push,
PR creation, publication, firmware installation, device wipe, or other external mutation.
1---2name: hardware-change-plan3description: Create or review an implementation plan, technical plan, task breakdown, acceptance criteria, or validation matrix for a Hardware JS SDK change.4---56# Plan A Hardware SDK Change781. Read the request and inspect the current worktree without changing implementation files.92. State target runtime/transport, device family, protocol version, lifecycle phase, owning layer,10 public compatibility surface, goals, non-goals, and unresolved decisions.113. Read the closest current code, tests, [documentation index](../../../docs/README.md), and relevant12 domain Skill. Use external sources only when local facts are insufficient.134. Identify exact files and symbols, dependency order, generated artifacts, firmware/submodule14 coupling, error/retry/cleanup behavior, and security constraints.155. Produce ordered implementation tasks with an acceptance condition and executable validation for16 each meaningful stage.176. Include a transport/device/protocol test matrix and identify verification that needs a physical18 device or external system.197. Include containment or rollback for risky compatibility changes.2021Return the plan in conversation by default. When the user requests a repository artifact, place it22in the closest current topic directory under `docs/` and link it from that directory's index.2324Planning authorizes analysis and plan creation only. It does not authorize implementation, push,25PR creation, publication, firmware installation, device wipe, or other external mutation.