phenix-insurance
Travel-insurance stack for Phenix: a Gateway API orchestrating the insurance sales flow and fanning out over HTTP to per-provider ACL services (currently Rock Insurance) behind a common contract.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | ASP.NET Core 8, MediatR, FluentValidation, Reqnroll |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2026-07-20 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Selling and quoting (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 3 release pipeline(s): \commercial\insurance\insurance-acls ROCK; \commercial\insurance\insurance-gateway-api; \commercial\insurance\zz obsolete phenix-insurance ui |
| Integration | rest, jwt, redis |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loosely attached Bound into the core by 1 mechanism(s).
- Pinning dependency: phenix-feature-service
Detaches when its pinning dependencies are cut or multi-targeted (phenix-feature-service).
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Modern runtime, good tests, no hosted legacy transport: the automated stealth path can carry it today.
- 1 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- Serialized state or messages in flight (Redis or queues): new code must deserialize objects written by the previous version
- Feature flags come from phenix-feature-service (WCF-only): flag reads themselves are a legacy dependency to watch
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Ready to containeriseModern runtime, no hosted legacy transport: this service can follow the estate's proven container path (Dockerfile, shared pipeline template, ECS via Terraform).
- Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
- Log to stdout and expose a health check endpoint so ECS can supervise it.
- Adopt the shared ci.yml pipeline template with the container parameters (awsRegion, containerAfterBuild, ecsTerraformRepo), which is exactly how the estate's existing AWS services deploy.
- Define the service in the Terraform repo, deploy to a non-production environment, then shift traffic and disarm the deployment-group release pipeline.
Recommended actions
Rotate the credentials committed to phenix-insurance
Risk flags indicate credentials or keys in source (secrets-in-source). Rotate now and enable secret scanning in CI; this is independent of all other work.
Impact: Closes a live security exposure at near-zero cost
proposedAssessment notes
phenix-insurance
Purpose
The "new XML insurance application" for Phenix. Insurance.Gateway.Api serves the UI and orchestrates the sales/booking flow (search, requote, recheck, book, FAQs, referral links, configuration) via MediatR handlers, selecting a provider ACL by URL and calling it over HTTP. Insurance.Acl.Library is the shared ACL host and Insurance.Acl.Rock wraps the Rock Insurance provider API; Insurance.Entities holds the shared contracts every ACL implements. The gateway also checks agent compliance training via Litmos data.
Tech stack
C# on .NET 8 throughout, SLNX solutions with central package management, trunk-based development. MediatR request/handler pattern, Newtonsoft serialization, FluentValidation with auto-validation, Coravel, TC.ApiTools (Swagger/logging/diagnostics), TC.ConnectionBroker (Mongo/Redis/Sql/Wcf/Api), TC.RemoteSession.Redis, StyleCop/Sonar/SecurityCodeScan analyzers. Well-documented via README, CLAUDE.md and PDFs in Docs/.
Deployment
3 releases under \commercial\insurance\: insurance-gateway-api, insurance-acls ROCK and an explicitly obsolete phenix-insurance ui (the UI build pipelines remain but no UI project exists in the repo any more). Gateway and ACL each have their own azure-pipelines.yml with path-based triggers so they build and deploy independently.
Dependencies
Internal packages: TC.ConnectionBroker.* (tc-connectionbroker), TC.ApiTools.* (tc-api-tools), Phenix.CartApi.Client (phenix-cart-api), Phenix.Provider.Domain/ProxyTools (phenix-provider), TC.Quote.Api.Client (phenix-quote), TC.Phenix.User.* (phenix-user-api), TC.Cache.Specialised.PhenixFeature (phenix-feature-service), plus TC.Phenix.Services.Client and TravelCounsellors.Money. External: the Rock Insurance provider API (quotes/booking, referral links to travelcounsellors.rockinsurance.com) and Litmos (training/compliance platform).
Data stores
No SQL database of its own. MongoDB: Litmos (compliance/training lookups) and per-app request/response log databases (InsuranceGateway_logs, InsuranceAcl_Rock_Insurance_logs). Redis backs remote session and the TC cache specialisations.
Integration points
REST between UI → Gateway → ACLs (JWT / tc-api-key auth forwarded through the chain) and outbound to the Rock provider; Redis for session/caching. The ACL contract (IProviderAclService, seven operations) is the extension point for new insurance providers.
Code health
Good: unit tests plus Reqnroll/SpecFlow integration tests with in-process WebApplicationFactory drivers and WireMock for both deployables, coverage runsettings, analyzers on build, active development (last commit 2026-07-20). One blemish: a Litmos API key sits in plaintext in the gateway's appsettings.json.
Modernisation risks
Low: modern .NET 8, well-tested, cleanly layered for adding providers. Items to tidy: move the Litmos API key out of source into secret storage, and retire the obsolete UI build/release pipelines that still reference this repo.