[SimonHeybrock]

Step 1 of #184: the developer docs say which process holds what in each deployment.

Why. The README described one workspace per proposal that every notebook and program shares, reached with connect(). No deployment of the first release has that. A notebook, a technique application with a batch page, and the automatic reduction are each one Python process that holds the application, its client, and its own workspace. The consequences were not written down anywhere.

What the new page docs/developer/deployments.md states. The README keeps a short section with the rule, the boundaries, and a table of the three deployments, and links to the page.

• Three boundaries, and which of them lies between two processes today:

  screen ──(a)──▶ application ──(b)──▶ workspace ──(c)──▶ binding
  

  A screen never calls a workspace: application logic is Python that holds a Client, and the HTTP interface of a page belongs to that page.

• One drawing per deployment: notebook, technique application with a batch page, automatic reduction (one process per instrument, a workspace per proposal), and what of each is implemented.

• A proposal has several histories, and a reference names a record of the same history. A value passes from one history to another as a file: written, named, published, listed, loaded. Parts exist; the path as a whole is listed as an open question.

Elsewhere in the README. open_folder is shown next to local. connect() is described as a hosted workspace, not implemented and not needed by the first release. "The proposal's history" is now "the workspace's history", and "app" is "application", defined once. Three open questions are added: where bindings run (threads today; a split would go between workspace and worker processes), the path of a value between histories, and the automatic reduction as a process (routing files to per-proposal workspaces, where its configuration is kept).

Requirements. The glossary defined the batch-reduction service as a long-running program on DMSC servers for many users. An application that a user starts on a VISA machine serves as well, and the entry now says so. The requirement in users.md that batch and automatic reduction run as services now asks this of automatic reduction only, and allows a first release to run automatic reduction as an application on a VISA machine. The memory bound holds for each.

Review. A fresh reviewer checked the text against the code and the linked guides. Fixed from it: the section claimed the batch page was implemented, while the web page is experimental and runs as a demo; "a reloaded web page" as the example of a second client in open question 9 and in accumulators.md no longer fits, since a page holds no client; the drawings were misaligned; several sentences repeated that no deployment needs a hosted workspace.

Not done here.

• User stories D and E are written against a shared service (connect(url, proposal=...)), and in E1 and E4 a user reads the automatic results through a second client. The conventions of user-stories.md and the head of system-stories.md now say how to read "the service". Rewriting the stories belongs with step 4 of Tracking: settle disk formats, deployments, and where reductions run #184, which settles one model for batch and automatic reduction.
• ess.apps.protocol and automatic-reduction.md state that a history is dropped once its proposal has been idle. That rule was written for a hosted workspace; what it means for a folder is part of step 3 (what is durable).
• ADRs are unchanged.

🤖 Generated with Claude Code