Files
photocraft/book/src
IvanandClaude Opus 5.5 487e18d726 fix(cli): help after a mistake, and mcp/serve option notes in --help (#7071)
The review round of the #7071 stack, which #9167 merged without
(it took the pre-review heads):

- A bare --help or -h before `--` is help after any parse error, not
  only after a missing value: `mcp stray.psd --help` and
  `serve --port abc --port 1 -h` print the subcommand's help.
- mcp and serve --help carry #8035's rules: what the automation roots
  grant, that bridge roots are refused, and that the token flags need
  --bridge or --port (or PHOTOCRAFT_CONTROL_PORT).
- check_server takes the subcommand and whether a transport is set;
  the bridge-roots check moves next to the other mcp checks.
- The server tests match clap's "a value is required for" text, and
  mcp.md in the book and docs names PHOTOCRAFT_CONTROL_PORT.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-25 00:08:14 +03:00
..

PhotoCraft Documentation

PhotoCraft is a native image editor written in Rust. This book is the maintained entry point for installation, architecture, formats, automation, development, and security documentation.

The repository's existing docs/ directory remains authoritative for detailed design notes, parity reports, UI conventions, release procedures, and the complete control-protocol method reference. The book links to those documents instead of copying them.

Start here

Documentation for coding agents

Coding agents should read the following in order:

  1. AGENTS.md for repository rules and verification gates.
  2. README.md for product scope and current entry points.
  3. book/src/architecture/ for crate boundaries and command flow.
  4. book/src/automation/ before driving the CLI, control protocol, or MCP server.
  5. book/src/security/ before changing a parser, file I/O, automation, MCP, the control server, command execution, or serialization/deserialization.

Agents must treat document bytes, paths, command parameters, and automation messages as untrusted input. A page that describes a proposed control does not mean that control is implemented.

Status language

Security pages use four labels consistently:

  • Implemented: behavior confirmed in current source or tests.
  • Known limitation: an exposed risk or missing control in current source.
  • Proposed: a design direction that is not enforced by the current build.
  • Future hardening: useful follow-up work without an accepted implementation yet.