new instructions

AGENTS.md

@@ -107,6 +107,7 @@ If implementation changes invalidate those docs, update them in the same change
 - Projects should be treated as a first-class future domain that anchors long-running program execution across CRM, sales, inventory, purchasing, shipping, and planning
 - Manufacturing should remain a separate future domain for work orders, routings, labor, and shop-floor execution
 - Planning should remain the scheduling/visibility layer over projects and manufacturing, not a replacement for either
+- New top-level modules added to shell navigation should ship with a matching SVG icon, not text-only nav entries
 
 ## Feature expectations
 

INSTRUCTIONS.md

@@ -31,6 +31,7 @@ This repository implements the platform foundation milestone:
 10. Purchase-order item selection must be restricted to inventory items where `isPurchasable = true`.
 11. Treat future `Projects` work as a first-class cross-module domain tying together CRM, sales, inventory, purchasing, shipping, and planning; do not bury it as a one-off manufacturing subfeature.
 12. Keep `Projects`, `Manufacturing`, and `Planning` distinct: projects are long-running program records, manufacturing is execution, and planning is scheduling/visibility.
+13. New top-level modules added to the app shell should include a matching SVG icon in navigation so the module list remains visually scannable.
 
 ## Operational notes
 

README.md

@@ -59,6 +59,12 @@ Dashboard direction:
 - richer recent-activity widgets and exception queues are a planned QOL follow-up, not a separate landing-page redesign
 - projects should eventually feed dashboard widgets for active jobs, overdue milestones, shortages, and shipment readiness
 
+Navigation direction:
+
+- module navigation now uses inline SVG icons alongside labels
+- new modules should add a clear, domain-appropriate SVG icon when they are added to the shell
+- icons should stay lightweight, theme-aware, and dependency-free unless there is a strong reason to introduce a shared icon package
+
 ## Projects Direction
 
 Projects should become the long-running program and delivery layer tying together commercial work, engineering context, purchasing, manufacturing, shipping, and customer-facing execution.

STRUCTURE.md

@@ -25,6 +25,7 @@
 - Treat `projects` as its own long-lived domain under both client and server when implemented; it should integrate with CRM, sales, inventory, purchasing, shipping, and planning rather than living inside only one of those modules.
 - Treat `manufacturing` as a separate long-lived domain from `projects`; work orders, routings, labor capture, WIP, and shop-floor execution should not be modeled only as project fields.
 - Treat `planning` as the scheduling/visibility layer that consumes project and manufacturing data rather than replacing either domain.
+- When adding a new top-level module to the shell, add a lightweight SVG icon in the navigation config so desktop and mobile nav stay aligned.
 
 ## Backend rules