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

Inline comments:
In
`@backend/OrderSystemApi/OrderSystem.Application/Orders/Services/OrderService.cs`:
- Around line 39-45: The code hardcodes customerId = 1L when calling
_orderRepository.GetPagedForCustomerAsync in the "GetMy*" flows; replace the
hardcoded value by retrieving the authenticated customer's id (e.g., from the
request DTO, injected user/context service, or HttpContext claims) and pass that
id into _orderRepository.GetPagedForCustomerAsync (and any other GetMy* calls
noted at 62-68). Update the method signature(s) or controller/service callers as
needed to accept or resolve the authenticated customer id and ensure
cancellationToken behavior remains unchanged.
- Around line 28-33: Replace the thrown NotImplementedException in
OrderService.CheckoutAsync with a handled “not available yet” response:
implement CheckoutAsync(CheckoutRequest, CancellationToken) to return a
completed Task<CheckoutResponse> that indicates failure/unavailable (e.g.,
Success = false, an ErrorCode like "CheckoutNotAvailable" and a human-friendly
Message) and respects the CancellationToken; keep the method signature and types
(CheckoutAsync, CheckoutRequest, CheckoutResponse) unchanged so the controller
remains callable but returns a safe, documented response until Cart/Inventory
integration is ready.

In
`@backend/OrderSystemApi/OrderSystem.Application/Payments/DTOs/Requests/PayByCardRequest.cs`:
- Around line 9-16: The PayByCardRequest DTO exposes raw card data (CardNumber,
Cvv, ExpiryMonth, ExpiryYear) which brings PCI-DSS scope; replace these raw
fields with a single token field (e.g., PaymentMethodToken or CardToken) and
update consumers to expect a token from the client-side payment processor, or if
this is intentionally placeholder/demo code add a clear comment above the
PayByCardRequest class stating it is not production-ready and must never be used
to transmit/store raw card data; update any references to PayByCardRequest
(handlers, validators, tests) to use the token property and ensure server-side
code no longer accepts or logs raw card details.

In
`@backend/OrderSystemApi/OrderSystem.Application/Payments/Interfaces/IPaymentService.cs`:
- Around line 22-24: IPaymentService.MarkCashPaidAsync is implemented in
PaymentService but never exposed, so either add an API endpoint to invoke it or
remove it and its implementation; to fix, create a controller action (e.g., in
OrdersController) with route POST "{orderId}/pay/cash" that accepts orderId and
CancellationToken, applies the appropriate [Authorize] policy/role, calls
IPaymentService.MarkCashPaidAsync(orderId, cancellationToken) and returns a
proper HTTP result, or if cash confirmation is not required remove the
MarkCashPaidAsync signature from IPaymentService and delete the corresponding
implementation in PaymentService and any unit tests that exercise it.

In
`@backend/OrderSystemApi/OrderSystem.Application/Payments/Services/PaymentService.cs`:
- Around line 77-91: The PaymentService currently marks payments as PAID and
fabricates a TransactionRef after only local validation; instead keep the
payment in a pending state and call the real payment processor/gateway (or a
PaymentProvider method) to authorize/capture the card, then update
payment.Status to PaymentStatus.PAID and set PaidAt and TransactionRef only when
the processor returns success, or set PaymentStatus.DECLINED/FAILED and persist
processor error details when it fails; ensure you invoke and await the payment
gateway method from PaymentService (or the relevant method that integrates with
the gateway), use the gateway-provided transaction id rather than generating
"CARD-...", and continue to call _paymentRepository.Update(payment) after
setting the final status and details.
- Around line 31-37: The code in PaymentService.cs hardcodes customerId = 1L
before calling _orderRepository.GetByIdForCustomerAsync, causing every request
to operate as the same customer; replace the hardcoded id by plumbing the
authenticated user's id into the service (e.g., inject a current-user
abstraction like ICurrentUserService or accept a customerId parameter from the
caller) and use that value when calling GetByIdForCustomerAsync (both
occurrences around the initial call and the second block at 55-61). Update the
PaymentService constructor to accept the ICurrentUserService (or propagate the
caller-supplied customerId through method signatures), remove the literal 1L,
and ensure you read the user id via ICurrentUserService.UserId (or the passed
parameter) before calling _orderRepository.GetByIdForCustomerAsync so
authorization is correct.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/20260325132042_Initial2.cs`:
- Around line 10-20: There are duplicate migration artifacts for the same
ApplicationDbContext: an empty Initial2 migration class (Initial2.cs), its
designer (Initial2.Designer.cs) and a duplicate
ApplicationDbContextModelSnapshot were added in a separate migrations location,
splitting the migration history; remove those duplicate files (Initial2,
Initial2.Designer, duplicate ApplicationDbContextModelSnapshot) from the
alternate migrations set so there is a single, linear migration history for
ApplicationDbContext, and if the Initial2 changes were intended, regenerate that
migration against the existing migrations location for ApplicationDbContext (so
the new migration and snapshot live only in the primary migrations folder).

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/20260325132042_Initial2.Designer.cs`:
- Around line 381-382: Remove the orphaned OrderItemId property from the Product
entity class and any explicit mapping so the relationship is represented only by
OrderItem.productId → Product.OrderItems; specifically delete the OrderItemId
property declaration in Product (and any Fluent API or DataAnnotation
references) and regenerate a migration that drops the OrderItemId column (or
edit the existing migration to remove the b.Property<long>("OrderItemId") entry
in the Designer and produce a migration step to drop that column), ensuring
OrderItemConfiguration remains the sole relationship configuration using
OrderItem.productId and Product.OrderItems.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/ApplicationDbContextModelSnapshot.cs`:
- Around line 271-280: The snapshot uses a lowercase property name "productId"
which deviates from the PascalCase used by the OrderItem entity and DTO; update
the OrderItem property and the EF model snapshot references to use "ProductId"
(replace occurrences of "productId" in ApplicationDbContextModelSnapshot.cs and
ensure the OrderItem class property is declared as public long ProductId) and
update any HasColumnName/HasIndex calls that reference the old name so the EF
model, indexes (HasIndex("productId") and composite index HasIndex("OrderId",
"productId")), and schema mapping consistently use "ProductId".
- Around line 606-615: The Order entity's navigation property is incorrectly
named Payments (plural) for a one-to-one relation; rename the property in the
Order class from Payments to Payment (public Payment Payment { get; set; }) and
update the EF Core migration snapshot references in
ApplicationDbContextModelSnapshot.cs so the relationship uses WithOne("Payment")
instead of WithOne("Payments") (and update any matching Navigation/HasForeignKey
references that rely on the old name). After renaming, rebuild and regenerate or
update the migration snapshot so all occurrences of "Payments" related to
Order/Payment are consistently "Payment".
- Around line 376-380: The Product entity contains an erroneous scalar
OrderItemId property that conflicts with the configured one-to-many relationship
(OrderItem.productId -> Product.OrderItems); remove the public long OrderItemId
{ get; set; } from the Product class, delete any mapping of OrderItemId in the
EF Core model snapshot/ApplicationDbContextModelSnapshot related to the Product
entity, and then regenerate or update the migration (so the snapshot no longer
contains the .Property<long>("OrderItemId") entry). Ensure the relationship
remains defined in OrderItemConfiguration via OrderItem.productId and
Product.OrderItems.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/OrderRepository.cs`:
- Around line 100-103: The Update method currently blocks on synchronous I/O and
redundantly calls _context.Orders.Update(order); change it to an async method
with signature public async Task UpdateAsync(Order order, CancellationToken
cancellationToken), remove the explicit _context.Orders.Update(order) since
GetByIdAsync returns a tracked entity, and replace _context.SaveChanges() with
await _context.SaveChangesAsync(cancellationToken); follow the existing AddAsync
pattern in this repository and update any callers to use UpdateAsync and pass
the cancellation token.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/PaymentRepository.cs`:
- Around line 34-38: The synchronous PaymentRepository.Update method blocks
async callers; change the repository API to an async pattern by renaming Update
to UpdateAsync (e.g., Task UpdateAsync(Payment payment)) in IPaymentRepository
and implement it in PaymentRepository to call _context.Payments.Update(payment)
followed by await _context.SaveChangesAsync(); then update all callers
(PayByCardAsync, MarkCashPaidAsync, and any other consumer methods) to await the
new UpdateAsync method and remove any sync-over-async usage.

In
`@backend/OrderSystemApi/OrderSystemApi/Controllers/Customer/OrdersController.cs`:
- Around line 7-9: Add authentication to the customer order endpoints by
decorating the OrdersController (or at minimum the Checkout, GetMyOrders, and
GetMyOrderById actions) with the [Authorize] attribute, and replace any
hardcoded customerId usage in those actions and the service calls with the
authenticated user's id obtained from the request claims (e.g., User.Identity /
User.FindFirst(ClaimTypes.NameIdentifier)) before calling the order service
methods so the controller uses the actual authenticated customer context.

In
`@backend/OrderSystemApi/OrderSystemApi/Controllers/Customer/PaymentsController.cs`:
- Around line 7-9: The PaymentsController class and related endpoints lack
authentication/authorization and the service layer uses a hardcoded customerId
(customerId = 1L); add the [Authorize] attribute to PaymentsController (or its
protected actions), configure authentication in Program.cs by calling
services.AddAuthentication(...) with the appropriate scheme and registering the
corresponding handler before app.UseAuthorization(), and change the
controller/service calls to extract the authenticated user's ID from User.Claims
(e.g., ClaimTypes.NameIdentifier or a JWT claim) and pass that value instead of
the hardcoded 1L to the payment/order service methods.

In
`@backend/OrderSystemApi/OrderSystemApi/Controllers/Manager/ManagerOrdersController.cs`:
- Around line 7-9: The ManagerOrdersController currently exposes privileged
endpoints without authorization; add the Authorize attribute to restrict access
to manager-only users by decorating the ManagerOrdersController class (or
individually secure actions like GetAllOrders and any status-transition methods
such as MarkAsDelivered/UpdateOrderStatus) with [Authorize(Roles = "Manager")]
or an equivalent policy name, and ensure the project imports the authorization
namespace (e.g., Microsoft.AspNetCore.Authorization) and that
authentication/role policies are wired up in startup/Program so only
authenticated users in the Manager role can call these endpoints.

---

Nitpick comments:
In
`@backend/OrderSystemApi/OrderSystem.Application/Orders/DTOs/Requests/OrderQueryRequest.cs`:
- Around line 10-15: OrderQueryRequest currently allows invalid pagination
values; add validation to enforce Page >= 1 and cap PageSize to a reasonable
maximum (e.g., introduce a public const int MaxPageSize = 100) and either apply
validation attributes (e.g., [Range(1, int.MaxValue)] on Page and [Range(1,
MaxPageSize)] on PageSize) or enforce these bounds in the request
handling/mapper where OrderQueryRequest is consumed (validate Page and PageSize,
normalize Page < 1 to 1, and clamp PageSize to MaxPageSize) so callers cannot
request invalid offsets or unbounded page sizes.

In
`@backend/OrderSystemApi/OrderSystem.Application/Payments/DTOs/Requests/PayByCardRequest.cs`:
- Around line 11-15: The PayByCardRequest DTO currently lacks validation; add
DataAnnotations to the properties (e.g. mark CardHolderName, CardNumber, Cvv as
[Required], apply a [RegularExpression] on CardNumber to allow only 13–19 digits
or use [CreditCard], apply [StringLength] or regex on Cvv for 3–4 digits, and
add [Range(1,12)] to ExpiryMonth and a sensible [Range] to ExpiryYear); for
cross-field validation of expiry (ExpiryMonth/ExpiryYear) implement
IValidatableObject on PayByCardRequest and validate that the card expiry is not
in the past. Ensure to include using System.ComponentModel.DataAnnotations and
keep property names CardHolderName, CardNumber, ExpiryMonth, ExpiryYear, Cvv
when adding attributes.

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Migrations/20260325132042_Initial2.Designer.cs`:
- Around line 285-291: The migration currently maps the OrderItem entity to
"OrderItem" (see the ToTable("OrderItem", ...) call and its check constraints
CK_OrderItem_*); change the table name to snake_case "order_items" in that
ToTable call so it matches other tables (orders, payments, cart_items), and
update any related references in the same migration (constraint names or FK
names if they embed the table name) or the corresponding entity configuration
(OnModelCreating / entityTypeBuilder for OrderItem) to use "order_items".

In
`@backend/OrderSystemApi/OrderSystem.Infrastructure/Repositories/OrderRepository.cs`:
- Around line 59-63: The paging order uses only CreatedAt which can produce
nondeterministic ties; in OrderRepository update the LINQ ordering chain on the
query variable q (the OrderByDescending(o => o.CreatedAt) call) to include a
stable tiebreaker by adding a secondary sort on Id (e.g., ThenByDescending(o =>
o.Id) to preserve newest-first stability), and apply the same change to the
second instance of the ordering (the block around the other pagination at lines
85-89) so offset pagination is deterministic and avoids duplicated/skipped
orders.

In `@backend/OrderSystemApi/OrderSystemApi/Program.cs`:
- Around line 56-58: The middleware pipeline in Program.cs is missing the
authentication middleware, so call app.UseAuthentication() immediately before
app.UseAuthorization() to ensure JWT tokens are validated; update the Program.cs
startup sequence to insert app.UseAuthentication() prior to the existing
app.UseAuthorization() call (or omit only if authentication is intentionally
deferred).