An application object in the dictionary is a tree of rows: a statement, filters, columns, joins, actions, events, links and forms. An agent cannot edit a tree of rows safely. This release serves each object as one JSON document and accepts one back.
Read and write
- One document A table, report or view object is returned whole, with surrogate ids for its parts and a content-hash version token. A conformance sweep over 505 objects reports no failures.
- Apply in one transaction A merge planner matches parts by id first, updates in place so ids survive, guards on the base version, previews the row diff in a dry run, and commits once. A patch mode adds and updates without deleting the rest.
- Reports and vocabularies too Report statements are compiled by the driver before acceptance and refused while a differing Studio draft is open. Menus, labels, renders, colourisers, palettes and images follow the same path.
Rules that prove themselves
- Harvested from specimens An authoring rule is an annotation on the demo object that demonstrates it, collected at build time and served as a resource. Rename or delete the specimen and its rule breaks. Forty-nine rules across seventeen families.
- Advisories at write time Several rules are checked as an object is written, as warnings, never as errors.
- Expressions parsed first Every server-side expression column is parsed with the runtime's own factory, and text that reads like SQL draws a hint. JSON configuration columns are validated against published schemas.
- Examples by intent An intent such as colouring a whole row maps to the specimens that show it, from an index shipped in the jar.
Code tools let an agent write functions and procedures. This release lets it write the application itself, under the same journal and the same gates.