Every change to the layer is written down here, with what moved and why. What is coming is on the same page, because a roadmap kept somewhere else is a wish list.
Breaking changes are named as such and never quiet. If a rule changes meaning, it gets a new name rather than a new definition.
01What is coming →Reckon has had two foundations. Versions 0.3 to 0.6 were built from one registry, and 0.7 replaced that layer wholesale with the cosscom/coss source. The name, the version line and the rules carried across unchanged — nothing forked.
Three layers finished together, because none is evidence on its own. Three products landed here and the five before them were re-audited against the finished rules — which is what makes the count eight rather than a running total.
The rules survived the change of source; their wording did not. AGENTS.md was rewritten against the new component set, and it is still not a style guide — styling is the tokens’ job. Three products landed against it, and the two from 0.8 were re-audited.
The component set closed against the new source, and the two shipped sites were recreated so the system could be read in situ rather than as a specimen sheet. The first two products were built against the closed inventory, which is what proved it was closed.
The foundation was replaced. Everything above the token layer stayed; every value below it changed, which is a break in the only sense that matters — a screen built at 0.6 does not render at 0.7. Reckon keeps its name; what it is recreated from is now cosscom/coss.
Five of nine worked templates deleted on purpose. They proved the rules ran, then proved something worse: nine products structurally identical, every one a dense record table with a rail of property pairs. Correctness was checked; form was merely invited, so form got defaulted.
The checked layer arrived. Rules that could only be stated before could now be run against a screen and reported on, which is the difference between guidance and a test.
Shells stopped being templates. Each shell now has to name three expressive choices and give a reason for each, which is what keeps two products built on it from looking identical.
The component set grew to cover what business screens actually need, and every state that never makes a mockup was drawn.
The first rules file a model would follow for more than four screens.
In the order it blocks other work rather than by date. A known gap is listed with the rest, because a demo should not be the thing that finds it.
02Straight answers →The readme opens with product context, which is right for a designer and wrong for someone who has just cloned. Small, and overdue.
A ninth product — a guest booking places to stay, top-nav shell, real map. Not finalised, so not part of 1.0 and not documented above.
Editable in Settings, but payouts do not check them yet. Named here so a demo does not find it first.
The questions that follow from a log and a roadmap: what breaks, what is promised, and what happens if I stop.
03Back to the top →It ships components and tokens, but that is not what you are buying. The product is the rules layer that decides what gets computed, what gets shown and what gets refused — plus the machinery that makes those rules checkable.
It is built for Claude Design users generating business UI. Because the layer is plain markdown loaded as project instructions, anything else that reads a rules file will use it too. There is nothing proprietary to integrate.
The tokens are yours to set and brand fit is a config change. The judgement rules are not configurable, because that is the product. If you want a different opinion about derivation, you want a different product.
The rules are written against behaviour rather than internals, so upstream releases move underneath them. Where a rule does need to change, it changes in one file you can read in an afternoon.
Marginally slower on the first generation. Considerably faster by the fourth, because you are not re-prompting it to fix a total that never tied.
Reckon
Components are the easy part. What you are missing is the layer that decides what gets computed, what gets shown, and what gets refused.