Prompt file imported from refahigroup/refahiplus-api (.codex/prompts/09-Phase-25a-shopproductvariant-backfill-audit-tooling.md). Copyright stays with the author.

Codex Implementation Prompt — Phase 25A: ShopProductVariant Backfill and Audit Tooling

Name: 09-Phase-25a-shopproductvariant-backfill-audit-tooling
Author: refahigroup

Read .codex/prompts/_session-bootstrap.md first. Then read AGENTS.md. Load only the relevant backend/module/store architecture skills from .codex/skills/.

This is a focused Backend API implementation task.

Run this prompt from:

C:\Workspace\repo\refahiplus-api

Do not modify Admin Web. Do not modify Customer WebApp. Do not modify Docker/GitHub Actions. Do not remove runtime fallback behavior. Do not remove ProductVariant.PriceMinor. Do not remove ShopProduct.Price. Do not change cart/checkout pricing behavior except for safe reporting/audit metadata if needed. Do not apply migrations to a real database. Do not make production release decisions.

Mandatory Report Output

At the end of this task, save the final report as:

.codex/reports/phase-25a-shopproductvariant-backfill-audit-tooling.md

If .codex/reports/ does not exist, create it.

Also print the same report in the Codex final response.

Context

The Store pricing refactor has reached this state:

ShopProductVariant exists in backend domain, persistence, contracts, and admin endpoints.
Admin Web can manage shop-specific variant offerings.
Backend runtime price resolver uses:
- ShopProduct for non-variant products;
- active ShopProductVariant for variant products;
- temporary fallback to ProductVariant when no non-deleted ShopProductVariant exists.
Customer WebApp consumes shop-specific variant price fields.
Customer WebApp now passes explicit shopSlug to product detail API on shop-specific product detail routes.

The next required step is data readiness:

Existing ShopProduct rows whose Product has variants need corresponding ShopProductVariant rows.

Current migration/fallback strategy:

- Do not remove fallback yet.
- First add audit/backfill tooling.
- Backfill missing ShopProductVariant rows from existing ProductVariant base prices.
- Validate data.
- Then in a later phase remove fallback and reject missing shop variant offerings.

Goal

Add backend audit and controlled backfill tooling for ShopProductVariant.

After this phase:

Admin/backend can audit ShopProduct rows with variant products and detect missing ShopProductVariant offerings.
Admin/backend can run a controlled backfill that creates missing ShopProductVariant rows.
Backfill uses ProductVariant.PriceMinor and ProductVariant.DiscountedPriceMinor as initial shop-specific variant prices.
Existing configured ShopProductVariant rows are never overwritten.
Products without variants are ignored.
Deleted/inactive products or deleted shop products are handled safely according to current Store rules.
Runtime fallback remains active.
No Admin Web or Customer WebApp source is changed.

Repository

Primary repository:

C:\Workspace\repo\refahiplus-api

Do not modify:

C:\Workspace\repo\refahiplus-admin
C:\Workspace\repo\refahiplus-webapp

Required Pre-Check

Run:

git status --short

Report dirty state clearly.

If the repo is not clean, preserve existing user changes and do not touch unrelated files.

Required Investigation Before Editing

Inspect current implementation and follow existing conventions.

Search for:

ShopProduct
ShopProductVariant
ProductVariant
ShopProductRepository
IShopProductRepository
StoreDbContext
ShopProductsEndpoints
AdminOnly
ApiResponseHelper
ProductVariant.PriceMinor
DiscountedPriceMinor
IsActive
IsDeleted
GetWithVariantOfferingsAsync
StoreProductPriceResolver

Likely areas:

src/Refahi.Modules.Store.Domain/
src/Refahi.Modules.Store.Application.Contracts/
src/Refahi.Modules.Store.Application/
src/Refahi.Modules.Store.Api/
src/Refahi.Modules.Store.Infrastructure/
src/Refahi.Modules.Store.Infrastructure/Persistence/

Do not assume file names. Use actual project structure.

Required Design

Implement this as controlled tooling, not an automatic migration backfill.

Preferred shape:

1. Audit query:
   tells admin how many ShopProductVariant rows are missing.

2. Backfill command:
   creates missing ShopProductVariant rows using ProductVariant base prices.

3. Optional dry-run:
   returns what would be created without writing.

Do not automatically backfill in EF migration unless the project already has a strong convention for data migrations. Schema already exists from Phase 19, so no schema migration should be needed unless a small support field is absolutely required.

Required Implementation Areas

1. Audit DTO / Query Contract

Add application contract for audit.

Suggested query:

public sealed record GetShopProductVariantBackfillAuditQuery(
    Guid? ShopId = null,
    Guid? ProductId = null
) : IRequest<ShopProductVariantBackfillAuditDto>;

Suggested DTOs:

public sealed record ShopProductVariantBackfillAuditDto(
    int ShopProductsChecked,
    int ProductsWithVariants,
    int ExistingOfferings,
    int MissingOfferings,
    IReadOnlyList<ShopProductVariantBackfillAuditItemDto> Items
);

public sealed record ShopProductVariantBackfillAuditItemDto(
    Guid ShopId,
    string ShopName,
    Guid ProductId,
    string ProductName,
    Guid ShopProductId,
    int VariantCount,
    int ExistingOfferingCount,
    int MissingOfferingCount
);

Adapt to project style.

Rules:

Optional ShopId and ProductId filters are useful but not mandatory if they complicate implementation.
Include enough data for QA.
Avoid returning huge lists without a reasonable cap/paging if the project has pagination conventions.
At minimum, return counts plus first N details.

2. Backfill Command Contract

Add command:

public sealed record BackfillShopProductVariantsCommand(
    Guid? ShopId = null,
    Guid? ProductId = null,
    bool DryRun = true
) : IRequest<ShopProductVariantBackfillResultDto>;

3. Application Handler Logic

Implement handlers in Store Application.

Expected algorithm:

For each non-deleted ShopProduct matching optional filters:
  Load Product with variants.
  If product has no variants:
    continue.
  Load existing non-deleted ShopProductVariant offerings.
  For each ProductVariant belonging to Product:
    If offering exists:
      skip.
    Else:
      if variant price is valid:
        in dry-run: add to CreatedItems preview.
        in write mode: create ShopProductVariant with base variant price.
      else:
        skip and warn.

Important:

Do not change ProductVariant.PriceMinor.
Do not change ShopProduct.Price.
Do not change stock/capacity.
Do not activate/deactivate ShopProduct.
Do not modify cart/order data.

4. Domain Method Reuse

Use existing ShopProduct aggregate methods from Phase 19 to create offerings when writing.

Do not bypass domain validation by inserting raw entities unless unavoidable.

5. Repository / Persistence

Use existing repositories where possible.

If needed, add narrow repository methods for:

ListShopProductsWithProductsAndVariantOfferingsAsync(...)

or equivalent.

Avoid N+1 queries if reasonably possible, but keep implementation clear and safe.

This phase is operational tooling; performance should be acceptable for admin backfill, but report if the implementation is not suitable for very large datasets.

6. API Endpoints

Add admin-only endpoints.

Suggested route group under Store admin/shop products:

GET  /admin/shop-product-variants/backfill/audit
POST /admin/shop-product-variants/backfill

or use current endpoint conventions.

Query/body examples:

GET /admin/shop-product-variants/backfill/audit?shopId={shopId}&productId={productId}

POST /admin/shop-product-variants/backfill
{
  "shopId": null,
  "productId": null,
  "dryRun": true
}

Rules:

Use AdminOnly.
Use existing response wrapper conventions.
Do not expose as public/customer API.
Make dry-run the safe default.

7. Safety / Idempotency

Backfill must be idempotent.

Running it multiple times should:

- create missing rows on first write run;
- create zero rows on subsequent write runs;
- never duplicate non-deleted rows;
- never overwrite configured prices.

8. Backward Compatibility

Preserve:

Existing ShopProductVariant admin endpoints.
Existing runtime price resolver.
Existing ProductVariant fallback behavior.
Existing cart/add/sync/checkout behavior.
Existing product detail behavior.
Existing Admin/WebApp compatibility.
Existing migrations.
Existing Orders/Wallet behavior.

9. Logging / Reporting

If existing logging is available, log write-mode backfill summary.

Do not log every row unless current style supports it and volume is small.

Final report must clearly state:

- whether this is dry-run capable;
- whether it writes only missing rows;
- whether fallback remains active;
- whether actual database backfill was executed.

10. Strict Out of Scope

Do not:

Modify Admin Web.
Modify Customer WebApp.
Remove ProductVariant fallback.
Enforce missing ShopProductVariant rejection.
Change runtime cart/checkout pricing rules.
Add shop-level stock/capacity override.
Add reservation/ledger.
Add remaining capacity display.
Modify Orders/Wallet.
Create data rows in a real database.
Apply migrations to a real database.
Change auth/security.
Change Docker/GitHub Actions.
Change package versions or target frameworks.
Mark production-ready.

Validation

From backend repository root, run:

dotnet restore .\Refahi.Backend.slnx
dotnet build .\Refahi.Backend.slnx --configuration Release --no-restore
dotnet test .\Refahi.Backend.slnx --configuration Release --no-build

If Store tests exist or can be added safely, add focused tests for:

- Audit counts missing offerings correctly.
- Dry-run backfill creates no rows.
- Write backfill creates missing rows.
- Second write backfill is idempotent.
- Existing offering price is not overwritten.
- Invalid variant price is skipped/warned.

Do not introduce a new test framework if no Store test infrastructure exists.

Do not claim validation passed unless commands actually pass.

Manual QA

Manual API QA is optional.

If local API/auth/test data exists, test:

- Run audit for all shops/products.
- Run dry-run backfill for a product with variants.
- Run write backfill for that product.
- Re-run audit and confirm missing count decreases.
- Re-run write backfill and confirm created count is zero.
- Verify existing configured ShopProductVariant prices are not overwritten.

If manual QA is not possible, report it as not run.

Final Report Format

Save the report to:

.codex/reports/phase-25a-shopproductvariant-backfill-audit-tooling.md

Use exactly this structure:

Summary:
- ...

Skills used:
- ...

Repository checked:
- ...

Git state:
- Pre-check:
- Final:

Files changed:
- ...

Audit contract/API:
- ...

Backfill contract/API:
- ...

Backfill behavior:
- ...

Safety/idempotency:
- ...

Repository/persistence changes:
- ...

Backward compatibility:
- ...

Validation:
- Command: ...
  Result: ...

Manual QA:
- ...

Fallback behavior:
- ...

Deferred items:
- ...

Risks / assumptions:
- ...

Suggested next phase:
- ...

# Codex Implementation Prompt — Phase 25A: ShopProductVariant Backfill and Audit Tooling Read `.codex/prompts/_session-bootstrap.md` first. Then read `AGENTS.md`. Load only the relevant backend/module/store architecture skills from `.codex/skills/`. This is a focused Backend API implementation task. Run this prompt from: ```text id="tjryy7" C:\Workspace\repo\refahiplus-api ``` Do not modify Admin Web. Do not modify Customer WebApp. Do not modify Docker/GitHub Actions. Do not remove runtime fallback behavior. Do not remove `ProductVariant.PriceMinor`. Do not remove `ShopProduct.Price`. Do not change cart/checkout pricing behavior except for safe reporting/audit metadata if needed. Do not apply migrations to a real database. Do not make production release decisions. ## Mandatory Report Output At the end of this task, save the final report as: ```text id="pga24c" .codex/reports/phase-25a-shopproductvariant-backfill-audit-tooling.md ``` If `.codex/reports/` does not exist, create it. Also print the same report in the Codex final response. ## Context The Store pricing refactor has reached this state: * `ShopProductVariant` exists in backend domain, persistence, contracts, and admin endpoints. * Admin Web can manage shop-specific variant offerings. * Backend runtime price resolver uses: * `ShopProduct` for non-variant products; * active `ShopProductVariant` for variant products; * temporary fallback to `ProductVariant` when no non-deleted `ShopProductVariant` exists. * Customer WebApp consumes shop-specific variant price fields. * Customer WebApp now passes explicit `shopSlug` to product detail API on shop-specific product detail routes. The next required step is data readiness: ```text id="zv7jbd" Existing ShopProduct rows whose Product has variants need corresponding ShopProductVariant rows. ``` Current migration/fallback strategy: ```text id="4gq2xx" - Do not remove fallback yet. - First add audit/backfill tooling. - Backfill missing ShopProductVariant rows from existing ProductVariant base prices. - Validate data. - Then in a later phase remove fallback and reject missing shop variant offerings. ``` ## Goal Add backend audit and controlled backfill tooling for `ShopProductVariant`. After this phase: * Admin/backend can audit `ShopProduct` rows with variant products and detect missing `ShopProductVariant` offerings. * Admin/backend can run a controlled backfill that creates missing `ShopProductVariant` rows. * Backfill uses `ProductVariant.PriceMinor` and `ProductVariant.DiscountedPriceMinor` as initial shop-specific variant prices. * Existing configured `ShopProductVariant` rows are never overwritten. * Products without variants are ignored. * Deleted/inactive products or deleted shop products are handled safely according to current Store rules. * Runtime fallback remains active. * No Admin Web or Customer WebApp source is changed. ## Repository Primary repository: ```text id="zcmx0m" C:\Workspace\repo\refahiplus-api ``` Do not modify: ```text id="xqrbpb" C:\Workspace\repo\refahiplus-admin C:\Workspace\repo\refahiplus-webapp ``` ## Required Pre-Check Run: ```bash id="e8yi5o" git status --short ``` Report dirty state clearly. If the repo is not clean, preserve existing user changes and do not touch unrelated files. ## Required Investigation Before Editing Inspect current implementation and follow existing conventions. Search for: ```text id="lprewi" ShopProduct ShopProductVariant ProductVariant ShopProductRepository IShopProductRepository StoreDbContext ShopProductsEndpoints AdminOnly ApiResponseHelper ProductVariant.PriceMinor DiscountedPriceMinor IsActive IsDeleted GetWithVariantOfferingsAsync StoreProductPriceResolver ``` Likely areas: ```text id="mzalqq" src/Refahi.Modules.Store.Domain/ src/Refahi.Modules.Store.Application.Contracts/ src/Refahi.Modules.Store.Application/ src/Refahi.Modules.Store.Api/ src/Refahi.Modules.Store.Infrastructure/ src/Refahi.Modules.Store.Infrastructure/Persistence/ ``` Do not assume file names. Use actual project structure. ## Required Design Implement this as **controlled tooling**, not an automatic migration backfill. Preferred shape: ```text id="qb0q3l" 1. Audit query: tells admin how many ShopProductVariant rows are missing. 2. Backfill command: creates missing ShopProductVariant rows using ProductVariant base prices. 3. Optional dry-run: returns what would be created without writing. ``` Do not automatically backfill in EF migration unless the project already has a strong convention for data migrations. Schema already exists from Phase 19, so no schema migration should be needed unless a small support field is absolutely required. ## Required Implementation Areas ### 1. Audit DTO / Query Contract Add application contract for audit. Suggested query: ```csharp id="p2kfxn" public sealed record GetShopProductVariantBackfillAuditQuery( Guid? ShopId = null, Guid? ProductId = null ) : IRequest<ShopProductVariantBackfillAuditDto>; ``` Suggested DTOs: ```csharp id="kqmkdu" public sealed record ShopProductVariantBackfillAuditDto( int ShopProductsChecked, int ProductsWithVariants, int ExistingOfferings, int MissingOfferings, IReadOnlyList<ShopProductVariantBackfillAuditItemDto> Items ); public sealed record ShopProductVariantBackfillAuditItemDto( Guid ShopId, string ShopName, Guid ProductId, string ProductName, Guid ShopProductId, int VariantCount, int ExistingOfferingCount, int MissingOfferingCount ); ``` Adapt to project style. Rules: * Optional `ShopId` and `ProductId` filters are useful but not mandatory if they complicate implementation. * Include enough data for QA. * Avoid returning huge lists without a reasonable cap/paging if the project has pagination conventions. * At minimum, return counts plus first N details. ### 2. Backfill Command Contract Add command: ```csharp id="0ezcgj" public sealed record BackfillShopProductVariantsCommand( Guid? ShopId = null, Guid? ProductId = null, bool DryRun = true ) : IRequest<ShopProductVariantBackfillResultDto>; ``` Suggested result DTO: ```csharp id="ci6hcy" public sealed record ShopProductVariantBackfillResultDto( bool DryRun, int ShopProductsChecked, int ProductsWithVariants, int CreatedOfferings, int SkippedExistingOfferings, int SkippedInvalidVariants, IReadOnlyList<ShopProductVariantBackfillCreatedItemDto> CreatedItems, IReadOnlyList<string> Warnings ); ``` Rules: * Default `DryRun = true`. * Actual write requires `DryRun = false`. * Existing configured offerings must not be overwritten. * Deleted offerings: * If a deleted offering exists and no non-deleted offering exists, treat it as missing and create a new non-deleted row, unless domain unique constraints prevent this. * Inactive non-deleted offerings: * Treat as existing and do not overwrite. * Missing offering: * Create new active offering by default. * Price from `ProductVariant.PriceMinor`. * Discount from `ProductVariant.DiscountedPriceMinor`. * If `ProductVariant.PriceMinor <= 0`, skip and warn. * If discounted price is invalid, either clear discount or skip with warning according to domain rules; prefer skip with clear warning if uncertain. * Products without variants are ignored. ### 3. Application Handler Logic Implement handlers in Store Application. Expected algorithm: ```text id="41y564" For each non-deleted ShopProduct matching optional filters: Load Product with variants. If product has no variants: continue. Load existing non-deleted ShopProductVariant offerings. For each ProductVariant belonging to Product: If offering exists: skip. Else: if variant price is valid: in dry-run: add to CreatedItems preview. in write mode: create ShopProductVariant with base variant price. else: skip and warn. ``` Important: * Do not change `ProductVariant.PriceMinor`. * Do not change `ShopProduct.Price`. * Do not change stock/capacity. * Do not activate/deactivate `ShopProduct`. * Do not modify cart/order data. ### 4. Domain Method Reuse Use existing `ShopProduct` aggregate methods from Phase 19 to create offerings when writing. Do not bypass domain validation by inserting raw entities unless unavoidable. ### 5. Repository / Persistence Use existing repositories where possible. If needed, add narrow repository methods for: ```csharp id="baxvaz" ListShopProductsWithProductsAndVariantOfferingsAsync(...) ``` or equivalent. Avoid N+1 queries if reasonably possible, but keep implementation clear and safe. This phase is operational tooling; performance should be acceptable for admin backfill, but report if the implementation is not suitable for very large datasets. ### 6. API Endpoints Add admin-only endpoints. Suggested route group under Store admin/shop products: ```text id="tc4fhn" GET /admin/shop-product-variants/backfill/audit POST /admin/shop-product-variants/backfill ``` or use current endpoint conventions. Query/body examples: ```http id="nv78vs" GET /admin/shop-product-variants/backfill/audit?shopId={shopId}&productId={productId} POST /admin/shop-product-variants/backfill { "shopId": null, "productId": null, "dryRun": true } ``` Rules: * Use `AdminOnly`. * Use existing response wrapper conventions. * Do not expose as public/customer API. * Make dry-run the safe default. ### 7. Safety / Idempotency Backfill must be idempotent. Running it multiple times should: ```text id="vve04l" - create missing rows on first write run; - create zero rows on subsequent write runs; - never duplicate non-deleted rows; - never overwrite configured prices. ``` ### 8. Backward Compatibility Preserve: * Existing ShopProductVariant admin endpoints. * Existing runtime price resolver. * Existing ProductVariant fallback behavior. * Existing cart/add/sync/checkout behavior. * Existing product detail behavior. * Existing Admin/WebApp compatibility. * Existing migrations. * Existing Orders/Wallet behavior. ### 9. Logging / Reporting If existing logging is available, log write-mode backfill summary. Do not log every row unless current style supports it and volume is small. Final report must clearly state: ```text id="42arqf" - whether this is dry-run capable; - whether it writes only missing rows; - whether fallback remains active; - whether actual database backfill was executed. ``` ### 10. Strict Out of Scope Do not: * Modify Admin Web. * Modify Customer WebApp. * Remove ProductVariant fallback. * Enforce missing ShopProductVariant rejection. * Change runtime cart/checkout pricing rules. * Add shop-level stock/capacity override. * Add reservation/ledger. * Add remaining capacity display. * Modify Orders/Wallet. * Create data rows in a real database. * Apply migrations to a real database. * Change auth/security. * Change Docker/GitHub Actions. * Change package versions or target frameworks. * Mark production-ready. ## Validation From backend repository root, run: ```bash id="zkctw5" dotnet restore .\Refahi.Backend.slnx dotnet build .\Refahi.Backend.slnx --configuration Release --no-restore dotnet test .\Refahi.Backend.slnx --configuration Release --no-build ``` If Store tests exist or can be added safely, add focused tests for: ```text id="6545ww" - Audit counts missing offerings correctly. - Dry-run backfill creates no rows. - Write backfill creates missing rows. - Second write backfill is idempotent. - Existing offering price is not overwritten. - Invalid variant price is skipped/warned. ``` Do not introduce a new test framework if no Store test infrastructure exists. Do not claim validation passed unless commands actually pass. ## Manual QA Manual API QA is optional. If local API/auth/test data exists, test: ```text id="h4hksd" - Run audit for all shops/products. - Run dry-run backfill for a product with variants. - Run write backfill for that product. - Re-run audit and confirm missing count decreases. - Re-run write backfill and confirm created count is zero. - Verify existing configured ShopProductVariant prices are not overwritten. ``` If manual QA is not possible, report it as not run. ## Final Report Format Save the report to: ```text id="q12pgb" .codex/reports/phase-25a-shopproductvariant-backfill-audit-tooling.md ``` Use exactly this structure: ```text id="gb8tg3" Summary: - ... Skills used: - ... Repository checked: - ... Git state: - Pre-check: - Final: Files changed: - ... Audit contract/API: - ... Backfill contract/API: - ... Backfill behavior: - ... Safety/idempotency: - ... Repository/persistence changes: - ... Backward compatibility: - ... Validation: - Command: ... Result: ... Manual QA: - ... Fallback behavior: - ... Deferred items: - ... Risks / assumptions: - ... Suggested next phase: - ... ```

{ "prompt": "# Codex Implementation Prompt — Phase 25A: ShopProductVariant Backfill and Audit Tooling\n\nRead `.codex/prompts/_session-bootstrap.md` first.\nThen read `AGENTS.md`.\nLoad only the relevant backend/module/store architecture skills from `.codex/skills/`.\n\nThis is a focused Backend API implementation task.\n\nRun this prompt from:\n\n```text id=\"tjryy7\"\nC:\\Workspace\\repo\\refahiplus-api\n```\n\nDo not modify Admin Web.\nDo not modify Customer WebApp.\nDo not modify Docker/GitHub Actions.\nDo not remove runtime fallback behavior.\nDo not remove `ProductVariant.PriceMinor`.\nDo not remove `ShopProduct.Price`.\nDo not change cart/checkout pricing behavior except for safe reporting/audit metadata if needed.\nDo not apply migrations to a real database.\nDo not make production release decisions.\n\n## Mandatory Report Output\n\nAt the end of this task, save the final report as:\n\n```text id=\"pga24c\"\n.codex/reports/phase-25a-shopproductvariant-backfill-audit-tooling.md\n```\n\nIf `.codex/reports/` does not exist, create it.\n\nAlso print the same report in the Codex final response.\n\n## Context\n\nThe Store pricing refactor has reached this state:\n\n* `ShopProductVariant` exists in backend domain, persistence, contracts, and admin endpoints.\n* Admin Web can manage shop-specific variant offerings.\n* Backend runtime price resolver uses:\n\n * `ShopProduct` for non-variant products;\n * active `ShopProductVariant` for variant products;\n * temporary fallback to `ProductVariant` when no non-deleted `ShopProductVariant` exists.\n* Customer WebApp consumes shop-specific variant price fields.\n* Customer WebApp now passes explicit `shopSlug` to product detail API on shop-specific product detail routes.\n\nThe next required step is data readiness:\n\n```text id=\"zv7jbd\"\nExisting ShopProduct rows whose Product has variants need corresponding ShopProductVariant rows.\n```\n\nCurrent migration/fallback strategy:\n\n```text id=\"4gq2xx\"\n- Do not remove fallback yet.\n- First add audit/backfill tooling.\n- Backfill missing ShopProductVariant rows from existing ProductVariant base prices.\n- Validate data.\n- Then in a later phase remove fallback and reject missing shop variant offerings.\n```\n\n## Goal\n\nAdd backend audit and controlled backfill tooling for `ShopProductVariant`.\n\nAfter this phase:\n\n* Admin/backend can audit `ShopProduct` rows with variant products and detect missing `ShopProductVariant` offerings.\n* Admin/backend can run a controlled backfill that creates missing `ShopProductVariant` rows.\n* Backfill uses `ProductVariant.PriceMinor` and `ProductVariant.DiscountedPriceMinor` as initial shop-specific variant prices.\n* Existing configured `ShopProductVariant` rows are never overwritten.\n* Products without variants are ignored.\n* Deleted/inactive products or deleted shop products are handled safely according to current Store rules.\n* Runtime fallback remains active.\n* No Admin Web or Customer WebApp source is changed.\n\n## Repository\n\nPrimary repository:\n\n```text id=\"zcmx0m\"\nC:\\Workspace\\repo\\refahiplus-api\n```\n\nDo not modify:\n\n```text id=\"xqrbpb\"\nC:\\Workspace\\repo\\refahiplus-admin\nC:\\Workspace\\repo\\refahiplus-webapp\n```\n\n## Required Pre-Check\n\nRun:\n\n```bash id=\"e8yi5o\"\ngit status --short\n```\n\nReport dirty state clearly.\n\nIf the repo is not clean, preserve existing user changes and do not touch unrelated files.\n\n## Required Investigation Before Editing\n\nInspect current implementation and follow existing conventions.\n\nSearch for:\n\n```text id=\"lprewi\"\nShopProduct\nShopProductVariant\nProductVariant\nShopProductRepository\nIShopProductRepository\nStoreDbContext\nShopProductsEndpoints\nAdminOnly\nApiResponseHelper\nProductVariant.PriceMinor\nDiscountedPriceMinor\nIsActive\nIsDeleted\nGetWithVariantOfferingsAsync\nStoreProductPriceResolver\n```\n\nLikely areas:\n\n```text id=\"mzalqq\"\nsrc/Refahi.Modules.Store.Domain/\nsrc/Refahi.Modules.Store.Application.Contracts/\nsrc/Refahi.Modules.Store.Application/\nsrc/Refahi.Modules.Store.Api/\nsrc/Refahi.Modules.Store.Infrastructure/\nsrc/Refahi.Modules.Store.Infrastructure/Persistence/\n```\n\nDo not assume file names. Use actual project structure.\n\n## Required Design\n\nImplement this as **controlled tooling**, not an automatic migration backfill.\n\nPreferred shape:\n\n```text id=\"qb0q3l\"\n1. Audit query:\n tells admin how many ShopProductVariant rows are missing.\n\n2. Backfill command:\n creates missing ShopProductVariant rows using ProductVariant base prices.\n\n3. Optional dry-run:\n returns what would be created without writing.\n```\n\nDo not automatically backfill in EF migration unless the project already has a strong convention for data migrations.\nSchema already exists from Phase 19, so no schema migration should be needed unless a small support field is absolutely required.\n\n## Required Implementation Areas\n\n### 1. Audit DTO / Query Contract\n\nAdd application contract for audit.\n\nSuggested query:\n\n```csharp id=\"p2kfxn\"\npublic sealed record GetShopProductVariantBackfillAuditQuery(\n Guid? ShopId = null,\n Guid? ProductId = null\n) : IRequest<ShopProductVariantBackfillAuditDto>;\n```\n\nSuggested DTOs:\n\n```csharp id=\"kqmkdu\"\npublic sealed record ShopProductVariantBackfillAuditDto(\n int ShopProductsChecked,\n int ProductsWithVariants,\n int ExistingOfferings,\n int MissingOfferings,\n IReadOnlyList<ShopProductVariantBackfillAuditItemDto> Items\n);\n\npublic sealed record ShopProductVariantBackfillAuditItemDto(\n Guid ShopId,\n string ShopName,\n Guid ProductId,\n string ProductName,\n Guid ShopProductId,\n int VariantCount,\n int ExistingOfferingCount,\n int MissingOfferingCount\n);\n```\n\nAdapt to project style.\n\nRules:\n\n* Optional `ShopId` and `ProductId` filters are useful but not mandatory if they complicate implementation.\n* Include enough data for QA.\n* Avoid returning huge lists without a reasonable cap/paging if the project has pagination conventions.\n* At minimum, return counts plus first N details.\n\n### 2. Backfill Command Contract\n\nAdd command:\n\n```csharp id=\"0ezcgj\"\npublic sealed record BackfillShopProductVariantsCommand(\n Guid? ShopId = null,\n Guid? ProductId = null,\n bool DryRun = true\n) : IRequest<ShopProductVariantBackfillResultDto>;\n```\n\nSuggested result DTO:\n\n```csharp id=\"ci6hcy\"\npublic sealed record ShopProductVariantBackfillResultDto(\n bool DryRun,\n int ShopProductsChecked,\n int ProductsWithVariants,\n int CreatedOfferings,\n int SkippedExistingOfferings,\n int SkippedInvalidVariants,\n IReadOnlyList<ShopProductVariantBackfillCreatedItemDto> CreatedItems,\n IReadOnlyList<string> Warnings\n);\n```\n\nRules:\n\n* Default `DryRun = true`.\n* Actual write requires `DryRun = false`.\n* Existing configured offerings must not be overwritten.\n* Deleted offerings:\n\n * If a deleted offering exists and no non-deleted offering exists, treat it as missing and create a new non-deleted row, unless domain unique constraints prevent this.\n* Inactive non-deleted offerings:\n\n * Treat as existing and do not overwrite.\n* Missing offering:\n\n * Create new active offering by default.\n * Price from `ProductVariant.PriceMinor`.\n * Discount from `ProductVariant.DiscountedPriceMinor`.\n* If `ProductVariant.PriceMinor <= 0`, skip and warn.\n* If discounted price is invalid, either clear discount or skip with warning according to domain rules; prefer skip with clear warning if uncertain.\n* Products without variants are ignored.\n\n### 3. Application Handler Logic\n\nImplement handlers in Store Application.\n\nExpected algorithm:\n\n```text id=\"41y564\"\nFor each non-deleted ShopProduct matching optional filters:\n Load Product with variants.\n If product has no variants:\n continue.\n Load existing non-deleted ShopProductVariant offerings.\n For each ProductVariant belonging to Product:\n If offering exists:\n skip.\n Else:\n if variant price is valid:\n in dry-run: add to CreatedItems preview.\n in write mode: create ShopProductVariant with base variant price.\n else:\n skip and warn.\n```\n\nImportant:\n\n* Do not change `ProductVariant.PriceMinor`.\n* Do not change `ShopProduct.Price`.\n* Do not change stock/capacity.\n* Do not activate/deactivate `ShopProduct`.\n* Do not modify cart/order data.\n\n### 4. Domain Method Reuse\n\nUse existing `ShopProduct` aggregate methods from Phase 19 to create offerings when writing.\n\nDo not bypass domain validation by inserting raw entities unless unavoidable.\n\n### 5. Repository / Persistence\n\nUse existing repositories where possible.\n\nIf needed, add narrow repository methods for:\n\n```csharp id=\"baxvaz\"\nListShopProductsWithProductsAndVariantOfferingsAsync(...)\n```\n\nor equivalent.\n\nAvoid N+1 queries if reasonably possible, but keep implementation clear and safe.\n\nThis phase is operational tooling; performance should be acceptable for admin backfill, but report if the implementation is not suitable for very large datasets.\n\n### 6. API Endpoints\n\nAdd admin-only endpoints.\n\nSuggested route group under Store admin/shop products:\n\n```text id=\"tc4fhn\"\nGET /admin/shop-product-variants/backfill/audit\nPOST /admin/shop-product-variants/backfill\n```\n\nor use current endpoint conventions.\n\nQuery/body examples:\n\n```http id=\"nv78vs\"\nGET /admin/shop-product-variants/backfill/audit?shopId={shopId}&productId={productId}\n\nPOST /admin/shop-product-variants/backfill\n{\n \"shopId\": null,\n \"productId\": null,\n \"dryRun\": true\n}\n```\n\nRules:\n\n* Use `AdminOnly`.\n* Use existing response wrapper conventions.\n* Do not expose as public/customer API.\n* Make dry-run the safe default.\n\n### 7. Safety / Idempotency\n\nBackfill must be idempotent.\n\nRunning it multiple times should:\n\n```text id=\"vve04l\"\n- create missing rows on first write run;\n- create zero rows on subsequent write runs;\n- never duplicate non-deleted rows;\n- never overwrite configured prices.\n```\n\n### 8. Backward Compatibility\n\nPreserve:\n\n* Existing ShopProductVariant admin endpoints.\n* Existing runtime price resolver.\n* Existing ProductVariant fallback behavior.\n* Existing cart/add/sync/checkout behavior.\n* Existing product detail behavior.\n* Existing Admin/WebApp compatibility.\n* Existing migrations.\n* Existing Orders/Wallet behavior.\n\n### 9. Logging / Reporting\n\nIf existing logging is available, log write-mode backfill summary.\n\nDo not log every row unless current style supports it and volume is small.\n\nFinal report must clearly state:\n\n```text id=\"42arqf\"\n- whether this is dry-run capable;\n- whether it writes only missing rows;\n- whether fallback remains active;\n- whether actual database backfill was executed.\n```\n\n### 10. Strict Out of Scope\n\nDo not:\n\n* Modify Admin Web.\n* Modify Customer WebApp.\n* Remove ProductVariant fallback.\n* Enforce missing ShopProductVariant rejection.\n* Change runtime cart/checkout pricing rules.\n* Add shop-level stock/capacity override.\n* Add reservation/ledger.\n* Add remaining capacity display.\n* Modify Orders/Wallet.\n* Create data rows in a real database.\n* Apply migrations to a real database.\n* Change auth/security.\n* Change Docker/GitHub Actions.\n* Change package versions or target frameworks.\n* Mark production-ready.\n\n## Validation\n\nFrom backend repository root, run:\n\n```bash id=\"zkctw5\"\ndotnet restore .\\Refahi.Backend.slnx\ndotnet build .\\Refahi.Backend.slnx --configuration Release --no-restore\ndotnet test .\\Refahi.Backend.slnx --configuration Release --no-build\n```\n\nIf Store tests exist or can be added safely, add focused tests for:\n\n```text id=\"6545ww\"\n- Audit counts missing offerings correctly.\n- Dry-run backfill creates no rows.\n- Write backfill creates missing rows.\n- Second write backfill is idempotent.\n- Existing offering price is not overwritten.\n- Invalid variant price is skipped/warned.\n```\n\nDo not introduce a new test framework if no Store test infrastructure exists.\n\nDo not claim validation passed unless commands actually pass.\n\n## Manual QA\n\nManual API QA is optional.\n\nIf local API/auth/test data exists, test:\n\n```text id=\"h4hksd\"\n- Run audit for all shops/products.\n- Run dry-run backfill for a product with variants.\n- Run write backfill for that product.\n- Re-run audit and confirm missing count decreases.\n- Re-run write backfill and confirm created count is zero.\n- Verify existing configured ShopProductVariant prices are not overwritten.\n```\n\nIf manual QA is not possible, report it as not run.\n\n## Final Report Format\n\nSave the report to:\n\n```text id=\"q12pgb\"\n.codex/reports/phase-25a-shopproductvariant-backfill-audit-tooling.md\n```\n\nUse exactly this structure:\n\n```text id=\"gb8tg3\"\nSummary:\n- ...\n\nSkills used:\n- ...\n\nRepository checked:\n- ...\n\nGit state:\n- Pre-check:\n- Final:\n\nFiles changed:\n- ...\n\nAudit contract/API:\n- ...\n\nBackfill contract/API:\n- ...\n\nBackfill behavior:\n- ...\n\nSafety/idempotency:\n- ...\n\nRepository/persistence changes:\n- ...\n\nBackward compatibility:\n- ...\n\nValidation:\n- Command: ...\n Result: ...\n\nManual QA:\n- ...\n\nFallback behavior:\n- ...\n\nDeferred items:\n- ...\n\nRisks / assumptions:\n- ...\n\nSuggested next phase:\n- ...\n```", "variables": [], "notes": "Read `.codex/prompts/_session-bootstrap.md` first. Then read `AGENTS.md`. Load only the relevant backend/module/store architecture skills from `.codex/skills/`.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/refahigroup/refahiplus-api", "path": ".codex/prompts/09-Phase-25a-shopproductvariant-backfill-audit-tooling.md", "ref": "18003c6604b9e3d23b1d211e5ee0a2d42ee03cd4", "url": "https://github.com/refahigroup/refahiplus-api/blob/18003c6604b9e3d23b1d211e5ee0a2d42ee03cd4/.codex/prompts/09-Phase-25a-shopproductvariant-backfill-audit-tooling.md", "key": "refahigroup/refahiplus-api/.codex/prompts/09-Phase-25a-shopproductvariant-backfill-audit-tooling.md" } } }

09-Phase-25a-shopproductvariant-backfill-audit-tooling

About