Foundations
How the framework works
The technical systems a developer builds on. Each is where a large part of Wildo's leverage sits: something is declared once and much is derived. These pages are deep on purpose and written for developers; the plain-language account is ../what-wildo-is.md.
Seven foundations
- Change the presentation without losing the contract — A screen should be able to ask for a familiar control without owning its implementation. Wildo’s component system separates that request from the registered component that renders it.
- Define your business objects once, propagate everywhere — <p class="story-subtitle"> <span>> From database fields to form validation</span> <span>> From field specifications to display policies</span> <span>> From operations to API endpoints</span> </p>
- Describe the product and the meaning of its code — A specification records what the application is meant to do and what its parts mean. It gives developers and coding agents something more explicit than a collection of implementation files.
- Flows and actors — Flows and actors is the part of Wildo that runs AI agents and multi-step work inside an application, and shows that work to the people using it.
- Make movement a product decision — The same action should feel familiar wherever a person encounters it. Opening a record, working beside a list and returning from an edit should follow an intentional pattern.
- Templates and composition — Every piece of a Wildo application starts from a template, and every template knows where its output belongs. A new application is rendered from a skeleton;
- The backend runtime — A Wildo application does not write a server. It writes declarations (resources, roles, custom operations, batches, email templates, charts, agents) and hands them to the backend runtime, @wildo-ai/saas-backend-lib, which boots a complete…