svc-tenders Cluster Intro Map
Purpose
This note documents the one-line explanatory text immediately under the cluster headers in the densest svc-tenders route modules after Cleanup Sprint 42.
Focus:
- where intro wording was tightened
- where equivalent cluster intros were aligned
- where wording intentionally stayed different
Labels used here:
VERIFIEDREALTRANSITIONAL
registerTenderDeclarationRoutes.ts
Route module:
Cluster header:
ADMIN READ SURFACE
Intro text:
Broader declaration visibility gates this read cluster.
Where wording was tightened/aligned:
- shortened from a two-line explanation into the same concise pattern now used by the equivalent auction cluster
Cluster header:
DRAFT AUTHORING SURFACE
Intro text:
Create/update draft flows stay on the dedicated declaration write path.
Where wording was tightened/aligned:
- aligned with auction around
Create/update draft flows stay ...
Cluster header:
READINESS / DECLARE TRANSITION SURFACE
Intro text:
Readiness check, mark-ready, and declare keep the core declaration state machine together.
Where wording was tightened/aligned:
- aligned with auction around
Readiness check, mark-ready, and ... keep the core declaration state machine together.
Cluster header:
EVIDENCE SURFACE
Intro text:
Upload, list, and download keep shell storage plus declaration evidence logic together.
Where wording was tightened/aligned:
- aligned with auction around
Upload, list, and download keep ... together
registerAuctionDeclarationRoutes.ts
Route module:
Cluster header:
OUTPUT-ALLOCATION ADMIN SURFACE
Intro text:
Colocated admin routes over the composed output-allocation/declaration boundary.
Where wording was tightened/aligned:
- tightened for brevity
Where wording intentionally stayed different:
- kept explicit
output-allocation/declaration boundarylanguage because this cluster is genuinely more transitional than the others
Cluster header:
ADMIN READ SURFACE
Intro text:
Broader declaration visibility gates this read cluster.
Where wording was tightened/aligned:
- now matches tender exactly
Cluster header:
EVIDENCE SURFACE
Intro text:
Upload, list, and download keep shell storage plus declaration evidence logic together in the composed boundary.
Where wording was tightened/aligned:
- aligned with tender around
Upload, list, and download keep ... together
Where wording intentionally stayed different:
- kept
in the composed boundarybecause auction evidence still lives on a more transitional route surface
Cluster header:
DRAFT AUTHORING SURFACE
Intro text:
Create/update draft flows stay on the declaration-owned write path inside the composed boundary.
Where wording was tightened/aligned:
- aligned with tender around
Create/update draft flows stay ...
Where wording intentionally stayed different:
- kept
inside the composed boundarybecause auction draft flows still depend on the mixed boundary
Cluster header:
READINESS / ANNOUNCE TRANSITION SURFACE
Intro text:
Readiness check, mark-ready, and announce keep the core declaration state machine together.
Where wording was tightened/aligned:
- aligned with tender around
Readiness check, mark-ready, and ... keep the core declaration state machine together.
Where wording intentionally stayed different:
- kept
announceinstead ofdeclarebecause that is the real auction verb
Asymmetry/transitional notes:
TRANSITIONAL- auction intros stayed slightly more boundary-explicit where composed repository reality is still relevant
registerKesRoutes.ts
Route module:
Cluster header:
CASE ENTRY SURFACE
Intro text:
Authenticated case creation is the main KES write entry point.
Where wording was tightened/aligned:
- shortened for faster scanning
Cluster header:
OPERATOR READ / CONTROL-PLANE SURFACE
Intro text:
Public reads keep list, detail, projection, suggestions, and control-plane access together.
Where wording was tightened/aligned:
- tightened into one line
Where wording intentionally stayed different:
- kept
control-planeandpublic readsexplicit because this cluster is not equivalent to the admin read surfaces in declaration modules
Cluster header:
PROCESS-MAP MUTATION SURFACE
Intro text:
Authenticated process-map writes stay separate from payment ingress rules.
Where wording was tightened/aligned:
- tightened and kept parallel with the other KES action-cluster intros
Cluster header:
CASE / TASK / INSPECTION ACTION SURFACE
Intro text:
Authenticated orchestration actions stay separate from payment ingress rules.
Where wording was tightened/aligned:
- tightened and aligned with process-map wording around
stay separate from payment ingress rules
Cluster header:
PAYMENT-SENSITIVE ACTION SURFACE
Intro text:
Payment actions add stricter ingress checks than ordinary KES writes.
Where wording was tightened/aligned:
- tightened into one line
Where wording intentionally stayed different:
- kept
paymentandstricter ingressexplicit because this cluster is materially different
Cluster header:
CASE CLOSURE ACTION
Intro text:
Terminal close stays separate from broader orchestration and payment actions.
Where wording was tightened/aligned:
- tightened for brevity
Where wording intentionally stayed different:
- kept terminal-action wording because closure is a distinct end-state cluster
Asymmetry/transitional notes:
VERIFIED- KES intros remain more operational and ingress-aware than declaration intros because the underlying route families are genuinely different
Current Intentional Differences
VERIFIED
These intro lines intentionally stayed different:
- auction references to the composed boundary
announceversusdeclarepublic reads/control-planewording in KESpayment ingresswording in KESterminal closewording in KES
Reason:
- they describe real route-family differences, not wording drift