phenix-root-aws
Single static index.html serving as the root of the Phenix UI S3/CloudFront bucket, auto-redirecting users to the Phenix dashboard and offering a cookie/JWT debug view.
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 | javascript |
| Frameworks | Bootstrap 4 |
| Runtimes | browser |
| Tests / CI | none / CI in place |
| Last commit | 2025-05-20 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | jwt |
| Source | Open in Azure DevOps |
Risk flags
No risk flags recorded.
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
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
Ready with guardrailsClose: the deployment path exists, but specific checks are needed first, typically raising tests, auditing serialized data, or respecting a shared schema with expand and contract. Already deploys as a container to AWS, which releases without downtime today. No automated tests: at-will release without a safety net is bravado, not capability.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- 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.
- Externalise any remaining session state so users can move between nodes mid-session without disruption.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- 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
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
phenix-root-aws
Purpose
The landing/root file for the S3 bucket that hosts all AWS-served Phenix apps. Hitting the root auto-redirects to the Phenix home page (/dashboard), honouring a cognito-signout-redirect cookie if present; adding ?debug=true suppresses the redirect and renders a page showing the logged-in user's name/email/salesperson id and the decoded Cognito ID/access token JWTs from cookies.
Tech stack
One hand-written index.html with inline vanilla JavaScript (cookie parsing, client-side JWT decode) and CDN-hosted Bootstrap 4.4/jQuery slim. No build step, no package manager, no framework.
Deployment
Included via build->yaml-deploy with 0 classic releases: build pipeline phenix-root-aws from azure-pipeline.yaml, which zips src/, publishes it, uploads to the tc-phenix-ui-artifacts S3 bucket (us-east-1, AWS Shared Services credentials) and runs the phenix_cloudfront_websites CloudFront Terraform template from the aws-phenix-tc-apps repo, functional area phenix.
Dependencies
None internal in code terms — it redirects into the Phenix dashboard UI but has no package or API dependency. External: AWS Cognito (reads CognitoIdentityServiceProvider.* token cookies), plus CDN-served Bootstrap/jQuery with subresource integrity hashes.
Data stores
None; it is a single static page. The tc-phenix-ui-artifacts S3 bucket is a deployment artifact store, not application data.
Integration points
Browser-side only: reads Cognito JWT cookies for the debug view and issues client-side redirects to /dashboard and /signout. No API calls.
Code health
Appropriate for what it is: a one-file utility page with a short but genuinely descriptive README (including the debug=true behaviour). No tests, which is reasonable at this size. Last commit 2025-05-20.
Modernisation risks
Low. There is nothing to modernise beyond housekeeping: the debug view renders decoded auth tokens in the page (only the user's own cookies, but worth confirming this is acceptable in production), and the CDN Bootstrap/jQuery pins are old though integrity-protected. Its main estate significance is as the front door for the Cognito-authenticated Phenix AWS UI hosting.
Data store follow-up (2026-07-28)
Follow-up scan of project files, configuration and the central Terraform repos confirmed the empty data_stores list is correct. Infrastructure companion repo; no data store packages or configuration found.