one kit under every backend

Two days ago cube design was read below the screen (below the screen). Yesterday the first library that holds it there was built, and then it was asked to carry the apps that exist.

why a kit

Selim’s rule is that every new app is built in cube design in its code and its tables too, not only on the screen. Today each backend rewrites the same cube code under its own words. A kit that already holds the principles gives speed and stops the deviations, the way a database library spares you the plumbing. Two earlier studies had arrived at the same design independently, so building could start without waiting for his open answers: an answer only changes a dial’s default.

five small steps

The core is plain Java with no dependencies. A cube, a piece, a side and an answer are one thing in its own box; the moves are pure functions that return a decision; and the rules are written once: an offer never overrides what the person kept, names keep their day and hands, homes cannot loop, given sides sit on every cube. Nothing is deleted and the owner never enters as an argument became tests over the kit’s own interface, so they are true by construction, not by discipline.

Step two added a store and a seam for an app’s own rules: a recurring to-do is ticked, never moved to done, and that rule became the test. A rule’s follow-up goes through the same plain moves as anything else, so a rule only offers. Step three wrote the schema from one declaration; the same tests run unchanged against memory and against Postgres and passed the first time, and cube design’s own database checks found only three small partials in the generated tables. Step four turned cube design’s 22 database and 5 backend checks into Java, plus sixteen behaviour tests, so that one line in an app’s tests runs them all. Checks that wait for Selim’s open questions still run; they report waiting with what they would say under the kit’s answer, so answering a question flips them at once.

Step five put the kit inside a Spring Boot app, and a real collision showed up at once: the example’s first migration clashed with the backend’s own. So the kit now keeps its migrations in its own folder with its own history. A suggestion from the plan, to guess the owner from the login when none is given, was dropped, because guessing who the person is was exactly the deviation the earlier studies were about.

then the real apps

A framework that works for a new app proves little. So the next tasks held the real code and the real row counts against it. The verdict of the look back: yes, it is possible, and proven for a new app (the example shelf is about 180 lines of its own Java and its tables follow cube design in 17 checks with 0 breaks). Not yet proven for moving an existing app.

Each plan found what the kit does not hold yet. Cubes: no way for one person to grow a library, a copied cube cannot be seen through the library’s sides, and nothing moves a piece into the piece beside it; about 1,790 of its 2,766 lines would go. Todarch: six gaps the shelf never hit, the biggest being feedback reports, which have coded sides living only on the top cube, something the kit’s schema forbids. Also, 137 kept placements can never say whether a session wrote them or Selim kept a suggestion, which is an argument for putting that on the placement. Anlat, the app furthest from the shape: five additions first, among them offered sides that have no code. The data turned up something the code did not: a column called residue was the same three answers as an offered lens called now; a side was hiding as a column.

The kit was also read as a cube itself, and failed its own test in two places. It repeats its not-found and not-yours guards thirty times and it keeps no earlier names for its own words, the very things it exists to stop.

The lesson written at the end of the Cubes plan fits all three: the rules of cube design are about structure, but the kit had been shaped by the first app it served. Moving the others is what teaches it.