From dceb824e3f1a98a25ce3be67a1a3bfde13febbd2 Mon Sep 17 00:00:00 2001 From: Doxa Maps Date: Fri, 2 Oct 2026 05:31:23 +0000 Subject: [PATCH] README: the cloud paragraph says why one pilot server per app, and names the landing rebuild from accepted pull requests as planned too --- README.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 8751f350d..79f931211 100644 --- a/README.md +++ b/README.md @@ -762,9 +762,13 @@ gate-keeper that reads each change before it lands, are jobs your harness gives Keep the repository on a forge you host yourself: a swarm pushes often, and on a public host one wrong push publishes work you did not mean to share. Give each app two servers: a **pilot server** that follows the pilot branch with hot reload, and a **landing server** that rebuilds from the landing -branch. The cloud container in `deployment/cloud/` runs both today. Planned, not built yet: a pilot -server that can be switched to show a single PR branch, with a table of PR branches under it, so a -team can look at one feature together before it lands. +branch. The cloud container in `deployment/cloud/` runs both today. One pilot server per app, rather +than one per pull request, keeps the memory the same however many pull requests are open. Each +developer can still build on their own machine with the Plugin Studio and push their branch. + +Planned, not built yet: switching the pilot server to show one pull request at a time (with a table of +the open pull requests under it), and rebuilding the landing branch from the accepted pull requests in +order, so a rejected one is simply left out of the next rebuild. How to contribute, and the bar for shared code: [documentation/CONTRIBUTING.md](./documentation/CONTRIBUTING.md). Taking contributions from a contributor's own forge into your GitHub repository: [documentation/contribute/TUTORIAL.md](./documentation/contribute/TUTORIAL.md).