diff --git a/CHANGELOG.md b/CHANGELOG.md index 2f6d14b..0a30433 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,6 +23,9 @@ This file is the running release and change log for CODEXIUM. Keep it updated wh - Work-order `On Hold` quick status changes now require a recorded hold reason and persist the active blocker on the work-order record and audit trail - Project milestone cards now support inline quick status actions for start, block, complete, reset, and reopen flows directly from the project detail view - Project milestones with status, due dates, notes, and edit-time sequencing inside the project workflow +- UI density standardization pass across app shell, dashboard, finance, project detail, manufacturing detail, and admin surfaces, including tighter panel spacing, more compact shell/navigation spacing, and removal of redundant explanatory subcopy in favor of concise uppercase section labels +- Continued density standardization across CRM, inventory, sales, purchasing, and shipping list/detail surfaces so module headers, filter bars, and status panels follow the same tighter uppercase operational pattern +- Continued density standardization across CRM, sales, purchasing, shipping, manufacturing, and project form/detail headers so editor and record surfaces now follow the same compact uppercase pattern with less redundant helper copy - Project-side milestone and work-order rollups surfaced on project list and detail pages - Inventory SKU master builder with family-level sequence codes, branch-aware taxonomy management, and generated SKU previews on the item form - Thumbnail image attachment staging on inventory item create/edit pages, with upload-on-save and replacement/removal support diff --git a/INSTRUCTIONS.md b/INSTRUCTIONS.md index c4e7711..8ac02c0 100644 --- a/INSTRUCTIONS.md +++ b/INSTRUCTIONS.md @@ -55,11 +55,13 @@ This repository implements the platform foundation milestone: 6. Any non-filter UI that looks up records or items must use a searchable picker/autocomplete, not a long static dropdown. 7. Inventory items must carry both `defaultCost` and `defaultPrice`; sales documents should default line pricing from the selected item `defaultPrice`. 8. Maintain the denser UI baseline on active screens; avoid reintroducing oversized `px-4 py-3` style controls, tall action bars, or overly loose card spacing without a specific reason. -9. Treat the landing page as `Dashboard`: a metric-oriented, modular command surface that should accumulate reusable operational panels over time. -10. Purchase-order item selection must be restricted to inventory items where `isPurchasable = true`. -11. Treat `Projects` 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. +9. Prefer concise uppercase module and section labels in the live interface, and avoid redundant descriptive subcopy when the surrounding data already makes the purpose clear. +10. When designing operational pages, bias toward information density: tighter panel padding, smaller stack gaps, and fewer explanatory filler blocks. +11. Treat the landing page as `Dashboard`: a metric-oriented, modular command surface that should accumulate reusable operational panels over time. +12. Purchase-order item selection must be restricted to inventory items where `isPurchasable = true`. +13. Treat `Projects` 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. +14. Keep `Projects`, `Manufacturing`, and `Planning` distinct: projects are long-running program records, manufacturing is execution, and planning is scheduling/visibility. +15. 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 diff --git a/README.md b/README.md index cb4fed4..3afc086 100644 --- a/README.md +++ b/README.md @@ -89,6 +89,8 @@ 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 +- active operational screens should default to a denser layout baseline with tighter card padding, smaller inter-panel gaps, and less decorative negative space +- module headers and section labels should prefer uppercase naming and concise operational wording instead of redundant explanatory subcopy inside the working interface ## Finance Direction diff --git a/client/src/components/AppShell.tsx b/client/src/components/AppShell.tsx index f16e445..ccb446a 100644 --- a/client/src/components/AppShell.tsx +++ b/client/src/components/AppShell.tsx @@ -200,19 +200,19 @@ export function AppShell() { const { user, logout } = useAuth(); return ( -
-
-