jason/mrp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

new instructions

Browse Source
This commit is contained in:
jason
2026-03-15 01:17:07 -05:00
parent 4c4db687e0
commit 5a1164f497
4 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
AGENTS.md
View File

@@ -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 - 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 - 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 - 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 ## Feature expectations

1
INSTRUCTIONS.md
View File

@@ -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`. 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. 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. 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 ## Operational notes

6
README.md
View File

@@ -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 - 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 - 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 Direction
Projects should become the long-running program and delivery layer tying together commercial work, engineering context, purchasing, manufacturing, shipping, and customer-facing execution. Projects should become the long-running program and delivery layer tying together commercial work, engineering context, purchasing, manufacturing, shipping, and customer-facing execution.

1
STRUCTURE.md
View File

@@ -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 `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 `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. - 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 ## Backend rules