1 files changed, 4 insertions, 3 deletions
diff --git a/ci-arch.html b/ci-arch.html
index 71c3195..2153b3c 100644
--- a/ci-arch.html
+++ b/ci-arch.html
@@ -90,11 +90,12 @@
 <p>This is partly due to the <strong>SELFHOSTABLE</strong> requirement, but also because a WMF value is to prefer open source.</p></li>
 </ul></li>
 <li><p><strong>GITSUPPORT</strong> Must support git. We’re not switching version control systems for CI.</p></li>
-<li><p><strong>UNDERSTANDABLE</strong> Must be understandable without too much effort to our developers so that they can use CI/CD productively. Acceptance critera: our developers can use CI productively, after given a short, 1-page tutorial on how to specify build instructions for their software. FIXME: This might not be very clear.</p></li>
+<li><p><strong>UNDERSTANDABLE</strong> Must be understandable without too much effort to our developers so that they can use CI/CD productively. Acceptance critera: our developers can use CI productively, after given a short, 1-page tutorial on how to specify build instructions for their software. FIXME: This might not be very clear; suggetions welcome.</p></li>
 <li><p><strong>SELFSERVE</strong> Must support self-serve CI, meaning we don’t block people if they want CI for a new repo. Due to <strong>PROTECTPRODUCTION</strong>, there will probably to be some human approval requirement for new projects, but as much as possible, people should be allowed to do their work without having to ask permission.</p>
 <ul>
 <li><strong>SELFSERVE2</strong> Should allow the developers to define or declare at least parts of the pipeline jobs in the repository: what commands to run for building, testing, etc.</li>
 </ul></li>
+<li><p><strong>POSTMERGETESTS</strong> All automated tests must pass both before and after merging a change. This can be achieved by various means (run tests twice, or make sure target branch doesn’t change in between). The justification is that the way Gerrit and Zuul currently work, the target branch may change while other changes are reviewed and tested, so we run some test after a merge (but possibly before publishing the merge?). FIXME: is this adequate?</p></li>
 </ul>
 <h2 id="hard-requirements">Hard requirements</h2>
 <p>These are not absolute requirements, and can be negotiated, but only to a minor degree.</p>
@@ -132,7 +133,6 @@
 <li><p><strong>CONFIGVC</strong> Must keep configuration in version control. This is needed so that we can track changes over time.</p></li>
 <li><p><strong>GATING</strong> Must support gating / pre-merge testing. FIXME: This needs to be explained.</p></li>
 <li><p><strong>PERIODICBUILDS</strong> Must support periodic / scheduled testing. This is needed so that we can test that changes to the environment haven’t broken anything. An example would be changes to Debian, upon which we base our container images.</p></li>
-<li><p><strong>POSTMERGETESTS</strong> Must support post-merge testing. FIXME: This needs to be explained.</p></li>
 <li><p><strong>CIMERGES</strong> Must support tooling to do the merging, instead of developers. We don’t want developer merging by hand and pushing the merges. CI should test changes and merge only if tests pass, so that the branches for main lines of development are always releaseble.</p></li>
 <li><p><strong>TESTVC</strong> Must support storing tests in version control. This is probably best achieved by having tests be stored in the same git repository where the code is.</p></li>
 <li><p><strong>BUILDDEPS</strong> Must have some way to declare dependent repositories / software needed for testing. FIXME: This needs to be explained.</p></li>
@@ -150,7 +150,8 @@
 <li><p><strong>SLA</strong>: RelEng provides a promise, similar to a service-level agreement, for how well CI serves WMF and the movement.</p></li>
 </ul></li>
 <li><p><strong>HA</strong> Must be highly available - can restart any component without disrupting service.</p></li>
-<li><p><strong>CLEANWORKSPACE</strong> Must provide a clean workspace for each build or test run - either a clean VM or container.</p></li>
+<li><p><strong>CLEANBUILDENV</strong> Must provide a build environment with only explicitly declared build dependencies installed.</p></li>
+<li><p><strong>CLEANWORKSPACE</strong> Must provide a clean workspace for each build or test run - either a clean VM or container. The workspace should have the source code of the project to be built, with the right commit checked out from version control, and anything else explicitly declared, but nothing else.</p></li>
 <li><p><strong>SECRETS</strong> Must support secure storage of credentials / secrets.</p></li>
 </ul>
 <h2 id="softer-requirements">Softer requirements</h2>