bastian/travel-planner
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: adjust phase 01 plan for pre-existing angular/nestjs scaffold

Browse Source
This commit is contained in:
Bastian Wagner
2026-08-17 12:59:32 +02:00
parent feff7c717e
commit 2c91596c48
1 changed files with 15 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/superpowers/plans/travel-planner-phase-01-foundation-plan.md
View File

@@ -1713,3 +1713,18 @@ Then verify:
## Phase 01 Review Boundary ## Phase 01 Review Boundary
Do not start OIDC, users, trips, Mistral, agent tools, web research, or business migrations during this phase. Phase 02 begins only after the Phase 01 acceptance checklist is reviewed and green. Do not start OIDC, users, trips, Mistral, agent tools, web research, or business migrations during this phase. Phase 02 begins only after the Phase 01 acceptance checklist is reviewed and green.
---
## Addendum: Adjustments Against the Pre-Existing Scaffold (2026-08-17)
The repository already contains a generated Angular project (`frontend/`, Angular 21.2.0, npm) and a generated NestJS project (`backend/`, NestJS 11, single-app layout, ts-jest). The master instructions explicitly forbid re-scaffolding either project. This addendum documents the small, non-architectural adjustments applied to this plan as a result — per "kleine technische Details darfst du selbst sinnvoll lösen", no user decision was required:
1. **Task 1** — pnpm workspace wraps the *existing* `frontend/` and `backend/` directories; nothing there is regenerated.
2. **Task 2** — `backend/src/{app.module.ts,app.controller.ts,app.controller.spec.ts,app.service.ts,main.ts}` are **migrated** (moved + adapted) into `backend/apps/api/src/`, not regenerated from a schematic. `nest-cli.json` is converted to `monorepo: true` with `api` + `worker` projects, matching the target file structure. The existing `AppController`/`AppService` are kept as the initial `ApiModule` content instead of an empty module, since deleting working, tested code has no benefit.
3. **Test runner** — the existing backend Jest config uses `ts-jest`, not `@swc/jest`, and passes today. Per "bestehende funktionierende Konfiguration bevorzugt weiterverwenden", `ts-jest` is kept for Phase 01 instead of migrating to SWC; this is a test-runner detail, not an architectural one, and can be revisited later if build performance requires it.
4. **Task 4** — no `ng new`/`ng add @angular/pwa` full re-scaffold. The existing Angular 21.2 project is kept and extended in place: `pnpm add -D @angular/pwa` equivalent (`ng add @angular/pwa`) is run *against the existing project* to layer in the service worker/manifest without touching unrelated generated files. The project already uses the newer Angular file-naming convention (`app.ts`/`app.html`/`app.scss`/`app.spec.ts` instead of `app.component.ts` etc.); all plan steps referencing `app.component.*` apply to these equivalently-named files instead.
5. **Angular version** — kept at 21.2.x (already installed) rather than upgraded to 22.x. Upgrading a working, freshly generated Angular major version is out of scope for "establish the foundation" and is not required by any Phase 01 acceptance criterion; the roadmap's "Angular 22.x" baseline is a target for new projects, not a mandate to upgrade an existing working one mid-foundation. Revisit as an explicit, isolated upgrade task if a later phase needs an Angular-22-only feature.
6. **package manager pin** — both existing projects pin `packageManager` fields (`npm@11.12.1`). These are superseded by the root `packageManager: pnpm@...` per the master instructions (Abschnitt 52); the per-package fields are removed during the pnpm migration to avoid Corepack conflicts.
No product/business behavior changes result from these adjustments; they only change *how* the target file structure is reached.