A Go-like game designed to be playe by two-to-eight players competing for territory!

Fork 0

bit-blossom docs memories project capture-rules.md

32 kB

Markdown

at main

Arcadia Rose · Let Claude iterate on the bots · 1mo ago

66642ba2

Capture rules #

A piece can be captured three ways: the four-piece ring (orthogonal or diagonal), cutting, and territory. Each victim is evaluated independently, cell by cell — but territory takes a region's contents wholesale: every enemy piece sitting inside a region that newly becomes territory is captured together, so "no group captures" no longer holds in effect even though the underlying test stays per-cell rather than per-region.

The four-piece ring — orthogonal (N, S, E, W) or diagonal (NE, NW, SE, SW) — fires whenever all four neighbours of an enemy piece in one pattern are one player's stones, at least one of them placed this turn. Both patterns are hand-written special cases, and neither is redundant with territory:

The orthogonal ring fires on a cell that is ALREADY the capturing player's territory, which territory itself cannot: a cell's territory status only changes when its enclosure status changes, and tightening a ring around an infiltrator deep inside a standing territory doesn't change that. Deleted 2026-09-06 on the mistaken claim that a one-cell territory reproduces it exactly — checked only on an open board — and restored the same day when Arcadia's own diagram hit this case: a standing territory with an infiltrator inside, ringed afterward, captured nothing under territory alone.
The diagonal ring has no territory equivalent at all, open board or not: its four stones sit two cells apart with no connected chain between them (see "Shape properties" below), so there is no diagonal loop enclosing exactly one cell for territory to generalize from.

Home bases are exempt from capture. A home base (Piece.isHomeBase) can be a ring member, part of a wall, or sit inside a wall that gets cut — it counts as an ordinary piece for every rule above — but it is filtered out of the union in pendingCaptures, once, rather than guarded in each of pendingEncirclements, pendingCuts, and pendingTerritories. It can therefore participate in completing a capturing ring around some other piece without ever being the trigger or the target: it is stamped with the sentinel PRE_GAME_TURN, so placedThisTurn is permanently false for it, which both keeps it off the "at least one member placed this turn" pump check and rules it out as the capture target itself (a base is filtered from the final result regardless). See docs/memories/project/home-bases-and-victory.md for the full home base rule, including elimination, which is a different mechanism from capture entirely — a base is never removed from the board, but a player is eliminated while their base sits inside enemy territory.

Invariants that will hold for all future rules:

Captures are always triggered by the active player's own placements. Nothing is ever captured passively. A standing ring or territory does not keep firing on later turns — the capturing player must actively place a stone completing it for it to fire.
Captures resolve at end of turn, never on placement. Nothing commits until the player ends their turn, which keeps provisional placements fully retractable.
Only the active player captures. A player placing into an existing enemy ring or territory is safe; that square stays playable until an opponent actively re-forms it.
All four surrounders of a ring must be the same player. Two opponents contributing two stones each does not capture it.
Off-board is never a surrounder for either ring pattern or for a cut's own ring/shoulder check — an edge piece cannot be captured by a ring, and a corner piece cannot be captured by a ring, since a complete ring can never form partly off-board. Territory is the one exception: it treats the board edge as a wall, so corner and edge pieces ARE capturable there — corner costs 2 enclosing stones, edge costs 3, interior costs 4 (the Go liberty ladder). game.ts gained explicit board dimensions (BoardState.size) to make this possible, a deliberate trade against the file's previous dimension-independence. No rule other than territory may use bounds checking — the ring patterns and the cut must keep relying on pieceAt returning undefined off-board.

Cutting #

Current principle (since 2026-09-07): a cut severs a line; it needs a line of at least two enemy stones, not a closed shape.

Superseded principle, in force until 2026-09-07: "cuts are only allowed through encirclements, not through arbitrary shapes." That rule made cutting a late-game tool — it could only fire once an encirclement or a territory wall already existed — so it never punished a forming attack, and the player who attacked first and kept attacking dominated play. Opening cuts to any line lets cut-power scale with how much the aggressor has built, so the defender has a live answer to an attack in progress, not just to a finished one.

A link is the unit a cut is built from. Given a fresh stone A (placedThisTurn — the active player's, stamped this turn; a home base is never fresh) and one of the 8 directions d, a link from A along d exists in exactly two forms:

Joint link — the neighbour at A+d is itself fresh. Target is A+d.
Pierce link — the neighbour at A+d is a stone of a player other than the active player, AND the cell at A+2d is fresh. Target is A+2d, victim is the stone at A+d.

No other case is a link. This is what keeps two carried-over invariants true without a separate check: pre-existing own stones never participate (a joint needs the neighbour fresh; a pierce needs it enemy), and there's never an empty gap inside a cut line (both forms require the far cell occupied and fresh).

A cut is two links along the same direction, chained: a link from fresh stone A along d, and a link from that link's target along the same d. Three fresh stones, two links.

What each link captures, evaluated against its own source stone:

Joint link, d orthogonal: nothing — it only chains.
Joint link, d diagonal: the other two corners of the unit square between source and target. If both hold stones, both belong to one player, and that player isn't the active player: both are captured. No separate "these are a line of 2" check is needed — the two victims are diagonally adjacent to each other by construction, so they satisfy the line requirement automatically.
Pierce link: the victim is captured only if it has at least one 8-adjacent stone belonging to the same player as itself — the "line of 2+" requirement. A lone enemy stone can never be flanked this way, so cutting stays an anti-structure tool rather than a way to snipe isolated stones. The two cut cells flanking the victim are the active player's, so a same-owner neighbour is never on the cut line itself — no extra exclusion needed.

pendingCuts returns the deduplicated union of captures across every cut found this way. Iterating every fresh stone as a possible start and all 8 directions covers both traversal orders of each axis; the dedup absorbs the resulting double count.

Invariants, carried over and still true:

All cut cells must be placed in the same turn. Pre-existing pieces never count toward a cut.
Cuts, rings, and territory all resolve together at end of turn, computed against the same pre-capture board, applied as one batch.
A wall is cuttable exactly where the cutter has empty cells to play into — the cutter needs somewhere legal to place the fresh stones that form the link chain.

Invariants that changed:

A cut is no longer capped at two stones. A single cut line can cross a diagonal wall at more than one joint, and each diagonal crossing can capture a pair — so a cut can now take up to 4 stones (two diagonal crossings on one line), not a fixed 2.
The old orthogonal-d/diagonal-ring and diagonal-d/territory-wall branches are gone. There is one geometric rule (link, then cut), not two hand-written cases keyed to encirclement type. enemyRing, orthogonalCutCaptures, diagonalCutCaptures, and the territory cache inside pendingCuts were deleted; pendingCuts no longer calls enclosedCells at all, which is also a real performance win (see the bonus section below).

New strategic facts:

Diagonal walls are now severable anywhere along their length, not only where they bound territory — a meaningful nerf to "diagonal walls enclose roughly twice the area per stone of an orthogonal wall" below: that stone-efficiency advantage now comes with more exposure along the whole wall, not just at its corners.
Two-thick and solid walls remain cut-immune. A pierce link requires the middle cell to hold exactly one enemy stone with a fresh stone immediately beyond it; two enemy stones in a row block that. Territory is still the only answer to solid matter.
Parallel walls spaced exactly 2 apart are the one shape that makes the bonus (below) net-positive — one stone placed between them can complete a cut against each wall. This is an emergent strategic constraint to watch for, not a defect: don't build that shape.

Bonus placements #

Cutting refunds placements, within the same turn:

export const bonusPlacements = (state: BoardState): number =>
  pendingCuts(state).filter((piece) => !piece.isHomeBase).length;

Home bases are excluded because they're never actually removed by a cut. remaining becomes state.placementsPerTurn + bonusPlacements(state) - placementsThisTurn(state). It's derived, never stored — BoardState gains no field for it, and it's recomputed fresh from the provisional board on every placement.

remaining >= 0 is a turn-long invariant, maintained by a single guard in retract: a retraction is rejected if it would leave remaining negative. Placing more stones can only add pending cuts, never remove them, so remaining can only be driven negative by retraction — which is why the guard lives there and endTurn needs no budget check of its own. In practice a player retracts bonus stones before the stone that armed the cut, which naturally keeps the board in budget throughout.

Bonus stones are themselves fresh, so a bonus stone can complete a further cut and earn further bonus — chaining is intended, is the whole point of the change, and terminates because every capture consumes a distinct enemy stone. It's shipped uncapped; if play shows it running away, the fix is a cap on bonusPlacements, not a change to the geometry.

remaining can now exceed the number of empty cells on the board. boardIsFull is unaffected by this — no new restriction was added to place (it still rejects only out-of-bounds, occupied, no-placements-left, game-over, and the opening-adjacency rule), so "a legal move exists whenever any cell is empty" is still true and the long comment above boardIsFull in game.ts still holds.

Dependency worth protecting, now for links rather than rings/territory: a link's pierce form depends on placedThisTurn distinguishing fresh stones from pre-existing ones, and on pieceAt returning undefined off-board and for empty cells. Anyone "simplifying" either of those would silently change what counts as a link.

Overlays (since 2026-09-07) #

A doomed piece — anything in pendingCaptures — stays on the board until endTurn, but as of this date it's also a legal place target: placing into it costs a placement (an ordinary one, or a bonus one, exactly as if the cell were empty) but does not grant the captured stone automatically. Arcadia's framing: this is a real choice, not a freebie — cement the slot to deny the opponent a rebuild, or leave it open and expand elsewhere. Applies to every capture rule (rings, cuts, territory), not cuts alone, because the economy is untouched either way: territory grants no bonus placements, so a large territory capture still costs one placement per cell claimed, same as a single cut.

An overlay is a piece whose position is also occupied by another, earlier piece. The earlier piece is always the doomed one, since a victim necessarily predates any stone placed this turn. This makes the invariant "an overlay is inert for every rule during the turn it's placed" mostly free:

Everything that reads the board through pieceAt — tryLink, ringAt — already sees the victim, never the overlay, because pieceAt's .find always resolves to the earliest-appended piece at a position. This is now load-bearing, not incidental: don't "fix" pieceAt into topmost-wins, or overlays start participating in rings and cuts. retract is the sole exception, and the trap the next person will fall into: it's the one caller that deliberately wants the topmost piece at a position, since a click on an overlaid cell has to retract the overlay the active player actually placed, never the victim underneath. It goes through a separate overlayAt helper (latest piece at a position, or undefined if there's only one occupant) and falls back to pieceAt when there's no overlay to prefer. This was a genuine gap in the original overlay design — earliest-wins was established as load-bearing without being followed through to this one caller — so if retract is ever refactored, check that it's still asking for the overlay first.
Two places read state.pieces directly instead of through pieceAt, and both had to explicitly exclude overlays or they self-cancel: pendingCuts' fresh-stone scan (an overlay is fresh, so without the exclusion it becomes a link source on a cell pieceAt simultaneously reports as an enemy stone), and territoryByPlayer/pendingTerritories' blocker lists (an overlay is the active player's own stone, so without the exclusion it blocks its own cell in the after flood fill — un-dooming the very piece it was placed on).
pendingEncirclements needed no change: its victim filter already drops the active player's own pieces, and its ring test goes through pieceAt.

Why captures still can't resolve eagerly, at placement time, even though placeability is now immediate: pendingCuts (and every other pending-* rule) is recomputed from scratch off the live board on every call, not accumulated. Deleting a victim the instant it's doomed would make its own cut evaporate the moment something else on the board changes and the rule recomputes — there'd be nothing left at that position for the link to have pierced. Making that safe would require stashing removed pieces somewhere to reconstruct "what the board looked like when this fired," which is exactly the accumulated-history BoardState.scores's own comment says to avoid until something concrete needs it. So "captures resolve at end of turn" survives as a fact about state.pieces, even though the visual (translucent) and the legality (placeable) are both immediate.

place gained the overlay-acceptance rule (empty, or exactly one occupant that's currently doomed — never a second occupant, no stacking). retract gained an orphan guard alongside its existing budget guard: retracting the stone that armed a capture can leave an overlay sitting on a piece that's no longer doomed without ever driving remaining negative, so the budget guard alone doesn't catch it. retract also had to start preferring the latest piece at a position (the overlay) over pieceAt's earliest-piece answer, specifically so a click on an overlaid cell retracts the overlay and not the victim underneath — the one place in the codebase that deliberately wants topmost-wins instead of pieceAt's convention. boardIsFull switched from pieces.length to a count of distinct occupied positions, since an overlay and its victim share one cell but are two pieces.

Territory: the sticky sea #

Since 2026-09-09 (docs/tasks/2026-09-09/19-sticky-sea-territory.md), territory is no longer "the region(s) that aren't the single largest rim-touching region, recomputed from scratch." That global test had a real bug: a player's own later, distant subdivision of their outside space could make an already-standing territory bigger than either new outside child, promoting the standing territory back to "outside" and instantly un-capturing/un-eliminating everything in it — confirmed live 2026-09-09 when Arcadia extended a wall far from a trapped base and the trapped player came back to life with the enclosing wall around them completely untouched. See docs/memories/feedback/diagnosing-board-screenshots.md for how the bug was reconstructed from her screenshots.

Each player now has a sea: the part of the board they have not walled off. It starts as the whole board and can only shrink. To compute it, replay that player's live stones in turn order:

sea = every cell on the board
blocked = {}
for each distinct turn t of p's live pieces, ascending (PRE_GAME_TURN = -1 first):
    blocked |= positions of p's live pieces with turn == t
    if no piece of turn t sits in the current sea: continue      # it cannot split the sea
    children = 4-connected components of (sea \ blocked), connectivity restricted to sea cells
    rimmed = children touching the board rim
    if rimmed is empty: sea = {}; break
    m = max cell count among rimmed
    sea = union of every rimmed child whose count == m
territory(p) = every cell that is neither in sea nor in blocked

Each time a turn's stones subdivide the current sea, the largest rim-touching child stays the sea (ties: every tied child stays sea) and every other child becomes territory — and stays territory for as long as the stones that made that split remain on the board. game.ts: refineSea is one subdivision step, seaCells is the full replay, territoryCells is the complement (drop-in replacement for the old enclosedCells).

Facts that make this correct, and that constrain how the code may change:

Children are subsets of the parent, and blocked only grows within one replay, so sea cells can never later reconnect to territory cells. Restricting the flood fill to the current sea, not the whole board, is therefore exact, not an approximation — and it's also what keeps the cost down. Don't "simplify" it into a whole-board fill on every step.
A cell outside the current sea can never be affected by a later stone, which is what licenses skipping a turn whose stones don't touch the current sea. That skip is load-bearing for performance, not an optional micro-optimisation — see the Performance note below.
Ties staying sea preserves the existing "you must enclose a strict minority side" requirement.
A child touching no rim cell is never sea, which reproduces "a fully enclosed region is always territory" for free, regardless of size.
If a subdivision leaves no rim-touching child, the sea empties and the whole board becomes that player's territory — this preserves "if the active player owns the entire rim, every region is territory."
The replay reads only pieces currently on the board. A captured wall stone is simply absent from every step, so the split it made never happened, and the region it cut off merges back into the sea. That is what keeps "breach a wall and the territory releases; repair it and everything inside is re-captured" working with no extra code — and it's why this must stay a from-scratch derivation over live pieces rather than anything cached on BoardState. Caching the sea would break exactly this property, since a stone leaving the board would then need to invalidate a cache instead of simply being absent from a fresh replay.
Territory now only grows while a player's stones stand: subdividing your own sea can never release territory you already hold, because a standing territory cell was excluded from a previous step's sea \ blocked and a later step's sea is always a subset of the sea it refined. A cell can now stop being territory only by one of its own enclosing stones leaving the board — never by an unrelated subdivision elsewhere. This is the property the bug above violated and the whole point of the fix.

An enemy piece is captured when its cell is territory now and was not territory at the start of the turn — evaluated per cell, exactly as before. pendingTerritories computes after as a full sea replay of the active player's current live pieces, and before as a full independent replay of the pieces with turn < state.turn — not a truncation of after's sea, since the sea is inherently history-dependent and there is no shortcut from one replay to the other.

Order dependence is intended, and Arcadia explicitly accepted it. Two walls closed on different turns are adjudicated in the order they closed — the first wall's claim over its captured region sticks even after a later, larger subdivision of the remaining sea. The same two walls closed in a single turn are adjudicated together, against the whole sea at once, which can produce a different territory/sea split than closing them in sequence would. Her framing of the resulting game rule: "your free space only ever shrinks — each new wall captures the smaller side of whatever the sea has left." Worked 8x8 example in the task doc: an orthogonal wall at col 3 (regions 24 left / 32 right) followed on a later turn by a wall at row 3 of the right side (12 top-right / 16 bottom-right) leaves sea = 16, territory = 24 + 12. The same two walls closed on one turn instead leave sea = 24 (the largest of all three children at once), territory = 12 + 16 — a different, and equally correct, split.

Behaviours this produces (unchanged from before the sea rewrite):

A redundant stone added to a completed wall does nothing — the cells were already territory.
Playing inside a standing enemy territory is safe — those cells were already territory at the start of the turn.
Breaching a wall and repairing it re-captures everything inside — the cells stopped being territory when the wall broke and became territory again on repair. Infiltrators must keep the breach open.
Extending a wall to swallow new ground captures whatever was standing on it.
New: subdividing your own sea never releases territory you already hold — see the bug above.

Derived property: a single stone can only convert territory at a cut vertex of that player's sea. refineSea surrenders cells only when the sea splits into more than one child (or loses its last rim-touching child). One added stone splits the sea only if removing its cell disconnects the sea's 4-connected graph. So for any single placement, "does this capture territory" ⟹ "is this cell a cut vertex of my current sea," and the contrapositive gives a cheap sound filter for any code searching for a closing move:

Take the cell's four orthogonal sea-neighbours. Join two of them when the diagonal between them is also sea (N~E via NE, E~S via SE, S~W via SW, W~N via NW). If that leaves one component or fewer, the cell cannot convert anything — no flood fill needed.

No false negatives (neighbours connected through the cell's own 8-neighbourhood stay connected without it); false positives are resolved by a real seaCells replay. Derived by Seer 2026-09-10 while designing lib.seaCuts; used there as a prefilter. Note this is about a single placement — a multi-stone sequence closes gaps no single stone is a cut vertex for, which is why one-ply territory search can finish a wall but never plan one.

Strategic axis worth watching in play: diagonal walls enclose roughly twice the area per stone of an orthogonal wall, but every stone in a diagonal wall is itself orthogonally exposed and can be captured the same way. Solid and two-thick walls are immune to both ring patterns and to cutting (see "Shape properties" below) but cost far more stones per unit of enclosed area, and — unlike those two patterns — they are not immune to territory: an enemy stone's own solidity does not block an opponent's flood fill, so a solid blob fully surrounded by someone else's wall is captured wholesale just like anything else inside it.

Performance #

Shipped without a cache, per Arcadia's call — measure first. The replay costs one flood fill per turn in which a player played into their own current sea (skipped otherwise, see the load-bearing skip above), in place of one flat whole-board fill. place calls gameStatus, which calls territoryByPlayer for every player, so a candidate-scoring bot pays for a replay many times per turn. If a late-game bot turn measurably slows down, the fix is a content-addressed memo of the start-of-turn sea (key: rows x cols | t:r,c | t:r,c | ... over a player's live pieces with turn < state.turn, shared by every candidate move within one turn) — not storing the sea on BoardState, which would break the breach-releases-territory property above.

Measured, 2026-09-09 (headless 4-bot game, 16x16, bot.takeTurn + game.endTurn against compiled dist/, same seed before/after so turn count/winner/final piece count are identical and only timing differs):

seed	turns	old (global fill)	new (sticky sea, uncached)
1	133	152 ms/turn avg	1,965 ms/turn avg
3	107	not re-run	1,808 ms/turn avg

~13x slower, consistent across both seeds (not a one-seed artifact) — well past the "feels slow" threshold this section names as the memo's trigger. Reported to Arcadia via Seer 2026-09-09; the decision to spend on the memo is hers, not made here. If she authorizes it, Seer's specified shape: a content-addressed memo inside seaCells, written recursively — look up the key for the whole blocker list; on a miss, recurse on the same list minus its final turn-group (which hits after the first call of a turn), and do exactly one refineSea step from that result. Steady state becomes two key builds plus one refinement restricted to the current sea, against the old code's four whole-board fills, expected to land at or below the 152 ms baseline rather than merely undo the 13x. Also flagged, independent of the memo: seaCells currently rescans the whole blocker list twice per turn-group (O(turns × stones)); grouping by turn once would make it O(stones).

Measured again 2026-09-10, after bot/lib.ts gained seaCuts (a one-ply territory lookahead calling game.seaCells once per candidate closing cell, for every enemy plus self, on every nextPlacement):

run	turns	avg	worst single turn
4 bots, capped at 35 turns, 5 seeds	35	620–654 ms/turn	1.5–1.9 s
3 bots, unbounded	94–154	555–1,215 ms/turn	2.0–3.1 s

Do not read these against the 1,965 ms/turn above as a before/after — the conditions differ and the comparison is meaningless. That figure was a 4-bot, 133-turn game; these are a 35-turn cap (a much sparser board, so seaCells replays fewer turn-groups) and a 3-player game (one fewer sea replay inside every game.place). The lower number here does not mean adding seaCuts made anything faster. Player count and board density both move this metric more than the strategy code does, so any future timing claim needs to state both.

What the numbers do support: seaCuts is an additive cost of the same order as the existing baseline, not a multiplicative blowup. lib.moves still dominates — it spends roughly candidates × players sea replays per decision (~240) against seaCuts' ~64 per seat — so the seaCells memo specified above remains the right lever, and it helps the larger term. Optimising inside bot/*.ts would target the smaller one, and a module-level cache there would also cut against CLAUDE.md's "modules don't own mutable state." Reported to Arcadia via Seer 2026-09-10; the decision to spend on the memo is still hers.

Shape properties of the current rules #

These follow from the existing rules rather than being new rules. They were derived during the Territory design conversation and verified against game.ts.

Solid shapes are immune to both ring patterns and to cutting. Every stone in a solid rectangle — or in any wall two cells thick — has at least two orthogonal neighbours of its own colour, and its inward diagonals are its own colour as well. Neither ring can then be all-one-enemy around such a stone. Since 2026-09-07, cutting works by chaining links rather than piercing an encirclement, but the immunity survives: a pierce link needs its middle cell to hold exactly one enemy stone with an empty (fresh-placeable) cell immediately beyond it, and a solid or two-thick wall has no such cell anywhere along it. This was the main gap in the ruleset before territory shipped: territory has since become the answer to solid matter, since an enemy stone's own solidity does not block an opponent's flood fill — a solid blob fully enclosed by someone else's wall is captured wholesale like anything else inside it. See "Territory" above.

A one-thick line is NOT immune to the diagonal ring. Confirmed intended by Arcadia 2026-09-07 against a live board: an enemy stone with its own stones directly east and west — the middle of a one-thick horizontal line — was captured by the diagonal ring, and that is correct behaviour, not a defect. The immunity above is specifically about solid and two-thick shapes, where the victim's inward diagonals are its own colour; a one-thick line leaves all four diagonals free for the attacker, so its interior stones are capturable even though they stay orthogonally connected to their own group. "The rule captures a stone that is geometrically in the open" (below) describes the four ATTACKING stones and the four open orthogonal exits they leave — it is not a requirement that the victim be isolated. There is deliberately no escape/connection clause in pendingEncirclements: a ring needs all four cells of one pattern owned by the active player with at least one placed this turn, and nothing else. Note in particular that the diagonal ring does NOT mirror the cut rule's "line of 2+" victim test — cutting requires the victim to have a same-owner 8-neighbour, the diagonal ring requires nothing of the victim at all. That asymmetry is intended; don't "unify" them.

Hollow shapes are soft at their corners, and the hollow is why. In a 3x3 ring with an empty centre, a corner stone's four diagonals are three cells outside the shape plus the hollow centre — all empty. An attacker takes it for 4 placements over two turns: three outside diagonals on turn one (within the 3-placement budget), then the centre stone on turn two, which completes the ring and fires that same turn. One centre stone is the inward diagonal for all four corners at once. Edge-midpoint stones are immune, because both their inward diagonals are wall. Since 2026-09-07 this ring is independently cuttable too, wherever a fresh stone can reach an empty cell along a line that pierces one of its member stones — cutting no longer needs the ring itself to be a target of an encirclement.

The defence is to fill the hole, which makes the shape solid and fully immune — but a filled shape encloses nothing. A shape is impenetrable exactly when it holds no space.

The diagonal ring's pattern has no scaled-up equivalent, and the orthogonal ring is restored alongside it. Deleted 2026-09-06 on the mistaken claim that a one-cell territory reproduces it exactly (verified only on an open board); restored the same day when Arcadia's diagram showed a cell already inside standing territory, where the ring still fires and territory cannot — see "the four-piece ring" above. The diagonal ring's four stones sit two cells apart and are not adjacent to each other, not even diagonally, so they form no connected chain and leave four open orthogonal exits. The rule captures a stone that is geometrically in the open. Diagonal walls in general are fine — eight stones touching diagonally in sequence form a closed diamond that seals a five-cell region, and territory captures through it just as it would through any other wall — but there is no diagonal loop enclosing exactly one cell. So the four-stone diagonal ring must stay a hand-written special case rather than a small instance of anything more general.