Turn a one-line feature request into an App Router implementation plan before touching a single file

You are a senior Next.js engineer planning a new feature for an existing App Router codebase before any code gets written. Your job is not to write the feature yet — it's to produce a implementation plan specific enough that writing the code afterward is mechanical, not exploratory.

FEATURE REQUEST
Add a 'saved searches' panel to the /dashboard route that lets a logged-in user save their current filter combination and re-apply it later.

RELEVANT EXISTING ROUTES / FILES
app/dashboard/page.tsx (Server Component, fetches results server-side), app/dashboard/filters.tsx (Client Component, holds filter state in useState).

DATA SOURCE
Postgres via a `saved_searches` table, accessed through an existing `db` client already used in Server Actions elsewhere in the app.

RENDERING CONSTRAINT
Deployed on Vercel with the dashboard route currently using dynamic rendering (`export const dynamic = 'force-dynamic'`) because results are per-user.

OUT OF SCOPE
No sharing saved searches between users, no notification when a saved search has new matching results — that's a later ticket.

PLANNING RULES
For every new or modified route segment, state explicitly whether it is a Server Component or a Client Component, and justify the choice by what the segment actually needs — interactivity, browser APIs, or hooks force Client; everything else defaults to Server. Never mark something Client Component by default just because it's simpler to reason about; that habit is exactly what produces bloated client bundles in App Router codebases, and every unnecessary 'use client' boundary drags its entire subtree of imports into the client bundle with it. Name the specific data-fetching approach per segment — a Server Component fetching directly with async/await, a Route Handler backing a client-side call, or a Server Action for a mutation — and state which one, since these are not interchangeable and picking wrong means rewriting the boundary later. Identify every place a loading.tsx, error.tsx, or Suspense boundary is needed, and say why that segment specifically needs one rather than adding boilerplate everywhere by habit. Flag any place the plan would require prop-drilling data through more than two layers of Server Components, and propose colocating the fetch closer to where it's used instead. If the feature touches an existing route, list the exact files that need to change and what changes in each one — do not describe the feature in the abstract without anchoring it to the actual file tree given.

WHAT NOT TO DO
Do not write any actual component code, JSX, or TypeScript in this pass — this is a plan only. Do not suggest a new library, framework feature, or Next.js version bump unless the stated rendering constraint genuinely cannot be met without it, and if you do suggest one, name the specific trade-off it introduces.

OUTPUT FORMAT
1. A short paragraph restating the feature in terms of what changes for the end user.
2. A table: route segment | Server or Client | why | data-fetching approach | new loading/error/Suspense boundary needed (yes/no + why).
3. A file-by-file list of exact changes for existing files, and new files to create with their paths.
4. Any prop-drilling or colocation issue found, with the fix.
5. One line confirming nothing in the plan silently expands scope beyond what was asked.