packages/likec4/src/vite/vite-build.ts (1)

81-93: Extract the landing-page matcher into shared code.

This #tag/view.id matching logic is now duplicated in both build paths and separately in packages/likec4/app/src/filterLandingPageViews.ts. Pulling it into one shared helper will keep the warning behavior aligned with the actual runtime filter.

Also applies to: 103-115

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/likec4/src/vite/vite-build.ts` around lines 81 - 93, Extract the
duplicated "#tag"/"view.id" matching logic into a single shared helper (e.g.,
matchLandingPage or landingPageMatcher) and replace the inline logic in
vite-build.ts (the landingPage check that uses patterns.some(p =>
p.startsWith('#') ? v.tags?.some(t => t === p.slice(1)) : v.id === p)) and the
code in filterLandingPageViews.ts to call that helper; ensure the helper accepts
(diagrams, patterns) or (view, patterns) and implements the exact semantics:
pattern starting with '#' matches view.tags entries (compare to p.slice(1)),
otherwise matches view.id, and keep the existing hasMatch/warning behavior by
importing and invoking the new helper from both places.

packages/likec4/app/src/filterLandingPageViews.ts (1)

4-29: Accept the minimal view shape instead of full LayoutedView.

This helper only uses id and tags, but the current signature forces callers/tests to manufacture full LayoutedViews and is already leaking an as any into the new spec. A small reusable input type here keeps the API honest and removes that unsafe cast downstream.

♻️ Suggested refactor

 import type { LikeC4ProjectConfig } from '@likec4/config'
 import type { LayoutedView } from '@likec4/core/types'

+export type LandingPageView = Pick<LayoutedView, 'id' | 'tags'>
+
 export function filterLandingPageViews(
-  views: ReadonlyArray<LayoutedView>,
+  views: ReadonlyArray<LandingPageView>,
   filter: LikeC4ProjectConfig['landingPage'],
-): ReadonlyArray<LayoutedView> {
+): ReadonlyArray<LandingPageView> {
   if (!filter) return views

   if ('include' in filter) {
     return views.filter(view => matchesAny(view, filter.include))
   }
@@
   return views
 }

-function matchesAny(view: LayoutedView, patterns: string[]): boolean {
+function matchesAny(view: LandingPageView, patterns: ReadonlyArray<string>): boolean {
   return patterns.some(pattern => {

As per coding guidelines, "Agent types and interfaces should be defined separately and reused across the codebase" and "TypeScript-first repo; use explicit types Avoid using any, casts with as".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/likec4/app/src/filterLandingPageViews.ts` around lines 4 - 29,
Change filterLandingPageViews and matchesAny to accept a small reusable input
type (e.g., an interface with id: string and tags?: string[]) instead of
LayoutedView so callers/tests no longer need to fabricate full LayoutedView or
use `as any`; define this MinimalView type near other shared types and update
the function signatures (filterLandingPageViews(views:
ReadonlyArray<MinimalView>, ...) and matchesAny(view: MinimalView, patterns:
string[])) and any call sites/tests to pass the minimal shape; ensure logic
inside matchesAny still uses view.id and view.tags the same way and export the
new type for reuse across the codebase.

packages/likec4/app/src/filterLandingPageViews.spec.ts (1)

18-45: Add a redirect regression test.

landingPage.redirect is part of the new public contract, and this helper currently treats it as a no-op only through the final fall-through. An explicit spec here would keep that behavior from regressing if the branching changes later.

➕ Suggested test

 describe('filterLandingPageViews', () => {
   const views = [
     mockView('landscape', ['public']),
     mockView('context', ['public']),
     mockView('internal', ['draft']),
     mockView('detail', []),
   ]

   it('returns all views when no filter', () => {
     expect(filterLandingPageViews(views, undefined)).toEqual(views)
   })
+
+  it('returns all views when redirect is configured', () => {
+    expect(filterLandingPageViews(views, { redirect: true })).toEqual(views)
+  })

   it('includes by view ID', () => {

As per coding guidelines, "Aim to cover new features with relevant tests; keep test names descriptive."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/likec4/app/src/filterLandingPageViews.spec.ts` around lines 18 - 45,
Add a spec to filterLandingPageViews.spec.ts that verifies landingPage.redirect
is treated as a no-op by filterLandingPageViews: create a test (e.g., "treats
landingPage.redirect as no-op") that passes a view object with a
landingPage.redirect property to filterLandingPageViews (both with undefined
filter and with include/exclude filters) and assert the view is preserved in
results; reference the filterLandingPageViews helper and the
landingPage.redirect field so the test prevents regression if branching changes
later.

packages/likec4/app/src/routes/index.tsx (1)

2-2: Inconsistent data source: projects import vs context.projects.

Line 6 uses context.projects from the route context, but line 16 uses the directly imported projects from 'likec4:projects'. While they should contain the same data, mixing data sources can lead to subtle inconsistencies and makes the code harder to reason about.

Proposed fix: use context consistently

-import { projects } from 'likec4:projects'

-    if (projects[0]?.landingPage && 'redirect' in projects[0].landingPage) {
+    if (context.projects[0]?.landingPage && 'redirect' in context.projects[0].landingPage) {

Also applies to: 16-16

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/likec4/app/src/routes/index.tsx` at line 2, The file mixes two data
sources— the top-level import "projects" and the route context's
"context.projects"—causing potential inconsistencies; remove the direct import
of projects and update all usages (e.g., the occurrence at line 16) to use
context.projects instead so the component relies solely on the route context
(ensure you delete the import "import { projects } from 'likec4:projects'" and
replace any remaining references to projects with context.projects).