settings.servoGains holds the measured per-joint P/I/D, validated at PUT /settings (src/servo-gains.ts, no servo writes yet) #536

settings.servoGains now holds the measured per-joint P/I/D and is validated at PUT /settings. Nothing is written to a servo. src/servo-gains.test.ts and src/server.test.ts pass. I did not run the full suite, and tsc --noEmit reports errors elsewhere in the tree (for example src/ui/zone-notes.js) but none in src/servo-gains.ts or src/server.ts.

• Branch smith/439-…: it wasn't on the remote, so I wrote src/servo-gains.ts fresh to the issue's spec instead of taking it from there.
• src/servo-gains.ts: defaults are keyed by joint id ("1"–"5"). Joints 1, 4 and 5 are P64 I0 D32, and joints 2 and 3 are P64 I4 D32. The gripper (6) is left out. parseServoGains(input, base?) lays a partial per-joint patch over the base and throws on an unknown joint, the gripper, a non-integer, or a value outside 0–254.
• src/server.ts:

- Settings has servoGains, and GET /settings shows it. - PUT /settings merges partial patches into the current gains. Bad input is a 400, and the stored settings stay as they were. - A saved settings.json without servoGains loads with the defaults.

• Tests: src/servo-gains.test.ts covers the defaults, a partial patch, and the refusals. src/server.test.ts adds a GET/PUT /settings round-trip.
• Not tested: I added no test that loads an old settings.json without servoGains. That case rests on the load path starting from the defaults.

🤖 Generated with Claude Code

I added the restart test you asked for and pushed it to the branch. The two new tests pass; I didn't rerun the rest of src/server.test.ts.

• Restart test: "servoGains on disk" in src/server.test.ts writes a settings.json with no servoGains and starts the server. GET /settings returns DEFAULT_SERVO_GAINS. It then PUTs {"3": {"i": 6}} and restarts, and the stored gains come back with that change. A stored servoGains that names the gripper is skipped, and the defaults load.
• Preview: I didn't check it. This push should redeploy it, so servoGains should appear in GET /settings once that finishes. If it still doesn't, the deploy is behind and needs a look.
• README line: I didn't add it. Software/so101/README.md has no settings section to put it in, and the top-level README only mentions settings for 3D printing. The servoGains line in the server.ts header comment is the only place it's documented.

🤖 Generated with Claude Code

This push adds the README row. I couldn't confirm the preview shows it, so juniper's check that GET /settings shows the defaults is still open. The servoGains row is in the settings table in Software/README.md. I didn't run any tests this round, since only the README changed.

• Preview: https://arm--536--forge-trevato-apps.open-platform.sh/settings still has no servoGains key, 90 seconds after the push. That response has the other settings and tableOffsetMm: -20, so I believe the deploy is serving an older head or an older state. I can't redeploy it from here, and I couldn't send the PUT round-trip against it. The same round-trip is covered by src/server.test.ts, which passes here. If the preview is still old once the forge deploys this head, that deploy needs a look.
• No page or terminal surface: I left out any settings-page or tty.ts control on purpose, because nothing writes servoGains to a servo yet. The README row says so.
• README row: it lists the defaults, the 0–254 integer range, how patches merge, that the gripper is refused, and that a settings.json without servoGains loads the defaults.

🤖 Generated with Claude Code

Handed to a person by the crew: the reviewer asked for changes three times with no approval between, so the planner re-scopes it: split, replaced, or one more round with the reviewer's ask restated.

1. juniper: Code reads right: validation is strict (integers 0-254, joints 1-5, gripper refused, __proto__ and unknown keys rejected), base is copied
2. juniper: The code reads well: servo-gains.ts is one concept, input is validated at the boundary, and __proto__ and the gripper are refused. The res
3. juniper: The code reads well. servo-gains.ts is a small single-concept module, validation is strict (integers 0-254, joints 1-5, gripper refused, unk

One more round, with one concrete change.

The code is approved in all three reviews. What keeps failing is the preview check, and the preview cannot pass it. The preview's /settings is relayed to the real arm server on the Pi (ARM_SERVER), which runs main, not this branch. Its answer matches production byte for byte, tableOffsetMm: -20 included. servoGains will only show there after this lands and the Pi is deployed.

The change: add a test to src/server.test.ts that starts the branch's own arm server with an empty data dir and checks that GET /settings contains exactly DEFAULT_SERVO_GAINS. Then put bun --cwd Software/so101 test src/servo-gains.test.ts src/server.test.ts output in the description, with one line saying the preview's /settings comes from the Pi.

Reviewer: judge this round on that test, not on the preview's /settings.

Closing. #515 is replaced by #544, which starts from this branch (e53e109). The code carries over as it is. The new issue judges it on the branch's own arm server in src/server.test.ts, because the preview's /settings is the Pi's.