@@ -4021,7 +4021,7 @@
    "controls": {
     "source": {
      "line": "Where the picture comes from.",
-     "more": "The test pattern is a test card in the layout of Philips' PM5544, drawn at any size. **usb capture** decodes MJPEG from an HDMI grabber, scaled to fit."
+     "more": "The test pattern is a test card in the layout of Philips' PM5544, drawn at any size. With **usb capture**, MJPEG from an HDMI grabber fills the picture at its set size."
     },
     "fps": {
      "line": "Frames a second asked of a capture device, which streams the nearest rate it offers."
 
@@ -22,7 +22,7 @@ Neither a Confluence nor a Jira: the docs site is ours and GitHub's issues and P
 
 **Across origins and MoonCloud.** Browser storage stays on its origin, so what crosses origins is carried. Built: the address (`?walked=install`, the installer's handover). Candidates: `postMessage` between a page and a window it opens; marks kept on the device's own config, which costs a persisted control the 2026-10-16 decision kept out; and MoonCloud, with consent. A MoonWalk member of MoonCloud, its own checkbox and off until switched on like Stats and Talk, keeps the marks under the installation id so they follow the device to every browser, and in aggregate shows where people stop, a funnel per process. It sends process and step ids and nothing typed, under the privacy policy's rules (step 22). One consent already covers what the app reads from the docs site, the help and MoonWalk (decided 2026-10-16).
 
-**GitHub: issues, Projects, CI, the backlog and notes.** MoonWalk in the repo is the definition; GitHub holds the work and the runs, each feature one job. **Issues** are the work items, each labelled `walk:<process-id>` so the map shows open issues per process, and the issue forms are generated from MoonWalk (the steps of Log an issue become the bug form). **The backlog becomes issues**: three Markdown files of 3,408 lines beside 4 open issues are two backlogs for one job (step 21); an agent then reads it with `gh issue list`. **A Project** orders them: Status (Inbox, Backlog, Next, In progress, In review, Done), a Stage and a Process field, an Area. **Notes reach the Inbox** as a Project draft item, from the phone, `gh project item-create` or the agent, triaged into an issue or deleted (step 20). **Actions run what is already executable**: a step names a workflow, the local gates post check runs (step 19). Access: the agents' `gh` needs the `project` scope.
+**GitHub: issues, Projects, CI, the backlog and notes.** MoonWalk in the repo is the definition; GitHub holds the work and the runs, each feature one job. **Issues** are the work items, each labelled `walk:<process-id>` so the map shows open issues per process, and the issue forms are generated from MoonWalk (the steps of Log an issue become the bug form). **The backlog becomes the Project's draft items**: four Markdown files of 4,051 lines beside 4 open issues are two backlogs for one job (step 21). A draft item becomes an issue when it is accepted, so the issue list holds only accepted work and reports. **A Project** orders them: Status (Inbox, Backlog, Next, In progress, Waiting, In review, Done), Waiting holding work blocked on someone outside the project: a reply, a part, a tester, a Stage and a Process field, an Area. **Notes reach the Inbox** as a Project draft item, from the phone, `gh project item-create` or the agent, triaged into an issue or deleted (step 20). **Actions run what is already executable**: a step names a workflow, the local gates post check runs (step 19). Access: the agents' `gh` needs the `project` scope.
 
 ## The steps
 
@@ -56,13 +56,17 @@ Steps 1 to 14 are done, each in a line; git holds how.
     - **Volatile steps** act on a device or in the app, such as a user choosing an effect. Nothing records them, since nothing outside the device changes.
     - **Recorded steps** change the repo or what ships: a plan step, a commit gate, a merge, a release, a verification on hardware, a gallery submission. Each run leaves a record.
 
+    A run's state is Started, Done or Stuck. Stuck is a run waiting at a prompt for minutes, which `walk_status` reports as it reports a stale gate, and which reaches the product owner where they read, Discord included. Seen 2026-10-21 in a community member's setup: a bot posting each agent run's Started, Done and Stuck to Discord.
+
     A run's measurements, the step metrics above, ride on its record: a check run's output on GitHub, and the value series repo-health draws.
 
     Automated recorded steps record as check runs on the commit or pull request, the local gates included through `gh api`, so a pull request shows which gate passed on which commit. Manual recorded steps record in an issue created from an issue form generated from the process file, a step per sub-issue, and a GitHub Project shows every run and the step it stands at. To decide: whether a step's kind is declared or follows from its action, and whether a plan becomes such an issue instead of a file in `docs/work/present/`, which changes CLAUDE.md's process.
 
     **Every CI job also runs locally**, so a GitHub outage, or a CI service that changes or stops, costs a runner rather than the gates. A workflow is a thin caller of the MoonDeck script its process step names, and GitHub is one runner of the process files among others. Today each job reproduces by its own script, as `ci-on-pr` lists them, but not as one command, and four gaps remain: ThreadSanitizer needs Linux (`check_sanitizers` skips it on macOS), the MSVC build needs Windows, CodeQL needs its command-line tool, and the release's publishing (the release upload, Pages, the container registry) is GitHub's. The work: one MoonDeck entry runs `ci-on-pr` and `release`'s build steps locally, through `walk_status` as the commit checks already run; ThreadSanitizer runs in a Linux container; every workflow line that is not a script call moves into one; and a test reads `.github/workflows/` and fails on a job that calls no script a process step names.
-20. **The Project and the inbox on GitHub.** The Project with its fields and views, the `walk:` labels, the issue forms generated from MoonWalk, and the map's count of open issues per process. Apple Notes stays the scrapbook it is, the quickest place for a thought. The Inbox is tried as the step after it: a note worth acting on moves there and is triaged. Whether the Inbox can be the scrapbook too is learned by using it, and Apple Notes goes only if it can. Independent of the other steps, so it can run whenever the product owner picks it.
-21. **The backlog moves to issues.** A script reads `backlog-core.md`, `backlog-light.md` and `backlog-mixed.md`, proposes one issue per actionable item with its area, its `walk:` label and a link to any analysis it cites, and writes the list for the product owner to review before anything is created. Then it creates the issues, adds them to the Project's Backlog, and the three files are deleted in the same change. An item already shipped or no longer wanted is dropped in the review rather than migrated. After step 20, since the issues land in its Project.
+20. **The Project and the inbox on GitHub.** The Project with its fields and views, the `walk:` labels, the issue forms generated from MoonWalk, and the map's count of open issues per process. Apple Notes stays the scrapbook it is, the quickest place for a thought. The Inbox is tried as the step after it: a note worth acting on moves there and is triaged. Whether the Inbox can be the scrapbook too is learned by using it, and Apple Notes goes only if it can. Independent of the other steps, so it can run whenever the product owner picks it. Before step 21, about ten backlog items are moved as draft items and used for a while: queried and edited with `gh`, one converted to an issue, the board mirrored to JSON. What does not hold up in daily use changes step 21 before the rest moves.
+
+21. **The backlog moves to the Project.** Decided 2026-10-21. Each backlog item becomes a **draft item** in the Project's Backlog column, not an issue: around 230 items as issues would bury the open issues, and a draft item stays out of the issue list while `gh` still queries and edits it. A draft item becomes an **issue** when the product owner moves it to Next, which is the acceptance and the point where an agent may pick it up. An **analysis** stays a file in `docs/work/future/`, which the item links, so the reasoning stays in git and is reviewed in a diff; an item whose text is longer than a card holds moves to such a file. A script **mirrors the board** to a JSON file, so an agent searches it offline as it searches the docs. A script reads the four backlog files, proposes one draft item per actionable item with its area and a link to any analysis it cites, and writes the list for the product owner to review before anything is created. Then it creates the items, and the four files are deleted in the same change. An item already shipped or no longer wanted is dropped in the review rather than migrated. After step 20 and its trial, since the items land in its Project.
+
 22. **MoonWalk in MoonCloud.** The member above: its card and consent text, a route and a table in the MoonCloud worker, the privacy policy's entry, and the funnel shown back on the card as Stats shows its totals. It follows step 4, since only the app has an installation id.
 
 23. **Close the plan.** Once 15 to 22 are done: the lessons the steps taught go to `docs/work/past/lessons.md`, `moonwalk.md` is read against the built system, and the plan moves to `docs/work/past` as shipped. Deleting it is the product owner's call.
@@ -71,3 +75,6 @@ Steps 1 to 14 are done, each in a line; git holds how.
 ## To decide
 
 - The process of step 17, the first through every runner, and whether it is the one step 5 renders.
+- **A support process**: a question on Discord or GitHub, an agent drafting the answer, the product owner approving and sending it. It turns the rule that an agent posts only what the product owner has read into a process.
+- **An orchestrator**: one agent session per issue or pull request, started from the Project and reporting its state (step 19). It changes CLAUDE.md's roles, since the product owner initiates every event: whether an agent may start work on an issue the product owner moved to Next, and stop at a draft pull request for review.
+- **A plan rendered as progress**: a plan's numbered steps shown as the map shows a process, a page to share with done and next, rather than a plan becoming an issue (step 19).
@@ -30,7 +30,7 @@ class PictureService : public MoonModule {
     /// The sources `source` picks from, in option order.
     enum Source : uint8_t { kTestPattern, kUsbCapture, kSourceCount };
     /// Where the picture comes from.
-    /// @guide The test pattern is a test card in the layout of Philips' PM5544, drawn at any size. **usb capture** decodes MJPEG from an HDMI grabber, scaled to fit.
+    /// @guide The test pattern is a test card in the layout of Philips' PM5544, drawn at any size. With **usb capture**, MJPEG from an HDMI grabber fills the picture at its set size.
     uint8_t source = kTestPattern;
     /// Frames a second asked of a capture device, which streams the nearest rate it offers.
     uint8_t fps = 30;
 
@@ -133,7 +133,7 @@
 /// A host has no second card, so a subfolder of the one real root stands in. `sdMounted_` gates it as a missing card would, and format is a wipe-and-recreate.
 
 #include "platform/platform.h"
-#include "platform/usbvideo_frames.h"   // areaAverage: the shrink the device backend also uses
+#include "platform/usbvideo_frames.h"   // areaMean: the shrink the device backend also uses
 #include "core/util/FirmwareImage.h"  // identify/moonBaseRejection: shared image vetting
 #include "core/util/H264Bitstream.h"  // where the encoder's frames begin and end
 
 
@@ -398,10 +398,12 @@ struct PaceRig {
 TEST_CASE("NetworkSendDriver: a packet gap spaces a frame's packets, sent from a task") {
     PaceRig r(1000, 3000, 20);   // 3000 bytes: three DDP packets, 3 ms apart
     REQUIRE(r.driver.sendsInTask());
+    const uint32_t sent = mm::platform::micros();
     r.driver.tick();
     const std::vector<uint32_t> at = r.arrivals(3);
     REQUIRE(at.size() == 3);
-    for (size_t i = 1; i < at.size(); i++) CHECK(at[i] - at[i - 1] >= 2000);   // the gap, less scheduling slack
+    // From the tick to the last arrival, a bound a slow poll only pushes later, where two packets read in one late poll arrive together.
+    CHECK(at[2] - sent >= 4000);   // two 3 ms gaps, less scheduling slack
 }
 
 // A gap of 0 keeps the burst from the tick, with no task: the choice for a board that cannot spare one.
 
@@ -61,11 +61,11 @@ TEST_CASE("PraxisEffect varies color across the grid") {
     layer.tick();
 
     auto* data = layer.buffer().data();
-    // The y·macro·x cross term makes far-apart pixels land on different hues. Compare the origin with the far corner (15,15), where the spatial term is at its largest.
-    uint8_t r0 = data[0], g0 = data[1], b0 = data[2];
-    size_t idx = (15 * 16 + 15) * 3;
-    uint8_t r1 = data[idx], g1 = data[idx + 1], b1 = data[idx + 2];
-    CHECK((r0 != r1 || g0 != g1 || b0 != b1));
+    // Two lights can share a color at a moment, since the mutators follow the clock, so the grid as a whole holds more than one.
+    bool varies = false;
+    for (size_t i = 1; i < 16u * 16u && !varies; i++)
+        varies = data[i * 3] != data[0] || data[i * 3 + 1] != data[1] || data[i * 3 + 2] != data[2];
+    CHECK(varies);
 }
 
 // Hard rule: the effect runs at a degenerate grid without crashing. width/height <= 0 is guarded, and a 1×1 grid exercises the render loop at its smallest.