[umermjd11]

Step S2 of Discussion 208. This is the first PR under the new develop ruleset: it needs approval from @robertocarlous or @Santiagocetran, and whoever approves it merges it (merge commit).

What's in it

File	Change
.github/CODEOWNERS (new)	Reviewers are requested automatically by area. Contracts (foundry/, hardhat/): Robbert, Similoluwa, Umer. Python, tests, example services, CI (dincli/, tests/, cache_model_0/, cid_services/, pyproject.toml, .github/): Santiago, Umer. Documentation/ and Developer/: Santiago, Robbert. Everything else falls back to Umer. This file only requests reviewers: the ruleset doesn't require code-owner review (No. 3.3).
Developer/MAINTAINING.md (new)	The agreed process: the peer rule (No. 1); what the develop/main rulesets actually enforce; the reviewer pool and recusal (A1); review depth, with green CI as evidence and local reproduction only for gaps (A2); the 3-comment review record; merge paths and the admin bypass (No. 9.1, No. 9.5); attribution; a red develop after merge (A3); reverts; labels; the CI backbone (A4); issue/task approval and closing; docs syncing; wiki; what stays with Umer (No. 6); edge cases.
Developer/CONTRIBUTING.md	One line saying every PR goes to a peer, linking MAINTAINING.md.
Developer/README.md	A layout-table row for MAINTAINING.md.

Choices that differ from the thread

1. Contract owners cover all of foundry/ (including test/) plus hardhat/. The thread only named foundry/src and foundry/script.
2. The temporary shadow window (S4) and the initial review queue stay in the Discussion. They aren't in MAINTAINING.md.
3. @umeradl is a code owner on most areas, so this account's (umermjd11) PRs also auto-request umeradl. Under No. 9.2 that account doesn't approve them; a peer does.

Review notes

• Docs/config only. No code, so CI covers the doc-link check and nothing else applies (A2).
• Please check MAINTAINING.md against the Discussion: does it say what we agreed, and nothing more?
• GitHub's codeowners/errors API reports no errors for this branch.

🤖 Generated with Claude Code

[Santiagocetran]

Thanks for putting this together! I checked CODEOWNERS routing, documentation links, and green CI at d7ec370.

One fix and one clarification in Developer/MAINTAINING.md before merging:

• Line 166: The original PR author can’t give final approval after a reviewer adds substantial fixes. Could we require an eligible reviewer who is neither the PR author nor a contributor to those fixes? That would keep this consistent with the no-self-approval rule.
• Line 64: Is Abraham’s sign-off intended for every mechanism-changing PR? Section 5.1 allows Umer or Abraham to sign off on mechanism-design issues, while the agreed queue specifically requires Abraham for PR #236. I understand issue approval and PR approval may have different requirements; could we make that distinction explicit if it’s intentional?

The rest looks consistent with the rollout, including skill-based escalation, the two-working-day response window, and using CI evidence versus local testing. Thanks again for documenting the process; this should make it much easier for us to follow.

[umermjd11]

Thanks @Santiagocetran, both points are addressed in 04963c9 (previous: d7ec370):

• Line 166 (No. 7): yes. After a reviewer pushes substantial fixes, the final approval now comes from an eligible reviewer who is neither the PR author nor anyone who contributed to those fixes: another maintainer, or Umer.
• Line 64 (No. 4.2 / No. 5.1): there's no longer an issue-vs-PR split. Mechanism-design work (slashing, tokenomics, fees, scoring) needs @umeradl's approval on GitHub, both on the issue's plan and on every PR that changes a mechanism. Abraham may not reply on GitHub directly, so that sign-off isn't something a PR waits for there. If an author or contributor discussed a mechanism with Abraham off GitHub, they summarise the outcome in a comment on the issue or PR and cc @abrahamnash and @umeradl. The new "Mechanism sign-off" subsection under No. 4.2 says this, and No. 5.1 links to it.

The second sign-off on foundry/src/** (No. 9.4: Umer or Abraham, or a routed security reviewer) is unchanged.

[umermjd11]

Follow-up in 20a52a9 (previous: 04963c9): umeradl approving a umermjd11 PR would be self-approval (No. 1), so for Umer's own mechanism PRs the mechanism sign-off comes from @abrahamnash instead, whether he gives it on GitHub or off it. Off-GitHub sign-offs are recorded in a PR comment that cc's him. A peer's approval is still required. I also moved the "Mechanism sign-off" subsection to the end of No. 4.2, so "What counts as evidence" sits under review depth again.

[Santiagocetran]

Final review at 20a52a9: both points from my previous review are addressed.

• Final approval after substantial reviewer fixes now requires an eligible reviewer who is neither the PR author nor a contributor to those fixes.
• Mechanism sign-off is explicit and consistent across the review-depth and issue-approval sections, including Abraham's sign-off for Umer's own mechanism PRs and recording off-GitHub sign-offs while retaining peer approval.

I rechecked CODEOWNERS routing and the documentation links, including the Developer/ links outside the Docs CI job's scope. The branch is current with develop and mergeable. Solidity, Python, Docs, and CI OK all passed for this revision: https://github.com/InfiniteZeroFoundation/DevNet/actions/runs/39645242917

No remaining findings or blockers. Approved; ready to merge.

[Santiagocetran]

Verification record for PR #268 at 20a52a9340960f3a3d074131c2fcf91b91aaacb5, against current develop at 5f610c79063eef622acbe3a0997930a5d5204c14.

Claimed: The requested correction to final approval after substantial reviewer fixes is addressed.

Verified: Section 7 now requires an eligible reviewer who is neither the PR author nor anyone who contributed to those fixes. The original author is no longer offered as a final approver.

Claimed: Mechanism sign-off requirements are explicit and consistent.

Verified: Sections 4.2 and 5.1 refer to the same mechanism sign-off policy. It requires Umer's GitHub approval for mechanism work and explicitly handles Umer's own mechanism PRs through Abraham's sign-off, recorded in a PR comment if given off GitHub, while retaining independent peer approval. The separate second sign-off for foundry/src/** remains in place.

Claimed: CODEOWNERS routes review requests by area without making code-owner approval a merge requirement.

Verified: Checked the last-matching entries for contracts, Python/tests/services/CI, documentation, the maintainer guide, CODEOWNERS itself, Claude tooling, and the fallback. The routing matches the PR description. The active develop ruleset requires one approval, last-push approval, dismissal of stale approvals, an up-to-date branch, and CI OK; it does not require code-owner review. CODEOWNERS configures requests, not reviewer availability or approval eligibility.

Claimed: Documentation links are valid and CI passes.

Verified: All 16 relative links in the new maintainer guide resolve, including heading anchors; both newly added MAINTAINING.md references resolve. These were checked separately because the Docs job runs its link checker only over Documentation/. CI run 39645242917 passed Solidity, Python, Docs, and CI OK for this revision; covered tests were not rerun locally.

Claimed: The PR can merge as-is against current develop.

Verified: The four-file diff is +219/-0. git apply --check succeeds against a clean local checkout at the current develop SHA above. GitHub reports the same head/base, mergeable: true, and mergeable_state: clean. This was a patch applicability check, not a local merge/build.

Verification limits: No live-network or deployment verification applies to this docs/config-only change. The author's CODEOWNERS-errors API result and the original Discussion agreement were not independently re-fetched during this final pass; the final pass checked the previously requested fixes, full file diff, routing, links, active rulesets, and CI evidence.

No remaining findings or requested changes. The approval at this revision stands. The per-file merge proposal follows; the actual merge and post-merge outcome remain for the merger.

[Santiagocetran]

Merge proposal for PR #268 at 20a52a9340960f3a3d074131c2fcf91b91aaacb5.

Compared with current develop / merge base 5f610c79063eef622acbe3a0997930a5d5204c14: 4 files, +219/-0. The branch contains current develop; there is no intervening develop drift to reconcile. GitHub reports mergeable: true and mergeable_state: clean. The exact PR patch also passes git apply --check against the clean local checkout at that develop SHA.

.github/CODEOWNERS

Field	Value
Change	New
Lines	+37/-0
Diff	Adds the fallback followed by area-specific owners and explicit overrides for process/tooling files.
Functionality — how & why	How: GitHub uses the last matching pattern to request area reviewers; the active ruleset keeps code-owner approval optional. Why: Routes work to suitable reviewers while the independent peer-approval rule remains the merge gate.
Diff vs current develop	The change above applies directly to current develop; no additional reconciliation.
Recommended merge proposal	Merge as-is using GitHub's Create a merge commit.
Actual merge proposal	Soon
Pending proposal	None.
Local/GitHub conflict	Local patch applicability check: clean; GitHub: no conflict. A local merge was not performed.

Developer/MAINTAINING.md

Field	Value
Change	New
Lines	+179/-0
Diff	Documents peer review, enforced rules, reviewer routing/escalation, evidence, review records, merge paths, issue/task closure, and tooling limits; includes both requested fixes.
Functionality — how & why	How: Provides the human process alongside GitHub enforcement, including independent final approval and explicit mechanism sign-off. Why: Makes reviewer and merger responsibilities explicit and prevents self-approval.
Diff vs current develop	The change above applies directly to current develop; no additional reconciliation.
Recommended merge proposal	Merge as-is using GitHub's Create a merge commit.
Actual merge proposal	Soon
Pending proposal	None.
Local/GitHub conflict	Local patch applicability check: clean; GitHub: no conflict. A local merge was not performed.

Developer/CONTRIBUTING.md

Field	Value
Change	Modified
Lines	+2/-0
Diff	Adds the peer-review/merge statement and a relative link to MAINTAINING.md.
Functionality — how & why	How: Directs contributors from the contribution guide to the maintainer process. Why: Makes the review and merge expectations discoverable before submitting work.
Diff vs current develop	The change above applies directly to current develop; no additional reconciliation.
Recommended merge proposal	Merge as-is using GitHub's Create a merge commit.
Actual merge proposal	Soon
Pending proposal	None.
Local/GitHub conflict	Local patch applicability check: clean; GitHub: no conflict. A local merge was not performed.

Developer/README.md

Field	Value
Change	Modified
Lines	+1/-0
Diff	Adds MAINTAINING.md to the developer-documentation index.
Functionality — how & why	How: Adds a table entry linking to the new guide. Why: Makes the process discoverable from the Developer directory entry point.
Diff vs current develop	The change above applies directly to current develop; no additional reconciliation.
Recommended merge proposal	Merge as-is using GitHub's Create a merge commit.
Actual merge proposal	Soon
Pending proposal	None.
Local/GitHub conflict	Local patch applicability check: clean; GitHub: no conflict. A local merge was not performed.

Verification: claimed/verified record, approval, and passing CI.

No further code or documentation changes are proposed. After the merge, the merger should fill in the actual merge outcome, monitor the resulting develop CI run, and post the outcome comment with the real merge SHA, any deviations, and final build/test results.

[umeradl]

@Santiagocetran thanks. You'd already merged this a few seconds before I posted, so ignore the request that was here.

This is the first PR that went fully through the new process (S2 in Discussion 208). You reviewed and approved it, then merged it with a merge commit, 0f1b97b. The CI run on develop for that merge is in progress, and the merger owns it (No. 4.6).

When you get a chance, please confirm here that the next PR touching a CODEOWNERS path gets its reviewers requested automatically.

[Santiagocetran]

Post-merge outcome: merged by @Santiagocetran through GitHub's Create a merge commit as 0f1b97b5879d2ca73c156614f1e669693d1e9182.

All four files were merged as proposed, with no deviations: .github/CODEOWNERS, Developer/MAINTAINING.md, Developer/CONTRIBUTING.md, and Developer/README.md. The merge commit and reviewed PR head 20a52a9 have identical Git trees (ae7952bafdaf28e72fe5be8732a7fae040567542). This records the actual outcome for all four entries in the merge-proposal table.

Post-merge CI on develop completed successfully for the merge SHA:

• Solidity: successful build and size gate; Foundry 501 passed, 0 failed, 0 skipped; Hardhat compiled 30 Solidity files and 32 tests passed.
• Python: 474 passed, 133 deselected, 3 warnings.
• Docs: 287 inline relative links checked, all resolved.
• CI OK: passed. All four jobs succeeded.

The non-blocking advisory lint steps still report findings (forge lint: 49; Ruff: 664); they are advisory under the current workflow and did not fail the required checks.

@umeradl your merge request crossed with the merge by a few seconds; it was already completed using the requested method. Automatic CODEOWNERS reviewer requests remain pending live verification on the next newly opened PR touching a covered path; this comment does not claim that future check has happened.