Prompt file imported from refahigroup/refahiplus-api (.codex/prompts/03-persist-and-expose-productVariant-validityCapacity-fields.md). Copyright stays with the author.

Codex Implementation Prompt — Phase 9: Persist and Expose ProductVariant Validity/Capacity Fields

Name: 03-persist-and-expose-productVariant-validityCapacity-fields
Author: refahigroup

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

This is a focused Backend Store persistence and contract implementation task.

Do not modify Admin UI. Do not modify Customer WebApp. Do not modify Cart/Checkout behavior. Do not remove ProductSession. Do not make release decisions.

Mandatory Report Output

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

.codex/reports/03-persist-and-expose-productVariant-validityCapacity-fields.md

Also print the same report in the Codex final response.

Context

Phase 7 added domain-level validity and capacity semantics to ProductVariant.

Domain fields now exist:

FromDate
ToDate
CapacityType
Capacity
RequiresUsageDate
ValidateOrderEligibility(DateOnly? usageDate = null)
EnsureCapacityAvailable(int requestedQuantity, int soldCountInScope)

Phase 8 planning confirmed that these fields are not yet persisted, migrated, projected, or exposed end-to-end through backend contracts.

This phase must make the existing domain fields available through Backend Store persistence and backend contracts only.

Goal

Persist and expose ProductVariant validity/capacity fields end-to-end in the Backend Store module.

After this phase:

EF must map the new ProductVariant fields.
A Store migration must add the new columns.
Backend DTOs must expose the new fields.
Backend commands/validators must accept and validate the new fields when adding variants.
Product detail/admin query projections must return the new fields.
Existing legacy ProductSession flows must remain untouched.
Existing product/session/cart/checkout behavior must not change.

Repositories

Primary repository:

C:\Workspace\repo\refahiplus-api

Admin repository should not be modified in this phase.

Required Pre-Check

Run:

git status --short

in the Backend API repository.

If there are existing user changes, report them and do not touch unrelated files.

Scope

Work in Backend API only.

Expected areas to inspect and possibly modify:

src/Refahi.Modules.Store.Domain/Entities/ProductVariant.cs
src/Refahi.Modules.Store.Domain/Enums/VariantCapacityType.cs
src/Refahi.Modules.Store.Infrastructure/Persistence/Configurations/ProductVariantConfiguration.cs
src/Refahi.Modules.Store.Infrastructure/Persistence/Migrations/
src/Refahi.Modules.Store.Application.Contracts/
src/Refahi.Modules.Store.Application/
src/Refahi.Modules.Store.Api/

Likely contract/query/command areas:

ProductVariantDto
ProductDetailDto
ProductSummaryDto if variants are projected there
Admin product detail DTOs
AddProductVariantCommand
AddProductVariantCommandValidator
Product detail query handlers
Admin product detail query handlers
Any variant projection helper/mapping code

Use actual file names from the repository. Do not invent paths if names differ.

Required Backend Changes

1. EF Mapping

Update ProductVariantConfiguration to persist:

FromDate
ToDate
CapacityType
Capacity

Expected mapping rules:

FromDate: nullable date column.
ToDate: nullable date column.
CapacityType: required smallint/int column with default Unlimited.
Capacity: nullable integer column.
Preserve existing StockCount, PriceMinor, DiscountedPriceMinor, IsAvailable, and combination mappings.

Use the existing EF naming conventions in the Store module.

Recommended column names, unless existing conventions require otherwise:

from_date
to_date
capacity_type
capacity

Add indexes only if consistent and low-risk.

Recommended safe indexes:

product_id, capacity_type
product_id, from_date, to_date

Do not over-index.

2. EF Migration

Create a Store Infrastructure migration for the new columns.

Suggested migration name:

AddProductVariantValidityCapacity

Do not apply the migration to any real database.

Migration must:

Add nullable from_date.
Add nullable to_date.
Add non-null capacity_type with default 0 / Unlimited.
Add nullable capacity.
Update model snapshot.
Preserve existing data.

Do not remove or alter product_sessions.

3. DTOs and Projections

Expose the new fields wherever product variants are returned.

At minimum, update variant DTOs used by:

Admin product detail.
Public/customer product detail.
Product variant API responses.

Expose:

DateOnly? FromDate
DateOnly? ToDate
VariantCapacityType CapacityType
int? Capacity
bool RequiresUsageDate

If DTO conventions avoid exposing enum types directly, follow existing project conventions. Do not introduce inconsistent serialization style.

Update query projections so the values come from ProductVariant.

Do not expose runtime sold count in this phase.

Do not expose remaining capacity in this phase unless it already exists and can be computed without order data. Prefer not to add it.

4. Add Variant Commands

Update variant creation contracts/commands to accept:

DateOnly? FromDate
DateOnly? ToDate
VariantCapacityType CapacityType
int? Capacity

Ensure they flow into:

Product.AddVariant(...)

Preserve backward compatibility:

Existing callers that do not send these fields should behave as before.
Default capacity type should be Unlimited.
Capacity should be null for unlimited variants.

If there is an existing update-variant command/endpoint, update it as well. If update-variant does not exist, do not create a broad new feature unless the existing architecture clearly expects it.

5. Validators

Update validators for add/update variant commands.

Validation rules must match Domain rules:

If only one of FromDate or ToDate is provided, reject.
If both are provided, FromDate <= ToDate.
CapacityType == Unlimited: capacity must be null or ignored.
CapacityType == TotalPeriod: capacity must be greater than zero.
CapacityType == PerEligibleDay: capacity must be greater than zero.
Keep existing price/discount/stock validation unchanged.
Use Persian validation messages if existing validators use Persian messages.
Preserve existing validator style and error conventions.

Do not validate calendar semantics such as even days, odd days, holidays, weekdays, or excluded dates.

6. API Endpoints

Ensure existing API endpoints that create variants receive and pass through the new fields.

Do not create new endpoints unless absolutely required by the existing architecture.

Do not modify session endpoints.

Do not modify cart/checkout endpoints in this phase.

7. Backward Compatibility

Preserve:

Existing product creation.
Existing variant creation without validity/capacity fields.
Existing StockCount behavior.
Existing IsAvailable behavior.
Existing ProductSession behavior.
Existing cart/checkout/order behavior.
Existing API route paths.

8. Explicitly Deferred

Do not implement these in this phase:

UsageDate on cart/order.
Runtime sold-count calculation.
Capacity enforcement in checkout/payment.
Orders query/projection for sold count.
Concurrency/reservation/ledger.
Performance optimization.
Admin UI fields.
Customer UI fields.
Exclude dates.
Holiday/calendar handling.
Removal of ProductSession.
Migration of legacy session data.

Validation

From Backend API 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 full test is too expensive or fails due unrelated known external reasons, still run the most focused Store-related build and clearly report what happened.

Do not claim validation passed unless commands actually pass.

Final Report Format

Save the report to:

.codex/reports/03-persist-and-expose-productVariant-validityCapacity-fields.md

Use exactly this structure:

Summary:
- ...

Skills used:
- ...

Repository checked:
- ...

Git state:
- Pre-check:
- Final:

Files changed:
- ...

Persistence changes:
- ...

Migration:
- ...

Contract/DTO changes:
- ...

Command/validator changes:
- ...

Query/projection changes:
- ...

Backward compatibility:
- ...

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

Deferred items:
- ...

Risks / assumptions:
- ...

Suggested next phase:
- ...

# Codex Implementation Prompt — Phase 9: Persist and Expose ProductVariant Validity/Capacity Fields Read `.codex/prompts/_session-bootstrap.md` first. Then read `AGENTS.md`. Load only the relevant skills from `.codex/skills/`. This is a focused Backend Store persistence and contract implementation task. Do not modify Admin UI. Do not modify Customer WebApp. Do not modify Cart/Checkout behavior. Do not remove `ProductSession`. Do not make release decisions. ## Mandatory Report Output At the end of this task, save the final report as: ```text .codex/reports/03-persist-and-expose-productVariant-validityCapacity-fields.md ``` Also print the same report in the Codex final response. ## Context Phase 7 added domain-level validity and capacity semantics to `ProductVariant`. Domain fields now exist: ```csharp FromDate ToDate CapacityType Capacity RequiresUsageDate ValidateOrderEligibility(DateOnly? usageDate = null) EnsureCapacityAvailable(int requestedQuantity, int soldCountInScope) ``` Phase 8 planning confirmed that these fields are not yet persisted, migrated, projected, or exposed end-to-end through backend contracts. This phase must make the existing domain fields available through Backend Store persistence and backend contracts only. ## Goal Persist and expose `ProductVariant` validity/capacity fields end-to-end in the Backend Store module. After this phase: * EF must map the new `ProductVariant` fields. * A Store migration must add the new columns. * Backend DTOs must expose the new fields. * Backend commands/validators must accept and validate the new fields when adding variants. * Product detail/admin query projections must return the new fields. * Existing legacy `ProductSession` flows must remain untouched. * Existing product/session/cart/checkout behavior must not change. ## Repositories Primary repository: ```text C:\Workspace\repo\refahiplus-api ``` Admin repository should not be modified in this phase. ## Required Pre-Check Run: ```bash git status --short ``` in the Backend API repository. If there are existing user changes, report them and do not touch unrelated files. ## Scope Work in Backend API only. Expected areas to inspect and possibly modify: ```text src/Refahi.Modules.Store.Domain/Entities/ProductVariant.cs src/Refahi.Modules.Store.Domain/Enums/VariantCapacityType.cs src/Refahi.Modules.Store.Infrastructure/Persistence/Configurations/ProductVariantConfiguration.cs src/Refahi.Modules.Store.Infrastructure/Persistence/Migrations/ src/Refahi.Modules.Store.Application.Contracts/ src/Refahi.Modules.Store.Application/ src/Refahi.Modules.Store.Api/ ``` Likely contract/query/command areas: ```text ProductVariantDto ProductDetailDto ProductSummaryDto if variants are projected there Admin product detail DTOs AddProductVariantCommand AddProductVariantCommandValidator Product detail query handlers Admin product detail query handlers Any variant projection helper/mapping code ``` Use actual file names from the repository. Do not invent paths if names differ. ## Required Backend Changes ### 1. EF Mapping Update `ProductVariantConfiguration` to persist: ```csharp FromDate ToDate CapacityType Capacity ``` Expected mapping rules: * `FromDate`: nullable date column. * `ToDate`: nullable date column. * `CapacityType`: required smallint/int column with default `Unlimited`. * `Capacity`: nullable integer column. * Preserve existing `StockCount`, `PriceMinor`, `DiscountedPriceMinor`, `IsAvailable`, and combination mappings. Use the existing EF naming conventions in the Store module. Recommended column names, unless existing conventions require otherwise: ```text from_date to_date capacity_type capacity ``` Add indexes only if consistent and low-risk. Recommended safe indexes: ```text product_id, capacity_type product_id, from_date, to_date ``` Do not over-index. ### 2. EF Migration Create a Store Infrastructure migration for the new columns. Suggested migration name: ```text AddProductVariantValidityCapacity ``` Do not apply the migration to any real database. Migration must: * Add nullable `from_date`. * Add nullable `to_date`. * Add non-null `capacity_type` with default `0` / `Unlimited`. * Add nullable `capacity`. * Update model snapshot. * Preserve existing data. Do not remove or alter `product_sessions`. ### 3. DTOs and Projections Expose the new fields wherever product variants are returned. At minimum, update variant DTOs used by: * Admin product detail. * Public/customer product detail. * Product variant API responses. Expose: ```csharp DateOnly? FromDate DateOnly? ToDate VariantCapacityType CapacityType int? Capacity bool RequiresUsageDate ``` If DTO conventions avoid exposing enum types directly, follow existing project conventions. Do not introduce inconsistent serialization style. Update query projections so the values come from `ProductVariant`. Do not expose runtime sold count in this phase. Do not expose remaining capacity in this phase unless it already exists and can be computed without order data. Prefer not to add it. ### 4. Add Variant Commands Update variant creation contracts/commands to accept: ```csharp DateOnly? FromDate DateOnly? ToDate VariantCapacityType CapacityType int? Capacity ``` Ensure they flow into: ```csharp Product.AddVariant(...) ``` Preserve backward compatibility: * Existing callers that do not send these fields should behave as before. * Default capacity type should be `Unlimited`. * Capacity should be null for unlimited variants. If there is an existing update-variant command/endpoint, update it as well. If update-variant does not exist, do not create a broad new feature unless the existing architecture clearly expects it. ### 5. Validators Update validators for add/update variant commands. Validation rules must match Domain rules: * If only one of `FromDate` or `ToDate` is provided, reject. * If both are provided, `FromDate <= ToDate`. * `CapacityType == Unlimited`: capacity must be null or ignored. * `CapacityType == TotalPeriod`: capacity must be greater than zero. * `CapacityType == PerEligibleDay`: capacity must be greater than zero. * Keep existing price/discount/stock validation unchanged. * Use Persian validation messages if existing validators use Persian messages. * Preserve existing validator style and error conventions. Do not validate calendar semantics such as even days, odd days, holidays, weekdays, or excluded dates. ### 6. API Endpoints Ensure existing API endpoints that create variants receive and pass through the new fields. Do not create new endpoints unless absolutely required by the existing architecture. Do not modify session endpoints. Do not modify cart/checkout endpoints in this phase. ### 7. Backward Compatibility Preserve: * Existing product creation. * Existing variant creation without validity/capacity fields. * Existing `StockCount` behavior. * Existing `IsAvailable` behavior. * Existing `ProductSession` behavior. * Existing cart/checkout/order behavior. * Existing API route paths. ### 8. Explicitly Deferred Do not implement these in this phase: * `UsageDate` on cart/order. * Runtime sold-count calculation. * Capacity enforcement in checkout/payment. * Orders query/projection for sold count. * Concurrency/reservation/ledger. * Performance optimization. * Admin UI fields. * Customer UI fields. * Exclude dates. * Holiday/calendar handling. * Removal of `ProductSession`. * Migration of legacy session data. ## Validation From Backend API repository root, run: ```bash dotnet restore .\Refahi.Backend.slnx dotnet build .\Refahi.Backend.slnx --configuration Release --no-restore dotnet test .\Refahi.Backend.slnx --configuration Release --no-build ``` If full test is too expensive or fails due unrelated known external reasons, still run the most focused Store-related build and clearly report what happened. Do not claim validation passed unless commands actually pass. ## Final Report Format Save the report to: ```text .codex/reports/03-persist-and-expose-productVariant-validityCapacity-fields.md ``` Use exactly this structure: ```text Summary: - ... Skills used: - ... Repository checked: - ... Git state: - Pre-check: - Final: Files changed: - ... Persistence changes: - ... Migration: - ... Contract/DTO changes: - ... Command/validator changes: - ... Query/projection changes: - ... Backward compatibility: - ... Validation: - Command: ... Result: ... Deferred items: - ... Risks / assumptions: - ... Suggested next phase: - ... ```

{ "prompt": "# Codex Implementation Prompt — Phase 9: Persist and Expose ProductVariant Validity/Capacity Fields\n\nRead `.codex/prompts/_session-bootstrap.md` first.\nThen read `AGENTS.md`.\nLoad only the relevant skills from `.codex/skills/`.\n\nThis is a focused Backend Store persistence and contract implementation task.\n\nDo not modify Admin UI.\nDo not modify Customer WebApp.\nDo not modify Cart/Checkout behavior.\nDo not remove `ProductSession`.\nDo not make release decisions.\n\n## Mandatory Report Output\n\nAt the end of this task, save the final report as:\n\n```text\n.codex/reports/03-persist-and-expose-productVariant-validityCapacity-fields.md\n```\n\nAlso print the same report in the Codex final response.\n\n## Context\n\nPhase 7 added domain-level validity and capacity semantics to `ProductVariant`.\n\nDomain fields now exist:\n\n```csharp\nFromDate\nToDate\nCapacityType\nCapacity\nRequiresUsageDate\nValidateOrderEligibility(DateOnly? usageDate = null)\nEnsureCapacityAvailable(int requestedQuantity, int soldCountInScope)\n```\n\nPhase 8 planning confirmed that these fields are not yet persisted, migrated, projected, or exposed end-to-end through backend contracts.\n\nThis phase must make the existing domain fields available through Backend Store persistence and backend contracts only.\n\n## Goal\n\nPersist and expose `ProductVariant` validity/capacity fields end-to-end in the Backend Store module.\n\nAfter this phase:\n\n* EF must map the new `ProductVariant` fields.\n* A Store migration must add the new columns.\n* Backend DTOs must expose the new fields.\n* Backend commands/validators must accept and validate the new fields when adding variants.\n* Product detail/admin query projections must return the new fields.\n* Existing legacy `ProductSession` flows must remain untouched.\n* Existing product/session/cart/checkout behavior must not change.\n\n## Repositories\n\nPrimary repository:\n\n```text\nC:\\Workspace\\repo\\refahiplus-api\n```\n\nAdmin repository should not be modified in this phase.\n\n## Required Pre-Check\n\nRun:\n\n```bash\ngit status --short\n```\n\nin the Backend API repository.\n\nIf there are existing user changes, report them and do not touch unrelated files.\n\n## Scope\n\nWork in Backend API only.\n\nExpected areas to inspect and possibly modify:\n\n```text\nsrc/Refahi.Modules.Store.Domain/Entities/ProductVariant.cs\nsrc/Refahi.Modules.Store.Domain/Enums/VariantCapacityType.cs\nsrc/Refahi.Modules.Store.Infrastructure/Persistence/Configurations/ProductVariantConfiguration.cs\nsrc/Refahi.Modules.Store.Infrastructure/Persistence/Migrations/\nsrc/Refahi.Modules.Store.Application.Contracts/\nsrc/Refahi.Modules.Store.Application/\nsrc/Refahi.Modules.Store.Api/\n```\n\nLikely contract/query/command areas:\n\n```text\nProductVariantDto\nProductDetailDto\nProductSummaryDto if variants are projected there\nAdmin product detail DTOs\nAddProductVariantCommand\nAddProductVariantCommandValidator\nProduct detail query handlers\nAdmin product detail query handlers\nAny variant projection helper/mapping code\n```\n\nUse actual file names from the repository. Do not invent paths if names differ.\n\n## Required Backend Changes\n\n### 1. EF Mapping\n\nUpdate `ProductVariantConfiguration` to persist:\n\n```csharp\nFromDate\nToDate\nCapacityType\nCapacity\n```\n\nExpected mapping rules:\n\n* `FromDate`: nullable date column.\n* `ToDate`: nullable date column.\n* `CapacityType`: required smallint/int column with default `Unlimited`.\n* `Capacity`: nullable integer column.\n* Preserve existing `StockCount`, `PriceMinor`, `DiscountedPriceMinor`, `IsAvailable`, and combination mappings.\n\nUse the existing EF naming conventions in the Store module.\n\nRecommended column names, unless existing conventions require otherwise:\n\n```text\nfrom_date\nto_date\ncapacity_type\ncapacity\n```\n\nAdd indexes only if consistent and low-risk.\n\nRecommended safe indexes:\n\n```text\nproduct_id, capacity_type\nproduct_id, from_date, to_date\n```\n\nDo not over-index.\n\n### 2. EF Migration\n\nCreate a Store Infrastructure migration for the new columns.\n\nSuggested migration name:\n\n```text\nAddProductVariantValidityCapacity\n```\n\nDo not apply the migration to any real database.\n\nMigration must:\n\n* Add nullable `from_date`.\n* Add nullable `to_date`.\n* Add non-null `capacity_type` with default `0` / `Unlimited`.\n* Add nullable `capacity`.\n* Update model snapshot.\n* Preserve existing data.\n\nDo not remove or alter `product_sessions`.\n\n### 3. DTOs and Projections\n\nExpose the new fields wherever product variants are returned.\n\nAt minimum, update variant DTOs used by:\n\n* Admin product detail.\n* Public/customer product detail.\n* Product variant API responses.\n\nExpose:\n\n```csharp\nDateOnly? FromDate\nDateOnly? ToDate\nVariantCapacityType CapacityType\nint? Capacity\nbool RequiresUsageDate\n```\n\nIf DTO conventions avoid exposing enum types directly, follow existing project conventions. Do not introduce inconsistent serialization style.\n\nUpdate query projections so the values come from `ProductVariant`.\n\nDo not expose runtime sold count in this phase.\n\nDo not expose remaining capacity in this phase unless it already exists and can be computed without order data. Prefer not to add it.\n\n### 4. Add Variant Commands\n\nUpdate variant creation contracts/commands to accept:\n\n```csharp\nDateOnly? FromDate\nDateOnly? ToDate\nVariantCapacityType CapacityType\nint? Capacity\n```\n\nEnsure they flow into:\n\n```csharp\nProduct.AddVariant(...)\n```\n\nPreserve backward compatibility:\n\n* Existing callers that do not send these fields should behave as before.\n* Default capacity type should be `Unlimited`.\n* Capacity should be null for unlimited variants.\n\nIf there is an existing update-variant command/endpoint, update it as well.\nIf update-variant does not exist, do not create a broad new feature unless the existing architecture clearly expects it.\n\n### 5. Validators\n\nUpdate validators for add/update variant commands.\n\nValidation rules must match Domain rules:\n\n* If only one of `FromDate` or `ToDate` is provided, reject.\n* If both are provided, `FromDate <= ToDate`.\n* `CapacityType == Unlimited`: capacity must be null or ignored.\n* `CapacityType == TotalPeriod`: capacity must be greater than zero.\n* `CapacityType == PerEligibleDay`: capacity must be greater than zero.\n* Keep existing price/discount/stock validation unchanged.\n* Use Persian validation messages if existing validators use Persian messages.\n* Preserve existing validator style and error conventions.\n\nDo not validate calendar semantics such as even days, odd days, holidays, weekdays, or excluded dates.\n\n### 6. API Endpoints\n\nEnsure existing API endpoints that create variants receive and pass through the new fields.\n\nDo not create new endpoints unless absolutely required by the existing architecture.\n\nDo not modify session endpoints.\n\nDo not modify cart/checkout endpoints in this phase.\n\n### 7. Backward Compatibility\n\nPreserve:\n\n* Existing product creation.\n* Existing variant creation without validity/capacity fields.\n* Existing `StockCount` behavior.\n* Existing `IsAvailable` behavior.\n* Existing `ProductSession` behavior.\n* Existing cart/checkout/order behavior.\n* Existing API route paths.\n\n### 8. Explicitly Deferred\n\nDo not implement these in this phase:\n\n* `UsageDate` on cart/order.\n* Runtime sold-count calculation.\n* Capacity enforcement in checkout/payment.\n* Orders query/projection for sold count.\n* Concurrency/reservation/ledger.\n* Performance optimization.\n* Admin UI fields.\n* Customer UI fields.\n* Exclude dates.\n* Holiday/calendar handling.\n* Removal of `ProductSession`.\n* Migration of legacy session data.\n\n## Validation\n\nFrom Backend API repository root, run:\n\n```bash\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 full test is too expensive or fails due unrelated known external reasons, still run the most focused Store-related build and clearly report what happened.\n\nDo not claim validation passed unless commands actually pass.\n\n## Final Report Format\n\nSave the report to:\n\n```text\n.codex/reports/03-persist-and-expose-productVariant-validityCapacity-fields.md\n```\n\nUse exactly this structure:\n\n```text\nSummary:\n- ...\n\nSkills used:\n- ...\n\nRepository checked:\n- ...\n\nGit state:\n- Pre-check:\n- Final:\n\nFiles changed:\n- ...\n\nPersistence changes:\n- ...\n\nMigration:\n- ...\n\nContract/DTO changes:\n- ...\n\nCommand/validator changes:\n- ...\n\nQuery/projection changes:\n- ...\n\nBackward compatibility:\n- ...\n\nValidation:\n- Command: ...\n Result: ...\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 skills from `.codex/skills/`.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/refahigroup/refahiplus-api", "path": ".codex/prompts/03-persist-and-expose-productVariant-validityCapacity-fields.md", "ref": "18003c6604b9e3d23b1d211e5ee0a2d42ee03cd4", "url": "https://github.com/refahigroup/refahiplus-api/blob/18003c6604b9e3d23b1d211e5ee0a2d42ee03cd4/.codex/prompts/03-persist-and-expose-productVariant-validityCapacity-fields.md", "key": "refahigroup/refahiplus-api/.codex/prompts/03-persist-and-expose-productVariant-validityCapacity-fields.md" } } }

03-persist-and-expose-productVariant-validityCapacity-fields

About