HIPCTF2/.kilo/plans/849.md

Implementation Plan: Landing Page and Login/Register Modal 1.00

1. Architectural Reconnaissance

• Status: The landing page, login/register modal, bootstrap payload flow, and Markdown helper are present, but Job 849 is not fully implemented: the reported runtime-function string proves the welcome binding is not receiving the intended rendered HTML at runtime. Existing source currently derives welcomeHtml in frontend/src/app/features/landing/landing.component.ts:46 and binds [innerHTML]="welcomeHtml" in frontend/src/app/features/landing/landing.component.html:9; this integration needs to be corrected and covered by a focused component-level regression test.
• Codebase style & conventions: Node.js npm workspace monorepo; Angular 17 standalone components with signals, OnPush, Angular control-flow blocks, reactive forms, and inject() services. The landing container owns bootstrap-derived state and delegates blog HTTP calls to LandingService.
• Data Layer: No database or schema change is required. Backend SystemService.bootstrap exposes the persisted welcomeMarkdown setting, and BootstrapService stores it in its signal payload. Blog data is separately fetched from GET /api/v1/blog/posts.
• Markdown and security path: markdown.pure.ts:9-11 converts Markdown using marked.parse and sanitizes with DOMPurify; MarkdownService.render wraps that output for Angular HTML binding. Preserve sanitization and ensure the template receives the computed signal value, not a signal/function object. Avoid introducing new CSP inline handlers or unsafe dynamic execution; the existing CSP console error should be investigated only insofar as it is caused by the rendering integration, without weakening CSP.
• Test Framework & Structure: Root Jest 29 multi-project configuration in tests/jest.config.js; frontend tests use ts-jest and jsdom, live exclusively under tests/frontend/, and run from the root with npm test or the focused npm run test:frontend command. Existing landing-markdown.spec.ts tests the pure renderer only; no current test mounts LandingComponent or verifies its [innerHTML] output.
• Required Tools & Dependencies: No new runtime or system dependency is expected. Existing @angular/core, @angular/platform-browser, marked, dompurify, Jest/jsdom, and ts-jest are sufficient. The implementer should use the existing setup.sh (npm ci/fallback install plus Angular and Nest builds); do not add a package solely for this fix unless repository inspection during implementation demonstrates an unavoidable Angular testing requirement.

2. Impacted Files

• To Modify:
  • frontend/src/app/features/landing/landing.component.ts — correct the component-side value passed to the HTML binding while retaining bootstrap signal reactivity and the existing MarkdownService sanitization boundary.
  • frontend/src/app/features/landing/landing.component.html — update the binding expression if needed so Angular unwraps/consumes the computed signal value correctly and never renders the function object/source.
  • frontend/src/app/core/services/markdown.service.ts — only if needed by the confirmed root cause; keep the public render contract and sanitization behavior stable rather than bypassing Angular security.
  • tests/frontend/landing-markdown.spec.ts — extend with the smallest regression coverage if a pure helper contract is changed; retain the existing XSS/link sanitization assertions.
  • tests/frontend/landing.component.spec.ts — add a dedicated focused component test under the existing dedicated frontend test folder to mount the standalone landing component and verify the rendered welcome card.
• To Create:
  • tests/frontend/landing.component.spec.ts — focused success-path and key safety/error regression tests, unless the implementer chooses to place equivalent coverage in an existing landing test without expanding scope.

3. Proposed Changes

Explain the exact implementation logic step-by-step:

1. Database / Schema Migration: No migration. Confirm the existing bootstrap response contract remains welcomeMarkdown: string; use the value already loaded by BootstrapService.payload() and preserve the backend setting/default behavior.
2. Backend Logic & APIs: No backend route or service change. Continue relying on GET /api/v1/bootstrap, which already returns the welcome Markdown, and do not alter /api/v1/blog/posts, authentication routes, login/register modal behavior, or CSP headers unless root-cause investigation proves the CSP message is independently generated by an existing Angular event-handler configuration.
3. Frontend UI Integration:
   1. Trace Angular template expression semantics for computed() values and verify whether the current [innerHTML]="welcomeHtml" passes the computed signal object rather than its value in this Angular 17 setup. The likely correction is to consume the signal (welcomeHtml()) in the property binding, matching the component’s other signal accesses (pageTitle(), logo(), landing.posts(), etc.).
   2. Keep welcomeHtml as a computed value derived from bootstrap.payload()?.welcomeMarkdown ?? '', so it updates automatically after bootstrap completes and renders an empty sanitized result when the payload is unavailable.
   3. Continue routing Markdown through MarkdownService.render and renderMarkdownToHtml; do not substitute raw interpolation, unsanitized innerHTML, eval, Function, or a security bypass around untrusted content. If the current helper’s return type or sanitizer wrapper must change to make Angular accept the binding, make the narrowest compatible change and preserve DOMPurify’s HTML profile.
   4. Leave the existing landing title, login button, empty blog state, and modal forms unchanged except where template compilation requires a minimal adjacent adjustment. The expected welcome DOM for the supplied payload must contain an <h1> with Welcome and paragraph text Create the first admin to get started. rather than the Angular runtime helper source.
   5. Check the reported CSP error after the binding fix during automated verification. Do not weaken script-src-attr 'none'; if a separate source-level inline-handler issue is identified, replace it with Angular event bindings or document it as unrelated rather than adding an unsafe CSP exception.
4. Test Strategy Integration: Add only minimal automated frontend logic tests: one component test that supplies a mock BootstrapService payload containing the job’s Markdown, renders the standalone component with minimal providers/mocks, and asserts the welcome element contains the heading and paragraph and does not contain the runtime-function text; one safety/error-focused assertion may verify empty/null Markdown produces no runtime source and that the existing pure renderer remains sanitized. Mock LandingService.refresh() and any unrelated auth/router dependencies as resolved stubs so the test does not perform HTTP, navigation, or UI/browser automation. Keep tests in tests/frontend/ and make them pass through the existing root npm test command.

4. Test Strategy

• Target Unit Test File: tests/frontend/landing.component.spec.ts for the component/template regression; retain/update tests/frontend/landing-markdown.spec.ts only if the renderer contract is touched. No visual, screenshot, browser, network, database, or persistent /data fixture is needed.
• Mocking Strategy: Configure the standalone component through Angular TestBed; provide a deterministic BootstrapService stub with a signal-backed payload, a LandingService stub whose refresh is a resolved promise and whose posts/loading/error signals represent the empty blog state, plus minimal AuthService, Router, and MarkdownService stubs or real pure Markdown service as appropriate. If HTTP providers are required by transitive dependencies, use Angular’s testing providers rather than manual HTTP mocks and ensure no request is left outstanding. Assert through stable data-testid attributes or a small harness/query abstraction, not CSS classes. Verify both the expected sanitized HTML content and absence of the Angular runtime source string.
• Verification commands for the implementer: Run the focused frontend test, then root npm test, frontend production build, lint, and typecheck using the repository’s available scripts/configuration. Since no lint/typecheck scripts are present in the inspected root or frontend package.json, inspect any project tooling before implementation; if no commands exist, record that limitation rather than inventing dependencies. setup.sh already installs dependencies and builds both packages, so no update is planned.