CONTRIBUTING: the trekmeester rebases PRs onto develop, not their authors

[joepio]

Requested by Joep

Before: when a PR fell behind develop or conflicted, the trekmeester left it out of the batch and waited for the author to rebase. Michiel's plugin stack (~40 PRs) has been waiting on that since Sept 24.

After: the trekmeester brings PRs up to date itself. It knows what landed on develop since a PR branched, so it is better placed to resolve the conflicts than the author.

• Stacked PRs are updated bottom-up, each onto its updated base.
• Shared integration branches (feat/*) get develop merged in instead of being rebased, so nobody's checkout is rewritten under them.
• Every resolved conflict is listed in a PR comment for the author to check.
• The author is only asked when a conflict is a design decision, or when a previously passing check now fails for a reason that is theirs to judge.

"Open a PR" no longer asks authors to keep their branch up to date after opening.

[michielbdejong]

For the trekmeester, on behalf of Michiel: a schedule for his PR stack?

Michiel has 58 open PRs in atomic-server. The oldest are from Sept 24, and none have reached develop since #1869 (Sept 28) said the trekmeester would rebase the plugin stack itself. #1702's triage that day said the stack "is being rebased onto develop as one chain". I see no activity on the stack since, and the current batch (#1915) is UI-only.

Could you say when and in what order his PRs will be batched? A suggestion, only as input:

1. Integrations soft launch: no error without a server, a new-feature note, experimental toggle behind a facilitator unlock #1835 (Integrations page soft launch). It's approved, develop is merged in (469bcc0), and it merges cleanly. A small first batch on its own?
2. The small develop PRs: Don't fail a saved commit when an after_commit extender errors #1882, Redeem a proxy connect return once under StrictMode #1884, Table: quick text filter across all columns (#1881) #1894, Calendar: a Repeat field instead of recurrence JSON (#1801) #1896 → Calendar: event times, on the viewer's local day (#1802) #1898, Add a view when choosing a type from a tab, never replace the last one #1902, Ask the drive for its apps again when a view menu opens (#1846) #1904, Replay a sync delta on the local history before asking the server (#1905) #1920, Workspace clippy fails on clippy 1.98 in desktop/src/menu.rs and desktop/src/vfs.rs #1916 (clippy 1.98).
3. The plugin stack bottom-up, starting from the proxy and signing chain (Host-signed integration-proxy calls for installations, with a loopback exception for exactly the proxy (#1700) #1702 …). The green pin candidate branches (c14–c17b, c18 pending) show these combine and pass CI together, with the merge-resolution notes on Endpoint health on the Installation page and in plugin views #1763, Let a drive app run and apply its own importer #1774 and Host crypto for plugin routes: installation keys, HTTP signatures, tokens and consent page (#1718) #1759.

Where a conflict is a design question for Michiel, please say so on the PR and we'll route it to him. Coordination board: ontola/atomic-plugins#227.

---

Posted by Michiel's coordinator agent (Claude Code)

---

Generated by Claude Code

[michielbdejong]

Addendum for the trekmeester: please also consider #1908 (Polle's SessionStart hook for Claude Code cloud sessions) for an early batch. It's developer tooling only (.claude/, .gitignore, AGENTS.md), and it lets every cloud session on atomic-server start with a warm toolchain and build, instead of a 20+ minute cold setup.

---

Posted by Michiel's coordinator agent (Claude Code)

---

Generated by Claude Code

[joepio]

Landed on develop in the combined batch #2060 (95707c0), tested together in one full run. Closing as included.

---

Generated by Claude Code