chore(policy): .maintainer.yml says merges are never human-gated, but the ruleset requires an extra approval for unattributed commits

[ivndev001]

What to build

.maintainer.yml:100-105 states, as the load-bearing fact behind auto_merge: true, that required_approving_review_count is 0 and "Merges are gated by MACHINES — CI green plus the ruleset — never by a human review". The live main-protection ruleset (id 20556704, gh api repos/developerz-ai/wurk/rulesets/20556704) confirms the count is 0 but also carries require_extra_approval_for_unattributed_changes: true in its pull_request rule. GitHub's semantics for that flag: a pull request containing commits whose author is not attributed to a GitHub account needs one additional approving review on top of the configured count — so for this repo such a PR needs 1 human approval, and the platform bot's auto-merge (which the file says needs no human) will wait on it. Every squash on main today is attributed (checked the last 40: all author.login non-null), so the case has not fired yet; the day a fleet box commits with an email not linked to a GitHub account, that PR silently parks.

This issue is the documentation fix (the file's own rule at .maintainer.yml:10-14 is that it must not assert a ruleset state it does not have):

1. In the pr: block comment (.maintainer.yml:100-105), after the sentence about count 0, add the caveat: the ruleset also sets require_extra_approval_for_unattributed_changes: true, so a PR with any commit not attributed to a GitHub account needs one human approval before the bot can merge it; name the parameter and the ruleset id so the next reader can verify with gh api.
2. In CONTRIBUTING.md "Pull requests" (CONTRIBUTING.md:131-140), add a numbered step: commit with an email linked to your GitHub account (git config user.email), because unattributed commits require a human approval this repo otherwise never asks for.

Do not change the ruleset in this issue; flipping the flag is an operator decision and would be its own hitl ticket.

Acceptance criteria

• .maintainer.yml's pr: comment names require_extra_approval_for_unattributed_changes and ruleset 20556704, and no longer says merges are "never" human-gated without the caveat.
• CONTRIBUTING.md tells contributors to commit with a GitHub-linked email and says why.
• .maintainer.yml still parses as YAML (ruby -ryaml -e 'YAML.load_file(".maintainer.yml")').
• gates green: rubocop, rake test, rake test:parity (bin/check exit 0)

Affected paths

.maintainer.yml, CONTRIBUTING.md

Verified against

c346bc9

[developerz-ai]

🤖 developerz.ai maintainer bot — developerz-ai[bot]

Tracking pull request #501 for this issue.

[ivndev001]

A second stale load-bearing claim in the same file, found while tracing why
wurk stopped producing autonomous work. Worth fixing in the same PR, since it is
the identical defect class this issue names — a comment asserting a platform state
that has since changed.

.dz/maintainer/maintainer.yml, in the handoff: block, says of mode: fleet:

This key is also the opt-in for the autonomous scout backlog-drain
(apps/worker/src/cron/scout-backlog-drain.ts:22-29), which stays inert until
dz#1249 and dz#1530 close.

The drain is not inert. Verified against developerz.ai origin/main @
b4cfe94d76e9:

• it is an attached lane — apps/worker/src/wiring/lanes.generated.ts:58 imports
  scoutBacklogDrainLane and :121 registers it
• it fired 814 times fleet-wide in the 30 days to 2026-09-14, including 8 times
  on this repo (most recently 2026-08-27)

The cited source comment (scout-backlog-drain.ts:18-21) is itself the origin of
the claim and is also outdated — it describes the state before its own slice 2
landed.

Note this does not change anything about wurk's behaviour; the drain is currently
starved of input rather than blocked (every escalated wurk issue-session is either
on a closed issue or already drained). Tracked separately as
developerz-ai/developerz.ai#4006.

[developerz-ai]

Acknowledged — this is the same defect class (stale comment asserting platform state) but in a different file:

1. .dz/maintainer/maintainer.yml handoff block: the claim that the scout backlog-drain "stays inert until dz#1249 and dz#1530 close" is outdated — the drain is active
2. apps/worker/src/cron/scout-backlog-drain.ts:18-21: the source comment that originated the claim also describes pre-slice-2 state

This extends the original fix (PR #501) to these additional files. I can hand this off to the coding agent.

🤖 Posted by developerz.ai — the maintainer agent, not a human.

[developerz-ai]

Task dispatched to the coding fleet (tsk_3b91afcdb4124afea1bdbb82c032ade9). This extends the original fix to the handoff block in .dz/maintainer/maintainer.yml.

🤖 Posted by developerz.ai — the maintainer agent, not a human.

[developerz-ai]

chore(policy): fix second stale claim in .dz/maintainer/maintainer.yml

• Picked up
• Surveying the repo — 2026-09-14 16:36 UTC
• Working — 2026-09-14 16:38 UTC
• Pull request opened
• Done

Stopped — this needs a human. Nothing was merged.
Reason: insufficient disk after hygiene cleanup: free 0.6 GiB below 20.0 GiB floor on /home/sebastian/workspace-ai

12h40m · 507 tool calls · 152 messages

Sessions: coding run

---

🤖 developerz.ai maintainer bot — sebby-ovh-2 (developerz-ai[bot])

[ivndev001]

Reopening, re-scoped. The original premise is satisfied; a second one in the same
file is not, and it is the same defect class.

Satisfied — the original report

Verified against origin/main @ 0db84fd0b0: the caveat this issue asked for is
already present. .dz/maintainer/maintainer.yml:107-110 carries the "ONE EXCEPTION"
comment naming require_extra_approval_for_unattributed_changes: true, citing this
issue number and ruleset 20556704. CONTRIBUTING.md:171-178 already tells
contributors to commit with a GitHub-linked email and gives the why. A fleet coding
run reached the same conclusion independently.

Note the issue also says the file is .maintainer.yml at the repo root; it now lives
at .dz/maintainer/maintainer.yml (see .dz/README.md), moved by #523.

NOT satisfied — the remaining scope of this issue

The same file makes a second load-bearing claim that is false. In the handoff:
block, of mode: fleet:

This key is also the opt-in for the autonomous scout backlog-drain
(apps/worker/src/cron/scout-backlog-drain.ts:22-29), which stays inert until
dz#1249 and dz#1530 close.

The drain is not inert. Against developerz.ai origin/main:

• it is an attached lane — apps/worker/src/wiring/lanes.generated.ts:58 imports
  scoutBacklogDrainLane, :121 registers it
• it fired 814 times fleet-wide in the 30 days to 2026-09-14, 8 of them on this
  repo

This is exactly what this issue exists to stop: a comment in this file asserting a
platform state it does not have. The file's own rule (lines 10-14) says so.

Acceptance criteria

• The handoff: block no longer claims the drain is inert
• Whatever replaces it is checkable, or states the date and SHA it was true at
• No other claim in the file asserts an unverified platform state
• bin/check exits 0

Tracked context: developerz-ai/developerz.ai#4006 (why the drain is quiet on this
repo despite being live) and #4016 (the projection defect found alongside).