While writing up Minesweeper patterns for a strategy page, I kept noticing that
different guides describe the 1-1 pattern differently. Some say it locates a
mine. Some say it locates a safe cell. They can't both be right, and this is a
solved game from 1990 — so I did what you do when prose disagrees: enumerated
every consistent arrangement and counted.
Spoiler: the 1-1 pattern finds a safe cell, not a mine. And the guides that
say "mine" aren't just imprecise — they're telling you to do something actively
worse than guessing.
The setup
Two adjacent 1s along a wall, three covered cells above them:
a b c
? ? ?
1 1 ?
▓ ▓ ▓ ▓ = board edge
The left 1 is the load-bearing piece: the wall closes off its left side, so
it touches only a and b. Exactly one mine lives in {a, b}.
The right 1 touches a, b, and c, and also needs exactly one mine.
The enumeration
Two unknowns that matter: which of {a, b} holds the left 1's mine, and
whether c holds one. Four raw combinations, filtered by both constraints:
| a | b | c | left 1 satisfied? | right 1 satisfied? |
|---|---|---|---|---|
| 💣 | – | – | ✅ 1 mine in {a,b} | ✅ 1 mine in {a,b,c} |
| – | 💣 | – | ✅ | ✅ |
| 💣 | – | 💣 | ✅ | ❌ 2 mines |
| – | 💣 | 💣 | ✅ | ❌ 2 mines |
Two arrangements survive. c is empty in both. That's the whole proof:
c is safe with certainty, while a and b remain genuinely 50/50 —
nothing in this fragment resolves them, so don't try.
In code, because I don't trust my own tables:
const arrangements = [];
for (const mines of [[1,0,0],[0,1,0],[1,0,1],[0,1,1],[0,0,1],[1,1,0],[0,0,0],[1,1,1]]) {
const [a, b, c] = mines;
const left = a + b === 1; // left 1: touches a, b only (wall!)
const right = a + b + c === 1; // right 1: touches a, b, c
if (left && right) arrangements.push(mines);
}
console.log(arrangements); // [[1,0,0], [0,1,0]] — c is 0 in both
Why "it finds a mine" is worse than useless
If you believe the backwards version, you'll flag c — the one cell that is
provably empty — and then confidently click into the 50/50 at a or b.
The wrong version of this rule converts your only guaranteed-safe move into a
flag, and your genuine coin-flip into a "deduced" click. A player who knows
nothing does better.
The precondition everyone drops
The deduction dies without the wall. If the left 1 has covered cells on
both sides, its mine might live outside {a, b} entirely, the subset
argument collapses, and the pattern tells you nothing:
? a b c
? 1 1 ? ← open-ended: no deduction available
"Closed off" doesn't have to mean a literal wall — already-revealed cells work
too. But some boundary must pin the left 1's mine into the shared cells.
In my reading, dropped preconditions are how the backwards version spreads:
strip the constraint and the pattern becomes a vague shape you can
misremember in either direction. State the constraint and the deduction is
one subset argument you can rebuild from scratch at the board.
The general form, which survives rotation and reflection: the constrained 1
eats the shared cells, so the extra cell on the open end is safe.
Where this came from
I hit this while writing up patterns for a Minesweeper site I built from
scratch this summer — every pattern stated as a board fragment with the
deduction worked through rather than asserted, which is how the discrepancy
surfaced in the first place: you can't hand-wave a deduction you're forced to
enumerate. The full pattern set (1-2-1, 1-2-2-1, chording, and when guessing
is genuinely forced) is here:
https://minesweeperguide.com/strategy/
If you spot a hole in the enumeration above, I want to know — the entire
premise of this post is that this deduction is checkable, so check me.
