evidence-map.md

Portfolio Evidence Map

This is the working map for the portfolio. The profile README stays short; this file keeps the proof links, companion repo notes, and remaining evidence gaps in one place.

Evidence Ready Now

Project	Evidence
api-reliability-suite	Passing CI, Security, and Docs runs; committed Grafana dashboard and AI-debug screenshot
github-actions-ec2-pipeline	Passing CI matrix run, successful tagged release/deploy workflow, Release v1.0.20, controlled release workflow, and rollback script. The original EC2 host was temporary and later destroyed; historical deployment proof also exists in devops-labs: EC2 instance, workflow, Actions run, and live app screenshot
github-actions-cicd-demo	Passing CI/CD workflow with Node 22/24 matrix, linting, Trivy SARIF upload, Docker Buildx, and GHCR publish path
glpi-ticketing-system	Docker Compose runtime, operations runbook, backup/restore/smoke-test scripts, implementation write-up, local smoke evidence: login screen, dashboard, run note, plus repo screenshots for a sample ticket, asset inventory, service level, and ticket statistics
devops-labs	Root evidence map, capstone write-ups, screenshots inside module folders, Terraform files, Ansible playbooks, and GitHub Actions workflow files

Capstone And Companion Repo Positioning

Work	Main Place To Review	Companion Repo	How To Position It
WordPress HA on AWS	devops-labs Capstone 4	None yet	Keep inside devops-labs until it is extracted as a focused terraform-aws-wordpress-ha or aws-wordpress-ha-lab repo with IaC and fresh screenshots
E-commerce CI/CD	devops-labs Capstone 5	ecommerce-platform	Treat as a companion app repo. It now has passing CI and Docker Publish evidence, but still needs current screenshots before it should be promoted
EC2 release automation	github-actions-ec2-pipeline	Related devops-labs mini-project notes	This is polished enough to stay as a headline repo because the workflow, health check, and rollback story are easy to review
Container CI/CD quality gates	github-actions-cicd-demo	Related devops-labs mini-project notes	Keep as a headline repo. It is clearer than burying the Actions work inside devops-labs
MarketPeak EC2 deployment	devops-labs Capstone 3	MarketPeak_Ecommerce	Keep as historical/manual deployment evidence. Do not pin unless it gets a clean README, current screenshots, and a reproducible setup
Git collaboration capstone	devops-labs Capstone 1	greenwood-library-website	Keep as foundational Git workflow evidence. It is useful context, not a portfolio headline
Django + Terraform ECS lab	django-dynamic-app	Module 4 Terraform notes	Keep public and unpinned until it has Terraform apply output, ECS task evidence, and an ALB screenshot

Evidence To Capture Next

Project	Next Proof To Add
glpi-ticketing-system	Add backup/restore command output and, later, a technician role screenshot if the lab is rebuilt with a fuller fake-company dataset
github-actions-ec2-pipeline	Only if re-provisioned: add a fresh PROD_URL health-check run, EC2 /api/health, PM2 process status, and one rollback log with sensitive values hidden
devops-labs	Add a root screenshot index with the strongest 6-8 images
devops-labs Capstone 6	Only if rebuilt: add Grafana/Gatus exports and sanitized Terraform plan/apply output into the capstone folder
ecommerce-platform	Add current app screenshots and deployment logs before treating it as a headline repo
django-dynamic-app	Add Terraform plan/apply evidence, ECS task screenshot, ALB response screenshot, and CloudWatch log screenshot

Public Repo Cleanup Notes

The profile should stay centered on five pinned repos. Supporting public repos are fine when they are honestly framed as labs or prototypes:

• CommitVigil and cloudcull should stay unpinned until their proof is stronger.
• django-dynamic-app and warp-support-case-lab can stay public as supporting work, but they should not compete with the main DevOps pins.
• Archived companion repos are still linkable as history, but they should not be treated as headline projects until their evidence is refreshed.