svc-tenders Cluster Stack Order Map

Purpose

This note documents the comment-stack ordering used under the dense route-cluster headers in svc-tenders after Cleanup Sprint 43.

Focus:

• the repeated explanatory layer order
• where the order was aligned
• where extra notes intentionally remain outside the shared stack

Labels used here:

• VERIFIED
• REAL
• TRANSITIONAL

Shared Stack Order

VERIFIED

Where the full stack exists, the dominant order is now:

1. intro line
2. auth surface
3. dependency touchpoint
4. dominant sequence
5. dominant response shape
6. dominant error surface
7. dominant status families

Why this order:

• gate and dependency context now appear before execution/response detail
• the stack reads from access boundary to technical touchpoint to outward behavior

registerTenderDeclarationRoutes.ts

Route module:

• services/svc-tenders/src/routes/registerTenderDeclarationRoutes.ts

Route cluster:

• ADMIN READ SURFACE
• DRAFT AUTHORING SURFACE
• READINESS / DECLARE TRANSITION SURFACE
• EVIDENCE SURFACE

Stack order:

• intro
• auth surface
• dependency touchpoint
• sequence
• response
• error
• status

Where wording/order was aligned:

• all tender cluster headers now follow the same stack order

registerAuctionDeclarationRoutes.ts

Route module:

• services/svc-tenders/src/routes/registerAuctionDeclarationRoutes.ts

Route cluster:

• OUTPUT-ALLOCATION ADMIN SURFACE
• ADMIN READ SURFACE
• EVIDENCE SURFACE
• DRAFT AUTHORING SURFACE
• READINESS / ANNOUNCE TRANSITION SURFACE

Stack order:

• intro
• auth surface
• dependency touchpoint
• sequence
• response
• error
• status

Where wording/order was aligned:

• the shared explanatory layers now match tender and KES ordering

Where wording/order intentionally stayed different:

• OUTPUT-ALLOCATION ADMIN SURFACE still keeps the OWNERSHIP NOTE after the shared stack because it is a transitional note, not part of the common explanatory layers

Asymmetry/transitional notes:

• TRANSITIONAL
• auction still carries the only colocated ownership note in this cluster family

registerKesRoutes.ts

Route module:

• services/svc-tenders/src/routes/registerKesRoutes.ts

Route cluster:

• CASE ENTRY SURFACE
• OPERATOR READ / CONTROL-PLANE SURFACE
• PROCESS-MAP MUTATION SURFACE
• CASE / TASK / INSPECTION ACTION SURFACE
• PAYMENT-SENSITIVE ACTION SURFACE
• CASE CLOSURE ACTION

Stack order:

• intro
• auth surface
• dependency touchpoint
• sequence
• response
• error
• status

Where wording/order was aligned:

• KES now follows the same shared stack order as the declaration modules

Where wording/order intentionally stayed different:

• KES cluster bodies still contain extra ingress-specific or aggregate-specific notes where that reality is unique

Asymmetry/transitional notes:

• VERIFIED
• KES keeps more ingress and aggregate-specific terminology inside the shared order, but the order itself now matches the other modules

Current Intentional Exceptions

VERIFIED

These items intentionally remain outside the shared stack:

• the auction OWNERSHIP NOTE under OUTPUT-ALLOCATION ADMIN SURFACE
• route-local VALIDATION STACK and SUPPORT CONSUMPTION comments inside handlers
• KES ingress-specific inline notes near payment verification calls

Reason:

• they describe local or transitional detail, not cluster-header stack structure