Commit Graph
151 Commits
Author SHA1 Message Date
Claude 39ce5aa0ee Keep held dice held between throws
Picking the same three dice again after every throw is work the screen can do.
A kept die does not move and does not change, so the hold a player just made is
still the hold they want, and clearing it was throwing away a decision they had
already expressed.

The selection has to go when the turn does, though. A turn opens with the dice
back in the cup and its first throw must keep nothing -- the rules refuse
anything else -- so a selection carried over from the last turn would be
rejected and Throw would look broken in exactly the way it did before.

Keyed on the round as well as the seat, because a solo game never changes seat:
turn stays at zero and only the round moves on.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 19:56:19 +00:00
adrianoftyriel 81914e9b34 Merge pull request #26: keeping dice is a set, not a list
Holding dice did nothing unless they were tapped left to right: a tap-ordered
list was not among the ascending ones legalMoves offered, and the controller
drops what it cannot find there. Verified by ci.yml run 118.
2026-08-08 13:46:22 -06:00
Claude e5c9561fef Keeping dice is a set, not a list
Holding dice did nothing unless they happened to be tapped left to right.

The screen appends each die as it is tapped, so holding the third and then the
first produced [2, 0]. legalMoves only ever generated ascending subsets, and
RollDice is a data class over a List, so [2, 0] was a different move from
[0, 2] and simply was not among the legal ones. MatchController drops a move it
cannot find there, silently -- hence a highlighted die, a Throw that did
nothing, and no error to go on.

A keep is a set of positions. Holding the third die and then the first is the
same act as holding the first and then the third, and a set says so: the two
are now equal, and the order they were built up in cannot matter. That kills
the whole class of bug rather than sorting at the one call site that happened
to show it.

Positions rather than faces still stands -- two fives are two different dice.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 19:40:38 +00:00
adrianoftyriel 8a5a3bd0c3 Merge pull request #25: one menu per game
Priority is the GameMenu declaration order. Verified on dev by ci.yml run
114 and published as v1.2.116-dev from this tree.
2026-08-08 13:31:03 -06:00
adrianoftyriel 6231009954 Merge pull request #24: one menu per game
Priority is the GameMenu declaration order: solitaire, trick-taking, cards,
board. Verified by ci.yml run 114.
2026-08-08 13:20:30 -06:00
Claude b40f4a0206 File every game in one menu, by priority
Listing a game in each menu it belonged to made every section a partial
duplicate of another: Card Games repeated all four trick-taking games, and
repeated all four patiences again. A menu that echoes itself is harder to scan
than a longer one that does not.

GameDescriptor keeps its set, because it is still true that Klondike is a card
game and Euchre is a trick-taking one, and the blurbs and the sub-menu heading
both lean on that. What changed is where a game is listed: home takes the first
of its menus in GameMenu declaration order, and that order is the priority --
solitaire, then trick-taking, then the rest of the card games, then board
games. The enum is reordered to say so, which puts the rule in one place
instead of in a comparator somewhere else.

Sequence goes back to being a board game only. It is played with two packs, so
it was listed as both, and under this priority "both" would have quietly filed
it under Card Games -- away from where anyone who owns the box would look. The
set is the wrong tool for a game that is only arguably two things.

Nothing in the screens changed: inMenu now answers with homes, and the section
screens were already asking it.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 19:14:38 +00:00
adrianoftyriel 2083847967 Merge pull request #23: promote to main
Seven new games, single-player support and a menu tree. Verified on dev by
ci.yml through run 109 and published as v1.2.112-dev from this tree.
2026-08-08 11:54:19 -06:00
adrianoftyriel a8b8cd8838 Merge pull request #22: one centred column for the main menu
A short list spread across a grid read as a page half empty. Verified by
ci.yml run 109.
2026-08-08 11:38:27 -06:00
Claude e5e1d134a7 One centred column for the main menu
The games moved a level down when the menus became a tree, so the top screen
now holds three sections and two buttons. Spread across an adaptive grid that
read as a page half empty rather than as a menu.

One column, held in the middle, capped at 340dp so a tablet gets a menu rather
than a row of very wide buttons. Join and Scorekeeper sit below the sections and
run the same width, so the column stays a column all the way down rather than
turning into a wrapped row at the top.

The grid is still what the section screens use, where there are enough games for
it to earn its place.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 17:32:35 +00:00
adrianoftyriel cbe25898c8 Merge pull request #21: a menu tree
Solitaire, Card Games and Board Games, with Trick-taking under Card Games,
and a game listed in every menu it belongs to rather than just one.

Verified by ci.yml run 105.
2026-08-08 11:22:02 -06:00
Claude b12a0ed3c9 A menu tree, and games that can be in more than one branch of it
Three sections on the main screen -- Solitaire, Card Games, Board Games -- and
Trick-taking sitting under Card Games rather than beside it, because it is a
kind of card game and not a rival to one.

GameDescriptor carries a set of menus rather than one category. A patience is
solitaire and a card game; Euchre is a card game and a trick-taking one; peg
solitaire is solitaire and a board game. Each is listed in every place it
belongs, which is the point: a game reachable one way and not the other is a
game somebody cannot find.

GameMenu reads its parent from a `when` rather than taking it as a constructor
argument. An enum entry cannot refer to another entry while the class is still
initialising, and the lookup afterwards costs nothing.

Counting a section counts a set rather than adding lists together, since a game
in both Card Games and Trick-taking is one game and not two. hasAnything asks
about a menu and its children together, so a section is only hidden when there
is nothing under it anywhere -- the same rule that used to keep a heading from
being stranded over an empty category.

The dev-build "coming soon" behaviour is unchanged and still tested. What could
not survive the change is the old test that counted games across categories and
expected the total to equal the catalogue: with a game in several menus that
sum is meaningly larger. It is now a union, which is what it was really
checking -- that no game is stranded in no menu at all.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 17:16:16 +00:00
adrianoftyriel f6767c48bf Merge pull request #20: FreeCell, Spider and Pyramid
Three more patiences, all playable, and the Klondike table laid out the way
a real one is.

Verified by ci.yml runs 100 and 101, green across build, tests and lint.
2026-08-08 10:29:17 -06:00
Claude 459670012e Screens for FreeCell, Spider and Pyramid, and all three into the catalogue
Seven games now, and the three new ones are tappable.

The furniture they share moves into CardTable: a place a card sits, an empty
place that can still be tapped into, and the two dialogs for leaving. Klondike
keeps its own copies rather than being rewritten to use them -- it was written
first, its constants are tuned to seven columns, and its private helpers cannot
collide with these.

FreeCell puts the cells on the left and the homes on the right, which is what
makes the cells read as somewhere to put things rather than somewhere cards come
from. Spider shows the two numbers the game actually turns on above the columns:
runs gone away, and rows still in the stock waiting to bury everything.

Pyramid is drawn as it is dealt, each row offset half a card so every card sits
in the notch between the two below it. The shape is the rules -- a card is only
in play once both the cards resting on it have gone -- so seeing it at a glance
is most of playing it. Tapping a king takes it alone; tapping anything else
holds it and lights up only what would make thirteen with it.

All three restart by rebuilding the controller, as Klondike and peg solitaire
do, because a blocked deal is genuinely finished and advanceIdle never runs.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 16:23:17 +00:00
Claude 4e7aa98b61 A cell can strand a card, and the test said otherwise
The test asserted that a card parked in a free cell can always be played again.
It cannot. A cell holds a card nothing on the tableau will take and that is not
yet ready for a foundation, and it stays there -- that is the whole danger of
the cells rather than a fault in them, and the reason four of them is a game
worth playing.

What is worth pinning is what parking actually does: the card leaves the column
and is in the cell afterwards. The one card a cell can never strand is an ace,
since a foundation will always have it, so that gets a test of its own.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 16:14:06 +00:00
Claude deaf85938c Lay the Klondike table out the way a real one is
Three changes, all about where things are and how much room they take.

Columns now overlap by a third rather than sitting one under another. A column
of thirteen took more vertical space than a phone has; overlapped, it fits, and
a third is the most that can be hidden while every card still shows its rank and
suit. Absolute offsets rather than negative spacing, because the column has to
work out its own height anyway to reserve the right room.

The cards turned off the stock fan sideways by the same third. Drawing three and
showing one hid two cards the player is entitled to see -- they are face up on
the table. Only the last is playable, which the rules already enforce; the other
two are there to be read.

The stock and the cards turned from it move to the bottom left, under the hand
that turns them, and the foundations keep the top on their own. That is where
both live on a real table, and it puts the pile you tap most within reach of a
thumb rather than at the far corner of the screen.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 16:07:39 +00:00
Claude 40ea68f4c0 FreeCell, Spider and Pyramid, as rules
Three more patiences, and they are three different games rather than three
settings of one. FreeCell builds down in alternating colours with everything
face up; Spider builds down in rank but only moves runs of one suit; Pyramid
builds nothing at all and takes cards away in pairs that make thirteen.

FreeCell's supermove is arithmetic rather than a rule. A run is really moved one
card at a time through the cells and the spaces, so what can travel is what
those could have held: one per free cell plus the card itself, doubled for every
empty column usable as a staging pile. Moving into an empty column cannot also
stage through it, which is the fiddly case and is tested on its own.

Spider separates landing from travelling, which is the whole difficulty of the
four-suit game: a card lands on anything a rank higher, but only a same-suit run
moves as a unit. The pack is a hundred and four cards whatever the suit count --
eight copies of one suit, or two of each of four -- so the deal keeps its shape.

Pyramid blanks the places it takes cards from rather than compacting them. A
place is what tells the two cards above it that they are free, so an index that
shifted would uncover the wrong cards.

All three read the ace-low ordering from game.solitaire rather than defining it,
which is the point of having put it there.

The AI is deliberately dim -- it takes the first move on offer. A greedy
patience player that looked clever would be worse, because it would be trusted
as a hint, and a hint that walks a run back and forth is more annoying than no
hint at all. Klondike has a real one because its move ordering is obvious;
these three do not, and pretending otherwise would be the wrong kind of helpful.

Ids only for now. Catalogue entries land with the screens.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 16:05:03 +00:00
adrianoftyriel 1980c69541 Merge pull request #19: Yahtzee and Klondike
A dice game and the first card solitaire, both playable. The ace-low
convention patience needs is now shared in game.solitaire rather than
defined per game.

Verified by ci.yml runs 90, 92, 93 and 94, all green.
2026-08-08 09:50:52 -06:00
Claude 7569f0b891 Share the ace-low convention rather than copy it
Klondike had its own patienceOrder, acceptsOnFoundation and buildsDown. FreeCell
builds the same way, Spider builds in suit, and Pyramid needs an ace worth one
to pair to thirteen -- four separate definitions of "the ace is low" would be
four chances to disagree, and the one that already went wrong cost a CI round
trip to find.

game.solitaire.Patience now holds the ordering and the build rules, and
Klondike reads them from there. buildsDown stays as a name in the Klondike
package because that is what this game builds with; it just no longer defines
what it means.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 15:44:53 +00:00
Claude 831b2fc925 Screens for Yahtzee and Klondike, and both into the catalogue
Two engines that had been sitting behind ids now have screens, so they are
tappable and playable.

The Yahtzee card shows what the dice on the table would score in every box
still open. That comparison is the whole of the decision, and doing the
arithmetic by eye is not what anybody wants from a phone. A turn is two choices
and the screen shows them together: which dice to keep before throwing again,
and which box to write in when the throwing stops.

Klondike plays tap-to-take then tap-to-put rather than by dragging. A drag
across seven columns of overlapping cards on a phone is mostly a test of aim.
Tapping a face-up card takes it and everything resting on it, so a run travels
the way it would on a table. Which taps do anything is read off the legal moves
the rules offer, so the screen never has to know why a move is allowed.

Klondike deals again by rebuilding the controller, as peg solitaire does: a
blocked deal is genuinely finished, so driveIdleSeats has already stopped and
advanceIdle would never run.

Yahtzee seats one to six, so it needed a case in seatCountFor. Without one the
seat count falls through to the catalogue minimum, which is one now that solo
play exists -- a two-handed game would have been dealt a single seat and the
rules would have refused the table.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 15:39:04 +00:00
Claude 3dbc4b5557 Count the ace low in Klondike
Rank.order puts the ace at fourteen, which is right for the games this deck
was built for -- in Euchre, Kaiser and the rest it is the highest card there
is. Patience counts it the other way: foundations run ace upwards and columns
run down to an ace.

Using the raw order meant a two could never follow an ace home and an ace could
never be laid on a two, so no foundation could be built past its first card.
Nothing about the deal or the moves would have looked wrong; the game would
simply never have gone out.

patienceOrder is local to this game rather than a change to Rank, because ace
high is correct everywhere else in the app.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 15:30:15 +00:00
Claude 2b09bcdde8 Klondike, the first of the card solitaires
Seven columns, four foundations and a stock, played by one person against the
deal. Three axes of variation, which is what most people mean by house rules
for patience: one card off the stock or three, how often the waste may be
turned back over, and whether an empty column will take anything or only a
king. A single pass through the pack is redealLimit = 0.

A spot is a kind and an index rather than a class per kind. Every place a card
can be in this game is one of four things identified by at most one number, so
a pair says everything a hierarchy would and crosses the wire as two plain
fields.

A tableau pile keeps its face-down and face-up parts separate, because that
split is the game: a column is only worth what has been turned up, and what is
buried is the thing being played for. Stripping the turned-up run off a column
turns the next card, which is where most of a deal is won.

Shifting a whole column into an empty one is not offered as a move at all. It
achieves nothing and would let a game walk back and forth for ever -- which
matters here more than usual, because isFinished is "won, or nothing left to
try", and a game that can always shuffle pointlessly is never blocked.

Turning a packet over reverses it, so drawing three leaves the deepest of the
three showing, and a redeal puts the top of the waste at the bottom of the new
stock. Both are tested, because getting either backwards is invisible until
somebody counts the cards.

The AI orders its preferences rather than scoring finely: home always, then
turning a card up, then emptying a column, and aimless shuffling between
columns below drawing, so it is only reached when there is nothing else. That
ordering is what keeps it from walking a run between two columns for ever.

Not in GameCatalog yet -- id now, entry with the screen.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 15:23:47 +00:00
Claude 68f8da0379 Yahtzee, as rules and an AI
Five dice, thirteen boxes, three throws a turn. The first dice game in the
app -- backgammon rolls them, but as a race rather than for what the faces
themselves are worth.

The throw is derived from the state rather than from a generator held on the
side. applyMove has to return the same thing every time it is given the same
state and move, because the host and every client run it separately, and a
throw that differed between them would split the game in two. Seeding on the
round, the seat, the rolls used and what was kept gives dice that are
unpredictable to play against and identical to replay.

RollDice carries positions rather than faces. Two fives are two different dice,
and keeping one while rerolling the other is something a set of faces cannot
say.

A card is thirteen slots in printed order rather than a map, so an unfilled box
crosses the wire as a plain null instead of going missing. A full house is
strictly three and two, so five of a kind does not pay for it -- that is what is
printed on the card, and the joker variations that say otherwise are not played
here. The second-Yahtzee hundred is only earned over a fifty: a zero written in
that box earlier forfeits it.

The AI does not try each way of keeping and look at what came back. Since the
throw is a pure function of the state and the dice held, that would be reading
the roll before making it -- winning by seeing the future rather than by playing
well. It decides from what is already on the table: a run if one is nearly
there, otherwise the face there is most of.

Not in GameCatalog yet, for the same reason as the others: the id exists so the
rules compile, and the entry lands with the screen.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 15:14:16 +00:00
adrianoftyriel 3afae95067 Merge pull request #18: Hearts, peg solitaire, and a seat for one
Two new games and the first single-player one. GameRules needed no change
for a one-seat table; CatalogTest's floor of two players is the only
invariant that moved.

Verified by ci.yml run 86 on 480f0ba: build, unit tests and lint all green.
2026-08-08 08:30:08 -06:00
Claude 480f0ba164 Import the two new screens into PlayScreen
They live in ui.game and PlayScreen is in ui, so naming them was not enough.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 14:19:43 +00:00
Claude 434ea86605 Screens for Hearts and peg solitaire, and a seat for one
Both engines had been sitting behind ids with no screen. This gives them one
each and puts them in the catalogue.

Peg solitaire is the first game here played alone, and almost nothing had to
move for it. seatCountFor already fell through to minPlayers, so one seat came
free; CatalogTest's floor of two players is the only invariant that had to go,
and it went to one. The setup screen grows a solo path instead: a one-seat game
has nobody to play against and no seat anyone could join, so it offers "Play"
and not "Host a game for others to join", and the menu says "On your own"
rather than "1 players".

Playing again cannot go through advanceIdle. driveIdleSeats returns the moment
rules.isFinished is true, before it ever reaches the confirmation branch, and a
peg board with no jumps left genuinely is finished -- unlike a Wizard round,
which is only between deals. Rather than bend isFinished into meaning something
else, the screen rebuilds the controller behind a generation counter. The board
is deterministic, so the retry is the same puzzle rather than a new one.

One board layout serves both geometries. Each hole is placed in hole-widths
rather than pixels and a triangle offsets its rows by half a hole, which is the
same staggering that gives a triangular hole six neighbours instead of four.

The Hearts screen reads the phase because two different things happen at it:
choosing three cards to give away, which is a multiple selection nothing else
in the app does, and then playing one card at a time like every other trick
screen here. Passing is capped at three by the picker rather than by the error
the rules would otherwise raise.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 14:13:10 +00:00
Claude 51aa0c3518 Peg solitaire, on five boards
The tee game from a restaurant table, and four larger boards it generalises to.
Two grid shapes, and the only difference between them is how many directions a
peg can jump: a triangle staggers its rows so a hole has six neighbours, a
square board has four. The jump, the goal and the dead end are the same either
way, which is why one legalJumps serves all five.

Hole counts are checked rather than asserted from memory -- 15, 21, 33 for the
English cross, 37 for the shallower French cut, 41 for the diamond -- and a
test walks every board from its opening to a standstill, which is what would
catch a geometry that produced a board nobody can move on.

PegJump carries only its ends. A jump is always two steps in one direction, so
the hole in between is the only one it can be, and storing it as well would be
a second copy of the same fact with the freedom to disagree.

This is the first one-seat game in the app. GameRules took it without changes:
one seat, always on the clock until the board runs out of jumps, and viewFor is
the identity because there is nobody to hide anything from. The catalogue entry
and the seat-count change it needs come with the screen.

The AI never runs during an ordinary game, since the only seat belongs to the
person playing. It is here because an empty seat has to be playable by
something, and because keeping the pegs together is what a "suggest a jump"
button would want.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 13:01:07 +00:00
Claude 84a9b3ffd7 Keep the Hearts id, which the rules engine needs to compile
HeartsRules names GameCatalog.HEARTS as its gameId, so the constant has to
exist even though the game is not in the catalogue yet. The id alone puts
nothing in the menu -- `all` is what the menu is built from -- so this compiles
the engine without offering a game that has no screen behind it.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 05:16:57 +00:00
Claude 88948eac9e Hearts, as rules and an AI
The trick-taking games already here all ask a seat to win tricks it named.
Hearts inverts that: every heart costs a point, the queen of spades costs
thirteen, and the hand is played to take none of them.

Four restrictions decide what may be played, and they lift in that order: the
two of clubs opens the round, a seat holding the led suit must follow it, no
point card may be discarded on the first trick, and hearts cannot be led until
one has been played. Each of the last three lifts when a seat holds nothing
else, which is why playableCards checks them in sequence rather than as one
condition.

Passing is simultaneous at the table but the engine hands out one seat at a
time, so currentSeat returns the lowest seat that has not chosen and the swap
runs once the last one has. viewFor strips the selections as well as the hands:
a pass a client could read in advance is not a pass.

Taking all twenty-six is the one case where a round does not sum to twenty-six,
so scoreRound works from the cards taken rather than a running total -- a count
cannot tell an unbroken moon from thirteen hearts and a queen picked up
elsewhere.

The AI plays to avoid points rather than to shoot: it sheds the queen and her
guards early, ducks under whoever is winning, and takes a trick as cheaply as
it can when it cannot get out of the way.

Not in GameCatalog yet. The engine is complete and tested, but tapping a
catalogue entry with no screen behind it would crash, so it is added with the
screen rather than before it.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 05:11:00 +00:00
adrianoftyriel 82c3479294 Merge pull request #17: promote 1.2 to main
Brings the rtk output-filtering hooks to the default branch, so sessions
cloned from main get them, and opens the 1.2 series on main.

Verified by ci.yml runs 76, 77 and 80; run 80 published v1.2.80-dev from
this tree.
2026-08-07 23:01:00 -06:00
adrianoftyriel c208afc213 Merge pull request #16: filter bash output through rtk, open 1.2
Adds a PreToolUse hook that rewrites Bash commands through rtk, a
SessionStart hook that installs the pinned binary into the empty sandbox
container, and moves the version series to 1.2.

Verified on the branch by ci.yml runs 76 and 77, both green.
2026-08-07 22:41:30 -06:00
Claude ee94d073dd Open the 1.2 series
The number after the series is the CI run number and climbs on its own, so
this is the only part of a version that is set by hand. Dev builds published
from dev now tag v1.2.<run>-dev.

The example in the comment above tracked the old value; a stale copy of the
number is the exact thing that comment warns about, so it moves too.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 04:35:56 +00:00
Claude af6f27cf60 Filter bash output through rtk before it reaches the model
Register a PreToolUse hook on Bash that rewrites each command through rtk,
so `git status` runs as `rtk git status` and the output is compressed on the
way back. The rewrite is transparent; commands are still written normally.

Measured on this repo, a full `git diff HEAD~3` drops from 521 KB to 28 KB,
a recursive grep over app/src/main from 117 KB to 19 KB, and `git log -20`
from 20 KB to 5.3 KB. Small outputs grow marginally because rtk adds a
header, which at those sizes is not worth avoiding.

The container starts empty, so a SessionStart hook installs the binary first.
It pins RTK_VERSION because the installer's default is to resolve the latest
tag through api.github.com, which the proxy answers 403 for every repository
but this one. Outside the sandbox the hook installs nothing and only prints
the command to run, and every failure path exits clean: with rtk absent the
rewrite no-ops and the only cost is verbose output.

Verified that rtk leaves what must not change alone -- `rtk read` returns
GameSetupScreen.kt byte-for-byte, commit messages keep their quoting, and
already-rewritten commands are not wrapped twice.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 04:30:36 +00:00
adrianoftyriel e08d43d10a Merge dev: cribbage, and an updater that cannot cross channels
Cribbage for two, three or four players; the fix that lets an
end-of-hand scoreboard be dismissed, which Golf, Wizard and Crazy 8s
have needed since they shipped; the update channel read off the running
APK rather than chosen in Settings; and a check on launch that finally
runs and only speaks when there is something to install.
2026-08-07 21:46:51 -06:00
adrianoftyriel f53a628c7a Merge pull request #14: each channel updates only from itself
The update channel is now a property of the installed APK rather than a
setting that could point a phone at the other channel's builds, and the
"check on launch" switch is wired to a check that speaks only when there
is something to install.
2026-08-07 21:37:07 -06:00
Claude cd7f86f47b Make "check on launch" actually check on launch
The switch has been in Settings since the updater landed and has never
been read by anything: there was no launch-time check to turn on or off.
It is now wired to one.

It speaks only when there is a build to install. An app that is already
current says nothing, and neither does one that could not reach GitHub —
opening the app is not asking a question, and a phone with no signal
should not be told off for it once a launch. The button in Settings *is*
a question and still answers every time, up to date and failures alike.
That rule is `launchOffer`, next to the channel rule and tested with it.

Two things it is careful about:

The setting is read straight from the store rather than from the state
the screens are drawn with. That state begins as the defaults — where
checking is on — and is replaced a moment later by what is stored, so a
check driven off it would have fired on the default before ever learning
it had been switched off.

The prompt waits for the splash to clear before appearing, while the
check itself runs behind it. The look costs no time and cannot land on
top of the tartan.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01DCuRESmSZeJoJond43itw2
2026-08-08 03:29:42 +00:00
Claude 3372adf87a Let each channel update only from itself, with nothing to choose
The updater took the channel from a setting, so a production install
could be pointed at dev builds and vice versa. That setting was the only
thing standing between a phone and the wrong line of builds, and it was
a chip you could tap by accident.

The channel is now a property of the running APK and nothing else. The
app reads the -dev suffix in its own versionName, asks that channel and
no other, and then checks again at the point of decision — a release
belonging to the other channel is refused whatever came back from the
fetch. There is no preference, no key in the DataStore, and no way to
cross over.

Crossing over was never an upgrade in the first place. The two channels
are counted by different workflows and their numbers are unrelated: dev
is on 69 while production is on 40, so "newer" means nothing across the
divide. They are separate apps under separate applicationIds, so having
both is a matter of installing both, and each then keeps itself current.

The rule is now a pure function with no Android in it —
update/UpdatePolicy.kt — so it is unit-tested on the JVM like the rules
engines are, rather than being buried in a class that needs an Activity.
UpdatePolicyTest holds the wall: a dev install is refused a production
build and a production install a dev one, at every version number
including the ones where the two sequences overlap.

The settings screen states which build is running and where its updates
come from. It no longer offers a switch, because there is no longer one
to offer.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01DCuRESmSZeJoJond43itw2
2026-08-08 03:24:48 +00:00
adrianoftyriel 71e000a428 Merge pull request #13: cribbage for two, three or four players
Adds cribbage — the crib, the cut, the play and the show, for two head to
head, three playing singly, or four in partnerships — and fixes the hold
that left every end-of-hand scoreboard impossible to dismiss.
2026-08-07 16:05:37 -06:00
Claude 6d490a50b1 Test that a cribbage partnership plays for its own crib
Four-handed is the only table where the crib in front of somebody else
is still yours, and the lay-away is where that has to be read. Two AI
seats facing each other take more than half the games against two
random ones, which a side giving away half its own cribs would not.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01DCuRESmSZeJoJond43itw2
2026-08-07 19:13:18 +00:00
Claude 136f5bc4f1 Let a scoreboard actually be dismissed
The pause between hands never ended. driveIdleSeats asks
awaitsConfirmation about the state, and the state does not change while
the players are reading it — so confirmAdvance restarted the loop, the
loop stopped on the same scoreboard, and the next hand was never dealt.
The screens hid their own dialog on the way out, so the table looked
released and then simply sat there.

The release is now something spendable rather than a question re-asked
about an unchanged state: confirmAdvance grants one, and the loop
consumes it to walk past the hold exactly once.

This is not new with cribbage — Golf's card, Wizard's bids against
tricks and the Crazy 8s round score all stop on the same hold and all
end there. Cribbage's show is what made it impossible to miss, because
a game of cribbage is nothing but hands one after another.

Covered by MatchControllerScoreboardTest, which plays a whole game of
one-move hands and insists every one of them stops to be read and then
goes on.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01DCuRESmSZeJoJond43itw2
2026-08-07 19:11:59 +00:00
Claude 27af034095 Add cribbage for two, three or four players
The whole game: the crib, the cut, the play and the show, pegging on a
board drawn with both pegs so the last score is visible as well as the
total.

Three tables rather than one. Two play head to head with six cards and
lay two away; three play singly with five and lay one, with a fourth
card dealt straight into the crib because three hands cannot fill it;
four play in partnerships pegging on one score, where your partner's
crib is your crib. Every table keeps four cards and every crib holds
four, which is what lets one engine serve all three.

The rule that shapes the code is that a game ends on the point that
reaches the target, mid-count if that is where it falls. Every award
goes through one function that stops the game there and refuses
everything after it, so a non-dealer who counts out wins before the
dealer's hand and crib are counted at all — the show reports those as
never counted rather than adding them on.

A go is called by the engine rather than tapped. The count only rises
within a series, so a hand that cannot play now cannot play later in
it, and there is nothing to decide; the log says who went past.

The opponent works out its lay-away rather than guessing: every way of
keeping four is scored against all forty-six cards that could still be
cut, and what goes to the crib is valued separately and added or
subtracted depending on whose crib it is. It takes 114 games out of 120
against random legal play, from either seat.

teamForSeat now takes the seat count, because cribbage is only a
partnership game at four — reading seat % 2 at a table of three would
have put the first and third players on the same side.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01DCuRESmSZeJoJond43itw2
2026-08-07 19:07:19 +00:00
adrianoftyriel 0e23d752c4 Merge dev: release 1.1
Verified on dev at 61db79e, the same tree: build, unit tests and Android
lint green, and it published v1.1.62-dev.
2026-08-07 10:07:34 -06:00
adrianoftyriel 61db79e91f Merge pull request #11: move to the 1.1 series
Verified green on the feature branch before merging: build, unit tests
and Android lint (ci.yml run 59).
2026-08-07 09:56:31 -06:00
Claude e8c7162bc0 Move to the 1.1 series, from one place rather than three
The series a build is named for was written out three times — in the
build file and in both workflows' tag lines — so bumping it meant
changing all three and a release could be tagged one thing and built as
another. It now lives in gradle.properties as plgVersionSeries, which
the build reads when it stamps the APK and both workflows read when they
name the tag.

Set to 1.1.

versionCode is deliberately left as the CI run number alone, which is
what makes the bump safe: the run number keeps climbing across a change
of series, so 1.1 never looks like a downgrade to Android and an OTA
update is not interrupted. The series is a name for people; the run
number is what the machines compare. The updater already read only the
trailing number, and its comments now say so rather than naming 1.0.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_019Pr6B8xDDtJJcb6WJMw7Ud
2026-08-07 15:50:30 +00:00
adrianoftyriel 696b045e87 Merge pull request #10: players set their own Mastermind codes
Verified green on the feature branch before merging: build, unit tests
and Android lint (ci.yml run 55).
2026-08-07 08:55:50 -06:00
Claude 7cd2b412e2 Let each Mastermind player set their own code
A generated code takes away half the game. Whether to repeat a colour,
whether to leave one out, whether to do the thing this opponent will not
expect — those are real decisions, and no random number generator makes
them.

So a game now opens in a SETTING phase: each player chooses the code
their opponent will have to break, one after the other, and the guessing
starts once both are down. They choose in turn rather than at once
because the engine only ever has one seat on the clock, and it costs
nothing — neither can see the other's, so going second is not an
advantage.

The same move carries both: while the codes are being set it is your
code, and after that it is a guess at theirs. Which one it means comes
from the phase rather than from a flag on the move, because the phase is
the thing that actually knows — a flag could disagree with it.

An empty code used to mean one thing and now means two — not chosen yet,
or chosen and hidden from the device this copy was sent to — so the
state carries a flag per player. Whether the other player is ready is
not a secret, and a screen has to be able to say "waiting for them"
rather than sit blank.

The computer sets a code at random and does not try to be clever about
it: a code chosen to beat a particular solver has a pattern in it, and a
pattern is the one thing a code should not have. That single choice is
the only random in the app drawn from a source nobody else can see —
every other one is seeded from the position so a host and a client
agree, but a code seeded from anything on the wire could be worked out
by the player who is meant to be guessing it.

A code set on a guest's device reaches the host as a move and stops
there: moves are intents sent to the host and are never relayed to the
other player, so the only copy that reaches an opponent is redacted.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_019Pr6B8xDDtJJcb6WJMw7Ud
2026-08-07 14:49:46 +00:00
adrianoftyriel ae077573b3 Merge pull request #9: Checkers, Backgammon, Mastermind, Pirates and Bulgars
Verified green on the feature branch before merging: build, unit tests
and Android lint (ci.yml run 51). Nothing in the catalogue is marked
coming soon any more.
2026-08-07 02:04:27 -06:00
Claude 284f9f3f95 Add Checkers, Backgammon, Mastermind, and Pirates and Bulgars
The four games that were listed but not written. Nothing in the
catalogue is marked "coming soon" any more.

Checkers is English draughts on the thirty-two dark squares, numbered
the way the game is written down. Captures are compulsory and a multiple
jump is one move object, so a player cannot stop halfway through one —
true by construction rather than by a rule that has to be enforced
somewhere. The move generator matches the published perft counts at one
to four ply (7, 49, 302, 1469), which fold in compulsory capture,
crowning and the men's forward-only rule all at once.

Backgammon's hard rule is not how a checker moves but that a player must
use as much of the roll as they can, and that cannot be checked one move
at a time: a move can be illegal precisely because playing it strands
the other die. So the generator works backwards from whole turns —
memoised depth-first over the remaining dice — and offers only the first
steps of the longest plays. Recomputing it after each checker is what
makes the rule true by construction. Every die comes from the table's
seed and a count of rolls made, which is in the state rather than beside
it so a game is reproducible from what crosses the wire. There is no
doubling cube; the rules document says so plainly.

Mastermind is played as a duel — both players are set a code and both
are breaking one — because the pencil-and-paper game gives the codemaker
nothing to do. It ends at the foot of a round, never mid-round, or going
first would be worth half a guess. It is the one game here with anything
to hide, so viewFor does real work: the host sends each device only its
own code, and a device that was never given a code refuses to score a
guess against it rather than quietly answering "nothing".

Pirates and Bulgars is Sackson's theming of Asalto, and the rules
document is explicit about which parts are attested and which had to be
chosen — the book could not be obtained. Two hunters who take by
jumping against twenty-four who cannot take at all, on a thirty-three
point cross whose drawn lines come from the same adjacency table the
moves come from, so the board and the rules cannot disagree.

130 unit tests across the four engines, all run locally as well as in
CI: game/ has no Android in it, which is what makes that possible.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_019Pr6B8xDDtJJcb6WJMw7Ud
2026-08-07 07:58:12 +00:00
adrianoftyriel f16b21abe7 Merge dev: Nine Men's Morris
Verified on dev at 2328609, the same tree: build, unit tests and Android
lint green, and it published v1.0.49-dev.
2026-08-07 01:20:18 -06:00
adrianoftyriel 23286090f1 Merge pull request #7: Nine Men's Morris
Verified green on the feature branch before merging: build, unit tests
and Android lint (ci.yml run 46). Also brings dev back in step with main.
2026-08-06 23:58:18 -06:00
Claude 94b51347c3 Add Nine Men's Morris
Nine pieces each on twenty-four points: place them, then move them, and
every line of three takes an enemy piece off the board. Two pieces left,
or no legal move, and the game is over. See docs/RULES-morris.md.

The board is numbered ring * 8 + index, so its geometry falls out
arithmetically rather than being typed in as a table of twenty-four
rows: neighbours around a square are the index either side, the ladders
between squares run through the odd indices alone, and a mill is three
consecutive points centred on an odd one. A table would say the same
thing and could be wrong in one row.

A turn is one move object — the piece placed or stepped, and the enemy
piece taken when that closes a mill. Generating the removal as part of
the move rather than as a turn of its own means there is no moment where
a player is halfway through a turn, so a device that drops off the
network between closing a mill and choosing what to take cannot leave
the table stuck, and the search counts one ply for what is one decision.

Three rules about mills are easy to get backwards and all three are
tested: the piece that arrives is what closes a mill, so stepping out
takes nothing and stepping back in pays again; a slide along the line
being completed is not a mill, because the third piece it needs is the
one that just moved; and a piece in a mill is spared unless every enemy
piece is in one, without which a player could never be reduced and the
game would not end.

The AI is negamax with alpha-beta and iterative deepening over the same
rules engine, with a node budget so the placing phase does not stall a
phone. It has no quiescence tail and does not need one: there are no
exchanges in Morris. Its evaluation knows that being down to three is
dangerous even with flying on — without that term the search reads three
pieces going anywhere as freedom and starts steering towards losing
pieces to get there, which is a real game it would throw away.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_019Pr6B8xDDtJJcb6WJMw7Ud
2026-08-07 05:52:26 +00:00