Generated policies

Dynamic State Machines (part)

No part may implement or own its own state machine, including fixed status options, transitions, and state-changing UI or business logic. Define default machines as seed data in stateMachines.json, listing state names in states. Define each state in the sibling stateMachines/${name}.json file. The stateMachines part owns runtime definitions, item states, and transitions, and part code must use its shared integration.

Fix

Move default machine metadata and state names to stateMachines.json, put each state and its transitions in stateMachines/${name}.json, remove hardcoded status choices and state-changing logic from the part, and use the stateMachines part for runtime state changes.

File System Hierarchy (part)

A part repository must have a top-level part file and an api directory. Without both, it is not a valid part. Every part has a database. panel, site, and localization directories are optional.

Correct examples

part
api/

part
api/
panel/
site/

Incorrect examples

part
panel/

part
site/

Fix

Add the missing API implementation if this repository is a part, or remove its part file if it is not.

No Default Parameter Values (part)

Never use default parameter values in part code. They are permitted in core code, but avoid them there whenever practical.

Role Composition (part)

Non-admin runnable APIs and panels select the existing role they need independently from each part. Declare that selection with a symbolic link named after the part inside the process directory: panels link to the part’s panel/<selectedRole> directory, and APIs link to its api/api/<selectedRole> directory. For example, a managerPanel can link accounts to accounts/panel/admin, while managerApi links accounts to accounts/api/api/admin. Reuse shared core infrastructure and the selected part code through composition; do not copy it or create a part role directory merely to match the runnable process name. The selected implementation role does not change the authenticated user’s roles or bypass API authorization.

Fix

Replace duplicated process-specific part roles with symbolic links to existing part roles, and resolve those selections in core composition infrastructure.

Route Shape (part)

Use a part-first URL hierarchy: /${part} for the part home, /${part}/${action} for part actions, and /${part}/${type}/${action} for type actions. Correct examples include /blog, /blog/findAll, /blog/post/findAll, and /orders/invoice/find. Incorrect examples include /posts, /post/findAll, /blog/post/read/findAll, and /dashboard/orders.

Correct examples

/blog

/blog/findAll

/blog/post/findAll

/orders/invoice/find

Incorrect examples

/posts

/post/findAll

/blog/post/read/findAll

/dashboard/orders

Taxonomy Ownership (part)

No part may create its own categorization or tagging system. Parts must use the taxonomy part for categories and tags unless taxonomy cannot support the requirement and cannot reasonably be extended to support it.

Fix

Use taxonomy categories, tags, and item relations. Extend taxonomy for a missing reusable capability before defining a part-specific categorization or tagging system.

Themes Dependencies (part)

A runnable whose name ends with Themes must read dependencies from its backing runnable, whose name is the same without Themes. It must not have its own common/dependencies file.

Fix

Remove the themed runnable’s common/dependencies file and resolve dependencies from the backing runnable’s common/dependencies file.