Layers And Ownership

Layered overrides resolve module paths deterministically using a rank-based ordering system. L0 firmware provides the base, L1 group customware applies intermediate overrides, and L2 user customware takes the highest precedence to determine which content wins for a given path.

Place durable source code in L0 firmware, group-level customizations in L1 directories like _all or _admin, and user-specific runtime state in L2 paths such as <username>/user.yaml. Correct placement ensures proper file readability, writability, and permission constraints.

Store new frontend modules by evaluating ownership and permission constraints across L0, L1, and L2 layers. Repository-owned assets go in L0, group customware in L1, and user-specific configurations in L2 to maintain proper read and write access controls.

Structure canonical directories using L1 paths like _all for group-wide assets and _admin for administrative metadata, while using L2 paths like <username>/user.yaml for individual user customware to ensure deterministic module resolution and proper auth-related metadata separation.

Module resolution returns incorrect content when files are misplaced across L0, L1, and L2 layers. Misunderstanding the rank-based override order or ignoring permission constraints causes readability issues, preventing the correct layer from winning the module path resolution.

Yes, understanding repository structure permissions is required before adding frontend assets. You must know who can read and write which paths across L0, L1, and L2 to prevent permission issues and ensure layered overrides behave deterministically.