Project map — eshop-concepts-0.11.35

Generated by Silex · 2026-07-15 03:19 UTC

Summary

Entities (26)

State machines (4)

EventStateEnumStatus States: NotPublished (initial), 0, InProgress, 1, Published, 2, PublishedFailed, 3 Transitions: NotPublished → [NotPublished_to_0] 0 | 0 → [0_to_InProgress] InProgress | InProgress → [InProgress_to_1] 1 | 1 → [1_to_Published] Published | Published → [Published_to_2] 2 | 2 → [2_to_PublishedFailed] PublishedFailed | PublishedFailed → [PublishedFailed_to_3] 3

IntegrationEventLogEntryStatus States: get (initial), set Transitions: get → [get_to_set] set

OrderStatus States: Submitted (initial), 1, AwaitingValidation, 2, StockConfirmed, 3, Paid, 4, Shipped, 5, Cancelled, 6 Transitions: Submitted → [Submitted_to_1] 1 | 1 → [1_to_AwaitingValidation] AwaitingValidation | AwaitingValidation → [AwaitingValidation_to_2] 2 | 2 → [2_to_StockConfirmed] StockConfirmed | StockConfirmed → [StockConfirmed_to_3] 3 | 3 → [3_to_Paid] Paid | Paid → [Paid_to_4] 4 | 4 → [4_to_Shipped] Shipped | Shipped → [Shipped_to_5] 5 | 5 → [5_to_Cancelled] Cancelled | Cancelled → [Cancelled_to_6] 6

PermissionStatus States: Denied (initial), Disabled, Granted, Restricted, Unknown Transitions: Denied → [Denied_to_Disabled] Disabled | Disabled → [Disabled_to_Granted] Granted | Granted → [Granted_to_Restricted] Restricted | Restricted → [Restricted_to_Unknown] Unknown

Business rules (182)

🔧 Heuristic: 85 | 🕒 Agent proposal (pending review): 97

34 unnamed heuristic guards not shown in this view (empty statement — collapsed here, count read from the report metadata).

ApplicationUser (1)

BasketCheckoutInfo (2)

BasketItem (6)

BasketState (5)

Buyer (6)

CatalogApi (6)

CatalogItem (20)

CatalogView (1)

CatalogViewModel (1)

ChangePasswordViewModel (3)

CheckoutViewModel (2)

Consent (7)

ConsentController (1)

CustomerBasket (11)

Device (2)

DeviceController (1)

ExternalController (1)

FadeInAnimation (1)

FadeOutAnimation (1)

FadeToAnimation (1)

FixUriService (5)

IdentityService (1)

IntegrationEventLogEntry (2)

LocationService (1)

LoginInputModel (1)

LoginViewModel (1)

OpenApiOptionsExtensions (1)

Order (46)

OrderCheckout (1)

OrderDraft (1)

OrderItem (11)

OrderStatus (1)

PaymentMethod (4)

ProductPriceChangedIntegrationEvent (2)

ProfileService (2)

ProfileViewModel (1)

RabbitMQEventBus (1)

RegisterViewModel (3)

RequestProvider (2)

ResetPasswordViewModel (3)

SecuritySchemeDefinitionsTransformer (1)

SetPasswordViewModel (3)

TestServerCallContext (1)

VerifyCodeViewModel (1)

VerifyPhoneNumberViewModel (1)

VisualElementExtensions (2)

WebhookSubscription (4)

* n/a — agent rules (proposed or promoted) don't carry trigger/confidence: the submit never computes those fields, not even after human review.

Rule details

ApplicationUser (1)

#1 — Required on ApplicationUser

• Source: 🔧 heuristic
• Entity: ApplicationUser
• Type: validation
• Statement: Required on ApplicationUser
• Anchor: src/Identity.API/Models/ApplicationUser.cs:6
• Evidence:

[Required]

BasketCheckoutInfo (2)

#1 — Required on BasketCheckoutInfo

• Source: 🔧 heuristic
• Entity: BasketCheckoutInfo
• Type: validation
• Statement: Required on BasketCheckoutInfo
• Anchor: src/WebApp/Services/BasketCheckoutInfo.cs:7
• Evidence:

[Required]

#2 — Checkout requires a complete shipping address

• Source: 🕒 agent proposal (pending review)
• Entity: BasketCheckoutInfo
• Type: validation
• Statement: Street, City, State, Country and ZipCode are all [Required] on the checkout form; card fields are optional in this model (the demo checkout injects test card data).
• Anchor: src/WebApp/Services/BasketCheckoutInfo.cs:5
• Evidence:

[Required] public string? Street ... [Required] public string? City ... [Required] public string? State ... [Required] public string? Country ... [Required] public string? ZipCode

BasketItem (6)

#1 — Setting quantity to zero or less removes the item

• Source: 🕒 agent proposal (pending review)
• Entity: BasketItem
• Type: business_rule
• Statement: SetQuantityAsync updates the line quantity only when quantity > 0; a value of 0 or negative removes the item from the basket entirely, then the whole basket is persisted.
• Anchor: src/WebApp/Services/BasketState.cs:58
• Evidence:

if (quantity > 0) { row.Quantity = quantity; } else { existingItems.Remove(row); }

#2 — Adding an existing product increments quantity instead of duplicating the line

• Source: 🕒 agent proposal (pending review)
• Entity: BasketItem
• Type: business_rule
• Statement: AddAsync scans the basket for the product: if found, quantity is incremented by 1; if not, a new line with quantity 1 is added. The same de-duplication rule exists in the MAUI client (CustomerBasket.AddItemToBasket, src/ClientApp/Models/Basket/CustomerBasket.cs:11-23).
• Anchor: src/WebApp/Services/BasketState.cs:33
• Evidence:

if (existing.ProductId == item.Id) { items[i] = existing with { Quantity = existing.Quantity + 1 }; found = true; } ... if (!found) { items.Add(new BasketQuantity(item.Id, 1)); }

#3 — Client basket totals: line total and badge count derived from quantity

• Source: 🕒 agent proposal (pending review)
• Entity: BasketItem
• Type: business_rule
• Statement: In the MAUI client, a line's Total is Quantity * UnitPrice, the basket badge counts the sum of quantities, and an item is flagged as repriced (HasNewPrice) when OldUnitPrice != 0 (src/ClientApp/Models/Basket/BasketItem.cs:17-31).
• Anchor: src/ClientApp/ViewModels/BasketViewModel.cs:24
• Evidence:

public int BadgeCount => _basketItems?.Sum(basketItem => basketItem.Quantity) ?? 0; public decimal Total => _basketItems?.Sum(basketItem => basketItem.Quantity * basketItem.UnitPrice) ?? 0m;

#4 — Checkout navigation only when the basket has items

• Source: 🕒 agent proposal (pending review)
• Entity: BasketItem
• Type: business_rule
• Statement: In the MAUI client, the Checkout command navigates to the Checkout page only if the basket contains at least one item; an empty basket cannot start checkout.
• Anchor: src/ClientApp/ViewModels/BasketViewModel.cs:104
• Evidence:

if (_basketItems?.Any() ?? false) { _appEnvironmentService.BasketService.LocalBasketItems = _basketItems; await NavigationService.NavigateToAsync("Checkout"); }

#5 — Basket item quantity must be at least 1

• Source: 🕒 agent proposal (pending review)
• Entity: BasketItem
• Type: validation
• Statement: A basket item with Quantity < 1 fails validation with the error 'Invalid number of units' on the Quantity member (BasketItem implements IValidatableObject).
• Anchor: src/Basket.API/Model/BasketItem.cs:13
• Evidence:

if (Quantity < 1) { results.Add(new ValidationResult("Invalid number of units", new[] { "Quantity" })); }

#6 — Basket persists only product id and quantity; details are re-hydrated from the catalog

• Source: 🕒 agent proposal (pending review)
• Entity: BasketItem
• Type: business_rule
• Statement: The gRPC contract carries only product_id and quantity per basket item (basket.proto message BasketItem, src/Basket.API/Proto/basket.proto:20-23); when displaying, the WebApp joins each quantity with the catalog to fill name and unit price — prices always come from the current catalog, not from the stored basket.
• Anchor: src/WebApp/Services/BasketState.cs:117
• Evidence:

var catalogItems = (await catalogService.GetCatalogItems(productIds)).ToDictionary(...); ... ProductName = catalogItem.Name, UnitPrice = catalogItem.Price, Quantity = item.Quantity

BasketState (5)

#1 — InvalidOperationException in BasketState

• Source: 🔧 heuristic
• Entity: BasketState
• Type: validation
• Statement: InvalidOperationException in BasketState
• Anchor: src/WebApp/Services/BasketState.cs:85
• Evidence:

throw new InvalidOperationException("User does not have a buyer ID"

#2 — InvalidOperationException in BasketState

• Source: 🔧 heuristic
• Entity: BasketState
• Type: validation
• Statement: InvalidOperationException in BasketState
• Anchor: src/WebApp/Services/BasketState.cs:86
• Evidence:

throw new InvalidOperationException("User does not have a user name"

#3 — BasketState: checkoutInfo.RequestId auto-fill when default/null

• Source: 🔧 heuristic
• Entity: BasketState
• Type: auto_fill
• Statement: BasketState: checkoutInfo.RequestId auto-fill when default/null
• Anchor: src/WebApp/Services/BasketState.cs:80
• Evidence:

if (checkoutInfo.RequestId == default)
        {
            checkoutInfo.RequestId = Guid.NewGuid();

#1 — Required on Buyer

• Source: 🔧 heuristic
• Entity: Buyer
• Type: validation
• Statement: Required on Buyer
• Anchor: src/Ordering.Domain/AggregatesModel/BuyerAggregate/Buyer.cs:8
• Evidence:

[Required]

#2 — Default card type when unspecified

• Source: 🕒 agent proposal (pending review)
• Entity: Buyer
• Type: policy
• Statement: If an order is started without a card type (card type id 0), the system defaults the payment method's card type to 1 instead of failing.
• Anchor: src/Ordering.API/Application/DomainEventHandlers/ValidateOrAddBuyerAggregateWhenOrderStartedDomainEventHandler.cs:22
• Evidence:

var cardTypeId = domainEvent.CardTypeId != 0 ? domainEvent.CardTypeId : 1;

#3 — Buyer requires identity and name

• Source: 🕒 agent proposal (pending review)
• Entity: Buyer
• Type: validation
• Statement: A buyer cannot be created without a non-blank identity GUID and a non-blank name; violation raises ArgumentNullException.
• Anchor: src/Ordering.Domain/AggregatesModel/BuyerAggregate/Buyer.cs:23
• Evidence:

IdentityGuid = !string.IsNullOrWhiteSpace(identity) ? identity : throw new ArgumentNullException(nameof(identity));

#4 — Payment method verify-or-add (dedup)

• Source: 🕒 agent proposal (pending review)
• Entity: Buyer
• Type: policy
• Statement: When a buyer submits card data, an existing payment method with the same card type, card number and expiration is reused instead of duplicated; a new one is added only when no match exists. In both cases a BuyerAndPaymentMethodVerified domain event is raised for the order.
• Anchor: src/Ordering.Domain/AggregatesModel/BuyerAggregate/Buyer.cs:29
• Evidence:

var existingPayment = _paymentMethods.SingleOrDefault(p => p.IsEqualTo(cardTypeId, cardNumber, expiration));

#5 — Buyer verified-or-created at order start

• Source: 🕒 agent proposal (pending review)
• Entity: Buyer
• Type: policy
• Statement: When an order is started, the system looks up the buyer by user identity; if none exists a new Buyer aggregate is created from the user id and name. The buyer's payment method is then verified or added, and only afterwards the OrderStatusChangedToSubmitted integration event is published with the buyer's name and identity.
• Anchor: src/Ordering.API/Application/DomainEventHandlers/ValidateOrAddBuyerAggregateWhenOrderStartedDomainEventHandler.cs:20
• Evidence:

var buyer = await _buyerRepository.FindAsync(domainEvent.UserId); var buyerExisted = buyer is not null; if (!buyerExisted) { buyer = new Buyer(domainEvent.UserId, domainEvent.UserName); }

#6 — One buyer per user identity

• Source: 🕒 agent proposal (pending review)
• Entity: Buyer
• Type: invariant
• Statement: A user identity GUID maps to at most one buyer: lookup uses a single-or-default query on IdentityGuid, so duplicate buyers for the same identity are treated as a fault.
• Anchor: src/Ordering.Infrastructure/Repositories/BuyerRepository.cs:33
• Evidence:

.Where(b => b.IdentityGuid == identity).SingleOrDefaultAsync();

CatalogApi (6)

#1 — CatalogItem: guard (quantityDesired <= 0)

• Source: 🔧 heuristic
• Entity: CatalogItem
• Type: validation
• Statement: CatalogItem: guard (quantityDesired <= 0)
• Anchor: src/Catalog.API/Model/CatalogItem.cs:69
• Evidence:

if (quantityDesired <= 0)
        {
            throw

#2 — Required on CatalogItem

• Source: 🔧 heuristic
• Entity: CatalogItem
• Type: validation
• Statement: Required on CatalogItem
• Anchor: src/Catalog.API/Model/CatalogItem.cs:11
• Evidence:

[Required]

#3 — Price change triggers ProductPriceChangedIntegrationEvent

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: On item update, if and only if the Price property was modified, a ProductPriceChangedIntegrationEvent (ProductId, NewPrice, OldPrice) is created, saved atomically with the catalog change, and published through the event bus. If the price did not change, the update is saved with a plain SaveChanges and no event is emitted.
• Anchor: src/Catalog.API/Apis/CatalogApi.cs:345
• Evidence:

if (priceEntry.IsModified) { var priceChangedEvent = new ProductPriceChangedIntegrationEvent(catalogItem.Id, productToUpdate.Price, priceEntry.OriginalValue); await services.EventService.SaveEventAndCatalogContextChangesAsync(priceChangedEvent); await services.EventService.PublishThroughEventBusAsync(priceChangedEvent); } else { await services.Context.SaveChangesAsync(); }

#4 — AddStock clears the OnReorder flag

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: state_transition
• Statement: Any restock (AddStock) resets OnReorder to false: once units are added, the item is no longer considered pending reorder.
• Anchor: src/Catalog.API/Model/CatalogItem.cs:102
• Evidence:

this.OnReorder = false;

#5 — Catalog listing filters by name prefix, type and brand, ordered by name

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: GetAllItems composes optional filters — Name.StartsWith(name) (prefix match, not contains), CatalogTypeId == type, CatalogBrandId == brand — then orders by Name and paginates (Skip pageSize*pageIndex / Take pageSize), returning the total count alongside the page.
• Anchor: src/Catalog.API/Apis/CatalogApi.cs:123
• Evidence:

root = root.Where(c => c.Name.StartsWith(name)); ... root.Where(c => c.CatalogTypeId == type) ... OrderBy(c => c.Name).Skip(pageSize * pageIndex).Take(pageSize)

#6 — RemoveStock rejects sold-out items

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: validation
• Statement: RemoveStock throws CatalogDomainException ('Empty stock, product item {Name} is sold out') when AvailableStock == 0; stock removal is impossible on a sold-out item.
• Anchor: src/Catalog.API/Model/CatalogItem.cs:62
• Evidence:

if (AvailableStock == 0) { throw new CatalogDomainException($"Empty stock, product item {Name} is sold out"); }

#7 — V1 update requires the item id in the request body

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: validation
• Statement: UpdateItemV1 returns 400 BadRequest ('Item id must be provided in the request body.') when the incoming product has no Id, then delegates to the v2 UpdateItem which 404s if the id does not exist.
• Anchor: src/Catalog.API/Apis/CatalogApi.cs:315
• Evidence:

if (productToUpdate?.Id == null) { return TypedResults.BadRequest<ProblemDetails>(new (){ Detail = "Item id must be provided in the request body." }); }

#8 — Item embedding is computed from Name + Description, truncated to 384 dimensions

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: CatalogAI embeds a catalog item as the string '{Name} {Description}' and slices every generated embedding vector to exactly 384 dimensions (EmbeddingDimensions constant) before storing/searching. AI features are enabled only when an embedding generator is configured (IsEnabled).
• Anchor: src/Catalog.API/Services/CatalogAI.cs:9
• Evidence:

private const int EmbeddingDimensions = 384; ... public bool IsEnabled => _embeddingGenerator is not null; ... embedding = embedding[0..EmbeddingDimensions]; ... CatalogItemToString(CatalogItem item) => $"{item.Name} {item.Description}";

#9 — RemoveStock requires positive quantity

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: validation
• Statement: RemoveStock throws CatalogDomainException when quantityDesired <= 0; it is invalid to request removal of zero or negative units.
• Anchor: src/Catalog.API/Model/CatalogItem.cs:69
• Evidence:

if (quantityDesired <= 0) { throw new CatalogDomainException($"Item units desired should be greater than zero"); }

#10 — Chatbot catalog search uses semantic relevance with top 8 results

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: The AdventureWorks chatbot tool SearchCatalog answers product-description queries via GetCatalogItemsWithSemanticRelevance(page 0, take 8), rewriting each result's PictureUrl through the product image provider before returning it to the LLM.
• Anchor: src/WebApp/Components/Chatbot/ChatState.cs:117
• Evidence:

var results = await _catalogService.GetCatalogItemsWithSemanticRelevance(0, 8, productDescription!); ... results.Data[i] = results.Data[i] with { PictureUrl = _productImages.GetProductImageUrl(results.Data[i].Id) };

#11 — Client catalog filter requires both brand and type

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: In the MAUI client, the catalog filter can only be applied when BOTH a brand and a type are selected (CanFilter => SelectedBrand is not null && SelectedType is not null); ApplyFilterAsync re-checks the same condition before calling FilterAsync(brandId, typeId).
• Anchor: src/ClientApp/ViewModels/CatalogViewModel.cs:161
• Evidence:

if (SelectedBrand is not null && SelectedType is not null) { var filteredProducts = await _appEnvironmentService.CatalogService.FilterAsync(SelectedBrand.Id, SelectedType.Id); ... } (CanFilter at line 57: public bool CanFilter => SelectedBrand is not null && SelectedType is not null;)

#12 — GetItemById requires a positive id and 404s on missing item

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: validation
• Statement: GetItemById returns 400 BadRequest ('Id is not valid') when id <= 0, and 404 NotFound when no catalog item exists with that id; the item is loaded with its CatalogBrand included.
• Anchor: src/Catalog.API/Apis/CatalogApi.cs:176
• Evidence:

if (id <= 0) { return TypedResults.BadRequest<ProblemDetails>(new (){ Detail = "Id is not valid" }); } ... if (item == null) { return TypedResults.NotFound(); }

#13 — Stock can never go negative

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: RemoveStock removes at most the available quantity: removed = Math.Min(quantityDesired, AvailableStock), so AvailableStock never becomes negative. When stock is insufficient, the method removes what is available and returns the actual removed quantity; the caller is responsible for checking whether removed == desired (partial fulfillment).
• Anchor: src/Catalog.API/Model/CatalogItem.cs:74
• Evidence:

int removed = Math.Min(quantityDesired, this.AvailableStock); this.AvailableStock -= removed; return removed;

#14 — RestockThreshold is the reorder trigger level

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: domain_concept
• Statement: CatalogItem carries three stock control fields: AvailableStock (quantity in stock), RestockThreshold (available stock level at which the item should be reordered) and MaxStockThreshold (maximum units that can be in stock at any time). RemoveStock's contract documents that breaching RestockThreshold should generate a restock request.
• Anchor: src/Catalog.API/Model/CatalogItem.cs:28
• Evidence:

// Available stock at which we should reorder / public int RestockThreshold ... // Maximum number of units that can be in-stock at any time (due to physicial/logistical constraints in warehouses) / public int MaxStockThreshold

#15 — Chatbot add-to-cart requires an authenticated user

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: The chatbot AddToCart tool fetches the catalog item and adds it to the basket; an Unauthenticated gRPC error is translated into the business answer 'Unable to add an item to the cart. You must be logged in.' — anonymous users cannot add items via the chatbot.
• Anchor: src/WebApp/Components/Chatbot/ChatState.cs:136
• Evidence:

catch (Grpc.Core.RpcException e) when (e.StatusCode == Grpc.Core.StatusCode.Unauthenticated) { return "Unable to add an item to the cart. You must be logged in."; }

#16 — Semantic search falls back to name search when AI is unavailable

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: GetItemsBySemanticRelevance degrades gracefully: if CatalogAI.IsEnabled is false, or the embedding for the search text comes back null, the request is answered by the plain name search (StartsWith) instead of vector search.
• Anchor: src/Catalog.API/Apis/CatalogApi.cs:245
• Evidence:

if (!services.CatalogAI.IsEnabled) { return await GetItemsByName(paginationRequest, services, text); } var vector = await services.CatalogAI.GetEmbeddingAsync(text); if (vector is null) { return await GetItemsByName(paginationRequest, services, text); }

#17 — Semantic search ranks by cosine distance over embedded items only

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: AI search considers only catalog items with a non-null Embedding, orders them by ascending cosine distance to the query vector (most similar first) and paginates the result; items never embedded are invisible to semantic search.
• Anchor: src/Catalog.API/Apis/CatalogApi.cs:279
• Evidence:

.Where(c => c.Embedding != null) .OrderBy(c => c.Embedding!.CosineDistance(vector)) .Skip(pageSize * pageIndex) .Take(pageSize)

#18 — Create and update always recompute the item embedding

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: Both CreateItem and UpdateItem set item.Embedding = CatalogAI.GetEmbeddingAsync(item) before saving, keeping the semantic index consistent with the current Name/Description (null when AI disabled).
• Anchor: src/Catalog.API/Apis/CatalogApi.cs:382
• Evidence:

item.Embedding = await services.CatalogAI.GetEmbeddingAsync(item); (same call in UpdateItem at line 343: catalogItem.Embedding = await services.CatalogAI.GetEmbeddingAsync(catalogItem);)

#19 — AddStock caps at MaxStockThreshold

• Source: 🕒 agent proposal (pending review)
• Entity: CatalogItem
• Type: business_rule
• Statement: AddStock never raises AvailableStock above MaxStockThreshold (physical/logistical warehouse constraint). If the requested quantity would exceed the cap, only the difference up to MaxStockThreshold is added and the excess is silently discarded; the method returns the quantity actually added.
• Anchor: src/Catalog.API/Model/CatalogItem.cs:86
• Evidence:

if ((this.AvailableStock + quantity) > this.MaxStockThreshold) { this.AvailableStock += (this.MaxStockThreshold - this.AvailableStock); }

#1 — Required on ChangePasswordViewModel

• Source: 🔧 heuristic
• Entity: ChangePasswordViewModel
• Type: validation
• Statement: Required on ChangePasswordViewModel
• Anchor: src/Identity.API/Models/ManageViewModels/ChangePasswordViewModel.cs:5
• Evidence:

[Required]

#2 — StringLength on ChangePasswordViewModel

• Source: 🔧 heuristic
• Entity: ChangePasswordViewModel
• Type: validation
• Statement: StringLength on ChangePasswordViewModel
• Anchor: src/Identity.API/Models/ManageViewModels/ChangePasswordViewModel.cs:11
• Evidence:

[StringLength(100, ErrorMessage = "The {0} must be at least {2} and at max {1} characters long.", MinimumLength = 6)]

#3 — Compare on ChangePasswordViewModel

• Source: 🔧 heuristic
• Entity: ChangePasswordViewModel
• Type: validation
• Statement: Compare on ChangePasswordViewModel
• Anchor: src/Identity.API/Models/ManageViewModels/ChangePasswordViewModel.cs:18
• Evidence:

[Compare("NewPassword", ErrorMessage = "The new password and confirmation password do not match.")]

CheckoutViewModel (2)

#1 — Denying consent returns access_denied and raises audit event

• Source: 🕒 agent proposal (pending review)
• Entity: Consent
• Type: business_rule
• Statement: When the user clicks 'no' on the consent screen, the standard OAuth 'access_denied' error is returned to the client and a ConsentDeniedEvent is emitted with the user subject, client id and requested scopes.
• Anchor: src/Identity.API/Quickstart/Consent/ConsentController.cs:92
• Evidence:

if (model?.Button == "no") { grantedConsent = new ConsentResponse { Error = AuthorizationError.AccessDenied }; await _events.RaiseAsync(new ConsentDeniedEvent(...)); }

#2 — Granting consent requires at least one scope selected

• Source: 🕒 agent proposal (pending review)
• Entity: Consent
• Type: validation
• Statement: When the user clicks 'yes', consent is only granted if at least one scope was consented; with no scopes selected the submission is rejected with the MustChooseOne validation error and the consent screen is redisplayed.
• Anchor: src/Identity.API/Quickstart/Consent/ConsentController.cs:101
• Evidence:

if (model.ScopesConsented != null && model.ScopesConsented.Any()) { ... } else { result.ValidationError = ConsentOptions.MustChooseOneErrorMessage; }

#3 — Consent outcome communicated to IdentityServer before redirect

• Source: 🕒 agent proposal (pending review)
• Entity: Consent
• Type: business_rule
• Statement: Only when a consent response exists (granted or explicitly denied) is the outcome communicated back to IdentityServer via GrantConsentAsync, after which the user may be redirected to the authorization endpoint; otherwise the consent UI is redisplayed.
• Anchor: src/Identity.API/Quickstart/Consent/ConsentController.cs:132
• Evidence:

if (grantedConsent != null) { await _interaction.GrantConsentAsync(request, grantedConsent); result.RedirectUri = model.ReturnUrl; result.Client = request.Client; } else { result.ViewModel = await BuildViewModelAsync(model.ReturnUrl, model); }

#4 — Required scopes are always pre-checked on consent screen

• Source: 🕒 agent proposal (pending review)
• Entity: Consent
• Type: business_rule
• Statement: A scope marked as Required by the identity resource or API scope definition is always rendered as checked on the consent screen, regardless of the user's previous selection (Checked = check || Required).
• Anchor: src/Identity.API/Quickstart/Consent/ConsentController.cs:217
• Evidence:

return new ScopeViewModel { ... Required = apiScope.Required, Checked = check || apiScope.Required };

#5 — Consent requires a valid pending authorization context

• Source: 🕒 agent proposal (pending review)
• Entity: Consent
• Type: validation
• Statement: A consent decision is only processed if the return URL still matches a valid pending authorization request; if no authorization context is found, the consent is ignored (no grant, no redirect, error view).
• Anchor: src/Identity.API/Quickstart/Consent/ConsentController.cs:86
• Evidence:

// validate return url is still valid — var request = await _interaction.GetAuthorizationContextAsync(model.ReturnUrl); if (request == null) return result;

#6 — Consent decision must be explicit yes or no

• Source: 🕒 agent proposal (pending review)
• Entity: Consent
• Type: validation
• Statement: A consent postback whose button value is neither 'yes' nor 'no' is treated as an invalid selection: the InvalidSelection validation error is set and no consent is granted.
• Anchor: src/Identity.API/Quickstart/Consent/ConsentController.cs:126
• Evidence:

else { result.ValidationError = ConsentOptions.InvalidSelectionErrorMessage; } — reached when model?.Button is neither "no" nor "yes"

#7 — OfflineAccess scope stripped when offline access disabled

• Source: 🕒 agent proposal (pending review)
• Entity: Consent
• Type: business_rule
• Statement: If offline access is disabled in ConsentOptions (EnableOfflineAccess == false), the 'offline_access' scope is filtered out of the user's consented scopes even if it was submitted.
• Anchor: src/Identity.API/Quickstart/Consent/ConsentController.cs:105
• Evidence:

var scopes = model.ScopesConsented; if (ConsentOptions.EnableOfflineAccess == false) { scopes = scopes.Where(x => x != IdentityServerConstants.StandardScopes.OfflineAccess); }

ConsentController (1)

#1 — UpdateBasket requires an authenticated caller

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: authorization
• Statement: The gRPC UpdateBasket operation rejects callers without a user identity with gRPC status Unauthenticated ('The caller is not authenticated.'). The basket's BuyerId is always taken from the authenticated identity, not from the request payload.
• Anchor: src/Basket.API/Grpc/BasketService.cs:36
• Evidence:

var userId = context.GetUserIdentity(); if (string.IsNullOrEmpty(userId)) { ThrowNotAuthenticated(); } ... MapToCustomerBasket(userId, request)

#2 — DeleteBasket requires an authenticated caller

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: authorization
• Statement: The gRPC DeleteBasket operation rejects callers without a user identity with gRPC status Unauthenticated; only the caller's own basket (keyed by its user id) can be deleted.
• Anchor: src/Basket.API/Grpc/BasketService.cs:59
• Evidence:

var userId = context.GetUserIdentity(); if (string.IsNullOrEmpty(userId)) { ThrowNotAuthenticated(); } await repository.DeleteBasketAsync(userId);

#3 — Basket is deleted when the order starts

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: business_rule
• Statement: When an OrderStartedIntegrationEvent arrives (order creation began in Ordering), the basket service deletes the user's basket from the repository — the cart is consumed by the order.
• Anchor: src/Basket.API/IntegrationEvents/EventHandling/OrderStartedIntegrationEventHandler.cs:6
• Evidence:

public async Task Handle(OrderStartedIntegrationEvent @event) { ... await repository.DeleteBasketAsync(@event.UserId); }

#4 — One basket per customer, stored in Redis under /basket/{userId}

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: business_rule
• Statement: Each customer has a single basket persisted as one Redis string keyed by '/basket/' + userId; GetBasketAsync returns null when no entry exists for the customer.
• Anchor: src/Basket.API/Repositories/RedisBasketRepository.cs:6
• Evidence:

private static RedisKey BasketKeyPrefix = "/basket/"u8.ToArray(); ... if (data is null || data.Length == 0) { return null; }

#5 — Client basket operations are no-ops without an auth token

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: authorization
• Statement: In the MAUI BasketService, GetBasketAsync returns an empty basket, UpdateBasketAsync returns the input unchanged and ClearBasketAsync returns early when no auth token is available; all gRPC calls attach 'authorization: Bearer {token}'.
• Anchor: src/ClientApp/Services/Basket/BasketService.cs:32
• Evidence:

var authToken = await _identityService.GetAuthTokenAsync()...; if (string.IsNullOrEmpty(authToken)) { return basket; } ... headers.Add("authorization", $"Bearer {token}") (line 132-137)

#6 — Checkout requires buyer id and user name, then creates the order and deletes the basket

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: business_rule
• Statement: CheckoutAsync fails with InvalidOperationException when the user has no buyer ID or user name; otherwise it builds a CreateOrderRequest from the basket items, calls Ordering to create the order, and immediately deletes the basket.
• Anchor: src/WebApp/Services/BasketState.cs:78
• Evidence:

var buyerId = await authenticationStateProvider.GetBuyerIdAsync() ?? throw new InvalidOperationException("User does not have a buyer ID"); ... await orderingService.CreateOrder(request, checkoutInfo.RequestId); await DeleteBasketAsync();

#7 — Basket update is a full overwrite followed by read-back

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: business_rule
• Statement: UpdateBasketAsync serializes the whole basket and overwrites the Redis entry; on write failure it returns null (which the gRPC layer surfaces as NotFound), otherwise it returns the basket re-read from Redis.
• Anchor: src/Basket.API/Repositories/RedisBasketRepository.cs:34
• Evidence:

var created = await _database.StringSetAsync(GetBasketKey(basket.BuyerId), json); if (!created) { ... return null; } return await GetBasketAsync(basket.BuyerId);

#8 — Basket items are only shown to authenticated users

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: authorization
• Statement: GetBasketItemsAsync returns the basket contents only when the user identity is authenticated; anonymous visitors get an empty collection.
• Anchor: src/WebApp/Services/BasketState.cs:21
• Evidence:

(await GetUserAsync()).Identity?.IsAuthenticated == true ? await FetchBasketItemsAsync() : []

#9 — Checkout is idempotent via a request id

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: business_rule
• Statement: If the checkout info has no RequestId, a new GUID is generated; the order creation call sends it as the 'x-requestid' header so retried checkouts do not create duplicate orders.
• Anchor: src/WebApp/Services/BasketState.cs:80
• Evidence:

if (checkoutInfo.RequestId == default) { checkoutInfo.RequestId = Guid.NewGuid(); } — sent as x-requestid in OrderingService.CreateOrder (src/WebApp/Services/OrderingService.cs:12-18)

#10 — Updating a basket that does not persist yields NotFound

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: business_rule
• Statement: When the repository returns null for an update, UpdateBasket throws gRPC NotFound with message 'Basket with buyer id {userId} does not exist'.
• Anchor: src/Basket.API/Grpc/BasketService.cs:50
• Evidence:

if (response is null) { ThrowBasketDoesNotExist(userId); } ... StatusCode.NotFound, $"Basket with buyer id {userId} does not exist"

#11 — GetBasket is anonymous-tolerant: no identity yields an empty basket

• Source: 🕒 agent proposal (pending review)
• Entity: CustomerBasket
• Type: authorization
• Statement: The gRPC GetBasket operation is marked [AllowAnonymous]; when the caller has no user identity it returns an empty CustomerBasketResponse instead of an error. The basket is always resolved by the authenticated user id, never by a client-supplied id.
• Anchor: src/Basket.API/Grpc/BasketService.cs:12
• Evidence:

[AllowAnonymous] ... var userId = context.GetUserIdentity(); if (string.IsNullOrEmpty(userId)) { return new(); }

Device (2)

#1 — NullReferenceException in FadeInAnimation

• Source: 🔧 heuristic
• Entity: FadeInAnimation
• Type: validation
• Statement: NullReferenceException in FadeInAnimation
• Anchor: src/ClientApp/Animations/FadeToAnimation.cs:63
• Evidence:

throw new NullReferenceException("Null Target property."

FadeOutAnimation (1)

#1 — NullReferenceException in FadeOutAnimation

• Source: 🔧 heuristic
• Entity: FadeOutAnimation
• Type: validation
• Statement: NullReferenceException in FadeOutAnimation
• Anchor: src/ClientApp/Animations/FadeToAnimation.cs:121
• Evidence:

throw new NullReferenceException("Null Target property."

FadeToAnimation (1)

#1 — NullReferenceException in FadeToAnimation

• Source: 🔧 heuristic
• Entity: FadeToAnimation
• Type: validation
• Statement: NullReferenceException in FadeToAnimation
• Anchor: src/ClientApp/Animations/FadeToAnimation.cs:23
• Evidence:

throw new NullReferenceException("Null Target property."

FixUriService (5)

#1 — Required on IntegrationEventLogEntry

• Source: 🔧 heuristic
• Entity: IntegrationEventLogEntry
• Type: validation
• Statement: Required on IntegrationEventLogEntry
• Anchor: src/IntegrationEventLogEF/IntegrationEventLogEntry.cs:22
• Evidence:

[Required]

#2 — IntegrationEventLogEntry: State → EventStateEnum.NotPublished

• Source: 🔧 heuristic
• Entity: IntegrationEventLogEntry
• Type: state_transition
• Statement: IntegrationEventLogEntry: State → EventStateEnum.NotPublished
• Anchor: src/IntegrationEventLogEF/IntegrationEventLogEntry.cs:17
• Evidence:

State = EventStateEnum.NotPublished;

LocationService (1)

#1 — Required on LoginInputModel

• Source: 🔧 heuristic
• Entity: LoginInputModel
• Type: validation
• Statement: Required on LoginInputModel
• Anchor: src/Identity.API/Quickstart/Account/LoginInputModel.cs:9
• Evidence:

[Required]

LoginViewModel (1)

#1 — Required on LoginViewModel

• Source: 🔧 heuristic
• Entity: LoginViewModel
• Type: validation
• Statement: Required on LoginViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/LoginViewModel.cs:5
• Evidence:

[Required]

OpenApiOptionsExtensions (1)

#1 — OrderingContext: guard (_currentTransaction != null)

• Source: 🔧 heuristic
• Entity: Order
• Type: validation
• Statement: OrderingContext: guard (_currentTransaction != null)
• Anchor: src/Ordering.Infrastructure/OrderingContext.cs:66
• Evidence:

if (_currentTransaction != null) return

#2 — OrderingContext: guard (transaction == null)

• Source: 🔧 heuristic
• Entity: Order
• Type: validation
• Statement: OrderingContext: guard (transaction == null)
• Anchor: src/Ordering.Infrastructure/OrderingContext.cs:75
• Evidence:

if (transaction == null) throw

#3 — Required on Order

• Source: 🔧 heuristic
• Entity: Order
• Type: validation
• Statement: Required on Order
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:11
• Evidence:

[Required]

#4 — Paid and Shipped statuses trigger customer webhooks

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: When an order becomes Paid or Shipped, all webhook subscriptions of the matching type (OrderPaid / OrderShipped) are retrieved and the event payload is sent to every subscriber.
• Anchor: src/Webhooks.API/IntegrationEvents/OrderStatusChangedToShippedIntegrationEventHandler.cs:8
• Evidence:

var subscriptions = await retriever.GetSubscriptionsOfType(WebhookType.OrderShipped); ... await sender.SendAll(subscriptions, whook);

#5 — Stock rejection cancels the order

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: When the stock service rejects an order, the order is cancelled (SetCancelledStatusWhenStockIsRejected) carrying the list of rejected product ids; only the items flagged as out of stock are included in that list.
• Anchor: src/Ordering.API/Application/Commands/SetStockRejectedOrderStatusCommandHandler.cs:19
• Evidence:

orderToUpdate.SetCancelledStatusWhenStockIsRejected(command.OrderStockItems);

#6 — Payment outcome decided by gateway simulation

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: When an order reaches StockConfirmed, the payment step publishes exactly one of two outcomes: OrderPaymentSucceeded or OrderPaymentFailed, decided by the PaymentSucceeded configuration flag (simulating a real payment gateway).
• Anchor: src/PaymentProcessor/IntegrationEvents/EventHandling/OrderStatusChangedToStockConfirmedIntegrationEventHandler.cs:21
• Evidence:

if (options.CurrentValue.PaymentSucceeded) { orderPaymentIntegrationEvent = new OrderPaymentSucceededIntegrationEvent(@event.OrderId); } else { orderPaymentIntegrationEvent = new OrderPaymentFailedIntegrationEvent(@event.OrderId); }

#7 — Grace period confirmed triggers AwaitingValidation transition

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: When the grace period confirmation event is received, the order process continues to validation: the handler issues SetAwaitingValidationOrderStatusCommand for the order, moving it from Submitted toward AwaitingValidation instead of being cancelled.
• Anchor: src/Ordering.API/Application/IntegrationEvents/EventHandling/GracePeriodConfirmedIntegrationEventHandler.cs:15
• Evidence:

var command = new SetAwaitingValidationOrderStatusCommand(@event.OrderId); await mediator.Send(command); // doc: grace period completed and order will not initially be cancelled; order process continues for validation

#8 — Stock deducted only after payment, non-blocking

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: Catalog stock is physically removed only when the order is Paid: each ordered item's units are deducted from available stock, and inventory is explicitly not blocked/reserved before that point.
• Anchor: src/Catalog.API/IntegrationEvents/EventHandling/OrderStatusChangedToPaidIntegrationEventHandler.cs:12
• Evidence:

//we're not blocking stock/inventory ... catalogItem?.RemoveStock(orderStockItem.Units);

#9 — Periodic grace period polling

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: process_schedule
• Statement: Grace period verification is a recurring background process: the service polls for confirmed grace-period orders in a loop, waiting CheckUpdateTime seconds (configurable) between each check, until shutdown is requested.
• Anchor: src/OrderProcessor/Services/GracePeriodManagerService.cs:16
• Evidence:

var delayTime = TimeSpan.FromSeconds(_options.CheckUpdateTime); while (!stoppingToken.IsCancellationRequested) { await CheckConfirmedGracePeriodOrders(); await Task.Delay(delayTime, stoppingToken); }

#10 — Duplicate product lines are merged, keeping the higher discount

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: Adding an item for a product already in the order does not create a new line: units are accumulated on the existing line and the discount is replaced only when the new discount is higher than the current one.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:71
• Evidence:

if (discount > existingOrderForProduct.Discount) { existingOrderForProduct.SetNewDiscount(discount); } existingOrderForProduct.AddUnits(units);

#11 — Paid or shipped orders cannot be cancelled

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: Cancelling an order in Paid or Shipped status throws OrderingDomainException; any earlier status may be cancelled, raising OrderCancelledDomainEvent.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:142
• Evidence:

if (OrderStatus == OrderStatus.Paid || OrderStatus == OrderStatus.Shipped) { StatusChangeException(OrderStatus.Cancelled); }

#12 — Cancel, ship and create require a non-empty request ID

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: The orders API rejects cancel, ship and create requests whose x-requestid header is an empty GUID (idempotency key is mandatory), returning BadRequest.
• Anchor: src/Ordering.API/Apis/OrdersApi.cs:22
• Evidence:

if (requestId == Guid.Empty) { return TypedResults.BadRequest("Empty GUID is not valid for request ID"); } (same guard in ShipOrderAsync lines 51-78 and CreateOrderAsync lines 118-168)

#13 — Users only see their own orders

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: The orders listing resolves the user identity from the authenticated context and queries only orders whose buyer identity GUID matches that user.
• Anchor: src/Ordering.API/Application/Queries/OrderQueries.cs:37
• Evidence:

.Where(o => o.Buyer.IdentityGuid == userId) — userId supplied by OrdersApi.GetOrdersByUserAsync via services.IdentityService.GetUserIdentity() (OrdersApi.cs lines 93-98)

#14 — Set AwaitingValidation status only for existing orders

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: The command handler sets the order status to AwaitingValidation and persists it; if the order does not exist in the repository the command is a no-op and returns false (no status change is persisted).
• Anchor: src/Ordering.API/Application/Commands/SetAwaitingValidationOrderStatusCommandHandler.cs:19
• Evidence:

var orderToUpdate = await _orderRepository.GetAsync(command.OrderNumber); if (orderToUpdate == null) { return false; } orderToUpdate.SetAwaitingValidationStatus(); return await _orderRepository.UnitOfWork.SaveEntitiesAsync(cancellationToken);

#15 — Stock rejection auto-cancels order awaiting validation

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: When stock is rejected while the order is AwaitingValidation, the order is cancelled automatically and its description lists the product names without stock.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:155
• Evidence:

if (OrderStatus == OrderStatus.AwaitingValidation) { OrderStatus = OrderStatus.Cancelled; ... Description = $"The product items don't have stock: ({itemsStockRejectedDescription})."; }

#16 — Stock confirmed advances order to StockConfirmed

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: When the stock service confirms availability for an order, the order transitions to StockConfirmed status; if the order no longer exists the command reports failure instead of throwing.
• Anchor: src/Ordering.API/Application/Commands/SetStockConfirmedOrderStatusCommandHandler.cs:19
• Evidence:

orderToUpdate.SetStockConfirmedStatus(); return await _orderRepository.UnitOfWork.SaveEntitiesAsync(cancellationToken);

#17 — Real-time order status notification per buyer

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: Order status change notifications are delivered only to the active subscriptions of the specific buyer (keyed by buyer identity); buyers without subscriptions produce no notification, and a subscription stops receiving updates once disposed.
• Anchor: src/WebApp/Services/OrderStatus/OrderStatusNotificationService.cs:27
• Evidence:

return _subscriptionsByBuyerId.TryGetValue(buyerId, out var subscriptions) ? Task.WhenAll(subscriptions.Select(s => s.NotifyAsync())) : Task.CompletedTask;

#18 — Grace period eligibility criteria

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: temporal_condition
• Statement: An order is only considered past its grace period when the elapsed time since OrderDate is >= the configured GracePeriodTime (in minutes) AND the order status is still 'Submitted'. Only such orders are selected for confirmation.
• Anchor: src/OrderProcessor/Services/GracePeriodManagerService.cs:63
• Evidence:

SQL: SELECT "Id" FROM ordering.orders WHERE CURRENT_TIMESTAMP - "OrderDate" >= @GracePeriodTime AND "OrderStatus" = 'Submitted'; parameter bound to TimeSpan.FromMinutes(_options.GracePeriodTime)

#19 — Ship command fails for non-existent order

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: validation
• Statement: The ship order command returns false (no state change) when the order number does not resolve to an existing order.
• Anchor: src/Ordering.API/Application/Commands/ShipOrderCommandHandler.cs:19
• Evidence:

var orderToUpdate = await _orderRepository.GetAsync(command.OrderNumber); if (orderToUpdate == null) { return false; } orderToUpdate.SetShippedStatus();

#20 — Order creation publishes OrderStarted integration event to clear the basket

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: Handling CreateOrderCommand first saves an OrderStartedIntegrationEvent for the buyer so the basket is cleaned, then builds the Order aggregate (address + payment data) and adds each item through AddOrderItem so aggregate invariants are enforced.
• Anchor: src/Ordering.API/Application/Commands/CreateOrderCommandHandler.cs:29
• Evidence:

var orderStartedIntegrationEvent = new OrderStartedIntegrationEvent(message.UserId); ... foreach (var item in message.OrderItems) { order.AddOrderItem(...); }

#21 — Order total is the sum of units times unit price

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: calculation
• Statement: The order total is computed as the sum over all order items of Units * UnitPrice (discounts are not subtracted in this calculation).
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:185
• Evidence:

public decimal GetTotal() => _orderItems.Sum(o => o.Units * o.UnitPrice);

#22 — Basket items without product name are excluded from checkout order

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: validation
• Statement: When building order items from basket items at checkout, entries with an empty product name are skipped and do not become order items.
• Anchor: src/ClientApp/ViewModels/CheckoutViewModel.cs:136
• Evidence:

if (!string.IsNullOrEmpty(basketItem.ProductName)) { orderItems.Add(new OrderItem { ... }); }

#23 — New order starts as Submitted and raises OrderStarted event

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: invariant
• Statement: Every order created through the aggregate constructor starts in Submitted status with OrderDate set to UTC now, and an OrderStartedDomainEvent is queued for dispatch after persistence.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:52
• Evidence:

OrderStatus = OrderStatus.Submitted; OrderDate = DateTime.UtcNow; ... AddOrderStartedDomainEvent(...)

#24 — Credit card number is masked before order creation and never logged

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: When creating an order, the API masks the card number keeping only the last 4 digits (rest padded with 'X') before building the CreateOrderCommand, and deliberately does not log the request because it contains the card number.
• Anchor: src/Ordering.API/Apis/OrdersApi.cs:118
• Evidence:

var maskedCCNumber = request.CardNumber.Substring(request.CardNumber.Length - 4).PadLeft(request.CardNumber.Length, 'X'); //don't log the request as it has CC number

#25 — Stock validation: any missing item rejects the whole order

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: When an order awaits validation, the catalog checks each ordered item: the item has stock only if available stock covers the ordered units. If ANY item lacks stock the whole order stock request is rejected (OrderStockRejected); only when all items have stock is it confirmed (OrderStockConfirmed).
• Anchor: src/Catalog.API/IntegrationEvents/EventHandling/OrderStatusChangedToAwaitingValidationIntegrationEventHandler.cs:20
• Evidence:

var hasStock = catalogItem.AvailableStock >= orderStockItem.Units; ... confirmedOrderStockItems.Any(c => !c.HasStock) ? new OrderStockRejectedIntegrationEvent(...) : new OrderStockConfirmedIntegrationEvent(...)

#26 — Order linked to buyer and payment only after verification

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: An order is updated with its buyer id and payment method id only after the buyer and the payment method have been created or verified to exist (reaction to BuyerAndPaymentMethodVerified domain event).
• Anchor: src/Ordering.API/Application/DomainEventHandlers/UpdateOrderWhenBuyerAndPaymentMethodVerifiedDomainEventHandler.cs:16
• Evidence:

// When the Buyer and Buyer's payment method have been created or verified that they existed, then we can update the original Order with the BuyerId and PaymentId (foreign keys) ... orderToUpdate.SetPaymentMethodVerified(domainEvent.Buyer.Id, domainEvent.Payment.Id);

#27 — Cancel attempt on already-progressed order is reported as failure

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: In the client order service, a BadRequest response to the cancel request (order status changed before the user clicked cancel) makes CancelOrderAsync return false instead of throwing.
• Anchor: src/ClientApp/Services/Order/OrderService.cs:83
• Evidence:

catch (HttpRequestExceptionEx ex) when (ex.HttpCode == HttpStatusCode.BadRequest) { return false; }

#28 — Grace period confirmation event per order

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: event_publication
• Statement: For each order whose grace period has elapsed, a GracePeriodConfirmedIntegrationEvent carrying the OrderId is published to the event bus, signaling that the order will not be cancelled during the grace window and may proceed.
• Anchor: src/OrderProcessor/Services/GracePeriodManagerService.cs:44
• Evidence:

foreach (var orderId in orderIds) { var confirmGracePeriodEvent = new GracePeriodConfirmedIntegrationEvent(orderId); await eventBus.PublishAsync(confirmGracePeriodEvent); }

#29 — Only out-of-stock items reported on rejection

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: When a stock rejection event arrives, only the products actually lacking stock (HasStock == false) are extracted and forwarded to the order cancellation command.
• Anchor: src/Ordering.API/Application/IntegrationEvents/EventHandling/OrderStockRejectedIntegrationEventHandler.cs:10
• Evidence:

var orderStockRejectedItems = @event.OrderStockItems.FindAll(c => !c.HasStock).Select(c => c.ProductId).ToList();

#30 — Payment success advances order to Paid

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: When the payment gateway reports success, the order transitions to Paid status; a non-existent order makes the command return false (no-op).
• Anchor: src/Ordering.API/Application/Commands/SetPaidOrderStatusCommandHandler.cs:19
• Evidence:

orderToUpdate.SetPaidStatus(); return await _orderRepository.UnitOfWork.SaveEntitiesAsync(cancellationToken);

#31 — Client cancel action only offered while order is Submitted

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: In the client app, the cancel option is enabled only when the fetched order status equals 'Submitted' (case-insensitive); after a cancel attempt the flag is cleared.
• Anchor: src/ClientApp/ViewModels/OrderDetailViewModel.cs:31
• Evidence:

IsSubmittedOrder = Order.OrderStatus.Equals("Submitted", StringComparison.OrdinalIgnoreCase);

#32 — StockConfirmed only reachable from AwaitingValidation

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: An order is marked StockConfirmed (with description 'All the items were confirmed with available stock.') only when it is currently AwaitingValidation.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:108
• Evidence:

if (OrderStatus == OrderStatus.AwaitingValidation) { ... OrderStatus = OrderStatus.StockConfirmed; }

#33 — AwaitingValidation only reachable from Submitted

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: An order moves to AwaitingValidation (raising OrderStatusChangedToAwaitingValidationDomainEvent with its items) only if it is currently Submitted; otherwise the call is silently ignored.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:99
• Evidence:

if (OrderStatus == OrderStatus.Submitted) { ... OrderStatus = OrderStatus.AwaitingValidation; }

#34 — Paid only reachable from StockConfirmed

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: An order is marked Paid (raising OrderStatusChangedToPaidDomainEvent with its items) only when it is currently StockConfirmed.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:119
• Evidence:

if (OrderStatus == OrderStatus.StockConfirmed) { ... OrderStatus = OrderStatus.Paid; }

#35 — Payment failure triggers order cancellation

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: When an OrderPaymentFailedIntegrationEvent is received, the handler issues a CancelOrderCommand for that order, cancelling it (subject to the aggregate's cancel rules).
• Anchor: src/Ordering.API/Application/IntegrationEvents/EventHandling/OrderPaymentFailedIntegrationEventHandler.cs:8
• Evidence:

var command = new CancelOrderCommand(@event.OrderId); ... await mediator.Send(command);

#36 — Cancel command fails for non-existent order

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: validation
• Statement: The cancel order command returns false (no state change) when the order number does not resolve to an existing order.
• Anchor: src/Ordering.API/Application/Commands/CancelOrderCommandHandler.cs:19
• Evidence:

var orderToUpdate = await _orderRepository.GetAsync(command.OrderNumber); if (orderToUpdate == null) { return false; } orderToUpdate.SetCancelledStatus();

#37 — Every status change broadcast with buyer identity

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: Each order status transition (Submitted, AwaitingValidation, StockConfirmed, Paid, Shipped, Cancelled) publishes an integration event enriched with the buyer's name and identity GUID, loaded from the order's buyer, so downstream consumers can notify the right customer.
• Anchor: src/Ordering.API/Application/DomainEventHandlers/OrderCancelledDomainEventHandler.cs:23
• Evidence:

var buyer = await _buyerRepository.FindByIdAsync(order.BuyerId.Value); var integrationEvent = new OrderStatusChangedToCancelledIntegrationEvent(order.Id, order.OrderStatus, buyer.Name, buyer.IdentityGuid);

#38 — Only paid orders can be shipped

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: state_transition
• Statement: Shipping an order whose status is not Paid throws OrderingDomainException; on success the order becomes Shipped and OrderShippedDomainEvent is raised.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:130
• Evidence:

if (OrderStatus != OrderStatus.Paid) { StatusChangeException(OrderStatus.Shipped); }

#39 — Outbox: integration events saved with transaction, published after

• Source: 🕒 agent proposal (pending review)
• Entity: Order
• Type: policy
• Statement: Ordering integration events are first persisted to an event log tied to the current database transaction and only published to the event bus afterwards, per transaction id; each event is marked InProgress before publishing, Published on success and Failed on error (transactional outbox guaranteeing no event without committed state).
• Anchor: src/Ordering.API/Application/IntegrationEvents/OrderingIntegrationEventService.cs:13
• Evidence:

await _eventLogService.MarkEventAsInProgressAsync(logEvt.EventId); await _eventBus.PublishAsync(logEvt.IntegrationEvent); await _eventLogService.MarkEventAsPublishedAsync(logEvt.EventId); ... MarkEventAsFailedAsync

#41 — Order: OrderStatus → OrderStatus.Submitted

• Source: 🔧 heuristic
• Entity: Order
• Type: state_transition
• Statement: Order: OrderStatus → OrderStatus.Submitted
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:57
• Evidence:

OrderStatus = OrderStatus.Submitted;

#42 — Order: OrderStatus → OrderStatus.AwaitingValidation

• Source: 🔧 heuristic
• Entity: Order
• Type: state_transition
• Statement: Order: OrderStatus → OrderStatus.AwaitingValidation
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:104
• Evidence:

OrderStatus = OrderStatus.AwaitingValidation;

#43 — Order: OrderStatus → OrderStatus.StockConfirmed

• Source: 🔧 heuristic
• Entity: Order
• Type: state_transition
• Statement: Order: OrderStatus → OrderStatus.StockConfirmed
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:114
• Evidence:

OrderStatus = OrderStatus.StockConfirmed;

#44 — Order: OrderStatus → OrderStatus.Paid

• Source: 🔧 heuristic
• Entity: Order
• Type: state_transition
• Statement: Order: OrderStatus → OrderStatus.Paid
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:125
• Evidence:

OrderStatus = OrderStatus.Paid;

#45 — Order: OrderStatus → OrderStatus.Shipped

• Source: 🔧 heuristic
• Entity: Order
• Type: state_transition
• Statement: Order: OrderStatus → OrderStatus.Shipped
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:137
• Evidence:

OrderStatus = OrderStatus.Shipped;

#46 — Order: OrderStatus → OrderStatus.Cancelled

• Source: 🔧 heuristic
• Entity: Order
• Type: state_transition
• Statement: Order: OrderStatus → OrderStatus.Cancelled
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs:150
• Evidence:

OrderStatus = OrderStatus.Cancelled;

OrderCheckout (1)

#1 — Required on OrderCheckout

• Source: 🔧 heuristic
• Entity: OrderCheckout
• Type: validation
• Statement: Required on OrderCheckout
• Anchor: src/ClientApp/Models/Orders/OrderCheckout.cs:8
• Evidence:

[Required]

OrderDraft (1)

#1 — Order draft is built from basket items, one order item per basket item

• Source: 🕒 agent proposal (pending review)
• Entity: OrderDraft
• Type: business_rule
• Statement: CreateOrderDraftCommandHandler starts a new draft Order and adds one order item per basket item (Units = basket Quantity via ToOrderItemDTO, src/Ordering.API/Extensions/BasketItemExtensions.cs:13-21); the draft total is computed by the Order aggregate. Functional test asserts Total == sum(Quantity * UnitPrice) (tests/Ordering.FunctionalTests/OrderingApiTests.cs:188-205).
• Anchor: src/Ordering.API/Application/Commands/CreateOrderDraftCommandHandler.cs:7
• Evidence:

var order = Order.NewDraft(); var orderItems = message.Items.Select(i => i.ToOrderItemDTO()); foreach (var item in orderItems) { order.AddOrderItem(...); } return Task.FromResult(OrderDraftDTO.FromOrder(order));

OrderItem (11)

#1 — OrderItem: guard (units <= 0)

• Source: 🔧 heuristic
• Entity: OrderItem
• Type: validation
• Statement: OrderItem: guard (units <= 0)
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:25
• Evidence:

if (units <= 0)
        {
            throw

#2 — OrderItem: guard (discount < 0)

• Source: 🔧 heuristic
• Entity: OrderItem
• Type: validation
• Statement: OrderItem: guard (discount < 0)
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:46
• Evidence:

if (discount < 0)
        {
            throw

#3 — Required on OrderItem

• Source: 🔧 heuristic
• Entity: OrderItem
• Type: validation
• Statement: Required on OrderItem
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:8
• Evidence:

[Required]

#4 — OrderingDomainException in OrderItem

• Source: 🔧 heuristic
• Entity: OrderItem
• Type: validation
• Statement: OrderingDomainException in OrderItem
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:27
• Evidence:

throw new OrderingDomainException("Invalid number of units"

#5 — OrderingDomainException in OrderItem

• Source: 🔧 heuristic
• Entity: OrderItem
• Type: validation
• Statement: OrderingDomainException in OrderItem
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:32
• Evidence:

throw new OrderingDomainException("The total of order item is lower than applied discount"

#6 — OrderingDomainException in OrderItem

• Source: 🔧 heuristic
• Entity: OrderItem
• Type: validation
• Statement: OrderingDomainException in OrderItem
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:48
• Evidence:

throw new OrderingDomainException("Discount is not valid"

#7 — OrderingDomainException in OrderItem

• Source: 🔧 heuristic
• Entity: OrderItem
• Type: validation
• Statement: OrderingDomainException in OrderItem
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:58
• Evidence:

throw new OrderingDomainException("Invalid units"

#8 — New discount must be non-negative

• Source: 🕒 agent proposal (pending review)
• Entity: OrderItem
• Type: validation
• Statement: Updating an order item discount with a negative value is rejected with OrderingDomainException 'Discount is not valid'.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:44
• Evidence:

if (discount < 0) { throw new OrderingDomainException("Discount is not valid"); }

#9 — Added units must be non-negative

• Source: 🕒 agent proposal (pending review)
• Entity: OrderItem
• Type: validation
• Statement: Adding a negative quantity of units to an existing order item is rejected with OrderingDomainException 'Invalid units'.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:54
• Evidence:

if (units < 0) { throw new OrderingDomainException("Invalid units"); }

#10 — Discount cannot exceed order item total

• Source: 🕒 agent proposal (pending review)
• Entity: OrderItem
• Type: validation
• Statement: An order item cannot be created when the applied discount is greater than the line total (unitPrice * units); raises OrderingDomainException 'The total of order item is lower than applied discount'.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:30
• Evidence:

if ((unitPrice * units) < discount) { throw new OrderingDomainException("The total of order item is lower than applied discount"); }

#11 — Order item units must be positive

• Source: 🕒 agent proposal (pending review)
• Entity: OrderItem
• Type: validation
• Statement: An order item cannot be created with zero or negative units; violating this raises OrderingDomainException 'Invalid number of units'.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderItem.cs:25
• Evidence:

if (units <= 0) { throw new OrderingDomainException("Invalid number of units"); }

OrderStatus (1)

#1 — Order lifecycle states

• Source: 🕒 agent proposal (pending review)
• Entity: OrderStatus
• Type: state_machine
• Statement: An order has exactly six lifecycle states: Submitted (1), AwaitingValidation (2), StockConfirmed (3), Paid (4), Shipped (5) and Cancelled (6). The happy path progresses Submitted -> AwaitingValidation -> StockConfirmed -> Paid -> Shipped; Cancelled is the terminal failure state.
• Anchor: src/Ordering.Domain/AggregatesModel/OrderAggregate/OrderStatus.cs:5
• Evidence:

public enum OrderStatus { Submitted = 1, AwaitingValidation = 2, StockConfirmed = 3, Paid = 4, Shipped = 5, Cancelled = 6 }

PaymentMethod (4)

#1 — Required on PaymentMethod

• Source: 🔧 heuristic
• Entity: PaymentMethod
• Type: validation
• Statement: Required on PaymentMethod
• Anchor: src/Ordering.Domain/AggregatesModel/BuyerAggregate/PaymentMethod.cs:7
• Evidence:

[Required]

#2 — Payment method identity = card type + number + expiration

• Source: 🕒 agent proposal (pending review)
• Entity: PaymentMethod
• Type: invariant
• Statement: Two payment methods are considered the same if and only if card type id, card number and expiration date all match; alias, holder name and security number do not participate in identity.
• Anchor: src/Ordering.Domain/AggregatesModel/BuyerAggregate/PaymentMethod.cs:37
• Evidence:

return _cardTypeId == cardTypeId && _cardNumber == cardNumber && _expiration == expiration;

#3 — Expired card rejected

• Source: 🕒 agent proposal (pending review)
• Entity: PaymentMethod
• Type: validation
• Statement: A payment method cannot be created with an expiration date in the past (compared to current UTC time); it raises OrderingDomainException.
• Anchor: src/Ordering.Domain/AggregatesModel/BuyerAggregate/PaymentMethod.cs:27
• Evidence:

if (expiration < DateTime.UtcNow) { throw new OrderingDomainException(nameof(expiration)); }

#4 — Payment method mandatory card data

• Source: 🕒 agent proposal (pending review)
• Entity: PaymentMethod
• Type: validation
• Statement: A payment method requires non-blank card number, security number and card holder name; missing data raises OrderingDomainException.
• Anchor: src/Ordering.Domain/AggregatesModel/BuyerAggregate/PaymentMethod.cs:21
• Evidence:

_cardNumber = !string.IsNullOrWhiteSpace(cardNumber) ? cardNumber : throw new OrderingDomainException(nameof(cardNumber));

ProductPriceChangedIntegrationEvent (2)

#1 — Event and catalog change persist in one local transaction (outbox)

• Source: 🕒 agent proposal (pending review)
• Entity: ProductPriceChangedIntegrationEvent
• Type: business_rule
• Statement: SaveEventAndCatalogContextChangesAsync persists the catalog DB change and the integration event log entry inside a single resilient local transaction, guaranteeing atomicity between the catalog update and the outgoing event (outbox pattern).
• Anchor: src/Catalog.API/IntegrationEvents/CatalogIntegrationEventService.cs:28
• Evidence:

await ResilientTransaction.New(catalogContext).ExecuteAsync(async () => { await catalogContext.SaveChangesAsync(); await integrationEventLogService.SaveEventAsync(evt, catalogContext.Database.CurrentTransaction); });

#2 — Event publish lifecycle: InProgress -> Published, Failed on error

• Source: 🕒 agent proposal (pending review)
• Entity: ProductPriceChangedIntegrationEvent
• Type: state_transition
• Statement: Publishing an integration event marks it InProgress in the event log, publishes to the event bus, then marks it Published; any exception marks the event Failed instead of propagating, so the event log always reflects the delivery outcome.
• Anchor: src/Catalog.API/IntegrationEvents/CatalogIntegrationEventService.cs:11
• Evidence:

await integrationEventLogService.MarkEventAsInProgressAsync(evt.Id); await eventBus.PublishAsync(evt); await integrationEventLogService.MarkEventAsPublishedAsync(evt.Id); ... catch { await integrationEventLogService.MarkEventAsFailedAsync(evt.Id); }

ProfileService (2)

#1 — ArgumentException in ProfileService

• Source: 🔧 heuristic
• Entity: ProfileService
• Type: validation
• Statement: ArgumentException in ProfileService
• Anchor: src/Identity.API/Services/ProfileService.cs:20
• Evidence:

throw new ArgumentException("Invalid subject identifier"

#1 — InvalidOperationException in RabbitMQEventBus

• Source: 🔧 heuristic
• Entity: RabbitMQEventBus
• Type: validation
• Statement: InvalidOperationException in RabbitMQEventBus
• Anchor: src/EventBusRabbitMQ/RabbitMQEventBus.cs:40
• Evidence:

throw new InvalidOperationException("RabbitMQ connection is not open"

RegisterViewModel (3)

#1 — Required on RegisterViewModel

• Source: 🔧 heuristic
• Entity: RegisterViewModel
• Type: validation
• Statement: Required on RegisterViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/RegisterViewModel.cs:5
• Evidence:

[Required]

#2 — StringLength on RegisterViewModel

• Source: 🔧 heuristic
• Entity: RegisterViewModel
• Type: validation
• Statement: StringLength on RegisterViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/RegisterViewModel.cs:11
• Evidence:

[StringLength(100, ErrorMessage = "The {0} must be at least {2} and at max {1} characters long.", MinimumLength = 6)]

#3 — Compare on RegisterViewModel

• Source: 🔧 heuristic
• Entity: RegisterViewModel
• Type: validation
• Statement: Compare on RegisterViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/RegisterViewModel.cs:18
• Evidence:

[Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]

RequestProvider (2)

#1 — Required on ResetPasswordViewModel

• Source: 🔧 heuristic
• Entity: ResetPasswordViewModel
• Type: validation
• Statement: Required on ResetPasswordViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/ResetPasswordViewModel.cs:5
• Evidence:

[Required]

#2 — StringLength on ResetPasswordViewModel

• Source: 🔧 heuristic
• Entity: ResetPasswordViewModel
• Type: validation
• Statement: StringLength on ResetPasswordViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/ResetPasswordViewModel.cs:10
• Evidence:

[StringLength(100, ErrorMessage = "The {0} must be at least {2} and at max {1} characters long.", MinimumLength = 6)]

#3 — Compare on ResetPasswordViewModel

• Source: 🔧 heuristic
• Entity: ResetPasswordViewModel
• Type: validation
• Statement: Compare on ResetPasswordViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/ResetPasswordViewModel.cs:16
• Evidence:

[Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]

SecuritySchemeDefinitionsTransformer (1)

#1 — Required on SetPasswordViewModel

• Source: 🔧 heuristic
• Entity: SetPasswordViewModel
• Type: validation
• Statement: Required on SetPasswordViewModel
• Anchor: src/Identity.API/Models/ManageViewModels/SetPasswordViewModel.cs:5
• Evidence:

[Required]

#2 — StringLength on SetPasswordViewModel

• Source: 🔧 heuristic
• Entity: SetPasswordViewModel
• Type: validation
• Statement: StringLength on SetPasswordViewModel
• Anchor: src/Identity.API/Models/ManageViewModels/SetPasswordViewModel.cs:6
• Evidence:

[StringLength(100, ErrorMessage = "The {0} must be at least {2} and at max {1} characters long.", MinimumLength = 6)]

#3 — Compare on SetPasswordViewModel

• Source: 🔧 heuristic
• Entity: SetPasswordViewModel
• Type: validation
• Statement: Compare on SetPasswordViewModel
• Anchor: src/Identity.API/Models/ManageViewModels/SetPasswordViewModel.cs:13
• Evidence:

[Compare("NewPassword", ErrorMessage = "The new password and confirmation password do not match.")]

TestServerCallContext (1)

#1 — InvalidOperationException in TestServerCallContext

• Source: 🔧 heuristic
• Entity: TestServerCallContext
• Type: validation
• Statement: InvalidOperationException in TestServerCallContext
• Anchor: tests/Basket.UnitTests/Helpers/TestServerCallContext.cs:45
• Evidence:

throw new InvalidOperationException("Response headers have already been written."

VerifyCodeViewModel (1)

#1 — Required on VerifyCodeViewModel

• Source: 🔧 heuristic
• Entity: VerifyCodeViewModel
• Type: validation
• Statement: Required on VerifyCodeViewModel
• Anchor: src/Identity.API/Models/AccountViewModels/VerifyCodeViewModel.cs:5
• Evidence:

[Required]

VerifyPhoneNumberViewModel (1)

#1 — Required on VerifyPhoneNumberViewModel

• Source: 🔧 heuristic
• Entity: VerifyPhoneNumberViewModel
• Type: validation
• Statement: Required on VerifyPhoneNumberViewModel
• Anchor: src/Identity.API/Models/ManageViewModels/VerifyPhoneNumberViewModel.cs:5
• Evidence:

[Required]

VisualElementExtensions (2)

#1 — Required on WebhookSubscription

• Source: 🔧 heuristic
• Entity: WebhookSubscription
• Type: validation
• Statement: Required on WebhookSubscription
• Anchor: src/Webhooks.API/Model/WebhookSubscription.cs:9
• Evidence:

[Required]

#2 — Grant URL must share origin with hook URL

• Source: 🕒 agent proposal (pending review)
• Entity: WebhookSubscription
• Type: validation
• Statement: A webhook grant URL is only accepted if it belongs to the same origin (same scheme, host and port) as the hook URL; otherwise the grant test fails immediately without any HTTP call.
• Anchor: src/Webhooks.API/Services/GrantUrlTesterService.cs:7
• Evidence:

if (!CheckSameOrigin(urlHook, url)) { logger.LogWarning(...do not belong to same origin); return false; } — CheckSameOrigin compares Scheme, Port and Host (lines 38-46)

#3 — Unreachable grant URL cannot be granted

• Source: 🕒 agent proposal (pending review)
• Entity: WebhookSubscription
• Type: error_handling
• Statement: Any exception while sending the OPTIONS verification request (unreachable host, network failure, etc.) means the URL cannot be granted: the test returns false instead of propagating the error.
• Anchor: src/Webhooks.API/Services/GrantUrlTesterService.cs:29
• Evidence:

catch (Exception ex) { logger.LogWarning("Exception {TypeName} when sending OPTIONS request. Url can't be granted.", ex.GetType().Name); return false; }

#4 — Grant URL verified via OPTIONS challenge with token echo

• Source: 🕒 agent proposal (pending review)
• Entity: WebhookSubscription
• Type: validation
• Statement: Before a webhook URL is granted, it must answer an HTTP OPTIONS request carrying the X-eshop-whtoken header: the grant succeeds only if the response has a success status code AND the token echoed back in the X-eshop-whtoken response header equals the expected token (null when no token was provided).
• Anchor: src/Webhooks.API/Services/GrantUrlTesterService.cs:13
• Evidence:

var msg = new HttpRequestMessage(HttpMethod.Options, url); msg.Headers.Add("X-eshop-whtoken", token); ... return response.IsSuccessStatusCode && tokenReceived == tokenExpected; (tokenExpected = string.IsNullOrWhiteSpace(token) ? null : token)

Analysis depth

85 heuristic rules · 97 agent proposals (pending review) · 0 promoted

In Silex Pro, enrichment runs on its own — in batch and continuously, without depending on your agent.

Enums (7)

Gaps found (77)

🔴 Critical: 56 | 🟡 Warnings: 21

Next steps

→ Validate the extracted rules with a domain expert → Fix the critical gaps before migrating → Review the warnings — some may be acceptable for an MVP

Report generated by Silex Arqueologia · Documentation · Support