Packages, manifests and applications

Documentation status: reference — see Maturity and evidence.

Packages

A package is the deployment and loading unit for a group of model resources. It should make model roots, view paths, services and reusable assets explicit rather than relying on implicit search paths.

Class manifests

A class manifest is an allow-list. It prevents stale or experimental files from becoming part of a running application simply because they are present in a directory.

A manifest entry needs stable conceptual identity. Use one meaning -> one stable classId. Reuse the same identifier only when the model intentionally represents the same conceptual identity or an explicit supported redefinition mechanism.

Example shape:

package:
  plugginCaption: TaskManagement
  uri: http://www.logicells.net/package/TaskManagement
  classes:
    - Task:
        classId: app#task
        type: Entity
    - Project:
        classId: app#project
        type: Entity
    - TaskBelongsToProject:
        classId: app#task_belongs_to_project
        type: Relation

Applications

The application configuration answers one operational question: which runtime resources are assembled to make this conceptual application executable?

Keep environment-specific concerns there: database aliases, paths, enabled packages, service groups, ports, resources and runtime options. Prefer a memory configuration for first-load diagnosis and a persistent configuration for production-like validation.

Validation sequence

1. Application file is found and accepted.
2. Intended package is enabled.
3. Package resolves its model root.
4. Manifest is found and compiled.
5. Model file is found and compiled.
6. classId resolves to the intended runtime concept.
7. Conceptual initialization completes without duplicate-identity errors.

Cross-folder manifest references should be explicit architecture decisions, not invisible convenience.