Stage S5 — Serdica
P Stage correspondence. S5 Serdica. These are the same stage identities used by the product overview and case walkthrough. A checkpoint or nested task conversation stays inside its owning stage.
Purpose
The product prices, exists, and has offers — and no operator can find it. This stage does the platform wiring: routes and views so the product appears for the right people, translations so it reads correctly in every maintained language, endpoint registration where the product introduced new endpoints, roles where visibility is restricted, numbering, and print. It is the stage where "configured" historically diverges from "usable" — a product missing one route row is invisible, silently F: [routes model].
Inputs → Outputs
In: the tariff sign-out and the specification — product code and cover codes fixed at H1 — S3/S4 result ids only where a declared write dependency requires them; planning remains parallel (D75). Out: a product reachable by the intended roles, labeled in every maintained language, wired into its process — and the stage's script set, including the deploy-coupled items flagged for the deployment plan.
What runs this stage
| Agents | configuration.serdica.stage |
| Isolated sub-agents | configuration.verifier |
| Memory domain it owns | configuration/serdica — route shapes, the label sweep, endpoint registration, numbering and print keys (Agents Memory) |
| Skills it runs | ipal configure with the wiring coverage entries (writes via approved templates/executor), and route / label / endpoint check for proof and smoke (Agents Memory and Skills) |
| Its branch of the graph | Configuration Module § 0 — the module's agent tree, its memory branch and its skills · the component list is Components — Configuration |
Every stage also uses the module's shared profiles — configuration.root (the only one that reaches the human), configuration.verifier (isolated, no author context) and configuration.deployer — and the platform's write_executor and write_auditor, which are what actually touch a target (Gating).
The surface [F — stated 31.08.2026 + v1 sources]
| Area | What is configured |
|---|---|
| Views/visibility | SRD_SYS."Routes" rows — mandatory for the product to appear; needed at every ancestor level; empty AllowedRoles = deny F: [routes model] |
| Endpoints | SRD_SYS."EndPoints" / "EndpointSections" rows when new endpoints exist — often mandatory; resolved live by callers. ⚠ the case asymmetry is real and the names are quoted: EndPoints but EndpointSections F: EndPointsEntityType.cs:440-442, EndpointSectionsEntityType.cs:174-176, verified 01.09.2026; [service topology] |
| Core registration | some microservice endpoints also register in core's appsettings.json — the hand-maintained RabbitMQRoutingConfig.RouteConfigs command→exchange/queue table — deploy-coupled, riding the core deployment F: src/Core/Core/appsettings.json:113-114, verified 01.09.2026; [topology]. F Traced 02.09.2026 (Measurements § RE § 3): every service self-registers its EndpointSections/EndPoints rows at start-up (Microservice.Initializer.EndpointsRegistration), and the REST gateway and service-to-service RPC resolve from those rows; a core appsettings.json entry is needed only for commands Core itself sends (workflow service tasks through MessageHandler) — on master/bulstrad-qa one entry per exchange section suffices (prefix match), on bulstrad-staging every command needs its own entry. A new product needs no core entry unless it introduces a new microservice or exchange that Core calls |
| Process | not this stage — the process belongs to the policy product and is registered in S3 IPAL (D86); authoring or changing a BPMN is Development module (id source) work at Hd |
| Roles | sometimes new SRD_SYS.LT_USER_ROLES entries, referenced from Routes.AllowedRoles, when the product is visible only to a seller or servicing role — the D138 test: a "visible to group X" wish comes here when X is who sells or services; when X describes the insured it is an offer segment (Stage Offer § Challenges). The module configures roles, never users [P: decision 02.09.2026]: assigning a role to a user account (SRD_SYS.USER_ROLES, composite PK USER_ACCOUNT_ID + USER_ROLE [F: compiled EF model — LtUserRolesEntityType.cs:151-153, UserRolesEntityType.cs:124-126; verified 01.09.2026]) is the implementer's administration after deployment, and is what keeps the module free of personal data (CG-9). |
| Numbering | product-number keys and CFG_POLICY_NO_SEQ rows where the product uses IPAL numbering; S3 records any issued-test counter side effect, and S5 sweeps the deployable key set |
CFG_PRINT_DOCS and related product print registrations; BI template authoring is Development work, but its registration is configuration |
|
| Translations | S3 writes the product's message keys; S5 holds the responsibility (D137 — a role of this stage, not a stage of its own): it runs the route / label / endpoint check skill, completes every maintained language, and the verifier re-runs the same skill read-only at H3 — Translations |
Rules this stage holds
P A genuine asymmetry between surfaces is recorded, not harmonised. The surfaces are coupled by code and by name and by no constraint, so where the rating side and the catalogue side legitimately differ — a cover the engine splits per clause, a factor the screen groups differently, a name that could not be made equal to its code — the difference is written into the specification as a deliberate difference with its reason. The failure this prevents is the quiet one: harmonising the pair in whichever file is open and leaving the other surface to be rediscovered by a wrong premium. S5's completeness sweep asserts the recorded asymmetries rather than flagging them.
P Incumbent code is a change request, not a configuration row. A change to the incumbent system's own code or user exits — including a branch in a product-aware package on the seam — leaves this module as a handover at Hd and reaches the customer as a change request; it is never emitted as configuration and never worked around with a data write. Data corrections on named policies are the opposite case and need no change request. Saying which of the two a case is, and saying it at S1 rather than at deployment, is what keeps the deadline honest (Gating).
Real material — what live cases asked of this stage
Eight configuration cases were walked against this design (Configuration Module § 8 carries each case in full). What each one demanded here:
CS-1 · 9951 «Каско Максимум» replayed through v2 — The PC agent built 9951 on Ablera dev from a 13-sheet template (Продукт · Тарифни групи · Клаузи · Покрития · Зависимости · Оферти · Правила за премия · ЗС/лимити · Подписвачески въпросник 91 rows · Зависимости между въпроси 65 rows · Такси · Ref) and a 10-page tariff PDF (raздели I–VIII).
One Routes row under CASCO with AllowedRoles, IsDashboardItem open question (extract: code says child needs Y, live siblings carry N), labels for eight covers × 2 languages, CFG_POLICY_NO_SEQ per (product, year, office), CFG_PRINT_DOCS cloned from 4704, process registration none (existing process fits). [closed by § The surface] Numbering, print and translations are now first-class rows, so an S5 author writing from the table does not omit the things that fail silently.
CS-5 · Product 8000 „Здравна грижа" — packages × levels × options, cover modes, a Camunda process, CG-9 — Group health, EUR, QA only (10.239.82.106), 10 UI covers + 52 level-variant child rows (IP_O/IP_L/IP_E), consumption modes PRV/REIM per cover (PREVENTION and EXTRA_CARE PRV-only), tariff per member × package × level × option with ordered corrections (sector, group size, age band, −5 % commercial), Профилактика individually rated (no rate), Критични заболявания only above 150 persons, claims-side ABACUS templates SRVPRICE# and CLMIND#, BPMN in Core.Plugin.Bulstrad, HealthBasicProductId=8000 hardcoded.
The process is registered; routes for Bulstrad Life roles; print (списък застраховани, дебит нота — 21.05.2026 change round); numbering. Camunda work itself is Hd. [ok].
CS-6 · Cargo 1101/1102 — a product that transfers to INSIS, with no INSIS structure in the spec — Bulstrad asks to add HSSC (HelpDesk 00102452 „Добавяне на HSSC по всички кодове по Карго") — a new ICC cover across 1100/1101/1102/1103 — and, separately, a new print variant.
Print: CFG_PRINT_DOCS.TEMPLATE_PARAMETERS gate POV(DOCUMENT_TYPE#…) and the P_CNT_* parameters (KI-033) — the BI template itself is a Development artefact (RTF/XDO); its registration is configuration. Same shape as the Camunda rule („the process is Development, its registration is configuration") — [ok] by the Print row above.