A rebuild from scratch simulation and games engine framework set up to assimilate and optimize techniques and implementations useful for games, simulations, robotics.
|
Some checks failed
ci / check (push) Failing after 4s
The retrospective question was whether the mechanism set is complete or each pass still finds a new class. This pass produced both an eighth instance AND a fourth class, so the answer is the uncomfortable one. Ledger: 10 instances, 4 classes, across 3 workplans. Every pass has produced at least one class the previous pass had not seen. HDN harness-does-nothing 5 executable assertions TA trusted arithmetic 3 re-derivation SSB same-sample blind spot 1 assertions over ALL the data DFD duplicated-fact drift 2 NEW -- reading a copy against source DFD is genuinely distinct: no positive control catches it, because both copies are internally consistent, and re-derivation does not either, because the copy faithfully reproduces what it was copied from. Found when an inlined price sheet went stale within an hour of T11 changing the real one. So v1.2 stops trying to enumerate classes in advance. Every error in three passes was corrected in-session for under ~1% of the pass, so the stated design goal is now cheap CORRECTION: keep raw data so numbers are re-derivable, keep artifacts small and committed so a wrong number is one grep from everywhere quoting it, give every number a command. Plus the one rule the new class earns: single source of fact. The original hypothesis is revised rather than confirmed. "A rule that cannot be executed is not a rule" is wrong -- the two most valuable corrections in the project came from a decorative rule that cannot be automated (re-derive inherited numbers). An executable rule fires reliably and catches one class; a decorative one fires unreliably and can catch any class, including unnamed ones. Keep both. Gates this pass: loop-lint caught 3 real violations on first run, then failed on its own author within the hour when a T07 edit pushed InnerLoop.md to 407 lines against its own 400 limit. CB-WP-0003 complete: 11 of 11 tasks done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .forgejo/workflows | ||
| benchmarks/baselines | ||
| crates | ||
| decisions | ||
| evidence | ||
| games/ground | ||
| history | ||
| research | ||
| scenarios/ground | ||
| specs | ||
| tools | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| clippy.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.
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.