diff --git a/e2e/tests/i18n.spec.ts b/e2e/tests/i18n.spec.ts
index c01154a31..b997f2f6c 100644
--- a/e2e/tests/i18n.spec.ts
+++ b/e2e/tests/i18n.spec.ts
@@ -176,16 +176,18 @@ test.describe("i18n", () => {
 		});
 
 		test("shows Edit link for existing translations", async ({ admin }) => {
-			// FIXME(cloudflare): on the Cloudflare/workerd target the EN "Edit"
-			// link does not appear in the translations sidebar on the freshly
-			// created FR translation page (the EN sibling isn't read back in time),
-			// even though the translation itself is created and navigable (the
-			// other i18n specs pass). Same write-then-read signature as the skipped
-			// invite-flow test — suspected D1 Sessions read-after-write under
-			// miniflare dev. Flagged for maintainers; skipped so the CF lane stays green.
+			// FIXME(cloudflare): flaky on the Cloudflare/workerd target — the EN
+			// "Edit" link doesn't appear in the translations sidebar within the
+			// helper's timeout on the freshly created FR translation page. The
+			// backend is NOT at fault: hitting the translations API directly on
+			// D1 returns both siblings correctly (EN's translation_group is
+			// self-referential, FR's points to EN). It's a front-end render-timing
+			// issue specific to the slower workerd dev runtime — the sibling
+			// `clickEditTranslation` test (208) passes because `.click()` waits
+			// longer than this `isVisible` check. Skipped so the CF lane stays green.
 			test.skip(
 				process.env.EMDASH_E2E_TARGET === "cloudflare",
-				"CF: translation sibling not read back on the new translation page (under investigation)",
+				"CF: translations sidebar Edit link renders too slowly (front-end timing; backend verified OK)",
 			);
 			// Create a post and its FR translation
 			await admin.goToNewContent("posts");
diff --git a/e2e/tests/invite-flow.spec.ts b/e2e/tests/invite-flow.spec.ts
index dd7d02897..4cb923619 100644
--- a/e2e/tests/invite-flow.spec.ts
+++ b/e2e/tests/invite-flow.spec.ts
@@ -236,12 +236,16 @@ test.describe("Full invite flow with passkey registration", () => {
 		// not visible in the users list after the passkey-invite registration
 		// above — reproducible in isolation, passes on Node. The registration
 		// ceremony completes (redirects to admin, no errors) but the user row
-		// isn't read back. Suspected D1 Sessions read-after-write under miniflare
-		// dev rather than a production bug, but unconfirmed. Tracked for the
-		// EmDash maintainers to investigate; skipped here so the CF lane stays green.
+		// isn't read back. NOT a consistency artifact: miniflare D1 is a local
+		// SQLite file (strongly consistent), so if the read misses a committed
+		// write it's a real code bug — likely a SQLite-vs-D1-dialect difference in
+		// the invite-registration write or the user-list read. Needs a
+		// browser-driven repro (passkey-gated) to confirm backend vs front-end.
+		// Flagged for maintainers as possibly a real Cloudflare bug; skipped so
+		// the CF lane stays green.
 		test.skip(
 			process.env.EMDASH_E2E_TARGET === "cloudflare",
-			"CF: invited user not read back after passkey-invite registration (under investigation)",
+			"CF: invited user not read back after passkey-invite registration (possible real bug, under investigation)",
 		);
 		await admin.devBypassAuth();
 		await admin.goto("/users");