mirror of
https://github.com/storytold/photocraft.git
synced 2026-10-31 21:37:08 -06:00
IvanandClaude Opus 5.5
2f13a1564c
Step 4 of the issue: the control token flags and the automation roots move to photocraft-automation's new args module as two clap structs, which mcp and serve flatten and the desktop app can flatten in step 5 without moving them again. clap is a plain dependency of the crate. - ControlArgs holds --control-token and --control-token-file; AutomationArgs holds the roots, and AutomationArgs::workspace opens them (replacing the CLI's automation_workspace). - The port value parser is photocraft_automation::args::control_port, with its unit tests, for serve --port and --bridge now and the desktop app's --control later. It ignores surrounding spaces and refuses anything else with a typed NotAPort. - --bridge parses to Bridge::Port or Bridge::Addr: it takes a bare port, meaning 127.0.0.1:<port>, or any value containing a ':', which the bridge client then validates. Anything else is a usage error (exit 2) instead of a bridge error. - 127.0.0.1 addresses are built from Ipv4Addr::LOCALHOST. mcp_bridge_takes_a_port_or_an_address is new: `--bridge nope` is a usage error, and `--bridge 1` bridges to 127.0.0.1:1, which a tool call names when nothing listens there. No new environment behaviour: the token variables are still read at run time through security::token_inputs, and the roots stay flag-only. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>