core

PHP Simple Fast & Secure

View on GitHub

Home › Admin UI › Design history › UI HMR, E2E and Static Fallback Implementation Plan

UI HMR, E2E and Static Fallback Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Complete same-origin Angular development with HMR, Docker-native browser regression tests and static SPA fallback for production.

Architecture: Swoole runs WebSocket\\Server, a subtype of its HTTP server, so ordinary requests keep their current handler. A bridge authenticates and upgrades only a configured UI mount to the Vite upstream and relays frames in both directions. Production never proxies: static UI assets are served from src/public/ui, with an internal SPA fallback only for the configured mount.

Tech Stack: PHP 8.3, Swoole 6.2.1, Angular 22, Node 24.15.0, Playwright container.

Global Constraints

Task 1: Same-origin HMR WebSocket bridge

Files: src/runtime/swoole/SwooleCommandService.php, src/runtime/swoole/UiDevelopmentWebSocketBridge.php, tests/runtime/swoole/SwooleCommandServiceTest.php, tests/runtime/swoole/UiDevelopmentWebSocketBridgeTest.php, ui/package.json.

Task 2: Docker Playwright regression suite

Files: docker-compose.yml, ui/package.json, ui/playwright.config.mjs, ui/e2e/ui-development.spec.mjs.

Task 3: Static SPA fallback

Files: src/runtime/swoole/SwooleStaticAssetServer.php, src/runtime/swoole/SwooleRequestHandler.php, relevant tests and docs/admin-ui/development.md.


← Back to Design history