To support ongoing development and testing, we've updated the luxury database instance with 100 new product entries and integration of Lux AI red teaming chat logs. This expansion allows for more robust testing of AI behaviors against diverse scenarios.

Updated the Azure deployment workflow to use terraform apply -refresh-only instead of a full apply when verifying infrastructure states. This change aligns the execution strategy with the goal of correctly reconciling resource names from existing state after importing. It ensures that the state capture remains focused on drift detection rather than unnecessary infrastructure modifications.

Cleaned up the Terraform deployment workflow by removing an unnecessary role assignment import. Verification via remote container logs confirmed that the current AKS configuration remains functional without this explicit import. This reduces clutter in our CI/CD pipeline and ensures we are only managing required state resources.

Updated the resource import path for azurerm_role_assignment.aks_acr_pull in the Azure deployment workflow to reflect the correct role assignment ID. Ensuring this ID is correctly synced allows Terraform to accurately manage the existing AKS-to-ACR pull permissions without inadvertent recreation. This configuration adjustment keeps our infrastructure state clean and aligned with the Azure environment.

This change makes the GitHub Actions Azure deploy job more resilient when production resources already exist outside the current Terraform state. The workflow now clears stale state entries, sets the subscription ID explicitly, and imports the resource group, networking, AKS, ACR, Key Vault, App Service, SQL resources, and role assignment before running terraform apply. In practice, this should prevent the common "resource already exists" failure mode and make repeatable infrastructure deploys much smoother.

This change refines the Daily Repo Status agent prompt so the automated report now explicitly pays closer attention to Terraform and the Azure infrastructure the repo deploys. The compiled workflow was regenerated alongside that prompt update, which also introduced Copilot-specific engine metadata and concurrency guards in the locked workflow to keep runs from overlapping. In practice, the daily status issue should produce more infrastructure-aware insights with more predictable workflow execution.

This PR introduces a new GitHub Agentic Workflow that runs on a daily schedule or on demand to collect recent repo activity and turn it into a status report issue. The workflow definition and compiled lock file set up the agent runtime, GitHub read permissions, safe-output issue creation, and the supporting execution pipeline needed to produce these reports automatically. In practice, maintainers now get recurring, structured visibility into project activity and suggested next steps with much less manual triage.

This change introduces a new GitHub Actions workflow definition and its compiled lockfile for a daily "repo status" report powered by the agentic workflow system. The workflow is scheduled to collect recent issues, PRs, discussions, releases, and code changes, then turn that activity into a concise issue with recommendations and next steps for maintainers. It also marks generated lockfiles in .gitattributes to reduce merge noise and treat compiled workflow output as generated. The practical effect is a new automated daily project pulse check with cleaner workflow maintenance.

This change updates the project README with badges for Azure deployment, Checkov IaC scanning, OPA policy tests, and OWASP ZAP scans. It doesn’t change runtime behavior, but it improves transparency around build and security automation for contributors and reviewers. The practical effect is that anyone landing on the repo can quickly see whether key pipelines are passing.

This change moves the app’s deployment flow away from hardcoded Azure values by running Terraform in CI, capturing outputs like the ACR login server, resource group, and web app name, and then using those values for image push and web app updates. The infrastructure config was also retargeted to a new Azure subscription, region, and resource naming scheme, including new ACR, web app, SQL server, and Key Vault identifiers. For developers, this makes the deployment path more portable across Azure environments and reduces manual config drift between infra and app delivery. Practical effect: pushes to main now provision/apply against the new subscription and deploy using the live Terraform-managed endpoints.

This commit adds a comprehensive summary of the project’s recent security hardening work, including the headers, SRI, cookie, and cache-control changes made to address OWASP ZAP findings. The document also records testing results, expected alert reduction, known acceptable risks, and concrete post-deployment verification steps so the team can validate that fixes actually reached production. It’s documentation-only, but it usefully centralizes the security context and operational checklist for future audits and follow-up work.

This change adds a centralized after_request middleware that now sets CSP, HSTS, frame/MIME protections, permissions policy, and cross-origin isolation headers, while also stripping the Server header. It also applies context-aware cache rules so login, cart, checkout, and admin endpoints are not cached, while static assets get long-lived immutable caching, and CDN assets in the base template now include SRI hashes. The commit includes a verification guide documenting expected headers, deployment checks, and known platform limits, making the hardening easier to validate in production. Practical effect: safer defaults for every response with better protection against XSS, clickjacking, information leakage, and accidental caching of sensitive pages.

This commit adds an OWASP ZAP remediation plan and, more importantly, records a critical operational finding: the app already contains security header and cookie hardening changes, but production is still serving without them because those changes have not reached main and been deployed. The document captures evidence from the scan, identifies deployment as the immediate blocker, and breaks the remaining findings into prioritized follow-up PRs for SRI, cache control, input validation, and cleanup. The practical effect is a much clearer path to getting production back to the expected security baseline before tackling lower-priority issues.

This change addresses review feedback in app.py by making SESSION_COOKIE_SECURE depend on whether the app is using the local DB, which avoids breaking non-HTTPS local development while still enforcing secure cookies in production. It also tightens the Content Security Policy by removing http: from img-src, reducing mixed-content exposure, and adds comments clarifying the current unsafe-inline tradeoff and a future hardening path. The practical effect is a smoother local dev setup with slightly stronger default security in deployed environments.