frontend/src/shared/components/SectionHeading.tsx (1)

17-17: Prefer shrink-0 over flex-shrink-0 for Tailwind v4.

In Tailwind CSS v4, flex-shrink-* utilities were renamed to shrink-*. The legacy name may still resolve, but the idiomatic v4 class is shrink-0.

♻️ Proposed change

-      {action && <div className="flex-shrink-0">{action}</div>}
+      {action && <div className="shrink-0">{action}</div>}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/shared/components/SectionHeading.tsx` at line 17, The JSX in the
SectionHeading component uses the legacy Tailwind utility "flex-shrink-0" on the
action wrapper ({action && <div className="flex-shrink-0">{action}</div>});
update that class to the Tailwind v4 idiomatic "shrink-0" so the action
container uses the new utility name (change the className on the action div in
SectionHeading.tsx).

backend/OrderSystemApi/OrderSystemApi/OrderSystem.Api.csproj (1)

10-10: Verify the intended use case for Bogus in the API project.

The Bogus library is typically used for generating fake/test data and is commonly added to test projects rather than production API projects. Adding it here raises questions:

• If used for development/testing only: Consider moving this dependency to a separate test project or seeder tool to keep the production API lean.
• If used for production data seeding: Ensure this is intentional and that Bogus data generation is properly isolated to startup/migration scenarios, not active request handling.

Adding development/test dependencies to the main API increases bundle size and production surface area unnecessarily.

📦 Alternative approaches for test data generation

Option 1: Move to a separate test or seeder project:

• Create OrderSystem.DataSeeder project
• Reference Bogus only there
• Run as a separate tool or startup configuration

Option 2: Use conditional compilation if seeding is needed:

-    <PackageReference Include="Bogus" Version="35.6.5" />
+    <PackageReference Include="Bogus" Version="35.6.5" Condition="'$(Configuration)' == 'Debug'" />

This ensures Bogus is only included in development builds.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@backend/OrderSystemApi/OrderSystemApi/OrderSystem.Api.csproj` at line 10, The
csproj currently references the Bogus package via PackageReference
Include="Bogus", which is intended for test/data seeding rather than runtime API
usage; remove this PackageReference from the API project and either (A) move
Bogus into a dedicated seeder/test project (e.g., create OrderSystem.DataSeeder
and add Bogus there) and perform seeding from that tool, or (B) if you must keep
it in the repo, limit inclusion to non-production builds by adding Bogus only to
a test/seeder project or use conditional inclusion so Bogus is only
referenced/used during startup seeding paths and never in active request
handling (also audit any code in Startup/Program that references Bogus to ensure
it’s isolated to development/seeding flows).

frontend/src/shared/components/PageContainer.tsx (1)

1-1: Consider using a type-only import for ReactNode.

ReactNode is used only as a type in the interface. While your project has verbatimModuleSyntax disabled in tsconfig.app.json, using import type is still a best practice for clarity and future-proofs the code should configs change.

Suggested improvement

-import { ReactNode } from 'react';
+import type { ReactNode } from 'react';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/shared/components/PageContainer.tsx` at line 1, The import for
ReactNode in PageContainer.tsx is only used as a type; change it to a type-only
import to make the intent explicit and future-proof the file: replace the
current import of ReactNode with a type import (import type { ReactNode } from
'react') so the symbol is only retained for type-checking and not as a runtime
import; ensure any other uses in the file still reference the ReactNode type in
the component props/interface.

backend/OrderSystemApi/OrderSystem.Application/Products/Interfaces/IProductRepository.cs (1)

22-22: Thread cancellation through the bulk update contract.

UpdateBulk can persist many products, but it cannot observe request cancellation while the read methods above can. Consider adding a CancellationToken while this API is new.

♻️ Proposed contract adjustment

-        Task<bool> UpdateBulk(IEnumerable<Product> products);
+        Task<bool> UpdateBulk(IEnumerable<Product> products, CancellationToken ct);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Application/Products/Interfaces/IProductRepository.cs`
at line 22, The UpdateBulk contract lacks cancellation support—change the
IProductRepository.UpdateBulk signature to accept a CancellationToken (e.g.,
Task<bool> UpdateBulk(IEnumerable<Product> products, CancellationToken
cancellationToken)) and update all implementations and call sites to pass the
token through (propagate token from controller/service entry points and honor it
in any loops/async operations inside implementations such as repository classes
that perform DB or batch work), and ensure cancellations are observed (throw
OperationCanceledException or return early) where appropriate.

backend/OrderSystemApi/OrderSystemApi/Program.cs (1)

166-170: CORS: consider reading allowed origins from configuration.

Origins are hardcoded to localhost dev ports, which will need a code change for staging/prod. Moving them to appsettings (or env vars) avoids a code edit per environment and reduces the chance of deploying a dev-only CORS policy. Non-blocking.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@backend/OrderSystemApi/OrderSystemApi/Program.cs` around lines 166 - 170, The
app.UseCors call currently hardcodes origins; change it to read allowed origins
from configuration instead: add a configuration key (e.g. "Cors:AllowedOrigins")
in appsettings or an env var, load it via the IConfiguration instance in
Program.cs, parse into a string[] (or split a comma-separated env var) and pass
that array to builder.WithOrigins(...) in the existing app.UseCors block
(referencing the same app.UseCors builder lambda); keep
AllowAnyHeader/AllowAnyMethod/AllowCredentials as-is and validate the config
value for null/empty before applying.

frontend/src/modules/manager/api/products.api.ts (1)

51-62: Optional: type the POST response.

http.post is invoked without a generic, so data is inferred as any and addProductImage returns Promise<any>. Consider specifying a response type (e.g. { id: number } or a ProductImage DTO) for safer consumers.

Proposed tweak

-  const { data } = await http.post(
+  const { data } = await http.post<{ id: number }>(
     `/api/v1/manager/products/${payload.productId}/images`,
     { imageUrl, altText, sortOrder, isPrimary }
   );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/manager/api/products.api.ts` around lines 51 - 62, The
addProductImage function currently returns Promise<any> because http.post is
called without a generic; update addProductImage to declare and return a
concrete response type (for example a small DTO like ProductImage or { id:
number }) and pass that type as the generic to http.post so TypeScript infers
data correctly; update the function signature (addProductImage(payload:
CreateProductImageRequest): Promise<YourResponseType>) and adjust any callers if
needed. Ensure the change is applied in the addProductImage implementation that
constructs the POST to `/api/v1/manager/products/${payload.productId}/images`
(no change needed for deleteProductImage).

backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/20260418180805_AddSystemNotification.cs (1)

14-31: Consider indexing unread/recent notification access.

If the new notification endpoints query unread items and recent activity, this table will scan as it grows. Add an index that matches the read-status/recent-sort access pattern.

Possible migration addition

                 constraints: table =>
                 {
                     table.PrimaryKey("PK_system_notifications", x => x.Id);
                 });
+
+            migrationBuilder.CreateIndex(
+                name: "IX_system_notifications_IsRead_CreatedAt",
+                table: "system_notifications",
+                columns: new[] { "IsRead", "CreatedAt" });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/20260418180805_AddSystemNotification.cs`
around lines 14 - 31, Add a composite index to speed unread/recent queries by
calling migrationBuilder.CreateIndex after the CreateTable for
"system_notifications"; create an index named like
"IX_system_notifications_IsRead_CreatedAt" on the columns IsRead and CreatedAt
(e.g., columns: new[] { "IsRead", "CreatedAt" }) so queries filtering IsRead and
ordering by CreatedAt will use the index.

backend/OrderSystemApi/OrderSystem.Infrastructure/Data/Configurations/SystemNotificationConfiguration.cs (1)

14-37: Consider adding indexes for common notification query patterns.

Admin notification listings typically filter/sort by fields like IsRead, NotificationType, or CreatedAt. If the repository queries on these, adding indexes here (e.g., builder.HasIndex(x => x.CreatedAt), builder.HasIndex(x => new { x.IsRead, x.CreatedAt })) will prevent full table scans as the table grows.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Data/Configurations/SystemNotificationConfiguration.cs`
around lines 14 - 37, Add indexes on the SystemNotification entity to support
common query patterns: update the Configure method in
SystemNotificationConfiguration to add builder.HasIndex(x => x.CreatedAt),
builder.HasIndex(x => x.NotificationType), and a composite index
builder.HasIndex(x => new { x.IsRead, x.CreatedAt }) so queries that filter/sort
by CreatedAt, NotificationType, or IsRead+CreatedAt use indexes instead of full
table scans; ensure these index calls are placed after the Property(...)
declarations in the Configure(EntityTypeBuilder<SystemNotification> builder)
method.

frontend/src/modules/customer/pages/CustomerOrdersListPage.tsx (1)

54-77: Dead emptyMessage prop now that empty state is handled via early return.

Since the component early-returns the EmptyState whenever !isLoading && data.items.length === 0, the AppTable's emptyMessage branch is unreachable. Either drop the prop for clarity, or (preferred) consolidate and let AppTable render the shared EmptyState so loading→empty transitions stay inside one render path without an extra unmount/remount of PageHeader.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/customer/pages/CustomerOrdersListPage.tsx` around lines
54 - 77, The early-return in CustomerOrdersListPage that renders EmptyState
makes the AppTable.emptyMessage branch dead; remove the early return and instead
let AppTable handle empty rendering so PageHeader stays mounted across
loading→empty transitions, or if you prefer to keep the early-return, remove the
unused emptyMessage prop from the AppTable call; to implement the preferred
consolidation, keep PageHeader rendered, pass either the EmptyState component or
the t.orders.noOrders/noOrdersDesc strings into AppTable (via emptyMessage or an
emptyComponent prop), and rely on AppTable to check isLoading and
data?.items.length to render the same EmptyState UI.

backend/OrderSystemApi/OrderSystem.Application/Products/Interfaces/IProductService.cs (1)

18-19: Document the percentageChange unit and consider bounds.

percentageChange as decimal is ambiguous — callers can't tell whether 10 means +10% or +1000% (i.e., 0.10). Please clarify via XML docs on the interface (and enforce the contract in the implementation, e.g., reject values that would make prices non-positive, and cap the allowed range to avoid catastrophic bulk mutations from an admin typo).

Suggested doc

+        /// <summary>
+        /// Applies a percentage change to the price of the specified products.
+        /// </summary>
+        /// <param name="percentageChange">Percentage expressed as a whole number, e.g. 10 = +10%, -5 = -5%.</param>
         Task<int> BulkUpdatePriceAsync(List<long> productIds, decimal percentageChange, CancellationToken ct);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Application/Products/Interfaces/IProductService.cs`
around lines 18 - 19, Add XML documentation to
IProductService.BulkUpdatePriceAsync clarifying that percentageChange is a
fractional multiplier (e.g., 0.10 = +10%, -0.10 = -10%) and whether the method
applies price = price * (1 + percentageChange). In the implementing class for
BulkUpdatePriceAsync validate percentageChange against safe bounds (e.g.,
disallow values that would make any resulting price non-positive and cap extreme
inputs to a configured range such as [-0.9, 1.0] or similar), and throw
ArgumentOutOfRangeException (or return a clear error) when the argument is
outside policy; also explicitly handle/validate each product’s computed new
price before persisting to avoid catastrophic bulk mutations.

frontend/src/app/i18n/i18n-context.tsx (1)

35-38: Wrap localStorage.setItem in try/catch for consistency.

getSavedLocale already guards against storage errors (Safari private mode, quota, disabled cookies), but setLocale doesn't. If setItem throws, the user's locale flip will fail loudly even though the in-memory state updated successfully. Match the defensive pattern used above.

   const setLocale = useCallback((newLocale: Locale) => {
     setLocaleState(newLocale);
-    localStorage.setItem(LOCALE_STORAGE_KEY, newLocale);
+    try {
+      localStorage.setItem(LOCALE_STORAGE_KEY, newLocale);
+    } catch {
+      // Ignored — in-memory state still reflects the change
+    }
   }, []);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/app/i18n/i18n-context.tsx` around lines 35 - 38, The setLocale
callback currently calls localStorage.setItem without guarding against storage
errors; update the setLocale function (which calls setLocaleState and uses
LOCALE_STORAGE_KEY) to wrap the localStorage.setItem(LOCALE_STORAGE_KEY,
newLocale) call in a try/catch so failures (e.g., Safari private mode) don't
throw; ensure you still call setLocaleState(newLocale) before/around the try and
handle the catch by logging or silently ignoring to match the defensive pattern
used by getSavedLocale.

frontend/src/layouts/ManagerLayout.tsx (1)

29-79: Avoid redeclaring SidebarContent on every render.

Defining SidebarContent inside ManagerLayout means React sees a brand-new component type on every parent render. Every state update (e.g., toggling sidebarOpen, auth/i18n context changes) forces the sidebar subtree to unmount and remount, discarding any internal state inside LanguageSwitcher or future children (focus, uncontrolled input values, etc.). Extract it as a sibling component, or inline the JSX into a const sidebarContent = (...) expression so it isn't a new component identity on each render.

♻️ Suggested minimal refactor

-  const SidebarContent = () => (
-    <>
+  const sidebarContent = (
+    <>
       ...
-    </>
-  );
+    </>
+  );
@@
-        <SidebarContent />
+        {sidebarContent}
@@
-            <SidebarContent />
+            {sidebarContent}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/layouts/ManagerLayout.tsx` around lines 29 - 79, SidebarContent
is declared as a component inside ManagerLayout which creates a new component
type on each render causing unmount/remount of its subtree (affecting
LanguageSwitcher and other internal state); move SidebarContent out of the
ManagerLayout function (make it a sibling/top-level component) or replace it
with a const sidebarContent = ( ... ) JSX value so its identity is stable, and
pass in any needed props/state (user, navLinks, location, setSidebarOpen,
handleLogout, t) to the extracted component instead of capturing them from
closure.

frontend/src/modules/catalog/pages/ProductsListPage.tsx (1)

31-39: Search is debounced-free; consider debouncing before writing to the URL.

setSearch runs on every keystroke and writes to the URL + triggers a new query. Even with replace: true, this spams react-router updates and upstream API calls. A small debounce (e.g., 300 ms) on the URL write — while keeping the input value in local state — would reduce churn without changing behavior on submit.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/catalog/pages/ProductsListPage.tsx` around lines 31 -
39, setSearch currently writes to URL on every keystroke causing excessive
router updates and queries; debounce the URL write while keeping the immediate
input in local state. Change the component (ProductsListPage) to store the raw
input in a local state (e.g., searchInput) updated on every keystroke, and
debounce the call that calls setSearchParams (the inner updater that
sets/deletes 'search' and deletes 'page') by ~300ms using a stable debounced
function or a timeout stored in a ref; ensure you still call setSearchParams
with { replace: true } and clear the timeout on unmount to avoid leaks. Use the
existing setSearchParams/setSearch logic as the target for the debounced
invocation so behavior on form submit can still immediately sync the URL.

backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/20260418174733_AddSystemActivityLog.cs (1)

38-41: Consider additional indexes for common activity-log queries.

Activity logs are typically queried by timestamp (descending for recency) and by entity_type+entity_id (to show history for a given entity). As the table grows, the single user_id index may not be sufficient. A follow-up migration adding e.g. IX_system_activity_logs_timestamp and a composite IX_system_activity_logs_entity_type_entity_id would help once usage patterns are clear.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/20260418174733_AddSystemActivityLog.cs`
around lines 38 - 41, Add additional indexes to the migration to support common
queries: create an index on the timestamp column (e.g., index name
"IX_system_activity_logs_timestamp" and consider a descending order for recency
if your EF/DB supports it) and create a composite index on entity_type +
entity_id (e.g., "IX_system_activity_logs_entity_type_entity_id"); update the
AddSystemActivityLog migration by adding two migrationBuilder.CreateIndex calls
(matching the existing migrationBuilder.CreateIndex usage for
"IX_system_activity_logs_user_id") to create these indexes so queries filtering
by timestamp or by entity_type/entity_id are optimized.

frontend/src/modules/auth/pages/LoginPage.tsx (1)

2-2: Consider using type-only import for Path from react-hook-form.

Path is only used as a type (line 39: key as Path<LoginForm>). While not strictly required with the current configuration (verbatimModuleSyntax: false), using a type-only import improves clarity:

Suggested change

-import { useForm, Path } from 'react-hook-form';
+import { useForm } from 'react-hook-form';
+import type { Path } from 'react-hook-form';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/auth/pages/LoginPage.tsx` at line 2, The import
currently brings in Path from 'react-hook-form' as a value import; change it to
a type-only import so Path is imported only for types (leave useForm as a normal
import). Update the top-level import that references Path to a type import and
keep the runtime import for useForm unchanged; this affects the statement that
casts keys with "key as Path<LoginForm>" and ensures Path is erased at runtime.

backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/ApplicationDbContextModelSnapshot.cs (1)

502-510: Add an index for recent activity-log reads.

The activity API returns recent logs and supports filters, but only PerformedByUserId is indexed. Add an index such as Timestamp descending, or composite indexes aligned with entityType/userId + Timestamp, in the source EF configuration and regenerate the migration.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/ApplicationDbContextModelSnapshot.cs`
around lines 502 - 510, The snapshot shows only an index on PerformedByUserId;
update the EF Core entity configuration for the SystemActivityLog entity (e.g.,
in the EntityTypeBuilder for SystemActivityLog inside OnModelCreating or the
SystemActivityLogConfiguration class) to add an index on the Timestamp property
(preferably as descending) and/or a composite index such as (EntityType,
PerformedByUserId, Timestamp) to support recent reads and common filters, using
HasIndex(...).Then regenerate the migration so the
ApplicationDbContextModelSnapshot and migration files include the new index
definitions and apply the migration.

backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/ActivityLogRepository.cs (1)

21-54: Repository eagerly commits, and count is unbounded.

• AddAsync calls SaveChangesAsync internally. If the caller is part of a larger unit of work (e.g., status change + activity log from OrderService.MarkReadyAsync), the log is persisted even if subsequent operations fail — or, conversely, the caller's prior un-flushed changes get flushed alongside the log. Consider letting the caller own SaveChangesAsync so the log row participates in the same transaction as the action it describes.
• GetRecentLogsAsync(int count, …) does not validate/cap count. A large or negative value will either thrash the DB or (for negatives) produce an EF runtime error. Clamp, e.g., count = Math.Clamp(count, 1, 500);.

♻️ Suggested fix for the count bound

         public async Task<IEnumerable<SystemActivityLog>> GetRecentLogsAsync(int count, string? entityType = null, long? userId = null, CancellationToken cancellationToken = default)
         {
+            if (count <= 0) count = 50;
+            count = System.Math.Min(count, 500);
             var query = _context.SystemActivityLogs

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/ActivityLogRepository.cs`
around lines 21 - 54, The AddAsync method currently calls
_context.SaveChangesAsync causing eager commits; change
AddAsync(SystemActivityLog log, ...) to only call
_context.SystemActivityLogs.AddAsync(log, cancellationToken) and remove the
SaveChangesAsync call so callers control transaction/commit (e.g.,
OrderService.MarkReadyAsync can flush once). In GetRecentLogsAsync(int count,
...) validate and clamp count (e.g., count = Math.Clamp(count, 1, 500)) before
applying Take(count) to prevent negative or excessive values; keep existing
filtering and ordering logic intact.

backend/OrderSystemApi/OrderSystem.Application/Admin/Interfaces/ISystemNotificationRepository.cs (1)

14-14: UpdateAsync missing CancellationToken — inconsistent with the rest of the interface.

Every other method on ISystemNotificationRepository accepts a CancellationToken ct. Add one here too for API consistency and to allow cancellation to flow through the service/controller layers.

-        Task<bool> UpdateAsync(SystemNotification notification);
+        Task<bool> UpdateAsync(SystemNotification notification, CancellationToken ct);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Application/Admin/Interfaces/ISystemNotificationRepository.cs`
at line 14, The UpdateAsync method on ISystemNotificationRepository is missing a
CancellationToken parameter; update its signature to Task<bool>
UpdateAsync(SystemNotification notification, CancellationToken ct) so it matches
the other methods and allows cancellation to flow; ensure you update any
implementations of ISystemNotificationRepository (classes implementing
UpdateAsync) and any call sites (service/controller layers) to pass the
CancellationToken through.

frontend/src/modules/admin/pages/RevenueReportPage.tsx (1)

60-82: Currency formatting & CSV button/headers bypass i18n and hardcode USD.

• `$${row.amount.toFixed(2)}`, `$${d.totalRevenue.toFixed(2)}`, etc., hardcode the $ symbol. The codebase already uses PriceText (used in CartPage) for consistent currency rendering — prefer that so locale/currency changes stay centralized.
• Export CSV button label and the CSV headers ['Date', 'Orders', 'Revenue'] are not translated. At minimum translate the button label; the CSV headers can stay English if that's a deliberate "machine-readable export" choice, but document it.
• Minor: exporting raw row.date into CSV (line 73) while displaying it via formatDate(..., dateLocale) means CSV and UI diverge — consider exporting the formatted string if the CSV is intended for end-users.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/admin/pages/RevenueReportPage.tsx` around lines 60 - 82,
Replace hardcoded USD symbols and raw date export: use the existing PriceText
component to render amounts (replace references to row.amount and d.totalRevenue
in the table and header export) so currency formatting follows app
locale/currency; for CSV export, pass the same formatted date string (use
formatDate(date, dateLocale) or the same formatting helper used in the UI)
instead of raw r.date. Also make the export button label translatable (use
t.admin.exportCsv or appropriate i18n key) and document that CSV headers
['Date','Orders','Revenue'] are intentionally kept machine-readable if that is
desired; update downloadCSV usage in the Export button click handler
accordingly.

frontend/src/modules/cart/pages/CartPage.tsx (1)

19-19: Avoid any for CartItemRow props.

The updateItem, deleteItem, and t props are typed as any, which defeats TS checking in an otherwise typed component. Prefer the actual mutate signatures returned by the hooks and the t type exported from the i18n context.

♻️ Suggested typing

-function CartItemRow({ item, updateItem, deleteItem, t }: { item: CartItem; updateItem: any; deleteItem: any; t: any }) {
+type UpdateItemFn = (vars: { itemId: number; quantity: number }) => void;
+type DeleteItemFn = (itemId: number) => void;
+
+function CartItemRow({ item, updateItem, deleteItem, t }: {
+  item: CartItem;
+  updateItem: UpdateItemFn;
+  deleteItem: DeleteItemFn;
+  t: ReturnType<typeof useI18n>['t'];
+}) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/cart/pages/CartPage.tsx` at line 19, CartItemRow
currently uses `any` for updateItem, deleteItem, and t which loses type safety;
replace those `any` types with the actual mutate function signatures from your
cart hooks and the i18n T-function type. Concretely, change the prop types on
function CartItemRow to use the mutate types returned by your hooks (e.g. the
`mutate`/`mutateAsync` type from your useUpdateCartItem / useDeleteCartItem
hooks or React Query/SWR MutateFunction return types) and import the i18n
TFunction (or the `T`/`TFunction` type exported by your i18n setup) for `t`;
keep CartItem as the item type. This ensures updateItem/deleteItem match the
real hook signatures (mutate/mutateAsync) and `t` uses the i18n TFunction.

backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/SystemSettingsRepository.cs (1)

31-52: Remove redundant .Update() call and document null description semantics.

• _context.SystemSettings.Update(existing) is unnecessary — existing is already tracked after FirstOrDefaultAsync, so EF change tracking will pick up property mutations. Calling Update marks all properties as modified, which can bloat the generated UPDATE statement.
• if (description != null) existing.Description = description; silently preserves the existing description when callers pass null. If this partial-update behavior is intentional, document it; otherwise, callers have no way to clear a description via this upsert.

♻️ Proposed tweak

         if (existing != null)
         {
             existing.Value = value;
             if (description != null) existing.Description = description;
             existing.UpdatedAt = DateTime.UtcNow;
-            _context.SystemSettings.Update(existing);
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/SystemSettingsRepository.cs`
around lines 31 - 52, Remove the unnecessary
_context.SystemSettings.Update(existing) call in
SystemSettingsRepository.UpsertAsync (existing is already tracked after
FirstOrDefaultAsync) and add documentation on the UpsertAsync method explaining
that passing description == null preserves the current Description (i.e., null
means "do not modify"); if clearing the description should be supported instead,
adjust the method contract (e.g., use an explicit flag or sentinel) before
changing behavior.

frontend/src/modules/customer/pages/CheckoutPage.tsx (1)

26-34: Migrate from deprecated message to error parameter in Zod 4.

In Zod 4, the message option on z.nativeEnum() (and other schema methods) is still honored for backward compatibility, but has been deprecated in favor of the unified error parameter. While the current code works, migrating to error is recommended for future compatibility. The same pattern should be updated in RegisterPage.tsx and InventoryManagePage.tsx.

Proposed change

-    paymentMethod: z.preprocess(
-      (val) => Number(val),
-      z.nativeEnum(PaymentMethod, {
-        message: t.validation?.required || 'Payment method is required'
-      })
-    ),
+    paymentMethod: z.preprocess(
+      (val) => Number(val),
+      z.nativeEnum(PaymentMethod, {
+        error: t.validation?.required || 'Payment method is required',
+      }),
+    ),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/customer/pages/CheckoutPage.tsx` around lines 26 - 34,
Update the Zod nativeEnum option to use the new unified error parameter: in the
checkoutSchema where z.nativeEnum(PaymentMethod, { message: ... }) is used,
replace the deprecated message option with error: { message:
t.validation?.required || 'Payment method is required' }; apply the same change
for the other occurrences referenced (e.g., RegisterPage.tsx and
InventoryManagePage.tsx) so all z.nativeEnum calls use error: { message: ... }
instead of message.

frontend/src/modules/customer/pages/RegisterPage.tsx (1)

18-42: All validation keys are defined in both locales; consider consistent safe fallbacks.

The referenced validation messages (minLength, required, invalidEmail, passwordStrength, passwordNoMatch) all exist in both en.ts and ar.ts. However, the as string casts suppress type awareness at compile time. For consistency across the codebase, adopt the safer pattern already used in CheckoutPage.tsx:

• Use t.validation?.<key> ?? 'fallback' instead of as string
• This makes the fallback behavior explicit and maintains type safety

A small helper within the useMemo can reduce repetition:

const msg = (k: keyof typeof t.validation, fb: string) => t.validation?.[k] ?? fb;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/customer/pages/RegisterPage.tsx` around lines 18 - 42,
The registerSchema useMemo currently uses unsafe "as string" casts for
translation keys; replace those casts with explicit safe fallbacks using the
nullish coalescing pattern (t.validation?.<key> ?? '<fallback>') and reduce
repetition by adding a small helper inside the same useMemo (e.g., const msg =
(k, fb) => t.validation?.[k] ?? fb) and then call msg('minLength','Minimum
length is 2'), msg('required','Required'), msg('invalidEmail','Invalid email'),
msg('passwordStrength','Password must meet strength requirements') and
msg('passwordNoMatch','Passwords do not match') when constructing registerSchema
(including inside superRefine) so type safety and clear defaults mirror the
CheckoutPage.tsx approach.

backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/SystemNotificationRepository.cs (1)

56-68: Prefer ExecuteUpdateAsync for bulk updates in MarkAllAsReadAsync.

The current implementation loads all unread notifications into memory, mutates them, and saves—inefficient for large backlogs. EF Core 8.0.24 (confirmed in the project file) supports ExecuteUpdateAsync for server-side UPDATE statements, which is faster and avoids memory overhead.

Suggested refactor

-        public async Task<int> MarkAllAsReadAsync(CancellationToken ct)
-        {
-            var unread = await _context.SystemNotifications.Where(n => !n.IsRead).ToListAsync(ct);
-            if (!unread.Any()) return 0;
-            
-            foreach (var item in unread)
-            {
-                item.IsRead = true;
-            }
-            
-            _context.SystemNotifications.UpdateRange(unread);
-            return await _context.SaveChangesAsync(ct);
-        }
+        public Task<int> MarkAllAsReadAsync(CancellationToken ct)
+        {
+            return _context.SystemNotifications
+                .Where(n => !n.IsRead)
+                .ExecuteUpdateAsync(s => s.SetProperty(n => n.IsRead, true), ct);
+        }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/SystemNotificationRepository.cs`
around lines 56 - 68, Replace the in-memory load-and-update in
MarkAllAsReadAsync with a server-side update: call
_context.SystemNotifications.Where(n => !n.IsRead).ExecuteUpdateAsync(...) to
set IsRead = true (use SetProperty to assign true) and pass the
CancellationToken; return the integer result from ExecuteUpdateAsync instead of
calling ToListAsync/UpdateRange and SaveChangesAsync. Ensure you remove the
unread variable/loop and keep using the existing CancellationToken (ct) when
invoking ExecuteUpdateAsync.

frontend/src/modules/manager/pages/OrderDetailsPage.tsx (1)

120-145: Derive timeline progress from statusSteps indexes instead of enum values.

The current implementation using order.status / 3 and order.status >= step.key depends on OrderStatus having exactly the values 0..3 in timeline order, which is fragile. While the enum currently matches this (PROCESSING=0, READY=1, OUT_FOR_DELIVERY=2, DELIVERED=3), deriving progress from statusSteps array indexes would be more maintainable and prevent breakage if enum values change.

♻️ Proposed refactoring

   const statusSteps = [
     { key: OrderStatus.PROCESSING, label: t.orders.processing, icon: Clock },
     { key: OrderStatus.READY, label: t.orders.ready, icon: Package },
     { key: OrderStatus.OUT_FOR_DELIVERY, label: t.orders.outForDelivery, icon: Truck },
     { key: OrderStatus.DELIVERED, label: t.orders.delivered, icon: CheckCircle2 },
   ];
+  const currentStepIndex = statusSteps.findIndex((step) => step.key === order.status);
+  const progress =
+    currentStepIndex <= 0 ? 0 : (currentStepIndex / (statusSteps.length - 1)) * 100;

@@
-          <div className="absolute top-4 left-0 h-0.5 bg-primary-500 z-0 transition-all" style={{ width: `${(order.status / 3) * 100}%` }} />
-          {statusSteps.map((step) => {
+          <div className="absolute top-4 left-0 h-0.5 bg-primary-500 z-0 transition-all" style={{ width: `${progress}%` }} />
+          {statusSteps.map((step, stepIndex) => {
             const Icon = step.icon;
-            const isCompleted = order.status >= step.key;
+            const isCompleted = currentStepIndex >= stepIndex;
             const isCurrent = order.status === step.key;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/manager/pages/OrderDetailsPage.tsx` around lines 120 -
145, The timeline progress should be computed from the statusSteps array indexes
instead of assuming numeric enum values; find the currentStepIndex by locating
the index in statusSteps where step.key === order.status, compute
progressPercent = (currentStepIndex / (statusSteps.length - 1)) * 100 and use
that for the width style instead of (order.status / 3) * 100, and replace the
isCompleted check to compare indices (currentStepIndex >= stepIndex) when
mapping statusSteps (refer to statusSteps, step.key, order.status and the inline
style width and isCompleted logic).

frontend/src/modules/catalog/pages/ProductDetailsPage.tsx (1)

109-109: Avoid any for product images.

product.images already has a type from useProductQuery; typing img as any here discards it and risks silent drift if the backend shape changes (e.g., imageUrl, altText, id). Prefer the inferred element type (or an explicit ProductImage type) so the compiler catches accidental misuse in this JSX block, in product.images?.[selectedImage]?.imageUrl, and in the arrow-nav handlers.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/catalog/pages/ProductDetailsPage.tsx` at line 109, The
map callback currently types the image parameter as any which discards the real
type from useProductQuery; change the map to use the inferred element type
(remove : any) or explicitly use the product image type (e.g., ProductImage) so
TypeScript can validate properties like imageUrl/altText/id; update occurrences
that reference img (inside product.images.map(...),
product.images?.[selectedImage]?.imageUrl, and the arrow-nav handlers) to rely
on the correct type instead of any so the compiler will catch mismatches.

frontend/src/modules/catalog/pages/ProductsListPage.tsx (2)

17-19: Harden URL param parsing for categoryId.

If the URL carries a non-numeric categoryId (manual edit, stale link, bookmark), Number('abc') yields NaN, which is then passed into useProductsQuery({ ..., categoryId: NaN }) and ultimately into the backend request. Minor nit: searchParams.get('categoryId') is also called twice.

♻️ Proposed fix

-  const page = Number(searchParams.get('page')) || 1;
-  const search = searchParams.get('search') || '';
-  const categoryId = searchParams.get('categoryId') ? Number(searchParams.get('categoryId')) : undefined;
+  const page = Number(searchParams.get('page')) || 1;
+  const search = searchParams.get('search') || '';
+  const rawCategoryId = searchParams.get('categoryId');
+  const parsedCategoryId = rawCategoryId ? Number(rawCategoryId) : undefined;
+  const categoryId = Number.isFinite(parsedCategoryId) ? parsedCategoryId : undefined;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/catalog/pages/ProductsListPage.tsx` around lines 17 -
19, The categoryId parsing is fragile: calling searchParams.get('categoryId')
twice and passing Number(...) can produce NaN which then flows into
useProductsQuery; change parsing to call searchParams.get('categoryId') once,
store it in a local variable (e.g., rawCategoryId), validate it with
Number.isInteger or parseInt and isFinite, and only set categoryId when it is a
valid number (otherwise leave undefined); update the variable used in
useProductsQuery({..., categoryId}) so the backend never receives NaN.

---

147-156: All "Add to cart" buttons disable together during any in-flight add.

useAddCartItem is called once at the page level, so isAddingToCart is a single boolean shared across every rendered ProductCard. The moment a user clicks Add on one card, every other card's button also becomes disabled until the mutation resolves. Works, but may feel laggy on slower networks; if per-card disable is desired, track the pending productId locally (e.g., const [pendingId, setPendingId] = useState<number | null>(null)) and pass isAddingToCart={pendingId === prod.id}.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/catalog/pages/ProductsListPage.tsx` around lines 147 -
156, The page-level boolean from useAddCartItem causes every ProductCard's
isAddingToCart prop to disable all buttons simultaneously; change to track the
pending product id locally (e.g., add state pendingId with useState<number |
null>(null)) and update handleAddToCart to setPendingId(prod.id) before calling
the mutation and clear it (setPendingId(null)) in the mutation's
finally/onSettled handler so each ProductCard receives isAddingToCart={pendingId
=== prod.id}; keep using useAddCartItem for the mutation itself but only derive
per-card disable state from pendingId.

frontend/src/layouts/CustomerLayout.tsx (1)

55-66: Header search replaces, rather than merges, existing filter params.

When a user is already on /products?categoryId=3&page=2 and submits the header search, navigate('/products?search=...') drops categoryId (and page, which is probably desired). Consider preserving categoryId so the header search behaves like an additional filter rather than a full reset.

♻️ Possible approach

-              onSubmit={(e) => {
-                e.preventDefault();
-                const search = new FormData(e.currentTarget).get('search') as string;
-                if (search) {
-                  navigate(`/products?search=${encodeURIComponent(search)}`);
-                } else {
-                  navigate('/products');
-                }
-              }}
+              onSubmit={(e) => {
+                e.preventDefault();
+                const search = (new FormData(e.currentTarget).get('search') as string) ?? '';
+                const params = new URLSearchParams(window.location.pathname === '/products' ? window.location.search : '');
+                if (search) params.set('search', search);
+                else params.delete('search');
+                params.delete('page');
+                const qs = params.toString();
+                navigate(qs ? `/products?${qs}` : '/products');
+              }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/layouts/CustomerLayout.tsx` around lines 55 - 66, The header
search form's onSubmit handler currently calls navigate('/products?search=...')
which replaces existing query params (dropping categoryId); update the handler
in CustomerLayout's form onSubmit so it reads the current location.search (via
useLocation or the existing router location), parses query params, sets/updates
the "search" param while preserving existing params like "categoryId", then
builds the new query string and calls navigate(`/products?${newQuery}`); ensure
that when the search is empty the "search" param is removed (not set to empty)
so other filters remain intact.

frontend/src/modules/manager/pages/InventoryManagePage.tsx (2)

127-152: Card title doesn't match its contents.

The overview card's CardTitle is t.manager.productQuantity (rendered as "Current Stock"), but the card body renders both the current stock and the min-quantity tile. Consider a more general title key (e.g. a new t.manager.stockOverview) so the header accurately represents the section.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/manager/pages/InventoryManagePage.tsx` around lines 127
- 152, The Card header currently uses t.manager.productQuantity (CardTitle)
which mislabels the section because the body displays both product.quantity and
product.minQuantity; change the title to a more general key (e.g., add and use
t.manager.stockOverview) and update the CardTitle to use that new key (replace
t.manager.productQuantity with t.manager.stockOverview) so the header accurately
reflects the CardContent that includes the current stock, minQuantity tiles and
the isLow warning.

---

68-81: Defensive mapping of unknown server error keys.

The fallback branch casts any server field name to keyof InventoryFormType:

setError(key as keyof InventoryFormType, { type: 'server', message: msg });

The only form fields are qty and action, so keys like minQuantity (present on AdjustInventoryRequest) or any other DTO field will register an error against a non-existent input — the message is effectively swallowed and the user sees no feedback. Safer to surface unknown keys on root.serverError instead.

♻️ Proposed fix

       onError: (err: any) => {
         const map = getApiErrorMap(err);
         if (Object.keys(map).length > 0) {
+          const knownFields: Array<keyof InventoryFormType> = ['qty', 'action'];
           for (const [key, msg] of Object.entries(map)) {
             if (key === 'quantityDelta' || key === 'quantity') {
               setError('qty', { type: 'server', message: msg });
-            } else {
-              setError(key as keyof InventoryFormType, { type: 'server', message: msg });
+            } else if ((knownFields as string[]).includes(key)) {
+              setError(key as keyof InventoryFormType, { type: 'server', message: msg });
+            } else {
+              setError('root.serverError', { type: 'server', message: msg });
             }
           }
         } else {
           setError('root.serverError', { type: 'server', message: getApiErrorMessage(err) });
         }
       }

Also consider typing err as unknown rather than any.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/modules/manager/pages/InventoryManagePage.tsx` around lines 68 -
81, The handler maps server error keys directly to form fields causing messages
for unknown DTO fields to be lost; update the onError logic in
InventoryManagePage to only call setError for actual form fields (e.g., map
'quantity' and 'quantityDelta' to the form field 'qty', and allow 'action' if
present) and for any other unknown keys call setError('root.serverError', {
type: 'server', message: msg }) so the user sees the message; use getApiErrorMap
and setError as shown, and consider typing the err parameter as unknown instead
of any.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes