tegwick
4b40a537a6
Some checks failed
ci / check (push) Failing after 4s
The answer is "it depends what you call an information set", and the distinction is the result. 44,938 decision points, random play, 2/3/4/6 seats. Reading A — information set = the seat's current projection, which is what project(Viewer::Player(seat)) returns and what the page renders: 22 violations. Reading B — information set = the seat's observation history, every view seen and action taken in order: 0. The Reading A witness is concrete. Two histories reach a byte-identical view — round 3, Select step, same hand, same claimed Problem — where the seat had played SOLVE then GROUND-OU(protect) in one and SUPPORT then SOLVE in the other. The view does not tell the seat what it did, because our state is a snapshot rather than a history: selections clear each round and effects coincide, so a player cannot reconstruct their own past from the present. In a real game the player's memory supplies it; in the state, nothing does. That is precisely OpenSpiel's ObservationString vs InformationStateString split, arrived at here by measurement rather than read off. project() is an observation, not an information state. So Track B is not closed, it is constrained, and usefully: an extensive-form game built from this engine must key information sets on observation histories, never on project(). Both directions are asserted — Reading B empty AND Reading A non-empty — because if the sample stops finding Reading A violations the conclusion is unsupported and must be re-derived rather than quietly kept. And the check samples, so it can falsify perfect recall and cannot establish it: Reading B's zero means no counterexample was drawn, which is printed as such. Wired into make panels, so it is re-derived by the gate rather than by hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .forgejo/workflows | ||
| benchmarks | ||
| crates | ||
| decisions | ||
| editions | ||
| evidence | ||
| games/ground | ||
| history | ||
| research | ||
| reviews | ||
| scenarios | ||
| simulators | ||
| specs | ||
| tools | ||
| trials | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| clippy.toml | ||
| facts.toml | ||
| gates.toml | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| rust-toolchain.toml | ||
| WORK-RECORDS.md | ||
clay-borg
A rebuild from scratch simulation and games engine framework set up to assimilate and optimize techniques and implementations useful for games, simulations, robotics.
Licensed under the Target Revenue Source License (TRSL V1C1) — see LICENSE; canonical text lives in the org's target-revenue repository.
Running the gates
make all # every gate, from a clean shell
make -C /path/to/clay-borg all # …or from any other directory
There is no environment setup step. No cd, no export PATH, no
activation script. make locates the repo from its own path and cargo
from the standard rustup locations; the Python tools do the same via
tools/repo.py. The only prerequisites are a rustup toolchain and Python
3.11+.
This is deliberate and enforced: make env-test runs every tool from /
with a PATH containing no cargo, and make all includes it. CB-RES-0003
measured 84 agent turns and $15.33 spent prefixing commands with cd and
export PATH before that friction was fixed at the root (CB-WP-0004 T01).
Other useful targets: make cost (spend per task), make cost-budget
(spend since the last commit), make cost-mix (mechanical vs judgment
turns), make loop-lint (executable InnerLoop rules), make self-tests
(every tool's positive control).
GROUND
The first product vertical is a virtual tabletop implementation of GROUND — A Game of Bonds and Rivalry: DARVO Edition. The boardgame itself (rules, editions, content) is at home in the sister repository ground-game — that repo is authoritative for what GROUND is; clay-borg implements the engine that runs it.