Resolving locale, route permissions, and workspace projection.
النطاق الحالي: ضيف
الفئة: 10_normative | الإصدار: v1.0.0
المالك: DOCUMENT_CUSTODIAN | دورة المراجعة: 90 يومًا
جهة الاعتماد: GOVERNANCE_ADMIN
بوابة الوثائق للقراءة فقط. نقاط نهاية التعديل والتغيير معطلة.
منصة Kvary أُنشئت أصلًا باللغة الجورجية. وحيثما تتوفر نسخة جورجية، تبقى الجورجية هي اللغة المعتمدة لواجهة المنصة والوثائق والتفسير القانوني.
تُوفَّر الترجمات إلى اللغات الأخرى لسهولة الاستخدام فقط. وقد تنشأ بعض السجلات بلغات أخرى وتحمل لغة مصدر أو لغة قانونية خاصة بذلك المسار، ولكن حيثما تتوفر نسخة جورجية تكون الأولوية للنسخة الجورجية في صياغة المنصة وتفسيرها.
البيانات الوصفية غير مكتملة: Document ID, Version, Status, Owner Role, Last Review Date, Next Review Date, Change Log
svc-tenders Support And Gate MapThis note documents the support/gate responsibilities of the two densest support modules in after Cleanup Sprint 24:
svc-tendersThe goal is to make it obvious:
Labels used here:
VERIFIEDREALTRANSITIONALdeclarationRouteSupport.tsSupport module:
Consumed by route modules:
Status:
VERIFIEDTRANSITIONALWhy transitional:
Purpose:
Helpers:
getTenderDeclarationCapabilities(...)hasTenderDeclarationCapability(...)canCheckTenderDeclaration(...)getAuctionDeclarationCapabilities(...)hasAuctionDeclarationCapability(...)canCheckAuctionDeclaration(...)What it does:
*, admin:*, tender:*, auction:*Broader vs stricter gate note:
canCheckTenderDeclaration(...)canCheckAuctionDeclaration(...)hasTenderDeclarationCapability(...)hasAuctionDeclarationCapability(...)This distinction matters because declaration read/check endpoints are intentionally broader than state-changing endpoints.
Purpose:
Helpers:
parseTenderDeclarationEvidenceGroupKey(...)parseAuctionDeclarationEvidenceGroupKey(...)What it does:
undefinedTender evidence groups:
supportingDocumentsspecificationEvidencecomplianceEvidenceAuction evidence groups:
supportingDocumentsqualityEvidencesubjectEvidencetransportEvidenceThis is intentionally asymmetric because tender and auction declarations do not share the exact same evidence buckets.
Purpose:
server.tsInputs forwarded:
requireServiceAuthparseOptionalStringresolveIntentIdrunMulterSingleNotes:
resolveIntentId(...) is shared request-intent normalization, not declaration-specific business logicrunMulterSingle(...) is a declaration upload bridge, but still built from shell-owned upload middlewarekesRouteSupport.tsSupport module:
Consumed by route modules:
Status:
VERIFIEDTRANSITIONALWhy transitional:
Purpose:
Helpers forwarded:
parsePositiveIntparseOptionalIntparseOptionalStringparseOptionalUpperclampPositiveIntWhat it does not do:
Purpose:
Helpers forwarded:
ensureThirdPartyKycBoundary(...)verifyIncomingSignatureGate(...)What it does:
What it does not do:
This is the key distinction for KES:
requireServiceAuthrequireServiceAuthensureThirdPartyKycBoundary(...)verifyIncomingSignatureGate(...)requireServiceAuthverifyIncomingSignatureGate(...)That stricter branching lives in:
This is important: kesRouteSupport.ts exposes ingress helpers, but the route module is where stricter payment gating actually becomes active.
VERIFIED
These two support modules are not symmetric, and that is correct:
Trying to force symmetry here would hide the real support boundary.
VERIFIED
Declaration support still depends on shell-owned auth and upload inputs.
KES support still depends on shell-owned parser and ingress helpers.
KES route support is structurally clear, but the repository input behind the route remains transitional because KES persistence still lives behind the mixed root repository.