feat: implement HTTP 301 redirects for capitalized valid SPA pages in edge worker

[google-labs-jules]

Summary of Changes

• Implemented edge-level URL normalization in src/worker.ts to solve case-sensitive router match failures causing soft 404 crawl errors.
• Intercepts incoming GET/HEAD requests and returns an HTTP 301 Moved Permanently response when the requested route contains any uppercase characters but resolves to a valid SPA page.
• Preserves and appends all query parameters on redirect.
• Bypasses redirect logic for static assets and media files using existing file check rules to prevent broken resource requests.
• Bypasses redirect logic for truly non-existent paths, letting the client-side router handle wildcards and home page redirection naturally.
• Added comprehensive unit test coverage in src/worker.spec.ts matching all functional criteria.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	equipose	2b4ee80	Commit Preview URL Branch Preview URL	Aug 13 2026, 01:35 PM

[google-labs-jules]

[CI/CD Fix] Fixed the Angular test compilation failure. The Cloudflare Edge Worker spec file (src/worker.spec.ts) was being picked up and compiled by the Angular unit-test builder (ng test). Since the worker file imports the generated Cloudflare _headers file which contains native path-matching syntax (such as /*) that isn't terminated like a JavaScript multi-line comment, the compiler failed with "Expected */ to terminate multi-line comment". Excluding worker files from the browser-focused Angular unit-test builder via angular.json and tsconfig.spec.json fixes the compilation issue while keeping worker tests covered natively by Vitest (pnpm test:unit).

[google-labs-jules]

[CI/CD Fix] Resolved the setup/linter CI failure. The Cloudflare worker spec file (src/worker.spec.ts) was excluded from both tsconfig.app.json and tsconfig.spec.json to prevent Angular test compilation errors (due to path-matching comments in imported Cloudflare _headers files). However, this caused ESLint's TypeScript project service to throw a parsing error as these worker files were not part of any referenced TypeScript project.

To fix this cleanly, I created a dedicated tsconfig.worker.json project configuration that includes src/worker.ts and src/worker.spec.ts, and added it as a project reference in tsconfig.json. This makes the files fully discoverable and parseable by ESLint/TypeScript project service, while maintaining their exclusion from Angular build/test targets.

[fderuiter]

1. Assess and Synchronize the Base State:
   1. Analyze: Before initiating any integration, you must confirm your local working environment is safe. If you have unsaved changes, switching branches could result in data loss. Furthermore, rebasing against an outdated main defeats the purpose of the operation; you must establish the absolute latest "truth" from the remote repository.
   2. Execute: Run git status to ensure a clean working tree. If clean, run git checkout main followed by git pull origin main.
   3. Verify: Read the terminal output to confirm main successfully fast-forwarded and no local file locks prevented the update.

2. Prepare the Feature Branch for History Rewriting:
   1. Analyze: You must now switch back to your specific context. By commanding a rebase, you are instructing Git to temporarily remove your feature's commits, update the branch's foundation to match the new main, and sequentially replay your work on top. You must mentally prepare for the fact that this process may halt if Git cannot automatically reconcile your logic with the new base.
   2. Execute: Run git checkout <your-feature-branch>, then run git rebase main.
   3. Verify: Observe the terminal output. Does it say "Successfully rebased" or "Merge conflict"? This determines your immediate next action.

3. Analyze, Synthesize, or Remake: The critical evaluation and decision phase.
   1. Analyze: If Git suspends the operation due to conflicts, you must first assess the scale of the divergence. Ask yourself: What was the logical intent of the main branch's change, and does my feature still fit into this new reality? If the underlying architecture of main has shifted so drastically that your feature's foundation is invalidated, recognize that you do not have to force a broken integration. It is completely acceptable—and often safer—to essentially remake the Pull Request to accommodate the new paradigm.
   2. Execute:

• If remaking the PR: Run git rebase --abort. Check out a fresh branch from main, and manually rebuild or cherry-pick your logic to align with the new architecture.
• If proceeding: Leverage a modern IDE or visual merge tool to open the flagged files. Critically evaluate the logic, meticulously synthesize the code to preserve overall functionality, and explicitly strip out the standard Git conflict markers (<<<<<<<, =======, >>>>>>>).
  3. Verify: Before closing the file, you must mentally (or physically via local linting/testing) run the code to ensure you haven't created a syntax error or broken the business logic during the synthesis.

4. Confirm Resolution and Advance the Sequence:
   1. Analyze: Assuming you proceeded with the rebase and have saved the synthesized files, you must now explicitly inform Git that human intervention is complete for this specific commit. Staging the files acts as your confirmation mechanism. Only when the right files are staged can you safely instruct Git to resume its replay sequence.
   2. Execute: Run git status to see the modified files, stage them with git add ., and trigger the next phase with git rebase --continue.
   3. Verify: Check if Git applied the commit and moved to the next one, if it hit another conflict, or if the entire rebase process is now complete.

5. Safely Override the Remote History: Preventing remote data loss.
   1. Analyze: Once the rebase has successfully completed locally, you have rewritten the commit history. Because of this, your local branch and the remote branch have completely diverged, and a standard push will be rejected. You must force the remote to accept your new history, but a blanket force push is dangerous. You must use a "lease" to ensure you only overwrite the remote if no one else has pushed new work to your feature branch while you were rebasing.
   2. Execute: Run git push origin <your-branch> --force-with-lease.
   3. Verify: Check the terminal output to confirm the push was accepted and the remote branch was successfully updated without rejecting the lease.

[google-labs-jules]

Hi @fderuiter,

I have successfully addressed your instructions from your previous comment:

1. Assess and Synchronize the Base State: Synchronized local main with the remote repository to ensure the latest "truth" was pulled.
2. Prepare the Feature Branch for History Rewriting: Rebased the feature branch jules/edge-worker-301-redirects-js1-785aa07e-2fd2-4591-9175-11d423507ebc onto main.
3. Analyze, Synthesize, or Remake: Meticulously resolved the minor merge conflict in Validation_Traceability_Matrix.md (retaining the updated timestamp from main's HEAD).
4. Confirm Resolution and Advance the Sequence: Staged the resolved file and completed the rebase. Verified correctness locally: ran a successful production build (pnpm run build) and verified that all 856 unit/integration tests successfully compile and pass (pnpm test:unit).
5. Safely Override Remote History: Force-pushed the rebased branch back to the remote repository.

The PR is now fully up to date, rebased, and all unit/integration tests are verified green!

[github-actions]

🎉 This PR is included in version 1.51.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀