Auction Announcement / Declaration Flow v1
Scope
This implementation introduces the manual human-driven declaration path for auctions without rewriting the broader auction lifecycle. The source of truth is . remains a compatibility/demo path.
Resolving locale, route permissions, and workspace projection.
Current scope: Guest
Category: 90_stabilization | Version: v1.0.0
Owner: DOCUMENT_CUSTODIAN | Review cycle: 90 days
Approval authority: Unspecified
Documentation portal is read-only. Editing and mutation endpoints are disabled.
Kvary platform is originally created in Georgian. Where a Georgian version exists, Georgian is authoritative for platform UI, documentation, and legal interpretation.
Translations into other languages are provided for convenience. Some records may originate in other languages and carry their own source or legal locale for a specific flow, but where a Georgian version is available, the Georgian version prevails for platform-level wording and interpretation.
Metadata incomplete: Document ID, Version, Status, Owner Role, Last Review Date, Next Review Date, Change Log
This implementation introduces the manual human-driven declaration path for auctions without rewriting the broader auction lifecycle. The source of truth is . remains a compatibility/demo path.
services/svc-tendersservices/apiDRAFTREADY_FOR_ANNOUNCEMENTANNOUNCEDSupported transitions in v1:
DRAFT -> READY_FOR_ANNOUNCEMENTREADY_FOR_ANNOUNCEMENT -> ANNOUNCEDDirect DRAFT -> ANNOUNCED is intentionally not supported.
The form/domain payload is grouped into:
Evidence in v1 is reference-only. No file storage/upload orchestration is introduced.
packages/core/auction/declaration.ts defines:
AuctionAnnouncementFormDataDeclareAuctionCommandAuctionAnnouncementValidationResultAuctionReadinessChecklistItemAuctionAnnouncementPreviewAuctionAnnouncedEventcanMarkReadycanDeclareAuctionThe service normalizes the raw form payload before persistence or transition.
services/svc-tenders/src/validation.ts implements:
buildAuctionAnnouncementValidationResultReadiness covers:
auction_declarations remains the workflow/declaration source of truth. It stores:
auction_declarationsauction_declaration_eventsThe declaration row keeps:
auctions is the broader registry projection across internal lifecycle states. Declaration workflow now projects into auctions at three points:
DRAFTREADY_FOR_ANNOUNCEMENTANNOUNCEDDraft/ready registry rows intentionally preserve true missing values as null where the draft is still incomplete.
For v1 projection compatibility:
owner_stakeholder_id is sourced from explicit identity.ownerStakeholderIdlinkedAssetId | linkedLotId | linkedTenderIdorganizationId remains declaration metadata onlyworkflowTemplateId remains declaration metadata onlylinked_kes_contract_id stays null until a real KES/contract identifier existsminBid is temporarily projected from basePricePublic auction routes filter out internal-only states:
DRAFTREADY_FOR_ANNOUNCEMENTInternal/admin auction routes expose the broader registry, including those internal states, behind the existing declaration capability gate.
Output Allocation is an optional upstream commercial source in v1.
auction_declarations.allocation_id is nullableTwo declaration events are currently recorded:
AUCTION_READY_FOR_ANNOUNCEMENTAUCTION_DECLAREDThe declaration event includes:
auctionIdpreviousStatenewStatedeclaredBydeclaredAtrulesVersionintentIdsourceSystemThis is intentionally shaped so the same semantics can later feed outbox/KES integration.
Later KES automation should map to the same semantics:
mark ready -> explicit state transitiondeclare -> explicit state transition + event emissionThe intended future mapping is:
DeclareAuctionCommand