Documentation menu

OwlMeans Tech Concept

On this page

An OwlMeans application has a consistent structure from its first version. That structure gives new features a clear place to live and gives coding agents a common way to understand the project.

How the pieces fit

flowchart TD
    A[User interface and forms] --> B[Application behavior]
    B --> C[Authorization and services]
    C --> D[Database and shared state]
    E[Configuration and project guidance] --> A
    E --> B
    E --> C

The interface collects input and presents results. Application behavior describes what the product does. Services handle reusable work and check authorization. The database preserves the records. Shared configuration and agent guidance keep these parts aligned.

Shared definitions keep changes coherent

Generated applications use shared definitions for requests, responses and access rules. The interface and API work from the same contract, so a feature’s fields and permissions can stay aligned. OwlMeans Common supplies reusable patterns for these definitions and the services that carry them out.

Configuration gives the app a consistent way to find its services. The agent harness describes those conventions, so a new agent can extend the existing structure without rebuilding the foundation.

Why the structure helps

  • Consistent changes: a new screen follows the same forms, service and access conventions as earlier screens.
  • Clear permissions: identity and authorization are part of the application foundation, so access rules can follow the business behavior.
  • Reusable building blocks: OwlMeans Common provides much of the shared application code. You can spend more time defining the behavior people need.
  • Agent continuity: tailored skills and project memory explain the conventions to an agent that joins later.
  • Room to grow: separate responsibilities make it easier to extend the app as new requirements arrive.

The create-app project conventions and public OwlMeans Common packages form the basis of this approach. The technology pages explain the supporting libraries by purpose.

Put it to use

  1. Describe the business result and user roles in the specification.
  2. Keep a user story focused on behavior you can demonstrate.
  3. Ask the agent to follow the existing project architecture when adding a feature.
  4. Review the screen, stored records and permissions together.
  5. Preserve the harness and memory when moving development to another agent.

For a CRM, this means a contact form, contact service and visibility rules share one definition of who may read and edit a customer record.

Application example

Category: CRM and customer management. Example: a small team CRM with contact ownership and manager access.