Require a code-quality review pass before every contribution

contributing.md

@@ -143,6 +143,58 @@ Send button. Never treat `{}` / no selection as "yes" for a public action.
 
 ---
 
+## Review the code before every contribution
+
+MANDATORY for every PR, no exceptions. Run it after the code is written and
+**before** you build the review commit, so the branch the partner reviews is
+already the cleaned-up version. Reading and editing local source needs no
+approval and publishes nothing.
+
+Two passes over the branch diff, in order.
+
+**Pass 1 — strip the slop.** Read your own diff as a hostile reviewer of
+machine-written code and delete what a careful human would not have written:
+comments restating what the line already says or breaking the file's existing
+comment style, defensive `try`/`except` and existence checks on paths that are
+already trusted, casts and broad types that only silence a complaint, nesting an
+early return would flatten, and near-duplicates of a helper the codebase already
+has. Behavior stays identical unless you are fixing a clear bug, and the edits
+stay minimal and local.
+
+**Pass 2 — audit the structure, ambitiously.** Do not stop at "this could be
+tidier". Ask whether the change can be reframed so that branches, flags,
+helpers, or whole layers disappear rather than move. Treat each of these as a
+presumptive blocker you must either fix or justify:
+
+- the diff pushes a file from under 1000 lines to over it;
+- new ad-hoc conditionals or special cases are bolted into a flow that did not
+  care about them before;
+- feature-specific logic leaks into a shared or general-purpose path;
+- an abstraction, wrapper, or layer of indirection is added that does not buy
+  clarity;
+- optionality, `Any`, or loosely shaped dict payloads paper over an invariant
+  that should be explicit at the boundary;
+- logic lands somewhere other than the layer that already owns the concept, or
+  duplicates a canonical helper;
+- related updates can leave state half-applied, or independent work is
+  serialized for no reason.
+
+You are reviewing your own diff, so act on the findings instead of listing them:
+fix what surfaces, then re-read the diff. Anything you deliberately decline —
+a justified large file, a special case that has to live where it is — gets one
+sentence of justification in `body_draft`, so a reviewer never has to ask why
+the obvious decomposition was skipped.
+
+One limit keeps this from becoming scope creep: the restructuring stays inside
+the change you already agreed to build. A finding that would sprawl into
+unrelated subsystems is a follow-up you name for the partner, not something you
+fold into this PR.
+
+This section is the floor, not the ceiling. If the instance has a richer
+code-quality or slop-removal skill installed, apply it here too.
+
+---
+
 ## Prepare for review
 
 Nothing goes public here. For a PR, create a durable branch under `/data`, commit
@@ -211,7 +263,8 @@ plan: {action: pr|issue|issue_comment|discussion_comment,  # mirrors record.type
   stop #3). Compute the hash from the exact `.diff` bytes you store.
 
 Before you tell the partner it is ready, review the staged record yourself:
-re-read the stored `.diff`, confirm the body draft is exactly what should be
+re-read the stored `.diff`, confirm both quality passes above actually ran
+against the committed branch, confirm the body draft is exactly what should be
 published, confirm no private data appears in the branch, commit message, branch
 name, body, or diff, and confirm the branch is back on `main` when the prep
 steps require it.

mobius.json

@@ -1,7 +1,7 @@
 {
   "id": "contribute",
   "name": "Contribute",
-  "version": "0.5.6",
+  "version": "0.5.7",
   "description": "See what your agent has proposed upstream \u2014 pull requests, issues, and comments across the M\u00f6bius ecosystem, from prepared to merged.",
   "author": "mobius-os",
   "license": "MIT",

package.json

@@ -1,6 +1,6 @@
 {
   "name": "app-contribute",
-  "version": "0.5.6",
+  "version": "0.5.7",
   "private": true,
   "scripts": {
     "test": "node --test test/*.test.mjs"

review-followup.md

@@ -82,16 +82,24 @@ you hold the live round. `<base>` below is
 4. **Do the work in the worktree.** Implement in-scope changes. A merge conflict
    requires a history rewrite that the current grant does not authorize:
    escalate it rather than rebasing or force-pushing.
-5. **Run the project's tests** before pushing. If they still fail after two
+5. **Run the mandatory quality passes** over what you just wrote — the two
+   passes in *Review the code before every contribution* in
+   [contributing.md](contributing.md), applied **within this round's scope
+   only**. Your grant authorizes answering the review, not restructuring the
+   codebase: strip the slop and fix local structural problems in your own new
+   code, and when the structural pass surfaces something genuinely larger, say
+   so in the `/reply` instead of doing it. A finding that needs a rewrite the
+   grant does not cover is an `/escalate`, never a quiet force-push.
+6. **Run the project's tests** before pushing. If they still fail after two
    honest attempts, escalate — don't push red.
-6. **Re-read the FULL diff.** Then write the new `head_sha` and `diff_sha256`
+7. **Re-read the FULL diff.** Then write the new `head_sha` and `diff_sha256`
    onto the ledger record (a CAS storage write, same as preparing) so `/update`
    can bind to exactly what you reviewed.
-7. **Push and reply.** `POST /update` with the new head; then `POST /reply` for
+8. **Push and reply.** `POST /update` with the new head; then `POST /reply` for
    each thread you addressed, using its `in_reply_to` id when it is a review
    thread. Keep replies factual and scoped. Do not mark a draft ready or invent
    a review re-request; those are different GitHub actions.
-8. **Complete.** `POST /complete` with `outcome` and a one-sentence summary.
+9. **Complete.** `POST /complete` with `outcome` and a one-sentence summary.
 
 If a round has nothing to push (a plain question) you may `/reply` then
 `/complete` with `outcome: "replied"`. If you can do neither safely, `/escalate`.