add-lab-equipment-device

Add Lab Equipment Device

Add equipment support only after proving the physical interface, host environment, command protocol, and acceptance path. Preserve existing devices and keep model-specific behavior isolated. For recurring failure patterns from the AFG-2125 implementation, read lessons-learned.md before coding.

Workflow

1. Inspect the repository, README.md, src/lab_equipment_mcp/core/, existing device drivers, tests, and the device documentation tree. Check the current branch and worktree before edits.
2. Obtain the user manual and programmer/programming manual. Ask the user to download protected or vendor-gated manuals. Read the relevant files completely enough to establish interfaces, remote commands, identity response, termination rules, data formats, and safety restrictions. For PDFs, inspect the rendered command-tree and waveform figures as well as extracted text; record exact page numbers and distinguish optional bracket notation from literal command characters.
3. Confirm with the user which physical interface is connected now. Do not infer USBTMC from a USB connector alone; distinguish USB host/device, USBTMC, virtual COM, RS-232, LAN VXI-11, LAN raw socket, HiSLIP, GPIB, and vendor-specific transports.
4. Record every interface the model supports, even when only one is available for testing. Read interfaces.md and implement a DeviceProfile with one InterfaceSpec per supported path.
5. Diagnose the computer environment before coding. Check device enumeration, VISA resources, serial ports, IP reachability, drivers, runtimes, Python packages, and exclusive-session conflicts. Install safe command-line dependencies when authorized. If installation requires a vendor download, license acceptance, administrator UI, reboot, or manual hardware action, give the user the official download link and exact steps, then wait for confirmation.
6. Establish a read-only connection and identity query before changing instrument settings. Prefer *IDN?; use the manual's documented equivalent when SCPI is unsupported. Capture the firmware revision and preserve it in the device guide because command behavior can be firmware-specific.
7. Prepare Git contribution work before edits. Read contribution-workflow.md. Fork the upstream repository for external contributors, clone the fork, add upstream, update the default branch, and create a dedicated feature branch. Repository owners may branch directly but must not develop on main.
8. Implement shared transport behavior in core/ only when multiple devices can reuse it. Put vendor/model identity, commands, ranges, response parsing, and quirks under devices/<vendor>/<model>.py or a model package.
9. Prefix MCP tool names with the model or family. Mark read-only and state-changing tools with MCP annotations. Block reset, calibration, firmware, file deletion, output-enable, and other risky operations by default unless the project explicitly defines a guarded workflow. For every state-changing command, verify the requested value by read-back when the instrument supports it; otherwise return an explicit unverified/firmware-quirk result rather than claiming success.
10. Cover every command applicable to the target model that is documented in the programmer's manual. Each command must have either a dedicated typed MCP tool or a model-prefixed complete SCPI command/query entry point. Do not omit documented command groups merely because they were not part of the initial hardware test; mark them as implemented-but-untested and preserve manual-defined option/module conditions.
11. Add the device guide under docs/<vendor>/<MODEL>.md. Document manuals used, supported interfaces, tested interfaces, cable/pin requirements, driver links with verification dates, installation, example prompts, and troubleshooting.
12. Complete every applicable gate in acceptance.md. Do not claim an interface is tested when it was only implemented or simulated. For waveform sources, prefer a physical receiver MCP (oscilloscope, counter, load, or analyzer) for closed-loop acceptance; if no usable receiver MCP is available, ask the user to observe the panel/connected instrument and record the observation as user-observed, not agent-measured. SCPI read-back alone remains lower-confidence. Restore the original safe state in a finally path.
13. Commit focused changes. Push to the contributor's fork or, when authorized, push the branch to the owner's repository and open/prepare a pull request. Report untested interfaces and residual risks explicitly.