The Core Application Framework is the foundation every Tom application is built on: a Flutter client and a Dart server joined by a typed interface, both resting on a shared kernel. It is one of the seven building blocks of the framework, and the one that defines what a "Tom application" is.

Its defining promise is uniformity by construction. Tom Core guarantees — for every app, regardless of how that app's business logic was written or generated — a resource-driven configurable UI, full and uniform internationalization, uniform authentication, a uniform (now four-state, per-resource) authorization system, one architecture, and uniform deployment, operations, and provisioning. These cross- cutting features live in Core, so they are present in every Tom app automatically; the application creation flow only generates business logic on top of them.

The shape of a Tom application

        client app (Flutter)            server app (Dart / Shelf)
                │                                  │
          tom_core_flutter                   tom_core_server
                └──────────────┬──────────────────┘
                        tom_core_kernel
                          tom_basics

• The client is a Flutter app built on tom_core_flutter.
• The server is a Dart/Shelf server built on tom_core_server, reaching

external services and an application-owned relational (MySQL/MariaDB) database over a pluggable datasource layer. - A typed interface is the client⇄server contract between them. - Both halves rest on a shared tom_core_kernel and the tom_basics utility floor.

The components and modules

The area is delivered by the Core component (core) and its modules.

The layered base

• tom_core_kernel — the platform-independent base shared by client and

server: dependency injection / bean locator, the observable/reactive system, security, logging, isolate pooling, settings, JSON, timezone handling, and the reflection glue that turns generated reflection data into runtime wiring. - tom_core_server — the Dart/Shelf server foundation: authentication, authorization, data sources, database migration, endpoints, transactions, object persistence, caching, and health checks. - tom_core_flutter — the Flutter client foundation: resource-driven UI, forms, the observing/runtime layer, and client-side security.

The UI library

• tom_flutter_ui — the resource-driven widget and form library: the widgets,

form authorizers, theming, groups, and actions that make a Tom UI configurable from resources rather than hard-coded. - tom_flutter_form_test / tom_flutter_ui_test — the demonstration and test apps that exercise the forms and widgets.

Bridging and agentic glue

• tom_core_agentic — domain-free, dart:io-free agentic infrastructure:

cooperative cancellation, a use-after-close guard, category logging, async shutdown coordination, and typed YAML config read/write. Its lightweight tier (it depends only on tom_basics) is what lets even dart:io-forbidding packages build on it, which is why Tom Brain shares it. (The brain-specific BrainEventBus lives in tom_brain_shared, not here.) - tom_core_d4rt — the D4rt scripting tool with full Tom-framework bridge support: a REPL (d4rt) and headless script runner that registers generated bridges for a dozen Tom packages (kernel, server, build, distributed, and document toolkits), so sandboxed DartScript can call straight into the framework. - tom_core_bridge — an extended VS Code bridge server binary (core_bs): the base tom_bs from tom_vscode_bridge plus the complete Tom-framework D4rt bridge set that tom_core_d4rt registers, so editor scripts can drive a running app's core, server, and build APIs.

How it fits the rest of Tom

Core is the destination of the application creation flow and the host of the agentic line. The Software Factory produces business logic that targets Core's contracts; the implementation phase fills in the CodeSpec against tom_core_server and tom_core_flutter. Reflection (tom_reflection, via the kernel's reflection glue) is what lets an application assemble itself from resources at runtime. And in the agentic variant, the server can expose tom_brain as an external service whose generated agent surfaces run inside the Core-based Flutter client through tom_d4rt_flutter.

The two companion applications — tom_uam (users & authorization) and tom_sqm (subscriptions & quota) — are themselves built on Core, serving double duty as production apps and as canonical samples of how to build on the framework.

> Maturity note. Tom Core is functionally feature-complete — a skeletal app has > already run on it end-to-end. The remaining work is documentation, tests, a > code-cleanliness refactor, and targeted hardening (notably routing the four-state > authorization through all security code and ensuring the data-access layer always > uses prepared statements).