# Freiburger Bund — Product Knowledge Corpus

> Plain-text snapshot of implementation-agnostic feature specifications for Freiburger Bund pages and portals. Content is platform-authored product documentation, not live user-generated data. Employer and company features are excluded from this deployment. Corpus last updated 2026-09-16.

## Page: Homepage
- URL: https://freiburger-bund.com/en
- Type: product-spec
- Section: Public Entry & Discovery
- Access: public
- Source: docs/product-knowledge/pages/home.md
- Updated: 2026-09-21

### Purpose
Introduce the Freiburger Bund network to international healthcare professionals and help them discover the four journey phases, four product portals, and next steps to start planning a career in Germany.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Hero introduction
> 
> **What it does**
> 
> Presents the main value proposition with a headline, supporting tagline, background imagery, and two primary calls to action.
> 
> **User flow**
> 
> 1. User lands on the homepage.
> 2. User reads the headline and tagline about learning, connecting, and advancing a career in Germany.
> 3. User may click **Start Your Journey** or **Book a Consultation**.
> 
> **Rules**
> 
> - Both primary actions are always visible in the hero area.
> - **Start Your Journey** leads into the personal journey area.
> - **Book a Consultation** leads to a consultation booking experience.
> 
> **States**
> 
> - Default: headline, imagery, and both buttons visible.
> - Signed-in users may see the same hero; button destinations may differ from guest users.
> 
> ---
> 
> ### Network overview section
> 
> **What it does**
> 
> Explains in one paragraph what the Freiburger Bund offers: structured information, community, and career opportunities in one place.
> 
> **User flow**
> 
> 1. User scrolls below the hero.
> 2. User reads the “One Network. Every Opportunity.” section.
> 
> **Rules**
> 
> - Informational only; no interactive controls in this block.
> 
> **States**
> 
> - Always visible as static content.
> 
> ---
> 
> ### Four-phase journey overview
> 
> **What it does**
> 
> Shows the four interconnected phases of the path to Germany, each with a title, description, and stated goal.
> 
> **User flow**
> 
> 1. User reads the section introduction about choosing the right phase.
> 2. User reviews Phase 1 (Travel Preparation → goal: Visa), Phase 2 (Professional Recognition → goal: Approbation), Phase 3 (Job Entry → goal: Employment contract), and Phase 4 (Career → goal: Career).
> 3. User may select a phase to continue into the journey experience.
> 
> **Rules**
> 
> - Phases are presented in fixed order from preparation through long-term career.
> - Each phase card communicates one primary goal outcome.
> 
> **States**
> 
> - All four phases always shown.
> - **Unknown / requires product clarification:** whether phase cards on the homepage link directly into journey tools, info portal phases, or another destination.
> 
> ---
> 
> ### Portal and tools entry cards
> 
> **What it does**
> 
> Introduces the four main product areas—Info Portal, Community Portal, Job Portal, and Practical Tools—with a short description and an explore action for each.
> 
> **User flow**
> 
> 1. User reads the “Freiburger Bund Portals and Tools” section.
> 2. User reviews each portal card.
> 3. User clicks **Explore** on a card to enter that portal or tool area.
> 
> **Rules**
> 
> - Four cards are always shown: Info, Community, Job, and Practical Tools.
> - Each card has its own explore action.
> 
> **States**
> 
> - Default: all four cards visible.
> 
> ---
> 
> ### Member testimonials
> 
> **What it does**
> 
> Displays quotes from members about their experience with the platform, with name, role, and location attribution.
> 
> **User flow**
> 
> 1. User scrolls to “Voices from the Freiburger Bund.”
> 2. User reads one or more testimonial quotes.
> 3. User may swipe or scroll through multiple testimonials if more than one is shown.
> 
> **Rules**
> 
> - Testimonials are curated marketing content.
> - Attribution includes member name and professional context.
> 
> **States**
> 
> - Multiple testimonials may appear in a repeating or carousel layout.
> 
> ---
> 
> ### Mobile app promotion
> 
> **What it does**
> 
> Promotes the Freiburger Bund mobile app with store download links.
> 
> **User flow**
> 
> 1. User reads the app section headline and supporting copy.
> 2. User taps the Google Play or App Store badge.
> 3. The corresponding app store opens in a new browser tab.
> 
> **Rules**
> 
> - Both store badges are offered when the section is present.
> - Store links open externally.
> 
> **States**
> 
> - Section visible when configured in page content.
> 
> ---
> 
> ### Trusted partners
> 
> **What it does**
> 
> Displays logos of partner organizations that support integration and professional growth.
> 
> **User flow**
> 
> 1. User scrolls to the partners section.
> 2. User views partner logos and optional supporting copy.
> 
> **Rules**
> 
> - Logos are display-only unless individually linked.
> - Partner set is managed through page content.
> 
> **States**
> 
> - Empty or hidden if no partners are configured.
> 
> ---
> 
> ### Skip to main content
> 
> **What it does**
> 
> Allows keyboard and assistive-technology users to bypass repeated navigation and jump directly to page content.
> 
> **User flow**
> 
> 1. User activates the skip link (typically first focusable element).
> 2. Focus moves to the main content area.
> 
> **Rules**
> 
> - Available on initial page load.
> - Hidden visually until focused.
> 
> **States**
> 
> - Always available.
> 
> ---
> 
> ### Global site header
> 
> **What it does**
> 
> Provides persistent navigation, branding, language selection, search, and account access across the site.
> 
> **User flow**
> 
> 1. User sees the sticky header while scrolling.
> 2. User clicks the logo to return home.
> 3. User opens main navigation (mega-menu, dropdown, or mobile hamburger).
> 4. User switches language, searches, or signs in / opens profile.
> 
> **Rules**
> 
> - Header remains visible while scrolling.
> - Main navigation includes portal areas (Dashboard, Portals, Tools, About Us, FAQ) and nested links.
> - Language options include English, German, French, and Arabic.
> - When a translated equivalent page exists, language switching keeps the user on the same page in the new language.
> 
> **States**
> 
> - **Guest:** Login and Sign Up visible.
> - **Signed-in:** profile menu, notifications, chat, and support bot replace login/sign-up.
> - **Mobile:** navigation collapses into hamburger menu.
> - **Moderator:** moderator badge visible when applicable.
> 
> ---
> 
> ### Global site search
> 
> **What it does**
> 
> Lets users search the site from the header.
> 
> **User flow**
> 
> 1. User enters a query in the search field.
> 2. User submits search.
> 3. User is taken to the search results page.
> 
> **Rules**
> 
> - Available from the desktop header.
> - **Unknown / requires product clarification:** mobile search entry point.
> 
> **States**
> 
> - Empty query behavior follows standard form validation.
> 
> ---
> 
> ### Global site footer
> 
> **What it does**
> 
> Provides organization contact details, portal and support links, newsletter signup, social profiles, legal links, and copyright.
> 
> **User flow**
> 
> 1. User scrolls to the footer.
> 2. User clicks email or phone to contact the organization.
> 3. User navigates via footer link columns.
> 4. User subscribes to the newsletter.
> 5. User opens legal pages or cookie settings.
> 
> **Rules**
> 
> - Organization block shows address, email, and phone.
> - Newsletter requires an email address.
> - Legal links include privacy policy, terms, legal notice, and cookie settings.
> - On mobile, a compact newsletter strip may appear instead of the full desktop footer layout.
> 
> **States**
> 
> - **Newsletter success:** confirmation feedback after valid submission.
> - **Newsletter error:** error message on invalid or failed submission.
> 
> ---
> 
> ### Cookie consent banner
> 
> **What it does**
> 
> Informs users about cookie use and lets them accept all cookies or open detailed settings.
> 
> **User flow**
> 
> 1. User sees the cookie notification on first visit (or when consent is required).
> 2. User clicks **Accept All** or **Settings**.
> 3. Settings opens a modal to adjust cookie categories (Necessary, Tracking, External media).
> 
> **Rules**
> 
> - Shown until consent is recorded.
> - Necessary cookies are always required.
> 
> **States**
> 
> - **Visible:** consent not yet given.
> - **Dismissed:** after acceptance or configured preferences.
> 
> ---
> 
> ### Back to top
> 
> **What it does**
> 
> Returns the user to the top of the page after scrolling.
> 
> **User flow**
> 
> 1. User scrolls down the long landing page.
> 2. User clicks the back-to-top control.
> 3. Page scrolls to the top.
> 
> **Rules**
> 
> - Appears after sufficient scroll depth.
> 
> **States**
> 
> - Hidden at top of page; visible after scrolling.
> 
> ---
> 
> ### Multi-language page viewing
> 
> **What it does**
> 
> Lets users view the homepage in English, German, French, or Arabic.
> 
> **User flow**
> 
> 1. User opens the language menu in the header.
> 2. User selects a language.
> 3. Page reloads with localized content and URL.
> 
> **Rules**
> 
> - All four languages are supported.
> - Arabic layout uses right-to-left reading direction.
> 
> **States**
> 
> - Active language indicated in the header.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Direct visit, search engines, marketing links, logo clicks from other pages, post-login redirects, app store or campaign links.
> 
> **Outbound**
> 
> - Personal journey (Start Your Journey)
> - Consultation booking
> - Info Portal, Community Portal, Job Portal, Practical Tools (Explore cards and header)
> - About Us, FAQ, Dashboard (header)
> - Login, Sign Up
> - Search results
> - Mobile app stores
> - Footer support pages (Contact, Course Registration, Press, etc.)
> - Legal and policy pages
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Sees Login and Sign Up; no profile, notifications, or chat in header |
> | Signed-in member | Profile menu, notifications, chat, and support bot in header; hero button destinations may differ |
> | Moderator | Same as signed-in, plus moderator badge in profile area |
> 
> Employer-specific features are not visible on the homepage.
> 
> ---
> 
> ## Important Business Rules
> 
> - The homepage is the primary public entry point and must surface all four product pillars.
> - Journey phases are presented as a sequential narrative from visa preparation through long-term career.
> - Portal cards are the main discovery path into Info, Community, Job, and Tools.
> - Cookie consent must be obtainable before non-essential tracking.
> - Newsletter signup is optional and separate from account registration.
> - Organization contact details in the footer reflect Freiburg International Academy GmbH as the initiative behind the platform.
> 
> ---
> 
> ## Related Features
> 
> - Personal journey and dashboard
> - Info Portal phase landing
> - Community Portal phase landing
> - Job Portal home
> - Practical tools (cost calculator, visa navigator, etc.)
> - Consultation booking
> - Account registration and login
> - Mobile app (iOS and Android)
> - FAQ and support pages

---

## Page: About Us
- URL: https://freiburger-bund.com/en/about-us
- Type: cms
- Section: Public Entry & Discovery
- Access: public
- Source: docs/product-knowledge/pages/about-us.md
- Updated: 2026-09-21

### Purpose
Explain what the Freiburger Bund is, what it offers international healthcare professionals, how members can participate, and the organization’s guiding principles—so visitors understand the network before joining or using the portals.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Page title and introduction
> 
> **What it does**
> 
> Presents the About Us headline and an opening paragraph describing the nationwide network and peer support for healthcare professionals coming to Germany.
> 
> **User flow**
> 
> 1. User navigates to About Us from the main menu or footer.
> 2. User reads the page title and introductory text.
> 
> **Rules**
> 
> - Introductory copy sets context for the rest of the page.
> 
> **States**
> 
> - Static content.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows the user’s location within the site hierarchy and allows quick navigation back to Home.
> 
> **User flow**
> 
> 1. User sees breadcrumb trail above the main content.
> 2. User clicks Home to return to the homepage.
> 
> **Rules**
> 
> - Current page is shown as the active breadcrumb segment.
> - Earlier segments are clickable links.
> 
> **States**
> 
> - **Unknown / requires product clarification:** full breadcrumb label set; staging may show incomplete translation for some segments.
> 
> ---
> 
> ### What the network offers
> 
> **What it does**
> 
> Describes the scope of support from travel planning through integration into the German labor market, followed by portal overview cards.
> 
> **User flow**
> 
> 1. User reads the section heading and supporting paragraph.
> 2. User reviews three portal cards: Info portal, Community portal, and Job portal.
> 
> **Rules**
> 
> - Each card summarizes one major product area.
> - Cards are informational entry points into those portals.
> 
> **States**
> 
> - Three portal cards shown on current staging content (Info, Community, Job).
> 
> ---
> 
> ### Participate and network
> 
> **What it does**
> 
> Encourages members to contribute ideas and actively participate in building the community.
> 
> **User flow**
> 
> 1. User reads the participation section.
> 2. User understands that member engagement shapes the network.
> 
> **Rules**
> 
> - Informational section; no direct submission form on this page.
> 
> **States**
> 
> - Static content.
> 
> ---
> 
> ### Guiding principles
> 
> **What it does**
> 
> Presents the organization’s vision, mission, and values as three distinct principle blocks.
> 
> **User flow**
> 
> 1. User reads the Guiding Principles section heading.
> 2. User reviews **Our vision** (vibrant community, trust, cooperation).
> 3. User reviews **Our mission** (political neutrality, connection, practical support).
> 4. User reviews **Our values** as a list: equal opportunities and fairness; diversity and interculturality; openness and tolerance.
> 
> **Rules**
> 
> - Vision and mission each appear as a single narrative block.
> - Values appear as three enumerated items with short explanations.
> 
> **States**
> 
> - All three principle blocks always shown.
> 
> ---
> 
> ### Mobile app promotion
> 
> **What it does**
> 
> Promotes the Freiburger Bund mobile app with links to Google Play and the App Store.
> 
> **User flow**
> 
> 1. User reads the app promotion section.
> 2. User taps a store badge to open the external app store.
> 
> **Rules**
> 
> - Store links open in a new tab.
> 
> **States**
> 
> - Visible when included in page content.
> 
> ---
> 
> ### Embedded page footer block
> 
> **What it does**
> 
> On this page, a full footer content block (organization details, link columns, newsletter, social links, legal links) may appear within the page body in addition to the global site footer.
> 
> **User flow**
> 
> 1. User scrolls through page content.
> 2. User interacts with newsletter, links, or social icons in the embedded footer section.
> 
> **Rules**
> 
> - Mobile users on this page may see fuller footer content here than on pages that only use the compact mobile site footer.
> 
> **States**
> 
> - Duplicate footer presentation possible (embedded block plus global footer).
> 
> ---
> 
> ### Global site header (abbreviated)
> 
> **What it does**
> 
> Same sticky site header as other pages: logo, navigation, language, login/profile.
> 
> **User flow**
> 
> 1. User sees **About Us** highlighted as the active main navigation item.
> 2. User navigates to other portals or signs in.
> 
> **Rules**
> 
> - About Us tab remains active while on this page across supported languages.
> 
> **States**
> 
> - Guest vs signed-in behavior matches the homepage header.
> 
> ---
> 
> ### Global site footer and cookie consent
> 
> **What it does**
> 
> Provides site-wide footer links, newsletter, legal pages, social profiles, and cookie consent—same capabilities as the homepage.
> 
> **User flow**
> 
> 1. User uses footer links to reach portals, support pages, or legal documents.
> 2. User manages cookie preferences if prompted.
> 
> **Rules**
> 
> - Same business rules as homepage footer and cookie banner.
> 
> **States**
> 
> - Same as homepage.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Main navigation **About Us** tab
> - Footer “About us” link
> - Homepage and portal cross-links
> - Direct URL or search
> 
> **Outbound**
> 
> - Home (breadcrumb)
> - Info Portal, Community Portal, Job Portal (portal cards and footer)
> - Contact, FAQ, Consultation, Course Registration, Press, Partnership (footer)
> - Mobile app stores
> - Legal and privacy pages
> - Login, Sign Up, other portals via header
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Login and Sign Up in header; read-only content |
> | Signed-in member | Profile menu and messaging tools in header; same page content |
> | Moderator | Moderator badge when applicable |
> 
> No role-specific content blocks on the About Us page itself.
> 
> ---
> 
> ## Important Business Rules
> 
> - The Freiburger Bund is described as politically and ideologically neutral.
> - Support spans the full journey from travel planning to labor-market integration.
> - Values emphasize equal opportunity, diversity, and open discourse.
> - The page is informational; membership actions happen elsewhere (registration, community participation).
> - Organization contact details identify Freiburg International Academy GmbH as the initiative.
> 
> ---
> 
> ## Related Features
> 
> - Homepage (primary entry and portal discovery)
> - Info Portal, Community Portal, Job Portal
> - Account registration
> - Contact and consultation
> - FAQ
> - Mobile app
> - Sponsors and supporters pages

---

## Page: Global Search
- URL: https://freiburger-bund.com/en/search
- Type: product-spec
- Section: Public Entry & Discovery
- Access: public
- Source: docs/product-knowledge/pages/search.md
- Updated: 2026-09-21

### Purpose
Let anyone search across info articles, community channels and threads, job postings, and user profiles from one entry point with portal-specific filters and combined preview on the All tab.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Page header and search bar
> 
> **What it does**
> 
> Introduces cross-portal search with keyword field, debounced input, clear button, and URL-synced query.
> 
> **User flow**
> 
> 1. User types keywords; results update after short debounce.
> 2. User clears search to reset results.
> 3. Query persisted in page address for sharing.
> 
> **Rules**
> 
> - Open to guests and signed-in users; no login wall.
> - ~500ms debounce on keyword changes.
> 
> **States**
> 
> - Empty query, active query, clearing.
> 
> ---
> 
> ### Portal tabs
> 
> **What it does**
> 
> Tabs for All, Info Portal, Community Portal, Job Portal, and Users; selection persisted in URL.
> 
> **User flow**
> 
> 1. User switches tab to scope results.
> 2. Results layout changes per tab.
> 
> **Rules**
> 
> - Tab and query both reflected in address bar.
> 
> **States**
> 
> - Five tab options with one active.
> 
> ---
> 
> ### All tab — combined preview
> 
> **What it does**
> 
> Shows up to three hits each for info articles, community threads, and job postings, plus up to six users; hides empty sections.
> 
> **User flow**
> 
> 1. User searches on All tab.
> 2. User sees sectional previews with links to full portal content.
> 3. Empty sections suppressed rather than showing empty blocks.
> 
> **Rules**
> 
> - Community section may include channels subsection.
> - Section limits lower than dedicated tabs.
> 
> **States**
> 
> - Partial previews per portal, all sections hidden when no matches.
> 
> ---
> 
> ### Info tab
> 
> **What it does**
> 
> Up to nine article results with title and description highlighting; pagination.
> 
> **User flow**
> 
> 1. User browses info results.
> 2. User opens article from result row.
> 
> **Rules**
> 
> - Empty and error states per section.
> - Pagination when more than one page.
> 
> **States**
> 
> - Loading, populated, empty, error with retry.
> 
> ---
> 
> ### Community tab
> 
> **What it does**
> 
> Searches channels (name and description) and threads/posts with content-type-aware display; pagination.
> 
> **User flow**
> 
> 1. User browses channel and thread results.
> 2. User opens channel or thread detail.
> 
> **Rules**
> 
> - Channels and threads may appear as separate subsections.
> - Localized slugs in links.
> 
> **States**
> 
> - Loading, populated, empty, error per subsection.
> 
> ---
> 
> ### Job tab
> 
> **What it does**
> 
> Job search with total hit count, shared job filters (location, employment type, etc.), responsive job card grid, and pagination.
> 
> **User flow**
> 
> 1. User applies job filters alongside keyword.
> 2. User browses job cards and opens posting detail.
> 
> **Rules**
> 
> - Echoes search term in result count display.
> - Same filter concepts as job offers catalog.
> 
> **States**
> 
> - Loading skeletons, populated grid, empty, error.
> 
> ---
> 
> ### Users tab
> 
> **What it does**
> 
> Up to nine user results with avatar, name, and city; filters for city plus radius or state (mutually exclusive location modes); pagination.
> 
> **User flow**
> 
> 1. User searches members by keyword and optional location filters.
> 2. User opens user profile from result.
> 
> **Rules**
> 
> - City+radius OR state filter modes exclusive.
> - Filters debounced ~500ms.
> 
> **States**
> 
> - Loading, populated, empty, error.
> 
> ---
> 
> ### Result navigation
> 
> **What it does**
> 
> Each result links to canonical destination in respective portal or profile.
> 
> **User flow**
> 
> 1. User clicks result → leaves search to content page.
> 
> **Rules**
> 
> - Search state preserved in URL if user navigates back.
> 
> **States**
> 
> - Outbound links per result type.
> 
> ---
> 
> ### Error handling
> 
> **What it does**
> 
> Per-section retry when portal search fails (staging may show temporary issue banners).
> 
> **User flow**
> 
> 1. User sees error message with retry in failed section.
> 2. Other sections may still load independently on All tab.
> 
> **Rules**
> 
> - Sections fail independently on combined view.
> 
> **States**
> 
> - Section-level error with retry button.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header global search entry
> - Direct URL with query parameters
> 
> **Outbound**
> 
> - Info articles, community channels/threads, job detail, user profiles
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full search across all tabs |
> | Signed-in member | Same search capabilities |
> 
> ---
> 
> ## Important Business Rules
> 
> - Search is cross-portal but each tab uses portal-appropriate result types and filters.
> - All tab suppresses empty sections for cleaner combined view.
> - User location filters on Users tab do not apply to other tabs.
> - Keyword and tab state shareable via URL.
> 
> ---
> 
> ## Related Features
> 
> - [Info Portal — Article](info-portal-article.md)
> - [Community Portal — Thread](community-portal-thread.md)
> - [Job Portal — Job Offers Listings](job-portal-offers.md)
> - [User Profile](user-profile.md)

---

## Page: Info Portal — Phase Landing
- URL: https://freiburger-bund.com/en/info/travel-preparation-1
- Type: product-spec
- Section: Info Portal
- Access: public
- Source: docs/product-knowledge/pages/info-portal-phase.md
- Updated: 2026-09-21

### Purpose
Help international healthcare professionals find curated articles and tools for a specific journey phase, so they can read practical guidance organized by topic and access quick planning tools.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> This specification applies to **all four journey phase landing pages** (Travel Preparation, Professional Recognition, Job Entry, and Career). The experience is identical across phases; only the content (topics, articles, breadcrumbs, and editorial blocks) changes per phase.
> 
> ## Features
> 
> ### Portal introduction
> 
> **What it does**
> 
> Introduces the Info Portal with a headline and description about practical information for entering the German healthcare system.
> 
> **User flow**
> 
> 1. User enters the Info Portal (automatically lands on the first journey phase).
> 2. User reads the portal headline and supporting text about targeted information for every phase.
> 
> **Rules**
> 
> - Intro content appears above the phase and topic navigation.
> 
> **States**
> 
> - Static introductory copy.
> 
> ---
> 
> ### Journey phase switcher
> 
> **What it does**
> 
> Lets users switch between the four journey phases while staying in the Info Portal.
> 
> **User flow**
> 
> 1. User sees phase tabs for Travel Preparation, Professional Recognition, Job Entry, and Career.
> 2. User selects a different phase.
> 3. Page updates to show that phase’s topics and articles.
> 
> **Rules**
> 
> - Four phases always available when configured.
> - Current phase is visually highlighted.
> - Phase labels combine short title and phase number.
> 
> **States**
> 
> - **Active phase:** current phase tab selected.
> - **Loading:** brief transition while new phase content loads.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows location as Home → Info Portal → current phase and allows backward navigation.
> 
> **User flow**
> 
> 1. User sees breadcrumb above main content.
> 2. User clicks Home or Info Portal to navigate up.
> 
> **Rules**
> 
> - Info Portal segment links to the portal entry (which redirects to the first phase).
> - Current phase shown as active segment.
> 
> **States**
> 
> - On narrow screens, middle segments may collapse behind an ellipsis menu.
> 
> ---
> 
> ### Topic tabs
> 
> **What it does**
> 
> Filters articles within the current phase by topic or shows all articles.
> 
> **User flow**
> 
> 1. User sees topic tabs (e.g. All, Travel Planning, German Language, Recognition Decision, German Visa).
> 2. User selects a tab.
> 3. Article list updates to match the selected topic.
> 
> **Rules**
> 
> - “All” shows articles across every topic in the phase.
> - Individual topic tabs filter to that topic only.
> - Active tab drives the section heading (e.g. “All Topics” or topic name).
> 
> **States**
> 
> - **Desktop/tablet:** horizontal tabs with scroll arrows when overflow.
> - **Mobile:** topic selection via dropdown.
> - **Empty topic:** “coming soon” message instead of article grid.
> 
> ---
> 
> ### Bookmarked articles filter
> 
> **What it does**
> 
> Switches the article list to show only articles the user has bookmarked within the current context.
> 
> **User flow**
> 
> 1. User clicks the **Bookmarked** control.
> 2. System shows bookmarked articles for the current phase/topic filter.
> 3. User can return to the full list by selecting a topic tab again.
> 
> **Rules**
> 
> - Guest users see the control but must sign in to save or view personal bookmarks.
> - Signed-in users see live bookmark state on cards.
> 
> **States**
> 
> - **Empty bookmarks:** no articles shown with appropriate empty messaging.
> - **Guest click on bookmark action:** sign-in prompt.
> 
> ---
> 
> ### Article list grid
> 
> **What it does**
> 
> Displays up to six article preview cards per page with cover image, topic label, title, and reading time.
> 
> **User flow**
> 
> 1. User browses article cards in a responsive grid.
> 2. User clicks an article title or image to open the full article.
> 3. User paginates when more than six articles exist.
> 
> **Rules**
> 
> - Six articles per page maximum in the grid.
> - Cards show topic category, title, estimated read time, and optional audio duration indicator.
> 
> **States**
> 
> - **Loading:** skeleton placeholders while articles load.
> - **Empty:** coming-soon message when no articles match filters.
> - **Paginated:** page numbers and next/previous controls (e.g. pages 1, 2, 3 … 10).
> 
> ---
> 
> ### Inline audio playback
> 
> **What it does**
> 
> Lets users play article audio directly from the article card without opening the full article.
> 
> **User flow**
> 
> 1. User sees a play control on articles that include audio.
> 2. User clicks play.
> 3. Inline audio player expands on the card.
> 
> **Rules**
> 
> - Only shown for articles with audio content.
> - Available to guests and signed-in users.
> 
> **States**
> 
> - **Collapsed:** play button only.
> - **Expanded:** inline player active.
> 
> ---
> 
> ### Bookmark article from list
> 
> **What it does**
> 
> Lets signed-in users save or remove an article from their bookmarks directly on the list card.
> 
> **User flow**
> 
> 1. User clicks the bookmark control on an article card.
> 2. If signed in, bookmark toggles and confirmation feedback appears.
> 3. If guest, sign-in dialog opens.
> 
> **Rules**
> 
> - Bookmark state persists per user account.
> - Removing a bookmark in bookmark-filter view removes the card from the list.
> 
> **States**
> 
> - **Unbookmarked:** outline bookmark icon.
> - **Bookmarked:** filled bookmark icon.
> - **Guest:** sign-in required.
> 
> ---
> 
> ### Article pagination
> 
> **What it does**
> 
> Lets users move through multiple pages of articles within the selected topic.
> 
> **User flow**
> 
> 1. User clicks a page number or next/previous control.
> 2. New set of up to six articles loads.
> 3. Current page is reflected in the page address for sharing and return visits.
> 
> **Rules**
> 
> - Page number is preserved in the URL.
> - First page disables previous control; last page disables next.
> 
> **States**
> 
> - **First page:** previous disabled.
> - **Last page:** next disabled.
> 
> ---
> 
> ### Quick tools section
> 
> **What it does**
> 
> Surfaces interactive planning tools related to the journey phase.
> 
> **User flow**
> 
> 1. User scrolls to the Quick Tools section below articles.
> 2. User reads tool names and descriptions.
> 3. User opens a tool: Cost Calculator, CV Generator, Federal State Compass, Visa Navigator, or Motivation Letter Generator.
> 
> **Rules**
> 
> - Tools open in their dedicated tool experiences.
> - Tool set may vary by phase content configuration.
> 
> **States**
> 
> - Tools always listed when section is present on staging.
> 
> ---
> 
> ### Mobile app promotion
> 
> **What it does**
> 
> Promotes the mobile app with store download links below portal content.
> 
> **User flow**
> 
> 1. User reads app promotion copy.
> 2. User opens Google Play or App Store.
> 
> **Rules**
> 
> - External store links.
> 
> **States**
> 
> - Visible when included in page content.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Provides standard site navigation, language switching, account access, footer links, newsletter, and cookie consent.
> 
> **User flow**
> 
> 1. User navigates to other portals or account areas from the header.
> 2. User uses footer for support and legal links.
> 
> **Rules**
> 
> - Same as homepage global chrome.
> 
> **States**
> 
> - Guest vs signed-in header differences apply.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Info Portal menu link (redirects from portal root to first phase)
> - Homepage portal card or Explore link
> - Journey phase links from homepage or dashboard
> - Direct link to a specific phase
> - Search results linking to info content
> 
> **Outbound**
> 
> - Full article pages (from card click)
> - Bookmarked articles view
> - Quick tools (cost calculator, visa navigator, CV generator, etc.)
> - Other journey phases (phase switcher)
> - Other portals via header/footer
> - Mobile app stores
> - Sign-in (when bookmarking as guest)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Can browse phases, topics, articles, audio, and pagination; bookmark actions prompt sign-in |
> | Signed-in member | Bookmark save/remove, bookmark filter with personal list, synced bookmark icons on cards |
> 
> ---
> 
> ## Important Business Rules
> 
> - Entering the Info Portal root always redirects to the first configured journey phase (currently Travel Preparation).
> - Content is organized by journey phase first, then by topic within the phase.
> - Articles are the primary content unit; tools are secondary shortcuts on the same page.
> - Bookmarking is per-user and requires authentication.
> - Empty topics or phases show a coming-soon state rather than an error.
> - Pagination preserves shareable page state.
> 
> ---
> 
> ## Related Features
> 
> - Info article detail page
> - Bookmarked articles view
> - Info Portal remaining phases (2–4)
> - Personal journey and dashboard tools
> - Global bookmarks (info section)
> - FAQ (info category)
> - Homepage portal discovery

---

## Page: Info Portal — Topic Listing
- URL: https://freiburger-bund.com/en/info/travel-preparation-1/german-language
- Type: product-spec
- Section: Info Portal
- Access: public
- Source: docs/product-knowledge/pages/info-portal-topic.md
- Updated: 2026-09-21

### Purpose
Let users browse articles filtered to a single topic within a journey phase, switch between topics and phases, and open full articles or bookmarked subsets without leaving the info portal structure.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Topic validation
> 
> **What it does**
> 
> Ensures the topic in the address corresponds to a valid topic for the selected phase.
> 
> **User flow**
> 
> 1. User opens a topic listing link.
> 2. If the topic does not exist for that phase, the user sees a not-found page.
> 
> **Rules**
> 
> - Invalid topic slug for the phase returns not-found.
> - Special characters in topic addresses are decoded safely.
> 
> **States**
> 
> - **Valid topic:** listing loads.
> - **Invalid topic:** not-found page.
> 
> ---
> 
> ### Shared phase shell
> 
> **What it does**
> 
> Provides the same portal chrome as the phase landing page: introduction, breadcrumbs, phase switcher, topic tabs, CMS editorial blocks, and quick tools.
> 
> **User flow**
> 
> 1. User navigates within the info portal using phase tabs, topic tabs, and breadcrumbs.
> 
> **Rules**
> 
> - Same layout and controls as phase landing documented in the phase landing spec.
> - CMS blocks may appear above, between, and below the article list.
> 
> **States**
> 
> - Consistent with phase landing page.
> 
> ---
> 
> ### Topic-filtered article list
> 
> **What it does**
> 
> Shows only articles belonging to the selected topic (not all topics in the phase).
> 
> **User flow**
> 
> 1. User lands on a topic listing.
> 2. User sees up to six article cards per page for that topic only.
> 3. Section heading shows the topic name.
> 
> **Rules**
> 
> - Six articles maximum per page within the topic.
> - Article count indicator (on tablet and larger) reflects topic total, not whole-phase total.
> 
> **States**
> 
> - **Populated:** filtered grid of cards.
> - **Empty:** coming-soon message with descriptive copy.
> 
> ---
> 
> ### Topic tab navigation
> 
> **What it does**
> 
> Lets users switch topics or return to the all-topics view without leaving the phase.
> 
> **User flow**
> 
> 1. User clicks another topic tab → navigates to that topic’s listing.
> 2. User clicks **All** → navigates to phase landing (all topics combined).
> 3. On mobile, user selects topic from dropdown instead of horizontal tabs.
> 
> **Rules**
> 
> - Active topic tab is highlighted.
> - Desktop uses scrollable pill tabs with arrow controls when tabs overflow.
> 
> **States**
> 
> - **Active tab:** matches current topic or All on phase landing.
> 
> ---
> 
> ### Bookmarked filter entry
> 
> **What it does**
> 
> Opens the bookmarked-articles view scoped to the current phase and topic.
> 
> **User flow**
> 
> 1. User clicks **Bookmarked** pill control.
> 2. User sees only saved articles for this phase and topic context.
> 
> **Rules**
> 
> - Navigates to the bookmarked view for the same phase and topic.
> 
> **States**
> 
> - Toggle visually distinct when on bookmarked view (documented in bookmarked spec).
> 
> ---
> 
> ### Article preview cards
> 
> **What it does**
> 
> Displays cover image, topic label, title, read time, optional listen duration, inline audio control, and bookmark button for each article.
> 
> **User flow**
> 
> 1. User scans cards in a responsive one- or two-column grid.
> 2. User clicks image or title to open the full article.
> 3. User plays audio inline when available.
> 4. User toggles bookmark when signed in.
> 
> **Rules**
> 
> - Cards link to the full article using phase, topic, and article segments when data is available.
> - Bookmark state for signed-in users is synchronized with the user’s saved list, not only backend flags on the card.
> 
> **States**
> 
> - **Guest bookmark:** sign-in dialog.
> - **Signed-in:** toggle with confirmation feedback.
> 
> ---
> 
> ### Inline audio on list cards
> 
> **What it does**
> 
> Lets users preview article audio from the listing without opening the full article.
> 
> **User flow**
> 
> 1. User clicks play on a card with audio.
> 2. Floating mini player opens on the card.
> 
> **Rules**
> 
> - Shown only when article has audio content.
> - Available to guests and signed-in users.
> 
> **States**
> 
> - Collapsed (play button) or expanded (player active).
> 
> ---
> 
> ### Pagination
> 
> **What it does**
> 
> Pages through topic articles six at a time with previous, next, and numbered controls.
> 
> **User flow**
> 
> 1. User clicks a page number or arrow.
> 2. Next set of cards loads; page number is reflected in the address for sharing.
> 3. Controls dim during loading transition.
> 
> **Rules**
> 
> - Previous disabled on first page; next disabled on last page.
> - Ellipsis shown for long page ranges.
> - No automatic scroll jump on page change.
> 
> **States**
> 
> - **Loading:** pagination controls dimmed/disabled briefly.
> 
> ---
> 
> ### Breadcrumb trail
> 
> **What it does**
> 
> Shows Home → Info Portal → phase → topic with clickable earlier segments.
> 
> **User flow**
> 
> 1. User clicks Home, Info Portal, or phase to navigate up the hierarchy.
> 
> **Rules**
> 
> - Deepest breadcrumb is the current topic (non-clickable).
> - Collapses to ellipsis menu on narrow screens.
> 
> **States**
> 
> - Standard or collapsed breadcrumb.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard navigation, language, account access, newsletter, and legal links.
> 
> **User flow**
> 
> 1. User navigates to other portals or signs in from header.
> 
> **Rules**
> 
> - Same global chrome as other info portal pages.
> 
> **States**
> 
> - Guest vs signed-in header differences.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Phase landing topic tab selection
> - Phase landing article card (when topic context implied)
> - Search or external links to topic URLs
> - Bookmarked view returning to normal list
> - Article breadcrumb topic segment
> 
> **Outbound**
> 
> - Phase landing (All tab)
> - Other topic listings in same phase
> - Bookmarked articles view for same phase/topic
> - Full article pages
> - Sign-in (guest bookmark)
> - Quick tools and other portals via header/footer
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full browse, audio, pagination; bookmark prompts sign-in |
> | Signed-in member | Bookmark save/remove with live icon state and toast feedback |
> 
> ---
> 
> ## Important Business Rules
> 
> - Topic listing is a filtered view of the same article browser used on phase landing.
> - Pagination and counts are scoped to the active topic only.
> - Invalid topic for a phase is a hard not-found, not an empty list.
> - Bookmark filter is a separate view, not an inline filter on this page.
> - Topic tab **All** always returns to the phase landing, not an empty topic.
> 
> ---
> 
> ## Related Features
> 
> - Info Portal phase landing (all topics view)
> - Info Portal article detail
> - Info Portal bookmarked articles view
> - Info Portal tag-filtered articles
> - Global info bookmarks area
> - Login

---

## Page: Info Portal — Article Detail
- URL: https://freiburger-bund.com/en/info/travel-preparation-1/german-language/learning-german
- Type: product-spec
- Section: Info Portal
- Access: public
- Source: docs/product-knowledge/pages/info-portal-article.md
- Updated: 2026-09-21

### Purpose
Present a full info article with readable body content, audio, sharing, accessibility controls, community discussion entry, feedback, and sequential navigation—so users can deeply consume guidance and act on it.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Article loading and validation
> 
> **What it does**
> 
> Loads a published article by its slug and shows not-found when the article does not exist.
> 
> **User flow**
> 
> 1. User opens an article via canonical path (phase, topic, and article segments).
> 2. Valid article renders; unknown slug shows not-found page.
> 
> **Rules**
> 
> - Article is resolved primarily by article slug.
> - Phase and topic segments in the address are **not strictly validated** against the article; a mismatched phase or topic in the URL may still display the article.
> - Breadcrumbs may be adjusted from article metadata when URL segments do not match.
> - Unpublished draft content may appear in preview mode when editors preview drafts.
> 
> **States**
> 
> - **Loading:** page assembling content.
> - **Found:** full article layout.
> - **Not found:** error page.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Info Portal → phase → topic → article title with clickable parent segments.
> 
> **User flow**
> 
> 1. User navigates up to phase, topic, or info portal home from breadcrumbs.
> 
> **Rules**
> 
> - Info Portal breadcrumb link targets the first journey phase entry.
> - Topic segment inserted from article data when missing from URL.
> 
> **States**
> 
> - Full trail on desktop; may collapse on mobile.
> 
> ---
> 
> ### Header bookmark control
> 
> **What it does**
> 
> Lets signed-in users save or remove the article from bookmarks from the top bar beside breadcrumbs.
> 
> **User flow**
> 
> 1. Signed-in user toggles bookmark.
> 2. Confirmation feedback appears.
> 3. Guest attempting bookmark is redirected to login.
> 
> **Rules**
> 
> - Uses article’s category context for bookmark state.
> 
> **States**
> 
> - Saved vs unsaved icon states.
> - Guest → login redirect (distinct from list-card sign-in dialog).
> 
> ---
> 
> ### Article header metadata
> 
> **What it does**
> 
> Displays title, subtitle, author name, last updated date and time, and listen duration when audio exists.
> 
> **User flow**
> 
> 1. User reads headline and supporting description below breadcrumbs.
> 2. User sees author attribution and freshness timestamp.
> 
> **Rules**
> 
> - Listen duration shown with headphones icon only when audio is available.
> 
> **States**
> 
> - Optional fields hidden when data absent.
> 
> ---
> 
> ### Hero cover image
> 
> **What it does**
> 
> Shows full-width cover image below the metadata row.
> 
> **User flow**
> 
> 1. User views visual header for the article.
> 
> **Rules**
> 
> - Displayed when cover image exists in article data.
> 
> **States**
> 
> - Present or omitted.
> 
> ---
> 
> ### Full audio player
> 
> **What it does**
> 
> Provides listen experience with play/pause, skip forward and back, speed control, progress scrubbing, and playlist advance for multi-track audio.
> 
> **User flow**
> 
> 1. User clicks **Play audio**.
> 2. Floating player opens with waveform and controls.
> 3. User adjusts speed through preset steps (1×, 1.25×, 1.5×, 2×).
> 4. User skips ±10 seconds or scrubs progress.
> 5. User closes player when finished.
> 
> **Rules**
> 
> - Multi-track playlists auto-advance to next track.
> - Player labeled as AI-generated audio when applicable.
> - Available to guests and signed-in users.
> 
> **States**
> 
> - Collapsed (play button) or expanded (full player).
> - Arabic layout adjusts player positioning for right-to-left reading.
> 
> ---
> 
> ### Font size controls
> 
> **What it does**
> 
> Lets users increase, reset, or decrease article body text size for readability.
> 
> **User flow**
> 
> 1. User clicks A+ to enlarge (up to five steps above default).
> 2. User clicks A to reset to default.
> 3. User clicks A− to reduce (up to two steps below default).
> 
> **Rules**
> 
> - Controls appear in sticky sidebar on desktop and top row on mobile.
> - Reset disabled at default size.
> 
> **States**
> 
> - Five enlargement steps and two reduction steps from default.
> 
> ---
> 
> ### Social sharing
> 
> **What it does**
> 
> Offers share links for Telegram, Facebook, LinkedIn, Twitter/X, email, and copy-link.
> 
> **User flow**
> 
> 1. User clicks a share option from sticky sidebar.
> 2. User shares through provider or copies link to clipboard.
> 3. Copy success shows confirmation feedback.
> 
> **Rules**
> 
> - Sidebar sticky on desktop; adapted layout on mobile.
> - RTL adjusts sidebar border placement for Arabic.
> 
> **States**
> 
> - Copy link success toast.
> 
> ---
> 
> ### Rich article body
> 
> **What it does**
> 
> Renders formatted article content including headings, paragraphs, glossaries with tooltips, images, embedded video, comparison tables, and external links.
> 
> **User flow**
> 
> 1. User scrolls and reads article sections.
> 2. User interacts with glossary terms for definitions.
> 3. User follows in-article links to related articles or external resources.
> 
> **Rules**
> 
> - Internal links may point to other info articles or tools.
> - Media embeds play within article flow.
> 
> **States**
> 
> - Long-form scrollable content.
> 
> ---
> 
> ### AI explain on text selection
> 
> **What it does**
> 
> Lets users highlight passage text and request an AI-generated explanation.
> 
> **User flow**
> 
> 1. User selects text (highlight on desktop; long-press/drag on mobile).
> 2. User chooses **Explain** from selection tooltip.
> 3. Streaming explanation appears with loading indicator.
> 
> **Rules**
> 
> - Selection limited to approximately eight words or 120 characters.
> - Mobile selection menu may also offer Copy and Select All.
> - Rate-limit and service-unavailable errors shown inline.
> - Available without sign-in.
> 
> **States**
> 
> - **Loading:** explanation streaming.
> - **Error:** inline rate-limit or unavailable message.
> 
> ---
> 
> ### Reading progress persistence
> 
> **What it does**
> 
> Saves scroll position locally so users can resume reading when returning.
> 
> **User flow**
> 
> 1. User partway through article leaves the page.
> 2. User returns via continue-reading entry elsewhere and resumes near prior scroll position.
> 
> **Rules**
> 
> - Stored locally in the browser, not tied to account.
> 
> **States**
> 
> - Resume available when prior visit recorded.
> 
> ---
> 
> ### Article tags
> 
> **What it does**
> 
> Shows clickable tag chips linking to tag-filtered article listings.
> 
> **User flow**
> 
> 1. User clicks a tag chip.
> 2. User opens tag page with optional phase filter applied.
> 
> **Rules**
> 
> - Tags without slugs render as non-clickable labels only.
> - Phase filter appended when phase is known from article context.
> 
> **States**
> 
> - Clickable vs label-only tags.
> 
> ---
> 
> ### Ask the community
> 
> **What it does**
> 
> Lets users start a community discussion related to the article when linked channels exist.
> 
> **User flow**
> 
> 1. User sees community section when article has linked channels.
> 2. User selects a channel from picker (required unless default channel exists).
> 3. User clicks **Start discussion**.
> 4. Community overlay opens on the same page.
> 
> **Rules**
> 
> - Button disabled until channel selected when no default exists.
> - Overlay triggered via on-page parameter without full navigation away.
> 
> **States**
> 
> - **Hidden:** no linked channels.
> - **Disabled:** no channel selected.
> - **Active overlay:** discussion composer open.
> 
> ---
> 
> ### Previous and next article navigation
> 
> **What it does**
> 
> Links to sequentially adjacent articles in the same series.
> 
> **User flow**
> 
> 1. User clicks **Previous** or **Next** (mobile text buttons).
> 2. On desktop, user clicks full preview cards for neighbors.
> 
> **Rules**
> 
> - Hidden when no previous or next article exists.
> - Neighbor links use canonical phase/topic/article paths when metadata available.
> 
> **States**
> 
> - One or both neighbors visible.
> 
> ---
> 
> ### Article feedback form
> 
> **What it does**
> 
> Invites corrections and suggestions through a modal feedback form.
> 
> **User flow**
> 
> 1. User clicks **Share Your Feedback**.
> 2. User completes modal fields: title, name, email (optional if submitting anonymously), correction notes (required), source link, privacy acceptance.
> 3. User submits; success confirmation shown.
> 
> **Rules**
> 
> - Correction notes required.
> - Privacy checkbox required.
> - Submission scoped to the current article.
> - Available to guests and signed-in users.
> 
> **States**
> 
> - Modal closed or open.
> - Success toast after send.
> 
> ---
> 
> ### Editorial content blocks
> 
> **What it does**
> 
> Injects optional promotional or supplementary CMS content in multiple positions around the article layout.
> 
> **User flow**
> 
> 1. User may see related course promotions, quick tools, or app download blocks below or beside the article.
> 
> **Rules**
> 
> - Up to seven injectable content positions on canonical article path.
> 
> **States**
> 
> - Optional blocks per article configuration.
> 
> ---
> 
> ### Visit tracking
> 
> **What it does**
> 
> Records that the article was viewed when the page loads.
> 
> **User flow**
> 
> 1. User opens article; view counted server-side for analytics.
> 
> **Rules**
> 
> - Not visible to user; affects product analytics only.
> 
> **States**
> 
> - Automatic on load.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site chrome around article reading experience.
> 
> **User flow**
> 
> 1. User navigates to login, other portals, or support from header.
> 
> **Rules**
> 
> - Same as other info pages.
> 
> **States**
> 
> - Guest vs signed-in.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Article cards on phase landing, topic listing, tag page, or bookmarked view
> - Previous/next article links
> - Search and external shares (may use canonical or short article URL)
> - Dashboard recommended reading cards
> - In-article cross-links
> 
> **Outbound**
> 
> - Parent topic listing and phase landing (breadcrumbs)
> - Tag-filtered listings
> - Previous/next articles
> - Community discussion overlay
> - Linked tools and course promotions in body/CMS blocks
> - Login (guest bookmark)
> - Social share destinations (external)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read, audio, sharing, AI explain, feedback; bookmark redirects to login |
> | Signed-in member | Bookmark toggle in header; same reading features otherwise |
> 
> ---
> 
> ## Important Business Rules
> 
> - Article slug is authoritative; URL phase/topic mismatch does not block reading.
> - Audio, AI explain, and feedback are available without authentication.
> - Bookmarking requires an account.
> - Community discussion requires selecting a linked channel when multiple exist.
> - Sequential prev/next navigation respects editorial ordering within the article series.
> - Search engines receive structured article metadata for discoverability.
> 
> ---
> 
> ## Related Features
> 
> - Info Portal topic listing and phase landing
> - Direct article access (short URL variant)
> - Tag-filtered articles
> - Bookmarked articles view
> - Community channels and new discussion
> - Login
> - Quick tools promoted in article footer blocks

---

## Page: Info Portal — Direct Article Access
- URL: https://freiburger-bund.com/en/info/article/learning-german-115
- Type: product-spec
- Section: Info Portal
- Access: public
- Source: docs/product-knowledge/pages/info-portal-article-direct.md
- Updated: 2026-09-21

### Purpose
Let users open an info article through a short shareable link without phase or topic segments in the address, while delivering the same reading experience as the canonical article page.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Short URL entry
> 
> **What it does**
> 
> Provides a compact article address using only the article slug under the info portal.
> 
> **User flow**
> 
> 1. User follows a shared link or search result to the short article path.
> 2. Full article page loads without phase or topic in the URL.
> 
> **Rules**
> 
> - Intended for sharing, bookmarks, and deep links when canonical path is unknown.
> - Unknown article slug returns not-found page.
> 
> **States**
> 
> - **Valid slug:** article renders.
> - **Invalid slug:** not-found.
> 
> ---
> 
> ### Article resolution
> 
> **What it does**
> 
> Finds the published article by slug using search index first, then fallback lookup.
> 
> **User flow**
> 
> 1. User lands on short URL.
> 2. Matching published article displays.
> 
> **Rules**
> 
> - Same published content as canonical article path.
> - Draft preview behavior matches canonical path when editors preview unpublished versions.
> 
> **States**
> 
> - Found vs not-found.
> 
> ---
> 
> ### Reconstructed breadcrumbs
> 
> **What it does**
> 
> Builds breadcrumb trail from article metadata rather than URL segments.
> 
> **User flow**
> 
> 1. User sees Home → Info Portal → phase → topic → article title.
> 2. Phase and topic segments derived from article breadcrumb data or topic association fields.
> 
> **Rules**
> 
> - Info Portal link goes to first journey phase entry.
> - No “wrong segment” mismatch because URL lacks phase/topic parts.
> 
> **States**
> 
> - Complete trail when metadata available; partial trail if data sparse.
> 
> ---
> 
> ### Canonical link behavior from listings
> 
> **What it does**
> 
> Article cards use canonical three-segment links when phase and topic are known; otherwise fall back to short article path.
> 
> **User flow**
> 
> 1. User opens article from list with full metadata → canonical URL.
> 2. User opens from context without phase/topic → short URL.
> 
> **Rules**
> 
> - Both paths render the same article experience.
> 
> **States**
> 
> - Two valid entry URL shapes for same content.
> 
> ---
> 
> ### Full article reading experience
> 
> **What it does**
> 
> Delivers identical capabilities to the canonical article detail page.
> 
> **User flow**
> 
> 1. User reads title, body, audio, tags, prev/next, feedback, AI explain, sharing, font controls, and community section as on canonical page.
> 
> **Rules**
> 
> - Includes: header bookmark, audio player, font size, social share, rich body, AI explain, tags, ask community, prev/next, feedback form, reading progress, visit tracking, structured search metadata.
> 
> **States**
> 
> - Same as canonical article detail spec.
> 
> ---
> 
> ### Editorial content blocks
> 
> **What it does**
> 
> Injects optional CMS promotional blocks around the article.
> 
> **User flow**
> 
> 1. User may see quick tools, course promos, or app blocks below the article.
> 
> **Rules**
> 
> - Slightly fewer injectable positions than canonical path (functionally minor difference).
> 
> **States**
> 
> - Optional per article configuration.
> 
> ---
> 
> ### Graceful partial failure
> 
> **What it does**
> 
> Still renders the article when optional related data fails to load.
> 
> **User flow**
> 
> 1. If related-article neighbors fail to load, page shows without prev/next cards.
> 2. If CMS blocks unavailable, article body still displays.
> 
> **Rules**
> 
> - Core article is never blocked by secondary fetch failures.
> 
> **States**
> 
> - Full page vs neighbors-empty variant.
> 
> ---
> 
> ### Tag links with phase context
> 
> **What it does**
> 
> Tag chips link to tag-filtered listings with phase filter when phase ID is known from the article.
> 
> **User flow**
> 
> 1. User clicks tag on short-URL article.
> 2. Tag page opens scoped to relevant journey phase when possible.
> 
> **Rules**
> 
> - Same tag behavior as canonical article page.
> 
> **States**
> 
> - Phase-filtered or global tag view.
> 
> ---
> 
> ### Bookmark control
> 
> **What it does**
> 
> Uses article’s actual category context for bookmark lookup regardless of entry URL shape.
> 
> **User flow**
> 
> 1. Signed-in user toggles bookmark from header.
> 2. Guest redirected to login on bookmark attempt.
> 
> **Rules**
> 
> - Bookmark state independent of URL format used to arrive.
> 
> **States**
> 
> - Same as canonical article page.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site chrome.
> 
> **User flow**
> 
> 1. User navigates elsewhere from header or footer.
> 
> **Rules**
> 
> - Same global chrome.
> 
> **States**
> 
> - Guest vs signed-in header.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Shared article links without phase/topic
> - Article cards when phase/topic metadata missing
> - Search engines and external campaigns
> - Previous/next links that reconstruct short URLs
> 
> **Outbound**
> 
> - Breadcrumb destinations (phase, topic, info home)
> - Tag listings
> - Previous/next articles (canonical paths when metadata allows)
> - Community overlay
> - Login (guest bookmark)
> - Same outbound set as canonical article page
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read and tools except bookmark (login redirect) |
> | Signed-in member | Full experience including bookmark |
> 
> Identical role behavior to canonical article detail.
> 
> ---
> 
> ## Important Business Rules
> 
> - Short URL and canonical URL are two entry points to the same article product experience.
> - Breadcrumbs and prev/next links prefer canonical paths when phase/topic metadata exists.
> - No URL segment validation issue exists because phase/topic are not in the short path.
> - Feedback submissions always associate with the correct article ID regardless of entry URL.
> 
> ---
> 
> ## Related Features
> 
> - Info Portal article detail (canonical path)
> - Info Portal topic listing and phase landing
> - Tag-filtered articles
> - Bookmarked articles view
> - Community discussions
> - Login

---

## Page: Info Portal — Tag-Filtered Articles
- URL: https://freiburger-bund.com/en/info/tag/german-language
- Type: product-spec
- Section: Info Portal
- Access: public
- Source: docs/product-knowledge/pages/info-portal-tag.md
- Updated: 2026-09-21

### Purpose
Let users discover all info articles labeled with a specific tag, optionally scoped to one journey phase, and browse them with the same card experience as topic listings.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Tag validation
> 
> **What it does**
> 
> Loads articles for a known tag slug or shows not-found when the tag does not exist.
> 
> **User flow**
> 
> 1. User opens tag page from an article tag chip or direct link.
> 2. Valid tag shows listing; unknown tag shows not-found.
> 
> **Rules**
> 
> - Tag slug decoded safely from URL.
> - Tag must have a resolvable name/slug in the system.
> 
> **States**
> 
> - **Valid:** listing renders.
> - **Invalid:** not-found page.
> 
> ---
> 
> ### Tag page heading
> 
> **What it does**
> 
> Displays the tag name prominently as the page title.
> 
> **User flow**
> 
> 1. User confirms which tag filter is active from the large heading.
> 
> **Rules**
> 
> - Heading text matches tag display name.
> 
> **States**
> 
> - Static heading per tag.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Info Portal → tag context from backend breadcrumb data.
> 
> **User flow**
> 
> 1. User navigates up via clickable breadcrumb segments.
> 
> **Rules**
> 
> - Info Portal link includes phase context in the link when phase filter is active in the address.
> 
> **States**
> 
> - Standard or collapsed breadcrumb on narrow screens.
> 
> ---
> 
> ### Optional phase filter
> 
> **What it does**
> 
> Limits tag results to one journey phase when phase identifier is present in the query, or shows tag articles across all phases when absent.
> 
> **User flow**
> 
> 1. User arrives from article tag chip → phase filter usually pre-applied.
> 2. User opens tag URL without phase filter → sees cross-phase tag results.
> 
> **Rules**
> 
> - Phase filter passed as query parameter, not as path segment.
> - Pagination total reflects filtered set.
> 
> **States**
> 
> - **Phase-scoped:** subset of tag articles in one phase.
> - **Global:** all phases included.
> 
> ---
> 
> ### Article card grid
> 
> **What it does**
> 
> Lists matching articles using the same card design as topic listings.
> 
> **User flow**
> 
> 1. User browses up to six cards per page with image, topic label, title, read time, audio, and bookmark.
> 2. User opens article from card.
> 3. User plays inline audio or toggles bookmark.
> 
> **Rules**
> 
> - Cards link to canonical article path when phase/topic data exists on card; otherwise short article path.
> - Six articles per page.
> 
> **States**
> 
> - **Populated grid** or **empty state**.
> 
> ---
> 
> ### Empty results state
> 
> **What it does**
> 
> Shows a dedicated no-results message when no articles match the tag (and phase filter if applied).
> 
> **User flow**
> 
> 1. User sees empty message distinct from topic “coming soon” copy.
> 
> **Rules**
> 
> - Different messaging from phase/topic empty states.
> 
> **States**
> 
> - No articles for current filter combination.
> 
> ---
> 
> ### Pagination
> 
> **What it does**
> 
> Pages through tag results with previous, next, numbered pages, and ellipsis.
> 
> **User flow**
> 
> 1. User changes page; address updates with page parameter.
> 2. Controls dim during load.
> 
> **Rules**
> 
> - Page parameter preserved in URL.
> - RTL-aware arrow direction for Arabic.
> 
> **States**
> 
> - Loading dimmed controls between pages.
> 
> ---
> 
> ### Bookmark on cards
> 
> **What it does**
> 
> Lets signed-in users save or remove articles; guests prompted to sign in.
> 
> **User flow**
> 
> 1. Guest clicks bookmark → sign-in dialog.
> 2. Signed-in user toggles with toast and corrected saved state.
> 
> **Rules**
> 
> - Bookmark icons reflect user’s actual saved list.
> 
> **States**
> 
> - Guest vs signed-in as on other info lists.
> 
> ---
> 
> ### No phase or topic switcher
> 
> **What it does**
> 
> Omits journey phase tabs and topic tabs present on phase/topic pages—tag context only.
> 
> **User flow**
> 
> 1. User focuses on tag results without switching phase/topic tabs on this page.
> 
> **Rules**
> 
> - Phase filtering only via query parameter from inbound links, not via on-page tabs.
> 
> **States**
> 
> - Simpler chrome than phase landing.
> 
> ---
> 
> ### Optional CMS content block
> 
> **What it does**
> 
> Shows optional editorial content below the article grid when configured.
> 
> **User flow**
> 
> 1. User may see promotional blocks after the listing.
> 
> **Rules**
> 
> - Bottom slot only on tag pages.
> 
> **States**
> 
> - Present or absent per CMS configuration.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site navigation and footer.
> 
> **User flow**
> 
> 1. User navigates to other areas from header.
> 
> **Rules**
> 
> - Same global chrome.
> 
> **States**
> 
> - Guest vs signed-in.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Article tag chips (usually with phase filter)
> - Direct tag URL
> - **Unknown / requires product clarification** for main nav entry points
> 
> **Outbound**
> 
> - Full article pages (canonical or short URL)
> - Info portal phase entry (breadcrumb)
> - Sign-in (guest bookmark)
> - Home (breadcrumb)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Browse, paginate, audio; bookmark requires sign-in |
> | Signed-in member | Full bookmark toggle on cards |
> 
> ---
> 
> ## Important Business Rules
> 
> - Tag pages aggregate across articles regardless of which topic listed them.
> - Phase filter is optional and query-based, not a third path segment.
> - Empty tag results use “no search results” style messaging, not “coming soon.”
> - Pagination totals come from backend count for tag (+ phase when filtered).
> - No topic tabs on this page type.
> 
> ---
> 
> ## Related Features
> 
> - Info Portal article detail (tag chips outbound)
> - Info Portal topic listing and phase landing
> - Info Portal bookmarked articles view
> - Global info bookmarks
> - Login

---

## Page: Info Portal — Bookmarked Articles
- URL: https://freiburger-bund.com/en/info/travel-preparation-1/german-language/bookmarked
- Type: product-spec
- Section: Info Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/info-portal-bookmarked.md
- Updated: 2026-09-21

### Purpose
Let signed-in users view and manage info articles they have saved, filtered by the current journey phase and topic context, within the familiar info portal browsing layout.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Bookmark-scoped listing
> 
> **What it does**
> 
> Shows only articles the user has bookmarked, filtered by active phase and topic (or all topics in the phase when “All” context applies).
> 
> **User flow**
> 
> 1. User clicks **Bookmarked** from phase landing or topic listing.
> 2. User sees saved articles only in the current phase/topic scope.
> 
> **Rules**
> 
> - Requires signed-in session for meaningful results; guests see empty list or sign-in prompts on actions.
> - All displayed cards represent bookmarked items by definition.
> 
> **States**
> 
> - **Populated:** filtered bookmark grid.
> - **Empty:** coming-soon style message when no saves in scope.
> 
> ---
> 
> ### Phase and topic validation
> 
> **What it does**
> 
> Applies the same phase and topic validity rules as topic listing pages.
> 
> **User flow**
> 
> 1. Invalid phase or topic in address → not-found page.
> 
> **Rules**
> 
> - Same 404 behavior as standard topic pages.
> 
> **States**
> 
> - Valid vs invalid scope.
> 
> ---
> 
> ### Bookmark filter toggle (active state)
> 
> **What it does**
> 
> Highlights the **Bookmarked** control and lets user return to the normal unfiltered list.
> 
> **User flow**
> 
> 1. User sees **Bookmarked** pill in active/highlighted state.
> 2. User toggles off or navigates via topic tab to return to standard listing at the same phase/topic.
> 
> **Rules**
> 
> - Returning to normal list navigates to standard topic or phase landing URL without bookmark segment.
> 
> **States**
> 
> - **Active bookmark view** vs standard list.
> 
> ---
> 
> ### Shared phase shell
> 
> **What it does**
> 
> Retains phase switcher, topic tabs, breadcrumbs, CMS blocks, and quick tools from topic/phase pages.
> 
> **User flow**
> 
> 1. User switches topic tab while in bookmark mode → navigates to bookmarked view for that topic.
> 2. User switches phase tab → navigates toward bookmark view for new phase.
> 
> **Rules**
> 
> - Topic tab changes append bookmark segment to the path.
> - **Known product quirk:** switching phase from bookmark view may navigate to a bookmark URL missing the topic segment, which can fail with not-found; users should select a topic tab after phase change.
> 
> **States**
> 
> - Same chrome as topic listing with bookmark filter active.
> 
> ---
> 
> ### Client-side bookmark filtering and pagination
> 
> **What it does**
> 
> Loads the user’s full bookmark collection, filters by phase ID and topic slug client-side, then paginates six per page.
> 
> **User flow**
> 
> 1. User browses pages of bookmarked results within scope.
> 2. Page parameter preserved in address.
> 
> **Rules**
> 
> - Six cards per page after filtering.
> - Total page count reflects filtered bookmark count, not all portal articles.
> 
> **States**
> 
> - Pagination controls match filtered totals.
> 
> ---
> 
> ### Remove bookmark inline
> 
> **What it does**
> 
> Lets user un-bookmark directly from the list; card disappears immediately.
> 
> **User flow**
> 
> 1. Signed-in user toggles bookmark off on a card.
> 2. Card removed from list without full page reload.
> 3. If current page becomes empty, user moved to previous valid page automatically.
> 
> **Rules**
> 
> - Immediate UI removal on successful un-bookmark.
> - Auto page adjustment prevents blank page stuck state.
> 
> **States**
> 
> - Card list shrinks dynamically on remove.
> 
> ---
> 
> ### Article cards in bookmark view
> 
> **What it does**
> 
> Uses same card UI as standard listings: image, topic, title, read time, audio, bookmark toggle.
> 
> **User flow**
> 
> 1. User opens article from card.
> 2. User plays inline audio.
> 3. User re-bookmarks if previously removed in same session.
> 
> **Rules**
> 
> - Cards default to showing bookmarked/saved state.
> 
> **States**
> 
> - Same card states as topic listing.
> 
> ---
> 
> ### “All topics” bookmark scope
> 
> **What it does**
> 
> When topic context is “all,” shows bookmarks across every topic within the selected phase.
> 
> **User flow**
> 
> 1. User opens bookmarked view from phase landing All tab context.
> 2. Saved articles from any topic in that phase appear.
> 
> **Rules**
> 
> - Topic slug “all” or equivalent all-topics context includes cross-topic bookmarks in one phase.
> 
> **States**
> 
> - Broader filter than single-topic bookmark view.
> 
> ---
> 
> ### Guest access behavior
> 
> **What it does**
> 
> Allows page shell to load for guests but bookmark data and actions require sign-in.
> 
> **User flow**
> 
> 1. Guest opens bookmark URL directly → likely empty list.
> 2. Guest clicks bookmark toggle → sign-in dialog.
> 
> **Rules**
> 
> - Meaningful bookmark list requires authenticated session.
> 
> **States**
> 
> - **Guest:** empty or error edge case; sign-in prompts on actions.
> - **Signed-in:** full filtered list.
> 
> ---
> 
> ### Localized bookmark path
> 
> **What it does**
> 
> Supports localized bookmark segment in non-English languages (e.g. bookmark path translated per locale).
> 
> **User flow**
> 
> 1. User in German, French, or Arabic sees locale-appropriate bookmark URL segment.
> 
> **Rules**
> 
> - Same feature set across languages with translated path segments.
> 
> **States**
> 
> - Locale-specific URL shape, same behavior.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site chrome.
> 
> **User flow**
> 
> 1. User navigates to global bookmarks area or other portals from header when signed in.
> 
> **Rules**
> 
> - Global bookmarks hub under account menu is separate from this in-portal filtered view.
> 
> **States**
> 
> - Signed-in header with profile menu.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - **Bookmarked** toggle on phase landing or topic listing
> - Direct bookmark URL with phase/topic segments
> - Global info bookmarks may deep-link to articles but not necessarily this filtered view
> 
> **Outbound**
> 
> - Standard phase landing or topic listing (disabling bookmark filter)
> - Other topic bookmark views within same phase
> - Full article pages
> - Sign-in (guest actions)
> - Login from empty guest state
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Empty list likely; bookmark actions prompt sign-in |
> | Signed-in member | Full saved list, inline remove, pagination |
> 
> ---
> 
> ## Important Business Rules
> 
> - Bookmark view is a filter mode of the topic/phase browser, not a separate product area.
> - Filtering happens client-side after fetching user bookmarks.
> - Un-bookmarking updates the list immediately with pagination correction.
> - Phase switch from bookmark mode may produce broken intermediate URLs; topic tab selection recovers context.
> - Distinct from global **Bookmarks → Info** hub which aggregates saves across contexts.
> 
> ---
> 
> ## Related Features
> 
> - Info Portal phase landing and topic listing
> - Info Portal article detail (bookmark source)
> - Global bookmarks (info section)
> - Login
> - Info Portal tag-filtered articles

---

## Page: Community Portal — Phase Landing
- URL: https://freiburger-bund.com/en/community/travel-preparation-1
- Type: product-spec
- Section: Community Portal
- Access: public
- Source: docs/product-knowledge/pages/community-portal-phase.md
- Updated: 2026-09-21

### Purpose
Help international healthcare professionals discover forums, learning spaces, events, and learning partners for a specific journey phase—so they can join discussions, find study partners, and participate in community activities aligned with where they are in their path to Germany.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Portal introduction
> 
> **What it does**
> 
> Introduces the Community Portal with a headline and description about networking, exchange, and support for healthcare professionals.
> 
> **User flow**
> 
> 1. User enters the Community Portal (lands on the first journey phase by default).
> 2. User reads the portal headline and supporting text about phases bringing new questions.
> 
> **Rules**
> 
> - Intro appears above phase and category navigation.
> 
> **States**
> 
> - Static introductory copy.
> 
> ---
> 
> ### Journey phase switcher
> 
> **What it does**
> 
> Lets users switch between the four journey phases while browsing community content.
> 
> **User flow**
> 
> 1. User sees phase controls for Travel Preparation, Professional Recognition, Job Entry, and Career.
> 2. User selects another phase.
> 3. Channel listings and content update for that phase.
> 
> **Rules**
> 
> - Current phase highlighted.
> - Invalid phase in the address redirects to the first available phase.
> 
> **States**
> 
> - **Invalid phase:** page not found or auto-correction to first phase.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Community Portal → current phase and supports upward navigation.
> 
> **User flow**
> 
> 1. User sees breadcrumbs above content.
> 2. User clicks Home or Community Portal to navigate back.
> 
> **Rules**
> 
> - Community Portal segment links to portal root (redirects to first phase).
> 
> **States**
> 
> - Standard breadcrumb; may collapse on narrow screens.
> 
> ---
> 
> ### Content category tabs
> 
> **What it does**
> 
> Filters the community overview by content type: All Categories, Forum, Learning, Events, or Learn Partner.
> 
> **User flow**
> 
> 1. User selects a category tab.
> 2. Page updates to show filtered channels or navigates to the events hub when Events is selected.
> 
> **Rules**
> 
> - **All Categories** shows grouped sections for Forum, Learning, Learn Partner, and public events.
> - **Events** navigates to the global events hub rather than an inline filtered view.
> - Other categories show phase-specific filtered channel grids.
> - Current journey phase is preserved when switching categories.
> 
> **States**
> 
> - **Desktop:** horizontal pill tabs with scroll arrows when overflow.
> - **Mobile:** dropdown category picker.
> 
> ---
> 
> ### Bookmarked-only filter (All Categories view)
> 
> **What it does**
> 
> When viewing All Categories, lets users show only bookmarked channels and bookmarked public events across all sections.
> 
> **User flow**
> 
> 1. User toggles **Bookmarked**.
> 2. List reduces to favorited channels and events only.
> 3. User toggles off to restore full list.
> 
> **Rules**
> 
> - Guest users can toggle but typically see empty results unless bookmarks exist after sign-in.
> - Signed-in users filter against their saved items.
> 
> **States**
> 
> - **Empty favorites:** dedicated message when filter is on and nothing is saved.
> - **Guest bookmark attempt on card:** sign-in prompt.
> 
> ---
> 
> ### Forum channel section
> 
> **What it does**
> 
> Lists discussion channels grouped under Forum with member and discussion counts.
> 
> **User flow**
> 
> 1. User scrolls to the Forum heading under All Categories.
> 2. User browses channel cards (e.g. visa and residency, language exam administration, housing and social life).
> 3. User opens a channel to view discussions.
> 
> **Rules**
> 
> - Each card shows channel name, member count, and discussion count.
> - Empty forum sections show a coming-soon message.
> 
> **States**
> 
> - **Loading:** skeleton cards.
> - **Empty section:** hidden or shows coming-soon text.
> 
> ---
> 
> ### Learning channel section
> 
> **What it does**
> 
> Lists learning-focused channels grouped under Learning.
> 
> **User flow**
> 
> 1. User browses learning channels (e.g. language exam learning).
> 2. User opens a channel for study materials and discussions.
> 
> **Rules**
> 
> - Same card format as forum channels with member and discussion counts.
> 
> **States**
> 
> - Loading and empty states as for Forum.
> 
> ---
> 
> ### Learn Partner channel section
> 
> **What it does**
> 
> Lists channels for finding study partners matched by language level or topic.
> 
> **User flow**
> 
> 1. User browses learn-partner channels (e.g. German language learning partner A1–B2).
> 2. User reads channel description preview on the card.
> 3. User opens the channel to connect with partners.
> 
> **Rules**
> 
> - Learn partner cards emphasize descriptive preview text over member/discussion stats.
> 
> **States**
> 
> - May show rich text preview on cards.
> 
> ---
> 
> ### Public events preview
> 
> **What it does**
> 
> Shows upcoming public events within the phase overview, typically under the Learning section or at the end of All Categories.
> 
> **User flow**
> 
> 1. User sees event cards with date, time, and location.
> 2. User opens an event to view details.
> 3. User bookmarks an event from the card.
> 
> **Rules**
> 
> - Location shows “Online” when no physical location is set.
> - Events appear in All Categories even when Learning channels exist.
> 
> **States**
> 
> - **Loading:** skeleton event cards.
> - **Empty:** section omitted or empty when no public events.
> 
> ---
> 
> ### Channel card layout
> 
> **What it does**
> 
> Presents channels in a responsive carousel (three or more items) or a two-column grid (one or two items).
> 
> **User flow**
> 
> 1. User swipes or scrolls carousel sections with multiple channels.
> 2. User clicks a card to enter the channel.
> 
> **Rules**
> 
> - Layout adapts to number of items in each section.
> 
> **States**
> 
> - Carousel vs grid based on item count.
> 
> ---
> 
> ### Bookmark channel or event
> 
> **What it does**
> 
> Lets signed-in users save a channel or public event from its card.
> 
> **User flow**
> 
> 1. User clicks bookmark on a channel or event card.
> 2. Signed-in user toggles bookmark; icon fills when saved.
> 3. Guest user sees sign-in dialog.
> 
> **Rules**
> 
> - Bookmarks sync to the user account.
> - Bookmarked filter uses these saved items.
> 
> **States**
> 
> - Released vs pressed bookmark button states.
> 
> ---
> 
> ### Category-filtered channel grids
> 
> **What it does**
> 
> When user selects Forum, Learning, or Learn Partner (not All), shows a flat grid of channels for that category in the current phase.
> 
> **User flow**
> 
> 1. User selects Forum, Learning, or Learn Partner tab.
> 2. User sees channels only for that category.
> 3. User may apply a **Bookmarked** filter within that grid (signed-in).
> 
> **Rules**
> 
> - Bookmarked filter on category pages requires sign-in for guests.
> 
> **States**
> 
> - Empty grid shows coming-soon or no-favorites messaging.
> 
> ---
> 
> ### Quick tools section
> 
> **What it does**
> 
> Links to journey planning tools from the community phase page.
> 
> **User flow**
> 
> 1. User scrolls to Quick Tools below community content.
> 2. User opens Cost Calculator, CV Generator, Federal State Compass, Visa Navigator, or Motivation Letter Generator.
> 
> **Rules**
> 
> - Same tool shortcuts as Info Portal phase page.
> 
> **States**
> 
> - Tools listed when section is present.
> 
> ---
> 
> ### Mobile app promotion
> 
> **What it does**
> 
> Promotes the mobile app with store download badges.
> 
> **User flow**
> 
> 1. User reads app section and opens a store link.
> 
> **Rules**
> 
> - External store links.
> 
> **States**
> 
> - Visible when configured.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard navigation, account access, newsletter, social links, legal pages, and cookie consent.
> 
> **User flow**
> 
> 1. User navigates to other portals, account settings, or support pages.
> 
> **Rules**
> 
> - Full footer with social profiles (Telegram, TikTok, Instagram, Facebook, YouTube) on desktop for this portal layout.
> 
> **States**
> 
> - Guest vs signed-in header behavior.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Community Portal menu link (redirects from root to first phase)
> - Homepage portal card
> - Info or Job portal cross-links
> - Direct link to a specific phase
> - Category tab links shared within phase
> 
> **Outbound**
> 
> - Individual community channels (forum, learning, learn partner)
> - Public event detail pages
> - Global events hub (Events tab)
> - Category-filtered phase views (Forum, Learning, Learn Partner)
> - Quick tools (cost calculator, visa navigator, etc.)
> - Sign-in (guest bookmark or protected actions)
> - Mobile app stores
> - Other portals via header/footer
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Can browse phases, categories, channels, and public events; bookmark and category bookmark filters prompt sign-in |
> | Signed-in member | Save/remove bookmarks; use bookmarked filters with personal data; access create-event and calendar from events area |
> 
> Moderators may see additional badges in the global header; no separate moderator view on this overview page.
> 
> ---
> 
> ## Important Business Rules
> 
> - Community Portal root redirects to the first configured journey phase (currently Travel Preparation).
> - Content is organized by journey phase, then by category (Forum, Learning, Learn Partner, Events).
> - **All Categories** is the default overview combining multiple section types.
> - Selecting **Events** leaves the phase overview for the global events hub.
> - Channels display live member and discussion counts where applicable.
> - Bookmarking requires authentication; guests are prompted inline.
> - Empty sections use coming-soon messaging rather than hard errors.
> 
> ---
> 
> ## Related Features
> 
> - Community channel pages (discussions, materials, FSP workspace)
> - Events hub (upcoming, public, calendar, create event)
> - Community bookmarks page
> - Discussion threads and polls
> - Personal connections and chat
> - Info Portal (parallel phase structure)
> - Quick tools and personal journey dashboard
> - Report content flow

---

## Page: Community Portal — Category View
- URL: https://freiburger-bund.com/en/community/travel-preparation-1/forum
- Type: product-spec
- Section: Community Portal
- Access: public
- Source: docs/product-knowledge/pages/community-portal-category.md
- Updated: 2026-09-21

### Purpose
Let users browse channels within a single community category (Forum, Learning, or Learn Partner) for a chosen journey phase, filter to bookmarked channels, and open channels to participate in discussions or learning.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Category-scoped channel list
> 
> **What it does**
> 
> Shows a flat grid of channels belonging only to the selected category in the current journey phase—not a multi-section overview.
> 
> **User flow**
> 
> 1. User selects Forum, Learning, or Learn Partner from category tabs.
> 2. User sees channels for that category only with a section heading matching the category name.
> 
> **Rules**
> 
> - Differs from the All Categories landing, which groups multiple categories and may include a public events preview.
> - No public events strip on category-filtered views.
> - Always uses a grid layout (not carousel), even with many channels.
> 
> **States**
> 
> - **Populated:** channel grid visible.
> - **Empty:** coming-soon message when no channels exist for category/phase.
> 
> ---
> 
> ### Journey phase switcher
> 
> **What it does**
> 
> Lets users change journey phase while keeping the active category in the address.
> 
> **User flow**
> 
> 1. User clicks another phase tab.
> 2. Channel list updates for the same category in the new phase.
> 
> **Rules**
> 
> - Phase and category both preserved in navigation URLs.
> - Invalid phase redirects to first available phase or not-found.
> 
> **States**
> 
> - Active phase highlighted.
> 
> ---
> 
> ### Category tabs
> 
> **What it does**
> 
> Switches between All Categories, Forum, Learning, Events, and Learn Partner.
> 
> **User flow**
> 
> 1. User clicks **All Categories** → returns to phase overview landing.
> 2. User clicks **Events** → navigates to global events hub (leaves phase category view).
> 3. User clicks another category tab → stays in category-filtered view for that type.
> 
> **Rules**
> 
> - Desktop: horizontal scrollable pill tabs with overflow arrows.
> - Mobile: dropdown category picker.
> 
> **States**
> 
> - Active tab matches current category.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Community Portal → current phase.
> 
> **User flow**
> 
> 1. User navigates up via clickable breadcrumb segments.
> 
> **Rules**
> 
> - Same depth as phase landing (no category segment in breadcrumb).
> 
> **States**
> 
> - Standard or collapsed breadcrumb on narrow screens.
> 
> ---
> 
> ### Channel cards
> 
> **What it does**
> 
> Displays each channel with image (or placeholder), name, member count, and discussion count; learn-partner cards emphasize description preview.
> 
> **User flow**
> 
> 1. User scans the grid.
> 2. User opens a channel by clicking the card.
> 
> **Rules**
> 
> - Forum and learning cards show member and discussion counts.
> - Learn-partner cards may show rich description text instead of stats emphasis.
> 
> **States**
> 
> - Loading skeletons while data fetches.
> 
> ---
> 
> ### Bookmark channel
> 
> **What it does**
> 
> Lets signed-in users save or remove a channel from bookmarks on the card.
> 
> **User flow**
> 
> 1. Signed-in user toggles bookmark on a channel card.
> 2. Guest user sees sign-in prompt.
> 
> **Rules**
> 
> - Unlike All Categories header bookmark toggle, category view bookmark filter on the list requires sign-in to activate.
> 
> **States**
> 
> - Saved vs unsaved bookmark icon.
> 
> ---
> 
> ### Bookmarked-only filter
> 
> **What it does**
> 
> Shows only bookmarked channels within the current category and phase.
> 
> **User flow**
> 
> 1. Signed-in user enables **Bookmarked** filter.
> 2. Grid reduces to saved channels only.
> 3. Empty state when none saved in this scope.
> 
> **Rules**
> 
> - Guests attempting filter see sign-in prompt.
> - Toggle returns to full list when deactivated.
> 
> **States**
> 
> - **Empty favorites:** dedicated message.
> - **Filtered:** subset of cards.
> 
> ---
> 
> ### Portal introduction and CMS blocks
> 
> **What it does**
> 
> Shows community portal headline, supporting copy, and optional editorial blocks including quick tools and app promotion below the channel grid.
> 
> **User flow**
> 
> 1. User reads portal intro above category content.
> 2. User may follow quick tool links after scrolling.
> 
> **Rules**
> 
> - Same shell content as phase landing where configured.
> 
> **States**
> 
> - Optional CMS sections.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard navigation, language, login, footer links, and cookie consent.
> 
> **User flow**
> 
> 1. User signs in or navigates to other portals from header.
> 
> **Rules**
> 
> - Same global chrome as other community pages.
> 
> **States**
> 
> - Guest vs signed-in header.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Category tab from phase landing (All Categories view)
> - Phase landing section headings (indirect)
> - Direct category URL
> - Phase switcher from another category view
> 
> **Outbound**
> 
> - All Categories phase landing
> - Global events hub (Events tab)
> - Individual channel feeds
> - Sign-in (guest bookmark actions)
> - Quick tools and other portals
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Browse channels; bookmark filter and save require sign-in |
> | Signed-in member | Bookmark channels; use bookmarked-only filter |
> 
> ---
> 
> ## Important Business Rules
> 
> - Category view is a single-category slice of the phase landing, not a duplicate of All Categories.
> - Events category tab exits to the global events hub rather than an inline events list.
> - Grid layout always applies; carousels are used only on All Categories landing.
> - Channel membership and posting happen inside channel pages, not on this browse view.
> 
> ---
> 
> ## Related Features
> 
> - Community Portal phase landing (All Categories)
> - Community channel feed
> - Community bookmarks (global)
> - Events hub
> - Login

---

## Page: Community Portal — Channel Feed
- URL: https://freiburger-bund.com/en/community/channel/german-language
- Type: product-spec
- Section: Community Portal
- Access: public
- Source: docs/product-knowledge/pages/community-portal-channel.md
- Updated: 2026-09-21

### Purpose
Let users join a community channel, browse and create discussions or learning materials, use channel-specific tools (exam prep workspace, language learning, learn-partner matching), and participate in scoped group chat where applicable.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Channel hero and context
> 
> **What it does**
> 
> Presents channel name, journey phase tag, member count, hero image, and breadcrumb path (phase → category → channel).
> 
> **User flow**
> 
> 1. User lands from category browse or search.
> 2. User reads channel identity and navigational context.
> 
> **Rules**
> 
> - Breadcrumb links back to community phase and category views.
> 
> **States**
> 
> - Standard hero; may vary by channel type.
> 
> ---
> 
> ### Join and leave channel
> 
> **What it does**
> 
> Lets signed-in users join to participate or leave when no longer interested.
> 
> **User flow**
> 
> 1. Guest sees join action → sign-in prompt.
> 2. Signed-in user joins channel.
> 3. Joined user may leave via overflow menu (some collapsed parent channels support leaving multiple underlying channels at once).
> 
> **Rules**
> 
> - Many posting and upload actions require membership.
> - Direct-thread channels emphasize join before posting in feed header.
> 
> **States**
> 
> - **Not joined:** join CTA prominent.
> - **Joined:** leave option and participation enabled.
> 
> ---
> 
> ### Start new discussion
> 
> **What it does**
> 
> Opens discussion composer for a post or poll after user has joined.
> 
> **User flow**
> 
> 1. Joined user clicks start new discussion.
> 2. User navigates to composer with post/poll tabs, title, rich text, attachments, and optional target picker for sub-channels or exam/profession/state metadata.
> 
> **Rules**
> 
> - Submissions may enter under-review state until moderation approves.
> - Draft autosave while composing.
> - Guests prompted to sign-in.
> 
> **States**
> 
> - Composer on dedicated route or overlay depending on channel.
> 
> ---
> 
> ### Discussion feed (forum channels)
> 
> **What it does**
> 
> Lists posts and polls with search, sort, filter, pinned thread, and infinite scroll.
> 
> **User flow**
> 
> 1. User searches discussions by text.
> 2. User sorts by latest, most viewed, or most replied.
> 3. User filters all, unread, posts only, or polls only.
> 4. User opens thread from card; loads more by scrolling.
> 
> **Rules**
> 
> - Pinned discussion stays at top when present.
> - Collapsible under-review section shows user’s pending unapproved posts.
> - Thread cards show author, preview, likes, views, replies, poll badge.
> - Author or moderator may edit/delete from card overflow menu.
> 
> **States**
> 
> - **Empty:** encouragement to be first to share.
> - **Loading:** skeleton cards.
> - **Under review:** expandable pending section for author.
> 
> ---
> 
> ### Sidebar navigation (channel-type specific)
> 
> **What it does**
> 
> Adapts left or top navigation to channel type: sub-channel list, exam/profession/state filters, job profession filter, language provider tabs, or learn-partner filters.
> 
> **User flow**
> 
> 1. User selects sub-channel or filter scope.
> 2. Feed or workspace content updates to match selection.
> 
> **Rules**
> 
> - Channels with sub-channels may redirect to first sub-channel automatically.
> - FSP/KP learning channels may redirect to chat workspace entry.
> - Language-learning sub-channels may open practice-area tabs.
> 
> **States**
> 
> - Layout varies by channel configuration.
> 
> ---
> 
> ### Language learning channel mode
> 
> **What it does**
> 
> Provides practice-area tabs (all, reading, listening, writing, speaking, language building blocks), material upload, material grid, and pending uploads review.
> 
> **User flow**
> 
> 1. User browses approved learning materials with infinite scroll.
> 2. Signed-in user uploads files by practice area.
> 3. User views pending uploads in collapsible under-review section.
> 4. User jumps to personal contributions list via shortcut.
> 
> **Rules**
> 
> - Exam provider may appear in heading (e.g. telc).
> - Leave channel available when joined.
> 
> **States**
> 
> - Materials grid, upload form, pending section.
> 
> ---
> 
> ### FSP/KP exam workspace mode
> 
> **What it does**
> 
> Offers resource tabs for protocols, scripts, books, media, and chat with exam type, profession, and federal state filters.
> 
> **User flow**
> 
> 1. User switches resource tab.
> 2. User searches within active tab.
> 3. User uploads via per-type upload flows.
> 4. Joined user accesses state-scoped group chat with online members indicator.
> 
> **Rules**
> 
> - Join may apply to leaf channels covering multiple underlying scopes.
> - Chat panel available when joined and scope selected.
> 
> **States**
> 
> - Tabbed workspace with counts in header statistics.
> 
> ---
> 
> ### Learn-partner channel mode
> 
> **What it does**
> 
> Helps users discover study partners via filtered partner cards, send connection requests, and manage invitations.
> 
> **User flow**
> 
> 1. User applies sidebar filters: German level or exam type, profession, federal state, preferred spoken language, country of origin.
> 2. User browses partner cards with avatar, headline, languages, location, profession badges.
> 3. User sends connection request with message.
> 4. User manages incoming (accept/deny) and outgoing (cancel) invitations in pending panel.
> 5. User completes profile form and toggles “want to be found” visibility to appear in discovery.
> 
> **Rules**
> 
> - Guests cannot send requests; sign-in required.
> - Leave channel when joined.
> 
> **States**
> 
> - Discovery feed, invitation panels, profile completion form.
> 
> ---
> 
> ### Global site header
> 
> **What it does**
> 
> Extended community header with sidebar layout on supported channel pages.
> 
> **User flow**
> 
> 1. User navigates across community areas from extended header.
> 
> **Rules**
> 
> - Channel pages use community extended header layout with sidebar where configured.
> 
> **States**
> 
> - Signed-in users see messaging and notifications in header.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Category browse channel cards
> - Phase landing channel cards
> - Thread breadcrumb back to channel
> - Search results
> - Dashboard community recommendations
> 
> **Outbound**
> 
> - New discussion composer
> - Thread detail pages
> - Sub-channel routes and FSP workspace tabs
> - Upload flows per resource type
> - Sign-in
> - Learn-partner connection flows
> - Group chat within workspace
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Browse feeds and materials where public; join/post/upload/request require sign-in |
> | Signed-in member | Join, post, upload, partner requests, chat |
> | Moderator | Edit/delete threads from feed cards; additional moderation tools elsewhere |
> 
> ---
> 
> ## Important Business Rules
> 
> - Channel behavior is determined by channel type (forum, learning, FSP workspace, learn-partner, job, etc.).
> - New content may require moderation before public visibility.
> - Joining is the gate for most participation actions.
> - Sub-channel and filter selections scope what content and chat the user sees.
> - Redirect rules normalize collapsed or multi-sub-channel URLs to the appropriate default entry point.
> 
> ---
> 
> ## Related Features
> 
> - Community category view and phase landing
> - Discussion thread detail
> - Community events
> - Personal contributions (materials)
> - Chat and messaging
> - Login

---

## Page: Community Portal — Discussion Thread
- URL: https://freiburger-bund.com/en/community/thread/example-thread
- Type: product-spec
- Section: Community Portal
- Access: public
- Source: docs/product-knowledge/pages/community-portal-thread.md
- Updated: 2026-09-21

### Purpose
Let users read a full discussion (post or poll), interact through likes, follows, bookmarks, comments and replies, report inappropriate content, and navigate back to the parent channel.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Channel context header
> 
> **What it does**
> 
> Shows parent channel branding, member count, join state, and phase tag above the thread.
> 
> **User flow**
> 
> 1. User understands which channel the thread belongs to.
> 2. User may join channel from header if not yet joined.
> 
> **Rules**
> 
> - Join state affects whether reply composer is fully enabled.
> 
> **States**
> 
> - Joined vs not joined.
> 
> ---
> 
> ### Breadcrumb and back navigation
> 
> **What it does**
> 
> Displays breadcrumb trail (channel → truncated thread title) and link back to channel name.
> 
> **User flow**
> 
> 1. User clicks channel name to return to channel feed.
> 
> **Rules**
> 
> - Thread title truncated in breadcrumb when long.
> 
> **States**
> 
> - Standard breadcrumb.
> 
> ---
> 
> ### Thread content display
> 
> **What it does**
> 
> Renders thread title, author block (avatar, name, badges, headline, profile link, post time), markdown body, attachments, and poll widget for poll-type threads.
> 
> **User flow**
> 
> 1. User reads full discussion content.
> 2. User downloads attachments when present.
> 3. User votes or views poll results on poll threads.
> 
> **Rules**
> 
> - Poll-type threads cannot be edited after creation.
> - Verified or official badges shown on author when applicable.
> 
> **States**
> 
> - Post vs poll layout.
> 
> ---
> 
> ### Thread interactions bar
> 
> **What it does**
> 
> Provides reply, like, follow, bookmark, copy link, translate, report, edit, and delete actions.
> 
> **User flow**
> 
> 1. Signed-in user replies → opens rich-text composer (scroll-to-composer).
> 2. User toggles like with count update.
> 3. User toggles follow notifications (not on own posts).
> 4. User bookmarks thread for later.
> 5. User copies shareable link.
> 6. User toggles machine translation vs original.
> 7. User reports with reason dialog (not on own posts; shows already-reported state).
> 8. Author edits via edit page (posts only, not polls).
> 9. Author deletes with confirmation → redirect to channel.
> 
> **Rules**
> 
> - Guests can read, translate, copy link; interactive actions prompt sign-in.
> - Report unavailable on own content.
> 
> **States**
> 
> - **Guest:** read-only interactions except translate/copy.
> - **Author:** edit/delete own thread.
> - **Reported:** disabled report with prior state shown.
> 
> ---
> 
> ### Comments and nested replies
> 
> **What it does**
> 
> Lists top-level comments with infinite or paginated loading and threaded replies beneath each comment.
> 
> **User flow**
> 
> 1. User reads comments and nested replies.
> 2. Signed-in user adds comment or reply via markdown editor with mention support.
> 3. User likes, translates, edits, deletes own comments; reports others’ comments.
> 
> **Rules**
> 
> - Same action set as thread level at comment/reply granularity.
> - Success and error feedback via notifications.
> 
> **States**
> 
> - **Empty comments:** composer still available when joined/signed in.
> - **Loading:** more comments load on scroll.
> 
> ---
> 
> ### Invalid thread handling
> 
> **What it does**
> 
> Shows not-found when thread slug does not resolve.
> 
> **User flow**
> 
> 1. User follows broken link → not-found page.
> 
> **Rules**
> 
> - Unknown slug is hard 404.
> 
> **States**
> 
> - Not found.
> 
> ---
> 
> ### Global site header
> 
> **What it does**
> 
> Extended community header on thread pages.
> 
> **User flow**
> 
> 1. User navigates site-wide from header.
> 
> **Rules**
> 
> - Same community chrome as channel pages.
> 
> **States**
> 
> - Guest vs signed-in.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Channel discussion feed cards
> - Bookmarks and search
> - Notifications linking to thread
> - Profile activity links
> 
> **Outbound**
> 
> - Parent channel feed
> - Author public profile
> - Thread edit page (author, non-poll)
> - Sign-in (guest actions)
> - Report flow (dialog only)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Read, translate, copy link |
> | Signed-in member | Reply, like, follow, bookmark, report |
> | Author | Edit/delete own thread and comments (polls not editable) |
> | Moderator | May delete/edit from moderation tools; report queue separate |
> 
> ---
> 
> ## Important Business Rules
> 
> - Thread belongs to exactly one channel; breadcrumb always returns there on delete.
> - Polls are immutable after publish for editing (delete may still apply).
> - Reporting is per-user with already-reported guard.
> - Translation is reversible toggle per thread and per comment.
> - Follow notifications apply to threads user does not author.
> 
> ---
> 
> ## Related Features
> 
> - Community channel feed
> - Thread edit flow
> - Community bookmarks
> - Report moderation queue
> - Public user profile
> - Login

---

## Page: Community Portal — Events Hub
- URL: https://freiburger-bund.com/en/community/events
- Type: product-spec
- Section: Community Portal
- Access: public
- Source: docs/product-knowledge/pages/community-portal-events.md
- Updated: 2026-09-21

### Purpose
Centralize discovery of community events: the user’s upcoming registrations, public events, calendar view, and entry points to create events or manage pending submissions.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Events hub landing
> 
> **What it does**
> 
> Main events area with category tab active, phase switcher visible, and previews of personal upcoming and public events.
> 
> **User flow**
> 
> 1. User opens Events from community category tabs or direct link.
> 2. User sees hub layout with multiple event sections.
> 
> **Rules**
> 
> - Events hub is global (not tied to a single journey phase in the URL).
> - Phase switcher still visible but does not filter hub lists by phase in address.
> 
> **States**
> 
> - Default hub view.
> 
> ---
> 
> ### Journey phase switcher and category tabs
> 
> **What it does**
> 
> Shows community phase tabs and highlights Events as active category.
> 
> **User flow**
> 
> 1. User switches to another category → leaves events hub for phase views.
> 2. User switches phase tab on hub → **Unknown / requires product clarification** for whether lists filter visually.
> 
> **Rules**
> 
> - Events tab selected while on hub routes.
> 
> **States**
> 
> - Events tab active.
> 
> ---
> 
> ### Your upcoming events
> 
> **What it does**
> 
> Preview list of events the signed-in user is registered for or created, with date, time, location, participant count, and status.
> 
> **User flow**
> 
> 1. Signed-in user scans upcoming preview on hub.
> 2. User opens event detail from card.
> 3. User follows **View all upcoming** for full paginated list.
> 
> **Rules**
> 
> - Personal upcoming list requires sign-in; guests do not see personal section or see empty state.
> - Pending “under review” user submissions may appear in collapsible section.
> 
> **States**
> 
> - **Guest:** section hidden or empty.
> - **Signed-in:** populated preview or empty.
> 
> ---
> 
> ### Public events preview
> 
> **What it does**
> 
> Shows community-wide public event cards discoverable by all users.
> 
> **User flow**
> 
> 1. User browses public event cards with date, time, location, image, recurring badge.
> 2. User opens event detail.
> 3. User follows **View all public events** for full paginated catalog.
> 
> **Rules**
> 
> - Location shows Online when no physical location set.
> - Bookmark on cards where supported.
> 
> **States**
> 
> - Preview truncated on hub; full list on dedicated public events page.
> 
> ---
> 
> ### Create event
> 
> **What it does**
> 
> Lets signed-in users start the event creation form.
> 
> **User flow**
> 
> 1. User clicks create event.
> 2. User navigates to new event form (protected route).
> 
> **Rules**
> 
> - Guests receive sign-in prompt.
> 
> **States**
> 
> - Available to signed-in users only.
> 
> ---
> 
> ### Pending events (under review)
> 
> **What it does**
> 
> Collapsible list of events the user submitted awaiting moderator approval.
> 
> **User flow**
> 
> 1. Signed-in user expands pending section.
> 2. User sees status of submissions not yet public.
> 
> **Rules**
> 
> - Only user’s own pending events shown.
> 
> **States**
> 
> - Collapsed or expanded.
> 
> ---
> 
> ### Event calendar overlay
> 
> **What it does**
> 
> Full-screen calendar with month/week/year views, color-coded event types, navigation controls, and event click-through.
> 
> **User flow**
> 
> 1. User opens calendar toggle from hub header actions.
> 2. User navigates dates and switches calendar view.
> 3. User clicks event to open detail.
> 4. Signed-in user may add event to Google Calendar or start create-event from calendar.
> 
> **Rules**
> 
> - Calendar requires sign-in for some actions (create from calendar).
> - Returns to list view when closed.
> 
> **States**
> 
> - **List mode** vs **calendar overlay**.
> 
> ---
> 
> ### Hub header actions
> 
> **What it does**
> 
> Provides back control on sub-views, bookmarks shortcut to community bookmarks area, and calendar toggle.
> 
> **User flow**
> 
> 1. User opens community bookmarks from shortcut.
> 2. User toggles calendar or navigates back from sub-pages.
> 
> **Rules**
> 
> - Bookmarks shortcut may require sign-in depending on destination behavior.
> 
> **States**
> 
> - Contextual back on upcoming/public sub-routes.
> 
> ---
> 
> ### Sub-routes: upcoming and public full lists
> 
> **What it does**
> 
> Paginated full listings at dedicated upcoming and public event pages linked from hub.
> 
> **User flow**
> 
> 1. User views all upcoming or all public events with pagination.
> 2. User returns to hub via back control.
> 
> **Rules**
> 
> - Same card design as hub previews.
> 
> **States**
> 
> - Paginated list pages.
> 
> ---
> 
> ### Portal shell and CMS blocks
> 
> **What it does**
> 
> Community portal introduction, breadcrumbs, and optional CMS content around events area.
> 
> **User flow**
> 
> 1. User sees standard community chrome and editorial blocks.
> 
> **Rules**
> 
> - Same shell as other community WOSidebar pages.
> 
> **States**
> 
> - Optional CMS slots.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site navigation and footer.
> 
> **User flow**
> 
> 1. User navigates elsewhere from header.
> 
> **Rules**
> 
> - Extended community header layout.
> 
> **States**
> 
> - Guest vs signed-in.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Events category tab from phase or category views
> - Event detail back navigation
> - Dashboard or community recommendations
> - Direct hub URL
> 
> **Outbound**
> 
> - Event detail pages
> - Create event form
> - Full upcoming list
> - Full public events list
> - Community bookmarks area
> - Sign-in (guest create/register actions)
> - Google Calendar (export from calendar view)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Browse public events and calendar view where allowed; no personal upcoming or create |
> | Signed-in member | Upcoming list, create event, pending submissions, register from cards |
> | Event creator | Manage own events from detail pages (documented separately) |
> 
> ---
> 
> ## Important Business Rules
> 
> - Events hub is global; phase tabs do not replace phase-scoped channel browsing.
> - Public events visible to all; personal upcoming requires account.
> - New user-submitted events may require approval before appearing publicly.
> - Calendar is an overlay on the hub experience, not a separate product area.
> - Recurring events show recurring badge on cards.
> 
> ---
> 
> ## Related Features
> 
> - Event detail page
> - Community bookmarks
> - Community phase landing (Events tab entry)
> - Login
> - Video meeting and event chat (from event detail)

---

## Page: Community Portal — Event Detail
- URL: https://freiburger-bund.com/en/community/events/example-event
- Type: product-spec
- Section: Community Portal
- Access: public
- Source: docs/product-knowledge/pages/community-portal-event-detail.md
- Updated: 2026-09-21

### Purpose
Let users view full information about a community event, register or cancel attendance, join online meetings, access event chat, and let creators manage or cancel events including recurring series.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Event header and metadata
> 
> **What it does**
> 
> Displays event title (with recurring badge when applicable), cover image, date, time range, recurrence label, location or Online, and participant count.
> 
> **User flow**
> 
> 1. User reads when and where the event happens.
> 2. User sees how many others have registered (“join N professionals” or “be first to join”).
> 
> **Rules**
> 
> - Times shown in Central European Time range format.
> - Invalid event slug → not-found page.
> 
> **States**
> 
> - **Loading skeleton** while detail loads.
> - **Loaded** full detail.
> 
> ---
> 
> ### Event description
> 
> **What it does**
> 
> Shows markdown description, extended event details, and optional certificate callout when certificate is provided.
> 
> **User flow**
> 
> 1. User reads About the session and supplementary details.
> 
> **Rules**
> 
> - Certificate block appears only when event offers certificate.
> 
> **States**
> 
> - Rich text content.
> 
> ---
> 
> ### Register for event
> 
> **What it does**
> 
> Lets signed-in users register for attendance; for recurring series, registration applies to all dates in the series with explanatory hint.
> 
> **User flow**
> 
> 1. Signed-in user clicks register.
> 2. Confirmation banner shows already registered state.
> 3. Guest attempting register sees sign-in prompt or toast.
> 
> **Rules**
> 
> - Series registration is all-occurrence unless product specifies otherwise in UI hints.
> 
> **States**
> 
> - **Not registered:** register action available.
> - **Registered:** green confirmation banner.
> 
> ---
> 
> ### Cancel registration
> 
> **What it does**
> 
> Lets registered users cancel attendance, with scope dialog for recurring series (this occurrence, future, or all).
> 
> **User flow**
> 
> 1. User chooses cancel registration.
> 2. For recurring events, user selects scope in dialog.
> 3. Registration state updates.
> 
> **Rules**
> 
> - Scope choices mirror creator edit/delete recurring patterns.
> 
> **States**
> 
> - Registered → not registered after cancel.
> 
> ---
> 
> ### Join meeting and event chat
> 
> **What it does**
> 
> Provides video meeting entry when room is ready and link to event conversation when chat is provisioned.
> 
> **User flow**
> 
> 1. Registered user joins meeting when available.
> 2. User opens event chat when ready.
> 3. Pending message shown when meeting room not yet provisioned.
> 
> **Rules**
> 
> - Typically available only to registered users.
> - **Unknown / requires product clarification** for exact timing of room readiness.
> 
> **States**
> 
> - **Ready:** join and chat links active.
> - **Pending:** placeholder message.
> 
> ---
> 
> ### Bookmark and share
> 
> **What it does**
> 
> Lets users save event to bookmarks (series-level for recurring with hint) and share via link popover.
> 
> **User flow**
> 
> 1. User bookmarks event for later.
> 2. User copies or shares event link.
> 
> **Rules**
> 
> - Recurring bookmark applies to full series per UI hint.
> 
> **States**
> 
> - Bookmark saved vs not saved.
> 
> ---
> 
> ### View in calendar
> 
> **What it does**
> 
> Opens events hub calendar overlay focused on this event.
> 
> **User flow**
> 
> 1. User clicks view in calendar.
> 2. Calendar overlay opens from hub context.
> 
> **Rules**
> 
> - Bridges detail page to hub calendar component.
> 
> **States**
> 
> - Calendar overlay open.
> 
> ---
> 
> ### Creator manage actions
> 
> **What it does**
> 
> Lets event creator edit or delete/cancel own events with recurring scope dialogs.
> 
> **User flow**
> 
> 1. Creator opens edit → event edit form with scope choice for series (this / future / all).
> 2. Creator deletes/cancels with confirmation and recurring scope dialog.
> 3. After delete, user redirected to events hub.
> 
> **Rules**
> 
> - Edit/delete visible only to creator (and moderators **Unknown / requires product clarification**).
> - Post-delete redirect to events hub.
> 
> **States**
> 
> - Creator-only action buttons.
> 
> ---
> 
> ### Hub header actions inheritance
> 
> **What it does**
> 
> Event detail wrapped with events hub header actions: back, bookmarks shortcut, calendar toggle.
> 
> **User flow**
> 
> 1. User navigates back toward hub or opens bookmarks/calendar without losing event context path.
> 
> **Rules**
> 
> - Consistent header with events area.
> 
> **States**
> 
> - Same as events hub header.
> 
> ---
> 
> ### SEO and sharing metadata
> 
> **What it does**
> 
> Sets page title, description, and social preview image for external sharing.
> 
> **User flow**
> 
> 1. User shares link; preview reflects event title and image.
> 
> **Rules**
> 
> - Not visible on-page but affects link previews.
> 
> **States**
> 
> - Automatic metadata.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Event cards on hub, upcoming/public lists, calendar
> - Bookmarks opening saved events
> - Notifications and direct links
> 
> **Outbound**
> 
> - Events hub (back, post-delete)
> - Event edit form (creator)
> - Meeting room (external or embedded)
> - Event chat conversation
> - Sign-in (guest register)
> - Community bookmarks (header shortcut)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | View details; register prompts sign-in |
> | Signed-in member | Register, cancel, bookmark, join meeting/chat when registered |
> | Event creator | Edit, delete/cancel with recurring scope dialogs |
> 
> ---
> 
> ## Important Business Rules
> 
> - Registration is required before meeting/chat access in normal flow.
> - Recurring events surface series-level hints for bookmark, register, and cancel operations.
> - Creators bear responsibility for edit/delete scope selection on series.
> - Public events may still require sign-in to register.
> - Event must exist and be published/approved to load detail (pending events visible to creator in hub pending section).
> 
> ---
> 
> ## Related Features
> 
> - Events hub and calendar
> - Create/edit event form
> - Community bookmarks
> - Messaging and video meetings
> - Login

---

## Page: Community Portal — Bookmarks
- URL: https://freiburger-bund.com/en/bookmarks/community
- Type: product-spec
- Section: Community Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/community-portal-bookmarks.md
- Updated: 2026-09-21

### Purpose
Let signed-in users view, search, and remove saved community content (threads, polls, events, materials, and related types) in one paginated collection.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### URL redirect to global bookmarks
> 
> **What it does**
> 
> Automatically forwards the legacy community bookmark address to the global bookmarks area’s community section.
> 
> **User flow**
> 
> 1. User opens old community bookmark link.
> 2. User lands on global bookmarks page scoped to community saves.
> 
> **Rules**
> 
> - Community-specific sidebar bookmark layout is not used on live path; redirect is automatic.
> - Destination is the community section within global bookmarks, not the in-portal filtered channel view.
> 
> **States**
> 
> - Immediate redirect; user sees global bookmarks UI.
> 
> ---
> 
> ### Community bookmarks section
> 
> **What it does**
> 
> Displays heading and grid of all bookmarked community items for the signed-in user.
> 
> **User flow**
> 
> 1. Signed-in user browses saved threads, polls, events, protocols, materials, and other community types.
> 2. Guest may reach page but meaningful list requires account.
> 
> **Rules**
> 
> - Part of broader global bookmarks product area with portal sections.
> 
> **States**
> 
> - **Signed-in:** populated or empty grid.
> - **Guest:** **Unknown / requires product clarification** for empty vs redirect to login.
> 
> ---
> 
> ### Search bookmarks
> 
> **What it does**
> 
> Filters bookmark list by query parameter in the address.
> 
> **User flow**
> 
> 1. User enters search from parent bookmarks context.
> 2. Grid updates to matching saved items.
> 
> **Rules**
> 
> - Search passed via query string on global bookmarks page.
> 
> **States**
> 
> - Filtered vs full list.
> 
> ---
> 
> ### Bookmark cards
> 
> **What it does**
> 
> Shows content type label, title, truncated preview, tags when present, and open action.
> 
> **User flow**
> 
> 1. User identifies item type (thread, poll, event, protocol, material, etc.).
> 2. User opens item → navigates to respective detail page (thread, event, material, etc.).
> 
> **Rules**
> 
> - Card design responsive across one to three columns.
> 
> **States**
> 
> - Loading skeletons while fetching.
> 
> ---
> 
> ### Remove bookmark
> 
> **What it does**
> 
> Toggles bookmark off from card to unsave item.
> 
> **User flow**
> 
> 1. Signed-in user clicks bookmark control on card.
> 2. Item removed from list.
> 
> **Rules**
> 
> - Requires signed-in session.
> 
> **States**
> 
> - Card disappears from grid on success.
> 
> ---
> 
> ### Pagination
> 
> **What it does**
> 
> Pages through large bookmark collections with smoother prefetch of adjacent pages.
> 
> **User flow**
> 
> 1. User navigates pages when many bookmarks saved.
> 
> **Rules**
> 
> - Paginated grid on global bookmarks community section.
> 
> **States**
> 
> - Multi-page navigation.
> 
> ---
> 
> ### Empty and error states
> 
> **What it does**
> 
> Shows no-results message when no bookmarks match filters; shows error with retry path when load fails.
> 
> **User flow**
> 
> 1. User sees empty state when nothing saved or search has no matches.
> 2. User retries after error.
> 
> **Rules**
> 
> - Distinct empty copy from channel “coming soon.”
> 
> **States**
> 
> - Empty, error, loaded.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Legacy `/community/bookmark` redirect
> - Events hub bookmarks shortcut
> - Profile or header bookmarks entry (global)
> - **Unknown / requires product clarification** for all header entry points
> 
> **Outbound**
> 
> - Thread detail
> - Event detail
> - Material/protocol detail pages
> - Other community content detail routes by item type
> - Global bookmarks other sections (info, job, all)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Likely empty or blocked; remove requires sign-in |
> | Signed-in member | Full list, search, remove, open items |
> 
> ---
> 
> ## Important Business Rules
> 
> - Community bookmarks live in global bookmarks product, not the in-portal phase bookmark filter on channel browse pages.
> - Old community bookmark URL always redirects to global community section.
> - Bookmark types span multiple community entities unified in one list.
> - Removing bookmark here does not delete the underlying content.
> 
> ---
> 
> ## Related Features
> 
> - Global bookmarks (all sections)
> - Discussion threads, events, materials (bookmark sources)
> - Community phase/category bookmark filters (separate in-portal feature)
> - Login

---

## Page: Community Portal — Report Queue
- URL: https://freiburger-bund.com/en/community/report
- Type: product-spec
- Section: Community Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/community-portal-report.md
- Updated: 2026-09-21

### Purpose
Let moderators and administrators review reported community content and chat messages, archive or restore reported threads/comments, and delete offending chat messages.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Access restriction
> 
> **What it does**
> 
> Limits the report queue to users with moderator or administrator role; all others redirected to homepage.
> 
> **User flow**
> 
> 1. Non-moderator opens report URL → redirected away.
> 2. Moderator opens page → report tools visible.
> 
> **Rules**
> 
> - Guests and regular members cannot access.
> - No public browsing of report queue.
> 
> **States**
> 
> - **Authorized:** report UI.
> - **Unauthorized:** redirect to home.
> 
> ---
> 
> ### Page title and tab switcher
> 
> **What it does**
> 
> Presents Reports heading with two tabs: Content Reports and Chat Message Reports.
> 
> **User flow**
> 
> 1. Moderator switches tabs to change report type under review.
> 
> **Rules**
> 
> - Two parallel moderation queues in one page.
> 
> **States**
> 
> - Active tab highlighted.
> 
> ---
> 
> ### Content reports table
> 
> **What it does**
> 
> Lists reported threads, comments, and replies with excerpt, reason, reporter description, record type, status, date, and reporter name.
> 
> **User flow**
> 
> 1. Moderator reads each report row.
> 2. Moderator decides archive or unarchive action.
> 
> **Rules**
> 
> - Archive status badge distinguishes archived vs active live content.
> - Page size selectable: 5, 10, or 25 rows per page.
> 
> **States**
> 
> - **Loading:** skeleton rows.
> - **Empty:** no reports message.
> - **Populated:** paginated table.
> 
> ---
> 
> ### Archive and unarchive content
> 
> **What it does**
> 
> Lets moderator hide reported content from public view (archive) or restore it (unarchive).
> 
> **User flow**
> 
> 1. Moderator clicks archive on reported item.
> 2. Content removed from public visibility.
> 3. Moderator may unarchive to restore.
> 
> **Rules**
> 
> - Success and failure feedback via notifications.
> - Applies to reported thread, comment, or reply types shown in table.
> 
> **States**
> 
> - Archived vs active badge per row.
> 
> ---
> 
> ### Content reports pagination
> 
> **What it does**
> 
> Navigates pages when report volume exceeds selected page size.
> 
> **User flow**
> 
> 1. Moderator moves between pages of content reports.
> 
> **Rules**
> 
> - Standard page controls with configurable page size.
> 
> **States**
> 
> - Multi-page table.
> 
> ---
> 
> ### Chat message reports table
> 
> **What it does**
> 
> Lists reported chat messages with message text, author avatar and name, report reasons, report count, and latest report date.
> 
> **User flow**
> 
> 1. Moderator reviews repeated reports on same message via report count badge.
> 2. Moderator deletes message when appropriate.
> 
> **Rules**
> 
> - Report count aggregates multiple reports per message.
> 
> **States**
> 
> - Loading, empty, or populated.
> 
> ---
> 
> ### Delete chat message
> 
> **What it does**
> 
> Permanently removes reported chat message after moderator confirmation.
> 
> **User flow**
> 
> 1. Moderator initiates delete.
> 2. Confirmation dialog warns action is irreversible.
> 3. Message removed on confirm.
> 
> **Rules**
> 
> - Delete is destructive; no soft-delete described in UI.
> 
> **States**
> 
> - Confirmation dialog open vs closed.
> 
> ---
> 
> ### Chat reports pagination and errors
> 
> **What it does**
> 
> Pages through chat reports and shows retry panel on fetch failure.
> 
> **User flow**
> 
> 1. Moderator navigates pages of chat reports.
> 2. On API error, moderator retries load.
> 
> **Rules**
> 
> - Previous/next pagination when multiple pages.
> - Error state distinct from empty queue.
> 
> **States**
> 
> - Error with retry, empty, loaded.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Moderator profile menu or internal moderation links
> - Direct URL (moderators only)
> 
> **Outbound**
> 
> - Homepage (unauthorized redirect)
> - **Unknown / requires product clarification** for links from report rows to underlying content
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to homepage |
> | Signed-in member | Redirected to homepage |
> | Moderator / administrator | Full report queue access |
> 
> ---
> 
> ## Important Business Rules
> 
> - Moderation actions affect live community visibility (archive) or permanently remove chat messages (delete).
> - Content reports and chat reports are separate workflows on one page.
> - Reporter identity shown to moderators for content reports.
> - Archive is reversible; chat message delete is presented as irreversible.
> - Regular members use in-context report dialog on threads; this page is the moderator intake queue only.
> 
> ---
> 
> ## Related Features
> 
> - Discussion thread report action
> - Community channel chat (FSP workspace)
> - Public user profiles (reporter and author names)
> - Login and moderator role assignment

---

## Page: Job Portal — Home
- URL: https://freiburger-bund.com/en/job
- Type: product-spec
- Section: Job Portal
- Access: public
- Source: docs/product-knowledge/pages/job-portal.md
- Updated: 2026-09-21

### Purpose
Give international healthcare professionals a single entry point to discover job opportunities, peer-shared openings, and application tools—so they can start job searching and document preparation from one hub.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Portal hero
> 
> **What it does**
> 
> Introduces the Job Portal with a headline, description, category badge, and a primary call to action to browse vacancies.
> 
> **User flow**
> 
> 1. User lands on the Job Portal home tab.
> 2. User reads the hero message about finding opportunities in Germany.
> 3. User may follow the primary browse action or read the expert-guidance supporting copy.
> 
> **Rules**
> 
> - Hero communicates the portal’s focus on healthcare careers in Germany.
> - A decorative illustration and highlight callout appear on larger screens.
> 
> **States**
> 
> - Default hero visible on “All” tab.
> 
> ---
> 
> ### Portal section tabs
> 
> **What it does**
> 
> Lets users switch between the home overview, full job listings area, and application tools area.
> 
> **User flow**
> 
> 1. User sees three tabs: **All**, **Current Job Listings**, and **Job Application Tools**.
> 2. User clicks a tab.
> 3. Corresponding section or page loads.
> 
> **Rules**
> 
> - **All** is the default landing tab showing previews.
> - **Current Job Listings** and **Job Application Tools** navigate to dedicated sub-areas with deeper functionality.
> 
> **States**
> 
> - Active tab visually highlighted.
> 
> ---
> 
> ### Current job listings preview
> 
> **What it does**
> 
> Shows a preview of open healthcare job postings with a link to view the full listings catalog.
> 
> **User flow**
> 
> 1. User reads the section title and subtitle about relevant openings.
> 2. User browses up to three featured job cards (when available).
> 3. User clicks a job card to open the full posting.
> 4. User clicks **View all job offers** to open the complete listings area.
> 
> **Rules**
> 
> - Preview limited to a small number of featured listings on the home tab.
> - Each card shows title, employer, location, and short description when data is available.
> 
> **States**
> 
> - **Loading:** skeleton cards while listings fetch.
> - **Empty:** section heading and view-all link may appear without cards when no listings match.
> - **Populated:** up to three preview cards visible.
> 
> ---
> 
> ### Bookmark job from preview
> 
> **What it does**
> 
> Lets signed-in users save a job posting from the preview card for later.
> 
> **User flow**
> 
> 1. User clicks the bookmark control on a job card.
> 2. If signed in, job is saved and icon updates.
> 3. If guest, sign-in dialog opens.
> 
> **Rules**
> 
> - Bookmark state is per user.
> - Saved jobs accessible from the bookmarked jobs area.
> 
> **States**
> 
> - **Guest:** sign-in required.
> - **Saved:** filled bookmark icon.
> 
> ---
> 
> ### Colleague-to-colleague preview
> 
> **What it does**
> 
> Shows peer-shared job opportunities posted by community members with a link to view all colleague offers.
> 
> **User flow**
> 
> 1. User reads the Colleague 2 Colleague section introduction.
> 2. User browses preview offer cards when available.
> 3. User clicks **View all job offers** (section link) to see the full colleague offers catalog.
> 4. User may express interest in an offer from a preview card.
> 
> **Rules**
> 
> - Offers may show sharer identity or anonymous posting depending on the offer.
> - Cards include role category, title, organization, department, start date, and location when provided.
> 
> **States**
> 
> - **Loading:** skeleton cards.
> - **Empty:** section visible without cards when no offers exist.
> - **Interest expressed (signed-in):** button may show applied state.
> 
> ---
> 
> ### Bookmark colleague offer
> 
> **What it does**
> 
> Lets signed-in users save a colleague-shared offer from the preview list.
> 
> **User flow**
> 
> 1. User clicks bookmark on a colleague offer card.
> 2. Signed-in user toggles save state; guest sees sign-in prompt.
> 
> **Rules**
> 
> - Same bookmark rules as standard job listings.
> 
> **States**
> 
> - Guest vs signed-in as above.
> 
> ---
> 
> ### Express interest in colleague offer
> 
> **What it does**
> 
> Lets signed-in users signal interest in a colleague-shared opening to initiate contact.
> 
> **User flow**
> 
> 1. User clicks the interest/message action on a colleague offer card.
> 2. If signed in, interest is submitted and button state may update to applied.
> 3. If guest, sign-in dialog opens.
> 
> **Rules**
> 
> - Available only on colleague-to-colleague offers, not standard employer listings preview.
> 
> **States**
> 
> - **Not applied:** action available.
> - **Applied:** action shows completed state.
> 
> ---
> 
> ### Job application tools section
> 
> **What it does**
> 
> Presents three document tools: CV Generator, Motivation Letter Generator, and Documents folder.
> 
> **User flow**
> 
> 1. User reads the tools section introduction.
> 2. User opens **CV Generator** to create a German-standard CV.
> 3. User opens **Motivation Letter Generator** to create a cover letter.
> 4. User opens **Documents** to view and manage stored application files.
> 
> **Rules**
> 
> - Each tool card has a short description and a direct action link (Open Tool, Create now, View Folder).
> - Tools are accessible from the home tab without switching portal tabs.
> 
> **States**
> 
> - All three tools always shown on home tab.
> 
> ---
> 
> ### Success stories
> 
> **What it does**
> 
> Displays testimonials from international healthcare professionals who found work in Germany using the portal and community.
> 
> **User flow**
> 
> 1. User scrolls to Success Stories.
> 2. User reads one or more quotes with name, role, and city.
> 
> **Rules**
> 
> - Marketing content; no interactive actions beyond reading.
> 
> **States**
> 
> - Multiple stories may appear in a carousel or grid.
> 
> ---
> 
> ### Global site header
> 
> **What it does**
> 
> Standard site header with navigation, language, and account access; **Start Your Journey** shortcut also visible in the job portal header area.
> 
> **User flow**
> 
> 1. User navigates to other portals or account features from the header.
> 
> **Rules**
> 
> - Job Portal accessible from main Portals navigation.
> 
> **States**
> 
> - Guest vs signed-in as on other pages.
> 
> ---
> 
> ### Global site footer and newsletter
> 
> **What it does**
> 
> Organization contact, portal/support links, newsletter signup, legal links, and cookie consent.
> 
> **User flow**
> 
> 1. User subscribes to newsletter or navigates to support/legal pages.
> 
> **Rules**
> 
> - Desktop shows full footer; mobile may show compact newsletter strip on this page.
> 
> **States**
> 
> - Same as other portal pages.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Homepage Job Portal card or header link
> - Main navigation Portals → Job
> - Direct URL to job portal root
> - Legacy links with old tab query parameters (automatically redirected to correct section)
> 
> **Outbound**
> 
> - Full job listings area (Current Job Listings tab / view all)
> - Colleague-to-colleague offers catalog
> - CV Generator, Motivation Letter Generator, Documents folder
> - Individual job posting detail pages
> - Sign-in (guest bookmark or interest actions)
> - Other portals and journey tools via header/footer
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Can view hero, previews, tools, and success stories; bookmark and colleague interest actions require sign-in |
> | Signed-in member | Bookmark jobs and colleague offers; express interest on colleague offers; see saved/applied state on cards |
> 
> Employer posting and application review features live in the employer area, not on this public home tab.
> 
> ---
> 
> ## Important Business Rules
> 
> - The home “All” tab is a preview hub; full search, filter, and alert features live in the Current Job Listings sub-area.
> - Colleague-to-colleague offers are peer-shared and separate from employer-posted vacancies.
> - Application tools are available from the home tab but full builders live in dedicated tool pages.
> - Bookmarking and expressing interest require an authenticated account.
> - Empty listing previews still expose navigation to full catalogs.
> 
> ---
> 
> ## Related Features
> 
> - Job listings catalog (open offers)
> - Colleague-to-colleague offers
> - Bookmarked jobs and saved searches
> - Job alerts
> - Job posting detail and application flow
> - CV builder and motivation letter builder
> - Documents folder
> - Employer job posting (company area)
> - Community portal (peer network for colleague offers)

---

## Page: Job Portal — Job Offers Listings
- URL: https://freiburger-bund.com/en/job/open/offers
- Type: product-spec
- Section: Job Portal
- Access: public
- Source: docs/product-knowledge/pages/job-portal-offers.md
- Updated: 2026-09-21

### Purpose
Let healthcare professionals search, filter, and browse the full catalog of open job postings, save searches for later, and open individual postings to apply or bookmark.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Portal shell and navigation
> 
> **What it does**
> 
> Places the listings catalog inside the Job Portal with primary section tabs, open-positions secondary tabs, hero banner, and a shortcut to the job forum.
> 
> **User flow**
> 
> 1. User opens Current Job Listings → Job Offers.
> 2. User sees hero, primary tabs (All · Current Job Listings · Job Application Tools), and secondary tabs (Job Offers · Colleague-to-Colleague · Saved Jobs · Job Alerts).
> 3. User may switch tabs or follow the job forum link.
> 
> **Rules**
> 
> - Open Positions index redirects to Job Offers.
> - Legacy tab query parameters redirect to path-based routes while preserving other filters.
> 
> **States**
> 
> - Active primary and secondary tabs highlighted.
> 
> ---
> 
> ### Keyword search
> 
> **What it does**
> 
> Filters job postings by free-text keyword across titles and descriptions.
> 
> **User flow**
> 
> 1. User types in the search field.
> 2. Results update after a short debounce.
> 
> **Rules**
> 
> - Search state is reflected in the page address for shareable searches.
> 
> **States**
> 
> - **Default:** empty field, full catalog (subject to other filters).
> - **Active search:** result count and cards update.
> 
> ---
> 
> ### Employment type filter
> 
> **What it does**
> 
> Narrows results by scope of work (employment type), supporting multiple selections.
> 
> **User flow**
> 
> 1. User opens the employment type selector.
> 2. User selects one or more types.
> 3. Listing grid refreshes.
> 
> **Rules**
> 
> - Selected types appear as removable filter chips.
> 
> **States**
> 
> - **None selected:** all employment types included.
> - **One or more selected:** chips shown; results filtered.
> 
> ---
> 
> ### Location and radius filters
> 
> **What it does**
> 
> Filters jobs by geographic location using place search (postal code, city, or state) and optional radius when a city or postal code is chosen.
> 
> **User flow**
> 
> 1. User searches for a place in the location field.
> 2. User selects a suggestion.
> 3. When city or postal code is selected, user may set a radius.
> 4. Results refresh to match location criteria.
> 
> **Rules**
> 
> - Radius control hidden when only a state-level selection is active.
> - Removing location clears related radius filter.
> 
> **States**
> 
> - **No location:** nationwide or unfiltered by geography.
> - **Location set:** radius available for city/zip selections.
> 
> ---
> 
> ### Active filter chips
> 
> **What it does**
> 
> Shows currently applied filters as removable chips with a bulk clear action.
> 
> **User flow**
> 
> 1. User applies filters.
> 2. User removes individual chips or clicks clear all when two or more filters are active.
> 
> **Rules**
> 
> - Clearing a parent filter may auto-clear dependent filters (e.g., location removes radius).
> 
> **States**
> 
> - **No filters:** chips hidden.
> - **Filters active:** chips visible; clear all shown when two or more active.
> 
> ---
> 
> ### Result count and job card grid
> 
> **What it does**
> 
> Displays how many jobs match current criteria and renders responsive cards in a one-, two-, or three-column grid.
> 
> **User flow**
> 
> 1. User reads the result count (e.g., “X jobs found”).
> 2. User scans cards showing title, company, location, description snippet, and applicant count when available.
> 3. User clicks a card or **View job** to open the posting detail.
> 
> **Rules**
> 
> - Cards link to individual job detail pages.
> - Applicant count shown when data is available.
> 
> **States**
> 
> - **Loading:** skeleton cards.
> - **Populated:** grid of job cards.
> - **Empty:** no-results message when nothing matches filters.
> 
> ---
> 
> ### Bookmark toggle on cards
> 
> **What it does**
> 
> Lets signed-in users save or unsave a job from the listing without opening the detail page.
> 
> **User flow**
> 
> 1. User clicks the bookmark control on a card.
> 2. Job is added to or removed from saved jobs.
> 
> **Rules**
> 
> - Guests are prompted to sign in instead of bookmarking.
> 
> **States**
> 
> - **Bookmarked:** filled or active bookmark indicator.
> - **Not bookmarked:** default outline state.
> 
> ---
> 
> ### Pagination
> 
> **What it does**
> 
> Splits large result sets across pages.
> 
> **User flow**
> 
> 1. User navigates to next, previous, or a specific page when multiple pages exist.
> 
> **Rules**
> 
> - Pagination appears only when results exceed one page.
> 
> **States**
> 
> - **Single page:** pagination hidden.
> - **Multiple pages:** page controls visible.
> 
> ---
> 
> ### Save current search
> 
> **What it does**
> 
> Lets signed-in users store the active keyword and filter combination under a custom title for quick reuse.
> 
> **User flow**
> 
> 1. User configures search and filters.
> 2. User clicks save current search.
> 3. User enters a title in the dialog and confirms.
> 4. Optionally user checks notify me of similar jobs to create a linked job alert.
> 
> **Rules**
> 
> - Requires signed-in account; guests see sign-in prompt.
> - Optional notification checkbox creates or links a job alert subscription.
> 
> **States**
> 
> - **Success:** confirmation feedback; search appears in my searches.
> - **Guest:** sign-in dialog instead of save dialog.
> 
> ---
> 
> ### My searches link
> 
> **What it does**
> 
> Opens the saved-search management view where users can re-run or manage stored searches.
> 
> **User flow**
> 
> 1. User clicks **My searches**.
> 2. Saved search list opens.
> 
> **Rules**
> 
> - Requires signed-in account for meaningful content; guests may be prompted to sign in.
> 
> **States**
> 
> - **Has saved searches:** list of named searches.
> - **No saved searches:** empty guidance.
> 
> ---
> 
> ### Job forum shortcut
> 
> **What it does**
> 
> Links to the external or community job forum for discussion beyond listings.
> 
> **User flow**
> 
> 1. User clicks the job forum link from the listings area.
> 
> **Rules**
> 
> - Available on listings and most open-positions sub-pages.
> 
> **States**
> 
> - Link always visible in listings footer area.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Job Portal home → Current Job Listings tab or view all job offers
> - Secondary tab from Colleague-to-Colleague, Saved Jobs, or Job Alerts
> - Direct URL with optional filter query parameters
> - My searches re-run from saved search list
> 
> **Outbound**
> 
> - Individual job posting detail
> - Colleague-to-Colleague catalog, Saved Jobs, Job Alerts (secondary tabs)
> - Job Application Tools (primary tab)
> - Job Portal home (All tab)
> - My searches management
> - Sign-in (guest bookmark or save search)
> - Job forum
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full browse, search, filter, pagination; bookmark and save search require sign-in |
> | Signed-in member | Bookmark jobs, save searches, optional alert on save, access my searches |
> 
> ---
> 
> ## Important Business Rules
> 
> - Listings include employer-posted and aggregated openings; colleague-to-colleague offers live on a separate tab.
> - Filter state in the address bar enables shareable searches.
> - Saving a search with notification creates a job alert tied to the same criteria.
> - Expired postings are excluded from active listings.
> - Empty results still expose filters and navigation; user can broaden criteria.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — Home](job-portal.md)
> - [Job Portal — Colleague-to-Colleague](job-portal-c2c.md)
> - [Job Portal — Saved Jobs](job-portal-bookmarked.md)
> - [Job Portal — Job Alerts](job-portal-alerts.md)
> - [Job Portal — Job Posting Detail](job-portal-detail.md)
> - Employer job posting (company area)

---

## Page: Job Portal — Colleague-to-Colleague Offers
- URL: https://freiburger-bund.com/en/job/open/c2c
- Type: product-spec
- Section: Job Portal
- Access: public
- Source: docs/product-knowledge/pages/job-portal-c2c.md
- Updated: 2026-09-21

### Purpose
Let healthcare professionals discover peer-shared job leads, express interest, bookmark offers, and publish their own colleague-to-colleague listings when relocating or referring openings within the community.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Portal shell and C2C tab
> 
> **What it does**
> 
> Shows the colleague-to-colleague catalog within Current Job Listings, with the same primary portal tabs and secondary open-positions tabs as job offers.
> 
> **User flow**
> 
> 1. User selects Colleague-to-Colleague from secondary tabs.
> 2. User sees hero, filters, and offer cards distinct from employer listings.
> 
> **Rules**
> 
> - C2C uses start-date filtering instead of employment-type filter.
> - Job forum shortcut available.
> 
> **States**
> 
> - Active Colleague-to-Colleague tab highlighted.
> 
> ---
> 
> ### Keyword search
> 
> **What it does**
> 
> Filters colleague offers by free-text keyword.
> 
> **User flow**
> 
> 1. User types in the search field.
> 2. Results update after debounce.
> 
> **Rules**
> 
> - Works alongside start-date and location filters.
> 
> **States**
> 
> - **Empty search:** all offers (subject to other filters).
> - **Active search:** filtered grid.
> 
> ---
> 
> ### Start date filter
> 
> **What it does**
> 
> Narrows offers by desired or available start date using a calendar range picker.
> 
> **User flow**
> 
> 1. User opens the start date control.
> 2. User selects a date or range.
> 3. Offer list refreshes; additional client-side date filtering may apply after load.
> 
> **Rules**
> 
> - Replaces employment-type filter used on job offers tab.
> - Selected range appears as a removable chip.
> 
> **States**
> 
> - **Any:** no start-date constraint (default label may show “Any”).
> - **Range set:** filtered results; chip visible.
> 
> ---
> 
> ### Location and radius filters
> 
> **What it does**
> 
> Filters offers by city, postal code, or state with optional radius for city/zip selections.
> 
> **User flow**
> 
> 1. User searches and selects a place.
> 2. User optionally sets radius.
> 3. Cards update to matching geography.
> 
> **Rules**
> 
> - Same radius rules as job offers: radius hidden for state-only selection.
> 
> **States**
> 
> - **No location:** unfiltered by geography.
> - **Location set:** geo-filtered results.
> 
> ---
> 
> ### Create offer entry
> 
> **What it does**
> 
> Opens a form for signed-in users to publish a new colleague-to-colleague listing.
> 
> **User flow**
> 
> 1. User clicks create offer (or equivalent CTA).
> 2. Guest is prompted to sign in.
> 3. Signed-in user completes the create form and submits.
> 4. User returns to the C2C list on success.
> 
> **Rules**
> 
> - Create flow requires authentication.
> - Success redirects back to catalog.
> 
> **States**
> 
> - **Guest:** sign-in prompt.
> - **Signed-in:** create form available.
> 
> ---
> 
> ### Create offer form
> 
> **What it does**
> 
> Collects details for a peer-shared opening: location, profession, specialization, position, organization, department, employer contact email, start date, external job link, and optional anonymous posting.
> 
> **User flow**
> 
> 1. User fills required fields (profession, position at minimum).
> 2. User toggles anonymous mode to hide poster identity on the card.
> 3. User submits; validation feedback appears for missing required fields.
> 4. On success, new offer appears in catalog after redirect.
> 
> **Rules**
> 
> - Profession and position are required; missing values show validation feedback.
> - Anonymous mode hides poster name/avatar on public cards.
> 
> **States**
> 
> - **Validation error:** inline or toast feedback; form remains open.
> - **Success:** redirect to C2C list.
> 
> ---
> 
> ### Offer card grid
> 
> **What it does**
> 
> Displays colleague offers in a responsive grid with profession category, title, organization, department, start date, location, and poster identity (unless anonymous).
> 
> **User flow**
> 
> 1. User scans cards.
> 2. User bookmarks or expresses interest from a card.
> 
> **Rules**
> 
> - Anonymous offers hide poster identifying information.
> - Cards differ visually from employer job offer cards.
> 
> **States**
> 
> - **Loading:** skeleton cards.
> - **Populated:** grid of offer cards.
> - **Empty:** no cards when no matches (no dedicated empty illustration).
> 
> ---
> 
> ### Bookmark toggle
> 
> **What it does**
> 
> Saves or removes a colleague offer from the user’s saved jobs collection.
> 
> **User flow**
> 
> 1. User clicks bookmark on a card.
> 2. Offer syncs with Saved Jobs tab.
> 
> **Rules**
> 
> - Guests prompted to sign in.
> 
> **States**
> 
> - Bookmarked vs not bookmarked indicators.
> 
> ---
> 
> ### Express interest / message colleague
> 
> **What it does**
> 
> Lets signed-in users signal interest in an offer and initiate contact with the posting colleague.
> 
> **User flow**
> 
> 1. User clicks interest or message action on a card.
> 2. Guest sees sign-in prompt.
> 3. Signed-in user submits interest; button may change to applied state.
> 
> **Rules**
> 
> - One interest expression per user per offer; reapplied state shown when already expressed.
> - Error feedback via toast on failure.
> 
> **States**
> 
> - **Not applied:** primary CTA active.
> - **Applied:** disabled or “Applied” label.
> - **Guest:** sign-in dialog.
> 
> ---
> 
> ### Pagination
> 
> **What it does**
> 
> Pages through large offer result sets.
> 
> **User flow**
> 
> 1. User moves between pages when results exceed one page.
> 
> **Rules**
> 
> - Same pagination pattern as job offers.
> 
> **States**
> 
> - Hidden on single page; visible on multi-page results.
> 
> ---
> 
> ### Active filter chips
> 
> **What it does**
> 
> Shows removable chips for keyword, start date, location, and radius with clear-all when multiple active.
> 
> **User flow**
> 
> 1. User removes chips individually or clears all.
> 
> **Rules**
> 
> - Dependent filters clear together when parent removed.
> 
> **States**
> 
> - Chips reflect current filter set.
> 
> ---
> 
> ### Job forum shortcut
> 
> **What it does**
> 
> Links to job forum discussions complementary to peer listings.
> 
> **User flow**
> 
> 1. User follows job forum link from the C2C area.
> 
> **Rules**
> 
> - Consistent placement with other open-positions pages.
> 
> **States**
> 
> - Always available.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Job Portal home preview → view all colleague offers
> - Secondary tab from Job Offers, Saved Jobs, or Job Alerts
> - Return from create offer form after submit
> - Direct URL
> 
> **Outbound**
> 
> - Create offer form (authenticated)
> - Saved Jobs tab (bookmarked C2C offers appear there)
> - Job Offers and Job Alerts tabs
> - Sign-in (guest actions)
> - Job forum
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Browse, search, filter; bookmark, interest, and create require sign-in |
> | Signed-in member | Bookmark, express interest, create offers; see applied state on own interactions |
> 
> ---
> 
> ## Important Business Rules
> 
> - Colleague-to-colleague offers are peer-shared, not employer-managed postings.
> - Anonymous posting hides poster identity on public cards but does not remove moderation obligations.
> - Interest expression is distinct from a formal job application on employer postings.
> - Start-date filter complements keyword and location; some date filtering may apply after initial load.
> - C2C saved items appear alongside saved employer jobs on the Saved Jobs tab.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — Home](job-portal.md)
> - [Job Portal — Job Offers Listings](job-portal-offers.md)
> - [Job Portal — Saved Jobs](job-portal-bookmarked.md)
> - [Job Portal — Job Posting Detail](job-portal-detail.md) (employer listings only)
> - Community portal (peer network context)

---

## Page: Job Portal — Saved Jobs
- URL: https://freiburger-bund.com/en/job/open/bookmarked
- Type: product-spec
- Section: Job Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/job-portal-bookmarked.md
- Updated: 2026-09-21

### Purpose
Give users a single place to review bookmarked employer job postings and saved colleague-to-colleague offers, with search and filter tools and drill-down views for each collection.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Portal shell and Saved Jobs tab
> 
> **What it does**
> 
> Shows the user’s saved job and C2C bookmarks within Current Job Listings secondary navigation.
> 
> **User flow**
> 
> 1. User selects Saved Jobs from secondary tabs.
> 2. User sees overview or drill-down layout depending on interaction.
> 
> **Rules**
> 
> - Expired employer jobs excluded from saved job results.
> - Combined count may reflect both jobs and C2C offers.
> 
> **States**
> 
> - Saved Jobs tab active.
> 
> ---
> 
> ### Search and filters on saved items
> 
> **What it does**
> 
> Applies keyword, employment type (for jobs), and location filters to the user’s saved collection—same controls as job offers where applicable.
> 
> **User flow**
> 
> 1. User adjusts filters.
> 2. Saved subset refreshes; filter chips and clear-all behave like listings catalog.
> 
> **Rules**
> 
> - Filtering applies only within saved items, not the full catalog.
> 
> **States**
> 
> - **No matches:** empty state within saved view.
> - **Matches:** filtered saved cards.
> 
> ---
> 
> ### Combined saved count
> 
> **What it does**
> 
> Displays total saved items across employer jobs and colleague offers.
> 
> **User flow**
> 
> 1. User reads count headline reflecting current filter scope.
> 
> **Rules**
> 
> - Count updates when filters change or items are bookmarked/unbookmarked elsewhere.
> 
> **States**
> 
> - Zero when nothing saved or nothing matches filters.
> 
> ---
> 
> ### Overview layout with horizontal previews
> 
> **What it does**
> 
> Default view showing separate horizontal scroll sections for saved employer jobs and saved C2C offers with section headings and per-section counts.
> 
> **User flow**
> 
> 1. User lands on Saved Jobs overview.
> 2. User scrolls horizontally within each section preview.
> 3. User clicks **See all** on a section to open full grid drill-down.
> 
> **Rules**
> 
> - Two distinct sections when both types have saved items.
> - Sections may hide when one type is empty.
> 
> **States**
> 
> - **Overview:** horizontal previews with see-all links.
> - **Drill-down:** full grid for jobs only or C2C only.
> 
> ---
> 
> ### Drill-down full grid
> 
> **What it does**
> 
> Expands one saved collection (jobs or C2C) into a full paginated grid matching the respective card type.
> 
> **User flow**
> 
> 1. User clicks see all on jobs or C2C section.
> 2. Full grid loads with back navigation to overview.
> 3. User uses pagination within the drill-down view.
> 
> **Rules**
> 
> - Back arrow returns to overview without losing portal tab context.
> - Separate pagination for jobs vs C2C in drill-down.
> 
> **States**
> 
> - **Jobs drill-down:** employer job cards with bookmark toggle.
> - **C2C drill-down:** colleague offer cards with interest and bookmark actions.
> 
> ---
> 
> ### Saved job cards
> 
> **What it does**
> 
> Renders bookmarked employer postings with bookmark control positioned for saved context; opens detail on click.
> 
> **User flow**
> 
> 1. User toggles bookmark to remove from saved list.
> 2. User opens job detail from card.
> 
> **Rules**
> 
> - Expired jobs not shown.
> - Toast feedback if detail URL unavailable.
> 
> **States**
> 
> - **Available:** card clickable to detail.
> - **Unavailable:** error feedback instead of navigation.
> 
> ---
> 
> ### Saved C2C cards
> 
> **What it does**
> 
> Shows bookmarked colleague offers with express interest and bookmark controls consistent with C2C catalog.
> 
> **User flow**
> 
> 1. User manages bookmark or expresses interest from saved C2C card.
> 
> **Rules**
> 
> - Applied interest state reflected on card.
> 
> **States**
> 
> - Same card states as C2C catalog (applied, bookmarked).
> 
> ---
> 
> ### My searches link
> 
> **What it does**
> 
> Provides quick access to saved search management from the saved jobs area.
> 
> **User flow**
> 
> 1. User clicks my searches to open saved search list.
> 
> **Rules**
> 
> - Requires sign-in for meaningful content.
> 
> **States**
> 
> - Link visible on saved jobs toolbar area.
> 
> ---
> 
> ### Loading and empty states
> 
> **What it does**
> 
> Communicates fetch progress and absence of saved items.
> 
> **User flow**
> 
> 1. User waits during load (horizontal skeletons on overview).
> 2. User sees empty guidance when no saved items match.
> 
> **Rules**
> 
> - Guests may see empty collections until signed in and bookmarks exist.
> 
> **States**
> 
> - **Loading:** skeleton placeholders.
> - **Empty:** no saved items message.
> - **Populated:** overview or drill-down content.
> 
> ---
> 
> ### Job forum shortcut
> 
> **What it does**
> 
> Links to job forum from saved jobs context.
> 
> **User flow**
> 
> 1. User follows job forum link.
> 
> **Rules**
> 
> - Consistent with other open-positions pages.
> 
> **States**
> 
> - Always available.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Secondary tab from Job Offers, Colleague-to-Colleague, or Job Alerts
> - Bookmark action on any job or C2C card (redirect optional)
> - Direct URL
> 
> **Outbound**
> 
> - Job posting detail (saved employer jobs)
> - Overview ↔ drill-down within Saved Jobs
> - My searches
> - Other open-positions tabs
> - Sign-in (guest bookmark management)
> - Job forum
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Page loads; saved collections empty until signed in; bookmark actions prompt sign-in |
> | Signed-in member | Full saved jobs and C2C lists; bookmark and interest actions active |
> 
> ---
> 
> ## Important Business Rules
> 
> - Saved employer jobs and saved C2C offers share one tab but separate overview sections and drill-downs.
> - Expired employer postings drop out of saved job results automatically.
> - Bookmarking is per-user; not visible to other users as a public list.
> - Filters narrow within saved items only.
> - Removing bookmark on this page removes item from collection immediately.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — Job Offers Listings](job-portal-offers.md)
> - [Job Portal — Colleague-to-Colleague](job-portal-c2c.md)
> - [Job Portal — Job Posting Detail](job-portal-detail.md)
> - [Job Portal — Job Alerts](job-portal-alerts.md)
> - Global job bookmarks (bookmarks area) — **Unknown / requires product clarification** whether global bookmarks duplicate this tab

---

## Page: Job Portal — Job Alerts
- URL: https://freiburger-bund.com/en/job/open/alerts
- Type: product-spec
- Section: Job Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/job-portal-alerts.md
- Updated: 2026-09-21

### Purpose
Let users define search criteria subscriptions that surface matching new job postings, manage active alerts, and browse a feed of jobs that match existing alert rules.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Portal shell and Job Alerts tab
> 
> **What it does**
> 
> Places alert creation, feed, and management inside Current Job Listings with standard portal and secondary tab navigation.
> 
> **User flow**
> 
> 1. User selects Job Alerts secondary tab.
> 2. User sees alert creation panel and either empty guidance or matched job feed.
> 
> **Rules**
> 
> - Job forum shortcut available.
> 
> **States**
> 
> - Job Alerts tab active.
> 
> ---
> 
> ### Alert creation panel
> 
> **What it does**
> 
> Provides filter fields—keyword, employment type, location, radius—to define a new alert subscription.
> 
> **User flow**
> 
> 1. User fills one or more filter fields.
> 2. User clicks create first alert or create alert.
> 3. Guest is prompted to sign in; signed-in user creates subscription.
> 
> **Rules**
> 
> - At least one filter field required; empty submission shows validation feedback.
> - Same filter concepts as job offers listings.
> 
> **States**
> 
> - **Guest:** sign-in prompt on create.
> - **Valid submission:** alert added; feed may refresh.
> 
> ---
> 
> ### No alerts yet empty state
> 
> **What it does**
> 
> Shows instructional empty panel with icon and guidance when user has no alerts configured.
> 
> **User flow**
> 
> 1. New or guest user sees encouragement to create first alert.
> 2. User follows creation panel above.
> 
> **Rules**
> 
> - Distinct from “alerts exist but no matches” state.
> 
> **States**
> 
> - Bell or instructional empty panel visible.
> 
> ---
> 
> ### Matched jobs feed
> 
> **What it does**
> 
> When user has active alerts, displays employer job cards for postings matching alert criteria.
> 
> **User flow**
> 
> 1. User scrolls feed of matched jobs.
> 2. User opens a card to view posting detail.
> 3. User identifies alert source via badges on cards.
> 
> **Rules**
> 
> - Feed driven by user’s alert subscriptions, not full catalog search.
> - Alert match badge and alert name(s) shown on matched cards when applicable.
> 
> **States**
> 
> - **Loading:** skeleton cards for feed.
> - **Populated:** job cards with alert indicators.
> - **Feed error:** error banner with message.
> - **No matches:** falls back to creation guidance even when alerts exist.
> 
> ---
> 
> ### Manage alerts modal
> 
> **What it does**
> 
> Lets signed-in users view all subscriptions, toggle alerts on/off, delete alerts, and start creating a new alert from the modal.
> 
> **User flow**
> 
> 1. User clicks manage alerts.
> 2. Modal lists active subscriptions with filter tag summary per alert.
> 3. User toggles, deletes, or chooses create new alert (closes modal, stays on alerts page).
> 
> **Rules**
> 
> - Requires authentication.
> - Empty list message when no alerts configured inside modal.
> 
> **States**
> 
> - **Modal open:** list of subscriptions with controls.
> - **All disabled/deleted:** empty modal state.
> 
> ---
> 
> ### Alert toggle per subscription
> 
> **What it does**
> 
> Enables or pauses individual alert subscriptions without deleting criteria.
> 
> **User flow**
> 
> 1. User flips on/off control on a subscription.
> 2. Feed updates to reflect active alerts only.
> 
> **Rules**
> 
> - Paused alerts do not contribute to match feed.
> 
> **States**
> 
> - On vs off per subscription row.
> 
> ---
> 
> ### Delete alert
> 
> **What it does**
> 
> Permanently removes an alert subscription.
> 
> **User flow**
> 
> 1. User deletes an alert from manage modal.
> 2. Subscription removed; feed recalculates.
> 
> **Rules**
> 
> - Deletion immediate; no undo stated in UI.
> 
> **States**
> 
> - Row removed from list on success.
> 
> ---
> 
> ### Link from save search
> 
> **What it does**
> 
> When user saves a search from job offers with “notify me of similar jobs,” an alert may be created with the same criteria.
> 
> **User flow**
> 
> 1. User saves search on offers page with notification checked.
> 2. Corresponding alert appears in manage alerts and may surface in feed.
> 
> **Rules**
> 
> - Cross-feature linking between saved searches and alerts.
> 
> **States**
> 
> - Alert visible in manage modal after linked save.
> 
> ---
> 
> ### Loading and error states
> 
> **What it does**
> 
> Handles asynchronous load of alert list and match feed.
> 
> **User flow**
> 
> 1. User sees skeletons while alerts and feed load.
> 2. On feed error, user reads banner message and may retry by refresh.
> 
> **Rules**
> 
> - Feed error does not block alert creation panel.
> 
> **States**
> 
> - **Loading:** skeleton placeholders.
> - **Error:** red or prominent error banner.
> - **Success:** feed or empty guidance.
> 
> ---
> 
> ### Job forum shortcut
> 
> **What it does**
> 
> Links to job forum from alerts context.
> 
> **User flow**
> 
> 1. User follows job forum link.
> 
> **Rules**
> 
> - Consistent placement with open-positions pages.
> 
> **States**
> 
> - Always available.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Secondary tab from Job Offers, Colleague-to-Colleague, or Saved Jobs
> - Save search with notification from job offers listings
> - Direct URL
> 
> **Outbound**
> 
> - Job posting detail from matched feed cards
> - Manage alerts modal (overlay)
> - Other open-positions tabs
> - Sign-in (guest create/manage)
> - Job forum
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Can view UI shell and creation panel; create and manage require sign-in |
> | Signed-in member | Create alerts, manage subscriptions, view personalized match feed |
> 
> ---
> 
> ## Important Business Rules
> 
> - At least one filter criterion required to create an alert.
> - Alerts apply to employer job postings, not colleague-to-colleague offers (**Unknown / requires product clarification** if C2C alerts exist elsewhere).
> - Paused alerts stop matching until re-enabled.
> - Feed empty with active alerts means no current matches, not necessarily misconfiguration.
> - Alert criteria should align with job offers filter semantics for user expectations.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — Job Offers Listings](job-portal-offers.md) (save search + notify)
> - [Job Portal — Job Posting Detail](job-portal-detail.md)
> - [Job Portal — Saved Jobs](job-portal-bookmarked.md)
> - Notification preferences (account settings) — **Unknown / requires product clarification** for email vs in-app alert delivery

---

## Page: Job Portal — Job Posting Detail
- URL: https://freiburger-bund.com/en/job/example-job-posting
- Type: product-spec
- Section: Job Portal
- Access: public
- Source: docs/product-knowledge/pages/job-portal-detail.md
- Updated: 2026-09-21

### Purpose
Present the full content of a single job posting so candidates can evaluate the role, download attachments, bookmark or favorite the job, share it, and submit an application with resume and optional cover letter.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb and page header
> 
> **What it does**
> 
> Shows navigation context (Jobs → current job title) and a details subtitle; preserves search query parameters from listings when returning.
> 
> **User flow**
> 
> 1. User arrives from listings, alerts, applications, or direct link.
> 2. User uses breadcrumb to return toward jobs area.
> 
> **Rules**
> 
> - Invalid or unknown job slug shows not-found page.
> - Listing search parameters may persist in breadcrumb back link.
> 
> **States**
> 
> - **Valid job:** breadcrumb and title populated.
> - **Invalid slug:** not-found.
> 
> ---
> 
> ### Hero summary card
> 
> **What it does**
> 
> Highlights company logo, job title, company name, location with map pin, expiry information, and classification tags.
> 
> **User flow**
> 
> 1. User reads primary job identity at top of page.
> 2. User scans tags for employment type, position type, specialization, career group.
> 
> **Rules**
> 
> - Expiry shown as expired label, “expires in X days” within 30 days, or relative date otherwise.
> - Requirements may appear as a short preview snippet in hero area.
> 
> **States**
> 
> - **Active posting:** normal expiry display.
> - **Expired:** expired label; apply disabled.
> - **Preview mode:** apply disabled (**Unknown / requires product clarification** for preview audience).
> 
> ---
> 
> ### Bookmark control
> 
> **What it does**
> 
> Adds or removes the job from the user’s saved jobs.
> 
> **User flow**
> 
> 1. User toggles bookmark in hero area.
> 2. Guest sees sign-in prompt.
> 
> **Rules**
> 
> - Syncs with Saved Jobs tab collection.
> 
> **States**
> 
> - Bookmarked vs not bookmarked.
> 
> ---
> 
> ### Apply action
> 
> **What it does**
> 
> Opens a multi-step application dialog for signed-in users to select resume, optional cover letter, review, and submit.
> 
> **User flow**
> 
> 1. User clicks Apply.
> 2. Guest sees sign-in prompt.
> 3. Signed-in user completes three steps and submits.
> 4. Button changes to Applied after success.
> 
> **Rules**
> 
> - Apply disabled for expired jobs, preview jobs, and when user already applied.
> - Job owner sees Manage instead of Apply, linking to employer postings management.
> - Imported or external jobs show Apply on [source] opening external URL in new tab instead of internal dialog.
> - Optional address parameter may auto-open apply dialog on load; auto-open parameter stripped after load.
> - Optional new-document parameter pre-selects a freshly built CV in step one.
> 
> **States**
> 
> - **Apply available:** primary apply button.
> - **Applied:** disabled applied state.
> - **External:** outbound apply link.
> - **Owner:** manage link for posting owner.
> - **Expired/preview:** apply disabled.
> 
> ---
> 
> ### Application dialog — step 1 (resume)
> 
> **What it does**
> 
> Requires user to select an existing CV, upload a new file, preview or delete documents, or launch CV builder (returns with new document pre-selected).
> 
> **User flow**
> 
> 1. User selects or uploads resume.
> 2. User may open CV builder in apply flow; on save, returns here with new CV selected.
> 3. User advances when resume selected.
> 
> **Rules**
> 
> - Resume required before advancing; error banner if missing.
> - Delete may require confirmation.
> - Profile skills attached to application when available.
> 
> **States**
> 
> - **No selection:** advance blocked with error.
> - **Selected:** preview available; advance enabled.
> 
> ---
> 
> ### Application dialog — step 2 (cover letter)
> 
> **What it does**
> 
> Optional selection or upload of cover letter, or explicit skip.
> 
> **User flow**
> 
> 1. User selects existing letter, uploads new, or skips.
> 2. User advances to review.
> 
> **Rules**
> 
> - Cover letter optional; step labeled accordingly.
> 
> **States**
> 
> - Skipped vs document selected.
> 
> ---
> 
> ### Application dialog — step 3 (review and submit)
> 
> **What it does**
> 
> Summarizes chosen documents and confirms submission.
> 
> **User flow**
> 
> 1. User reviews selections.
> 2. User submits application.
> 3. Success feedback; dialog closes; page shows Applied state.
> 
> **Rules**
> 
> - Progress indicator shows required vs optional steps across all three steps.
> 
> **States**
> 
> - **Submit success:** toast and applied button state.
> - **Submit failure:** error feedback in dialog.
> 
> ---
> 
> ### Overview, requirements, and company sections
> 
> **What it does**
> 
> Renders full job description, requirements list, optional “why join [company]” section when company profile exists, and skills list.
> 
> **User flow**
> 
> 1. User scrolls markdown-formatted overview and requirements.
> 2. User reads company pitch and skills when present.
> 
> **Rules**
> 
> - Content sourced from posting and linked company profile.
> - Sections omitted when data absent.
> 
> **States**
> 
> - **Full content:** all sections populated.
> - **Partial:** missing sections hidden.
> 
> ---
> 
> ### Attachments download
> 
> **What it does**
> 
> Lists downloadable files attached to the posting.
> 
> **User flow**
> 
> 1. User downloads attachments from dedicated section.
> 
> **Rules**
> 
> - Only shown when attachments exist.
> 
> **States**
> 
> - **With attachments:** download links or buttons.
> - **None:** section hidden.
> 
> ---
> 
> ### More actions menu
> 
> **What it does**
> 
> Provides favorite job and share job actions beyond bookmark.
> 
> **User flow**
> 
> 1. User opens more menu.
> 2. User favorites or copies/shares job link.
> 
> **Rules**
> 
> - Favorite may require sign-in (**Unknown / requires product clarification** if distinct from bookmark).
> 
> **States**
> 
> - Menu available on valid active postings.
> 
> ---
> 
> ### Recommended similar jobs
> 
> **What it does**
> 
> Shows a carousel of related postings below main content.
> 
> **User flow**
> 
> 1. User browses recommendations and opens another posting.
> 
> **Rules**
> 
> - Hidden when no recommendations available.
> 
> **States**
> 
> - **Has recommendations:** carousel visible.
> - **None:** section omitted.
> 
> ---
> 
> ### Visit tracking
> 
> **What it does**
> 
> Records that the posting was viewed for analytics and employer insights.
> 
> **User flow**
> 
> 1. User loads page; view counted in background.
> 
> **Rules**
> 
> - Invisible to user; no UI change.
> 
> **States**
> 
> - N/A (background behavior).
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Job offers listings, alerts feed, saved jobs, applications list, employer manage link, direct URL
> - CV builder return with apply flow and new document parameter
> - Auto-open apply via address parameter
> 
> **Outbound**
> 
> - Jobs listings (breadcrumb)
> - CV builder (from apply step 1)
> - External apply URL (imported jobs)
> - Employer manage postings (job owner)
> - Company public profile (from company name links where present)
> - Similar job detail pages
> - Sign-in (guest apply/bookmark)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access; apply, bookmark, favorite require sign-in |
> | Signed-in candidate | Apply once; bookmark; see applied state after submission |
> | Job posting owner | Manage instead of apply; links to employer postings area |
> | Employer (non-owner) | Same as candidate unless **Unknown / requires product clarification** |
> 
> ---
> 
> ## Important Business Rules
> 
> - One application per user per posting; reapplied state after submission.
> - Internal apply requires resume; cover letter optional.
> - External/imported jobs bypass internal application dialog.
> - Expired and preview postings cannot receive new internal applications.
> - CV builder launched from apply returns to same posting with apply dialog reopened.
> - Invalid slugs must not expose partial posting data.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — Job Offers Listings](job-portal-offers.md)
> - [Job Portal — User Applications](job-portal-applications.md)
> - [Job Portal — CV Builder](job-portal-cv-builder.md)
> - [Job Portal — Application Tools](job-portal-tools.md)
> - Employer postings management (company area)
> - Company public profile

---

## Page: Job Portal — User Applications
- URL: https://freiburger-bund.com/en/job/applications
- Type: product-spec
- Section: Job Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/job-portal-applications.md
- Updated: 2026-09-21

### Purpose
Give signed-in candidates a consolidated view of jobs they have applied to, with status tracking, sorting, and filtering so they can follow progress from submission through hiring outcomes.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb and page header
> 
> **What it does**
> 
> Identifies the page as active applications with supportive subtitle about staying updated on progress.
> 
> **User flow**
> 
> 1. User opens applications from job portal navigation or direct link.
> 2. User reads page title and subtitle.
> 
> **Rules**
> 
> - Distinct from employer-side applicant review in company area.
> 
> **States**
> 
> - Header always visible.
> 
> ---
> 
> ### Application list
> 
> **What it does**
> 
> Shows one card per application with company logo, job title, company name, color-coded status badge, and application date.
> 
> **User flow**
> 
> 1. User scans cards for status and dates.
> 2. User clicks job title to open posting detail.
> 3. User clicks company name to open company public profile when linked.
> 
> **Rules**
> 
> - Data scoped to current signed-in user only.
> - Guests see empty list (**Unknown / requires product clarification** whether guests are redirected or see sign-in prompt).
> 
> **States**
> 
> - **Populated:** card list visible.
> - **Empty:** empty state when no applications match filters.
> - **Loading:** skeleton cards.
> 
> ---
> 
> ### Status filter
> 
> **What it does**
> 
> Narrows list by application pipeline stage.
> 
> **User flow**
> 
> 1. User selects filter: All, Applied, Review, Interview, Hired, or Rejected.
> 2. List refreshes; page resets to first page.
> 
> **Rules**
> 
> - Filter changes reset pagination to page one.
> 
> **States**
> 
> - Active filter highlighted.
> 
> ---
> 
> ### Sort order
> 
> **What it does**
> 
> Orders applications by newest or oldest application date.
> 
> **User flow**
> 
> 1. User toggles sort preference.
> 2. Card order updates.
> 
> **Rules**
> 
> - Sort applies within current status filter.
> 
> **States**
> 
> - Newest vs oldest active sort.
> 
> ---
> 
> ### Status badges
> 
> **What it does**
> 
> Communicates pipeline stage with color-coded labels on each card.
> 
> **User flow**
> 
> 1. User reads badge at a glance on each card.
> 
> **Rules**
> 
> - Status values driven by employer/recruiter updates on backend.
> - Exact color mapping is presentation detail; stages are Applied, Review, Interview, Hired, Rejected.
> 
> **States**
> 
> - One badge per card reflecting current status.
> 
> ---
> 
> ### Pagination
> 
> **What it does**
> 
> Shows ten applications per page with page navigation when needed.
> 
> **User flow**
> 
> 1. User moves between pages when applications exceed ten.
> 
> **Rules**
> 
> - Page size fixed at ten per page.
> 
> **States**
> 
> - **Single page:** pagination hidden.
> - **Multiple pages:** controls visible.
> 
> ---
> 
> ### Empty state
> 
> **What it does**
> 
> Explains when user has no applications or none match current filter.
> 
> **User flow**
> 
> 1. User sees guidance to browse jobs when list empty.
> 
> **Rules**
> 
> - Distinct messaging for filtered-empty vs never-applied **Unknown / requires product clarification** for exact copy.
> 
> **States**
> 
> - Empty illustration or message with link to job search.
> 
> ---
> 
> ### Loading state
> 
> **What it does**
> 
> Shows skeleton cards while application data loads.
> 
> **User flow**
> 
> 1. User waits during initial fetch or filter change.
> 
> **Rules**
> 
> - Skeleton count approximates card layout.
> 
> **States**
> 
> - Skeleton placeholders until data arrives.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Job portal navigation (applications entry)
> - Post-apply success from job detail (manual navigation)
> - Direct URL
> 
> **Outbound**
> 
> - Job posting detail (from job title on card)
> - Company public profile (from company name)
> - Job offers listings (from empty state CTA)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Empty or no data; may need sign-in to view (**Unknown / requires product clarification**) |
> | Signed-in candidate | Full personal application history with filters |
> 
> Employers review applications in the company area, not on this candidate-facing page.
> 
> ---
> 
> ## Important Business Rules
> 
> - Applications list is private to the submitting user.
> - Status updates reflect employer actions; candidates cannot self-change status on this page.
> - Re-applying to same job blocked at detail page, not duplicated here.
> - Filtering and sorting are client-facing views only; underlying records unchanged.
> - Application date reflects submission timestamp.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — Job Posting Detail](job-portal-detail.md) (apply flow)
> - [Job Portal — Job Offers Listings](job-portal-offers.md)
> - Employer current applications (company area)
> - Notification preferences for application updates — **Unknown / requires product clarification**

---

## Page: Job Portal — CV Hub
- URL: https://freiburger-bund.com/en/job/cv
- Type: product-spec
- Section: Job Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/job-portal-cv.md
- Updated: 2026-09-21

### Purpose
Let users upload existing CV files, manage certificates and credentials, detect in-progress CV drafts, and launch the CV builder—all from a dedicated CV management entry outside the portal tab shell.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb and page header
> 
> **What it does**
> 
> Orients user within the job area with upload and manage CV messaging.
> 
> **User flow**
> 
> 1. User opens CV hub from job navigation or tools cross-links.
> 2. User reads header describing upload and management purpose.
> 
> **Rules**
> 
> - Standalone page layout (not open-positions secondary tabs).
> 
> **States**
> 
> - Header and breadcrumb always visible.
> 
> ---
> 
> ### Build CV hero card
> 
> **What it does**
> 
> Promotes structured CV creation via the builder with dynamic label based on draft state.
> 
> **User flow**
> 
> 1. User sees build CV card with icon.
> 2. If local in-progress draft detected, CTA shows continue/edit; otherwise start.
> 3. User opens CV builder.
> 
> **Rules**
> 
> - Draft detection uses local saved progress.
> - Routes to CV builder on action.
> 
> **States**
> 
> - **No draft:** start messaging.
> - **Draft in progress:** continue messaging.
> 
> ---
> 
> ### Upload CV card
> 
> **What it does**
> 
> Opens file upload dialog for adding an existing CV document to the user’s library.
> 
> **User flow**
> 
> 1. User clicks upload CV.
> 2. Guest may be prompted to sign in.
> 3. User completes upload dialog.
> 
> **Rules**
> 
> - Upload requires authentication for persistence.
> 
> **States**
> 
> - **Guest:** sign-in prompt.
> - **Signed-in:** upload dialog opens.
> 
> ---
> 
> ### Upload dialog validation
> 
> **What it does**
> 
> Collects display filename and single file with size limit enforcement.
> 
> **User flow**
> 
> 1. User enters filename (required).
> 2. User selects exactly one file.
> 3. User submits; success or failure feedback shown.
> 
> **Rules**
> 
> - Filename required.
> - One file only per upload.
> - Maximum file size ten megabytes.
> - Toast on success or failure.
> 
> **States**
> 
> - **Validation error:** inline or toast feedback.
> - **Success:** file appears in list after refresh.
> 
> ---
> 
> ### Manage credentials card
> 
> **What it does**
> 
> Entry point for uploading and managing professional certificates separate from CV PDFs.
> 
> **User flow**
> 
> 1. User clicks manage credentials.
> 2. User follows certificate upload flow (**Unknown / requires product clarification** for inline vs separate view).
> 
> **Rules**
> 
> - Distinct from CV documents in business intent.
> 
> **States**
> 
> - Card always visible on hub.
> 
> ---
> 
> ### Uploaded files table
> 
> **What it does**
> 
> Lists user’s uploaded and generated documents with search, sort, pagination, preview, and actions.
> 
> **User flow**
> 
> 1. User searches by filename.
> 2. User sorts by newest, oldest, name A–Z, or Z–A.
> 3. User clicks row to preview; uses actions menu for download, delete, etc.
> 4. User paginates when list is long.
> 
> **Rules**
> 
> - Internal singleton draft entries hidden from list.
> - Desktop table and mobile-optimized row layout.
> - Signed-in user sees own files only.
> 
> **States**
> 
> - **Loading:** skeleton rows.
> - **Populated:** table or mobile list.
> - **Empty:** empty table messaging within list component.
> - **Guest:** empty list.
> 
> ---
> 
> ### File preview
> 
> **What it does**
> 
> Opens preview when user selects a file from the list.
> 
> **User flow**
> 
> 1. User clicks row or preview action.
> 2. Document preview displays.
> 
> **Rules**
> 
> - Preview supported for uploaded document types **Unknown / requires product clarification** for full format list.
> 
> **States**
> 
> - Preview overlay or panel open.
> 
> ---
> 
> ### File actions menu
> 
> **What it does**
> 
> Provides preview, download, delete, and related per-file actions.
> 
> **User flow**
> 
> 1. User opens actions on desktop inline or mobile overflow menu.
> 2. User performs action; delete may require confirmation.
> 
> **Rules**
> 
> - Delete removes file from user library.
> 
> **States**
> 
> - Actions available per row when file exists.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Job portal tools cross-links
> - CV builder save redirect (may go to documents tab instead — see tools spec)
> - Direct URL
> 
> **Outbound**
> 
> - CV builder
> - Document preview (inline)
> - Sign-in (guest upload)
> - Application tools documents tab (related document library)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Can view page shell; uploads and file list empty or gated |
> | Signed-in member | Upload, list, preview, delete own CV and credential files |
> 
> ---
> 
> ## Important Business Rules
> 
> - CV hub focuses on file library and builder entry; distinct from portal open-positions tabs.
> - Draft CV progress may exist locally before account save.
> - Generated CVs from builder appear in document library after submit.
> - Ten megabyte upload limit enforced on manual uploads.
> - Singleton internal draft records excluded from user-visible file list.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — CV Builder](job-portal-cv-builder.md)
> - [Job Portal — Application Tools](job-portal-tools.md) (documents tab)
> - [Job Portal — Job Posting Detail](job-portal-detail.md) (apply with CV selection)
> - Individual CV view by identifier — **Unknown / requires product clarification** whether `/job/cv/{id}` is user-facing detail or redirect

---

## Page: Job Portal — CV Builder
- URL: https://freiburger-bund.com/en/job/cv/builder
- Type: product-spec
- Section: Job Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/job-portal-cv-builder.md
- Updated: 2026-09-21

### Purpose
Guide healthcare professionals through a structured multi-step form to create a professional CV with live preview, profile sync, auto-save, and PDF generation for job applications or document library storage.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Four-step stepper
> 
> **What it does**
> 
> Organizes CV creation into General, Education, Experience, and Skills steps with progress indicator and previous/next navigation.
> 
> **User flow**
> 
> 1. User completes General step and clicks Next.
> 2. User progresses through Education and Experience with validation at each advance.
> 3. User finishes on Skills step with filename and submit.
> 
> **Rules**
> 
> - Cannot skip ahead without validating current step.
> - Stepper icons clickable only with same validation rules as Next.
> - Layout respects right-to-left reading direction for Arabic.
> 
> **States**
> 
> - Active step highlighted; completed steps marked.
> 
> ---
> 
> ### Toolbar — update from profile
> 
> **What it does**
> 
> Pulls latest account profile data into the CV form after user confirmation.
> 
> **User flow**
> 
> 1. User clicks update from profile.
> 2. User confirms in dialog.
> 3. Form fields refresh from profile.
> 
> **Rules**
> 
> - Overwrites current form values with profile data on confirm.
> - Requires signed-in account with profile data.
> 
> **States**
> 
> - Confirmation dialog before overwrite.
> 
> ---
> 
> ### Toolbar — save to profile
> 
> **What it does**
> 
> Pushes current CV form data back to the user’s account profile after confirmation.
> 
> **User flow**
> 
> 1. User clicks save to profile.
> 2. User confirms.
> 3. Profile updated from CV fields.
> 
> **Rules**
> 
> - Reverse sync of update from profile; confirmation required.
> 
> **States**
> 
> - Success feedback after save.
> 
> ---
> 
> ### Live PDF preview
> 
> **What it does**
> 
> Shows real-time rendered preview of CV as user edits.
> 
> **User flow**
> 
> 1. User edits fields while preview updates alongside form.
> 
> **Rules**
> 
> - Preview reflects current step content accumulated so far.
> 
> **States**
> 
> - Preview panel visible throughout builder.
> 
> ---
> 
> ### Auto-save draft
> 
> **What it does**
> 
> Persists in-progress CV to server and local storage on debounced changes.
> 
> **User flow**
> 
> 1. User edits fields; draft saves automatically in background.
> 2. User may resume later from CV hub or tools entry detecting local draft.
> 
> **Rules**
> 
> - Requires account for server persistence; local draft may exist before full save.
> - Debounced to avoid excessive saves.
> 
> **States**
> 
> - **Saving:** background persistence.
> - **Saved:** resume available on return.
> 
> ---
> 
> ### Step 1 — General (personal information)
> 
> **What it does**
> 
> Collects profile photo, honorifics, name, email, phone, date of birth, place of birth, nationality, address, gender, and professional summary.
> 
> **User flow**
> 
> 1. User uploads required profile photo.
> 2. User completes personal and summary fields.
> 3. User advances after step validation.
> 
> **Rules**
> 
> - Profile photo required.
> - Step validation scrolls to first error on failure.
> 
> **States**
> 
> - Validation errors on required fields.
> 
> ---
> 
> ### Step 2 — Education
> 
> **What it does**
> 
> Captures repeatable university entries, internships, and dissertation/thesis entries with program, institution, dates, city, and country.
> 
> **User flow**
> 
> 1. User adds one or more education blocks.
> 2. User advances after validation.
> 
> **Rules**
> 
> - Repeatable sections with add/remove per entry.
> - Validation before leaving step.
> 
> **States**
> 
> - Empty repeatable sections allowed if validation permits **Unknown / requires product clarification** for minimum entries.
> 
> ---
> 
> ### Step 3 — Experience
> 
> **What it does**
> 
> Records medical training (including currently in training), teaching activities, other activities, memberships, and publications.
> 
> **User flow**
> 
> 1. User fills repeatable training and teaching sections and free-text or repeatable publication fields.
> 2. User advances after validation.
> 
> **Rules**
> 
> - Medical training supports “currently in training” flag.
> - Mix of repeatable and free-text sections.
> 
> **States**
> 
> - Validation errors highlight missing required training fields if any.
> 
> ---
> 
> ### Step 4 — Skills and finish
> 
> **What it does**
> 
> Captures language skills and digital/other skills with proficiency levels, CV filename, and final submit.
> 
> **User flow**
> 
> 1. User adds language and skill entries with proficiency.
> 2. User enters CV filename.
> 3. User submits to generate PDF and save document.
> 
> **Rules**
> 
> - Submit generates PDF, uploads, and marks document as generated type.
> - Filename required for submit.
> 
> **States**
> 
> - **Submit in progress:** loading on submit action.
> - **Success:** redirect per save mode (see below).
> 
> ---
> 
> ### Submit outcomes
> 
> **What it does**
> 
> Routes user after successful PDF generation depending on entry context.
> 
> **User flow**
> 
> 1. **Normal save:** user redirected to Application Tools documents tab with success toast.
> 2. **Apply-flow save:** user redirected to job posting detail with apply dialog auto-open and new CV pre-selected.
> 
> **Rules**
> 
> - Apply-flow entered from job detail apply step.
> - Normal save from CV hub or tools entry.
> 
> **States**
> 
> - Success toast on normal save path.
> - Apply dialog open on apply-flow path.
> 
> ---
> 
> ### Previous and next navigation
> 
> **What it does**
> 
> Moves between steps with step counter display.
> 
> **User flow**
> 
> 1. User clicks Previous to go back without losing data.
> 2. User clicks Next to validate and advance.
> 
> **Rules**
> 
> - Next triggers validation on current step only.
> 
> **States**
> 
> - First step hides or disables Previous.
> - Last step shows Submit instead of Next.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - CV hub build card
> - Application tools CV creator
> - Job detail apply dialog — build new CV
> - Direct URL
> 
> **Outbound**
> 
> - Application tools documents tab (normal save)
> - Job posting detail with apply dialog (apply-flow save)
> - Sign-in prompt if save attempted without account
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | May browse form; persistence and submit effectively require account |
> | Signed-in member | Full auto-save, profile sync, submit, and document library integration |
> 
> ---
> 
> ## Important Business Rules
> 
> - Profile photo required before valid completion.
> - Step order enforced; no skipping invalid steps.
> - Generated CV stored as generated document type in library.
> - Apply-flow must return user to same job with resume pre-selected.
> - Update from profile and save to profile are explicit two-way sync operations with confirmation.
> - Arabic locale uses RTL-aware stepper layout.
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — CV Hub](job-portal-cv.md)
> - [Job Portal — Application Tools](job-portal-tools.md)
> - [Job Portal — Job Posting Detail](job-portal-detail.md) (apply integration)
> - Account profile settings (source for profile sync)

---

## Page: Job Portal — Application Tools
- URL: https://freiburger-bund.com/en/job/tools
- Type: product-spec
- Section: Job Portal
- Access: authenticated
- Source: docs/product-knowledge/pages/job-portal-tools.md
- Updated: 2026-09-21

### Purpose
Provide a dedicated area for managing application documents, starting CV and motivation letter workflows, and maintaining certificates—supporting job seekers from document creation through reuse in applications.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> Covers:
> 
> - Documents library (`/job/tools/documents`)
> - CV Creator landing (`/job/tools/cv-creator`)
> - Motivation Letter landing (`/job/tools/motivation-letter`)
> - Motivation Letter builder (`/job/tools/motivation-letter/builder`)
> 
> ## Features
> 
> ### Portal shell and tools navigation
> 
> **What it does**
> 
> Wraps application tools with primary tabs (All · Current Job Listings · Job Application Tools) and secondary tabs (Documents · CV Creator · Motivation Letter).
> 
> **User flow**
> 
> 1. User selects Job Application Tools primary tab.
> 2. User switches secondary tab for documents, CV creator, or motivation letter.
> 
> **Rules**
> 
> - Tools index redirects to Documents tab by default.
> - Legacy tab query parameters redirect to path-based routes.
> - Job forum shortcut on tool pages.
> 
> **States**
> 
> - Active primary and secondary tabs highlighted.
> 
> ---
> 
> ## Documents tab
> 
> ### Documents introduction
> 
> **What it does**
> 
> Explains that users can manage CVs, motivation letters, and certificates in one library.
> 
> **User flow**
> 
> 1. User reads intro copy at top of documents tab.
> 
> **Rules**
> 
> - Default landing sub-tab under Application Tools.
> 
> **States**
> 
> - Intro always visible above list.
> 
> ---
> 
> ### Certificate upload zone
> 
> **What it does**
> 
> Dashed upload area for dragging or selecting certificate files.
> 
> **User flow**
> 
> 1. User uploads certificates via zone or file picker.
> 2. Guest may be prompted to sign in.
> 
> **Rules**
> 
> - Adds to same document library as CVs and letters.
> 
> **States**
> 
> - **Guest:** sign-in prompt on upload attempt.
> - **Signed-in:** upload proceeds.
> 
> ---
> 
> ### Document filter bar
> 
> **What it does**
> 
> Filters library by filename search, category (All, CV, Certificate, Motivation letter), date range, and sort order (newest, oldest, A–Z, Z–A).
> 
> **User flow**
> 
> 1. User applies filters and sort.
> 2. Document list refreshes.
> 
> **Rules**
> 
> - Category filter narrows document type.
> - Date range picker limits by upload or generation date.
> 
> **States**
> 
> - Filter chips or controls reflect active criteria.
> 
> ---
> 
> ### Document list
> 
> **What it does**
> 
> Shows filename, source badge (Uploaded vs Generated), preview on row click, and download, rename, delete actions.
> 
> **User flow**
> 
> 1. User clicks row to preview.
> 2. User uses inline actions on desktop or overflow menu on mobile.
> 
> **Rules**
> 
> - Generated documents originate from CV or motivation letter builders.
> - Pagination when list exceeds one page.
> 
> **States**
> 
> - **Loading:** skeleton rows.
> - **Populated:** list with badges.
> - **Empty:** dedicated empty state (see below).
> 
> ---
> 
> ### Documents empty state
> 
> **What it does**
> 
> Shows illustration and guidance when no documents exist, with CTA to CV builder.
> 
> **User flow**
> 
> 1. New user sees empty message and create/upload guidance.
> 2. User follows CTA to CV builder.
> 
> **Rules**
> 
> - Copy encourages creating CV or letter or uploading certificates.
> 
> **States**
> 
> - Empty illustration with primary CTA.
> 
> ---
> 
> ### Success stories section
> 
> **What it does**
> 
> Displays motivational success stories at bottom of documents tab.
> 
> **User flow**
> 
> 1. User scrolls to read peer success content after document management.
> 
> **Rules**
> 
> - Same pattern as job portal home success stories.
> 
> **States**
> 
> - Visible on documents tab when content configured.
> 
> ---
> 
> ## CV Creator tab
> 
> ### CV Creator hero
> 
> **What it does**
> 
> Introduces CV creation benefits with illustration and get started CTA to CV builder.
> 
> **User flow**
> 
> 1. User reads subtitle about CV creation value.
> 2. User clicks get started to open builder.
> 
> **Rules**
> 
> - Landing page only; full builder is separate route.
> 
> **States**
> 
> - Hero with primary CTA.
> 
> ---
> 
> ### Upload existing CV card
> 
> **What it does**
> 
> Opens upload dialog for bringing an external CV into the library.
> 
> **User flow**
> 
> 1. User uploads file via dialog (same validation as CV hub: filename, one file, size limit).
> 
> **Rules**
> 
> - May require sign-in for persistence.
> 
> **States**
> 
> - Upload dialog success adds to documents library.
> 
> ---
> 
> ### Edit or continue draft card
> 
> **What it does**
> 
> Detects in-progress local CV draft and adjusts label to continue editing vs start fresh.
> 
> **User flow**
> 
> 1. User with draft sees continue label and opens builder at saved progress.
> 2. User without draft sees start label.
> 
> **Rules**
> 
> - Uses same local draft detection as CV hub.
> 
> **States**
> 
> - **Draft exists:** continue messaging.
> - **No draft:** start messaging.
> 
> ---
> 
> ## Motivation Letter tab
> 
> ### Motivation Letter hero
> 
> **What it does**
> 
> Introduces motivation letter writing with illustration and get started CTA to letter builder.
> 
> **User flow**
> 
> 1. User reads subtitle about application letters.
> 2. User opens builder via CTA.
> 
> **Rules**
> 
> - Landing only; builder is separate route.
> 
> **States**
> 
> - Hero with primary CTA.
> 
> ---
> 
> ### Upload existing letter card
> 
> **What it does**
> 
> Allows upload of an existing motivation letter file into document library.
> 
> **User flow**
> 
> 1. User uploads via dialog.
> 
> **Rules**
> 
> - Same upload constraints as CV uploads where applicable.
> 
> **States**
> 
> - Success adds letter to library under motivation letter category.
> 
> ---
> 
> ### Continue editing draft card
> 
> **What it does**
> 
> Opens motivation letter builder when saved draft exists.
> 
> **User flow**
> 
> 1. User with server or local draft continues editing.
> 2. User without draft starts new letter flow.
> 
> **Rules**
> 
> - Draft persistence in builder uses auto-save while editing.
> 
> **States**
> 
> - Continue vs start labels based on draft detection.
> 
> ---
> 
> ## Motivation Letter builder
> 
> ### Three-step letter flow
> 
> **What it does**
> 
> Guides user through Details, Story, and Editor steps with stepper progress.
> 
> **User flow**
> 
> 1. User completes Details (application type, profession, contact, career history, signature).
> 2. User answers Story questionnaire and generates draft.
> 3. User edits in Editor with AI assist and saves to documents.
> 
> **Rules**
> 
> - Can navigate back to earlier completed steps from stepper.
> - Cannot jump to incomplete future steps.
> 
> **States**
> 
> - Stepper shows current and completed steps.
> 
> ---
> 
> ### Details step validation
> 
> **What it does**
> 
> Requires key contact and position fields before continuing.
> 
> **User flow**
> 
> 1. User fills name, email, position, institution, and related fields.
> 2. User clicks continue; validation runs.
> 
> **Rules**
> 
> - Name, valid email format, position, and institution required.
> - Update from profile available when signed in.
> - Signature upload supported.
> 
> **States**
> 
> - Validation toast or inline errors on failure.
> 
> ---
> 
> ### Story step and AI generation
> 
> **What it does**
> 
> Presents guided questions (motivation, expertise, discovery source, etc.) with required vs optional markers, hints, and examples; generates AI draft letter.
> 
> **User flow**
> 
> 1. User answers questionnaire.
> 2. User clicks generate; loading state while draft created.
> 3. User advances to editor with generated content.
> 
> **Rules**
> 
> - Required answers must be filled before generate.
> - Validation toast if required answers missing.
> 
> **States**
> 
> - **Generating:** loading indicator.
> - **Generated:** editor populated.
> 
> ---
> 
> ### Editor step
> 
> **What it does**
> 
> Shows generated letter with editable blocks, AI grammar/regenerate per block, whole-letter refine panel, assistance level, word count, page estimate, coaching insights, copy to clipboard, and save to documents.
> 
> **User flow**
> 
> 1. User click-to-edits any paragraph or block.
> 2. User requests AI assist on block or whole letter via refine instruction.
> 3. User saves to document library or copies full letter.
> 
> **Rules**
> 
> - Stale-draft warning if details changed after generation; save may block until regenerate.
> - Auto-save draft to server while editing (debounced).
> - Save to documents requires non-stale draft.
> 
> **States**
> 
> - **Stale:** warning banner; save blocked until refresh.
> - **Current:** save enabled.
> - **Saving:** background auto-save.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Job Portal home Application Tools preview
> - Primary tab Job Application Tools
> - CV builder normal save redirect (documents tab)
> - Direct URLs per sub-tab or builder
> 
> **Outbound**
> 
> - CV builder
> - Motivation letter builder
> - Job forum
> - Job posting detail (when documents selected in apply flow — via library, not from tools landing)
> - Sign-in (guest uploads)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Can view tool landing pages; uploads, list, builder save require sign-in |
> | Signed-in member | Full document library, uploads, builder save, profile prefill in letter builder |
> 
> ---
> 
> ## Important Business Rules
> 
> - Documents library is canonical storage for uploaded and generated CVs, letters, and certificates.
> - Generated vs uploaded source badge distinguishes builder output from manual uploads.
> - CV and motivation letter builders are multi-step wizards; landing tabs only promote entry.
> - Motivation letter AI generation requires completed story questionnaire.
> - Stale letter draft must be regenerated after detail changes before save.
> - Tools index and legacy query tab URLs normalize to Documents path.
> - Maximum upload size ten megabytes for manual uploads (consistent with CV hub).
> 
> ---
> 
> ## Related Features
> 
> - [Job Portal — Home](job-portal.md)
> - [Job Portal — CV Hub](job-portal-cv.md)
> - [Job Portal — CV Builder](job-portal-cv-builder.md)
> - [Job Portal — Job Posting Detail](job-portal-detail.md) (document selection in apply)
> - [Job Portal — User Applications](job-portal-applications.md)

---

## Page: My Journey — Landing
- URL: https://freiburger-bund.com/en/my-journey
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: public
- Source: docs/product-knowledge/pages/my-journey.md
- Updated: 2026-09-21

### Purpose
Introduce the personal healthcare journey to Germany, preview all four phases and their steps, and guide visitors toward account creation or into the progress dashboard with relevant articles, jobs, and community entry points.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Page hero and introduction
> 
> **What it does**
> 
> Presents a headline, subtitle, and introductory copy about reliable guidance from document preparation through visa collection.
> 
> **User flow**
> 
> 1. User arrives from homepage **Start Your Journey**, header navigation, or direct link.
> 2. User reads the hero and supporting marketing content at the top of the page.
> 
> **Rules**
> 
> - Top-of-page content may include editable promotional blocks managed outside the core journey UI.
> 
> **States**
> 
> - Static marketing content.
> 
> ---
> 
> ### Journey value overview (guests only)
> 
> **What it does**
> 
> Shows a visual roadmap and four value pillars explaining why to use the platform: structured roadmap, trusted community experiences, up-to-date content, and helpful tools and checklists.
> 
> **User flow**
> 
> 1. Guest user scrolls below the hero.
> 2. User reads the illustrated overview and four benefit pillars.
> 3. User sees a **Sign Up for Free** call-to-action explaining saved progress and personalized content.
> 
> **Rules**
> 
> - This entire overview section is hidden for signed-in users.
> 
> **States**
> 
> - **Guest:** overview and sign-up prompt visible.
> - **Signed-in:** section not shown.
> 
> ---
> 
> ### Account creation prompts (guests)
> 
> **What it does**
> 
> Offers registration and login entry points within the journey landing experience.
> 
> **User flow**
> 
> 1. Guest clicks **Create account** or **Login**.
> 2. User is taken to registration or sign-in.
> 
> **Rules**
> 
> - Registration preserves return destination so users can continue afterward.
> 
> **States**
> 
> - Hidden for signed-in users who already have an account.
> 
> ---
> 
> ### Journey phase switcher
> 
> **What it does**
> 
> Lets users browse all four journey phases and read phase-specific descriptions.
> 
> **User flow**
> 
> 1. User selects a phase tab (Travel Preparation, Professional Recognition, Job Entry, Career).
> 2. Phase title, long description, and illustration update.
> 3. Step stepper below updates to that phase’s steps.
> 
> **Rules**
> 
> - Phases appear in journey order.
> - Current phase tab is visually highlighted.
> 
> **States**
> 
> - **Loading:** stepper may show placeholders until steps load.
> - **Active phase:** one phase selected at a time.
> 
> ---
> 
> ### Interactive journey stepper
> 
> **What it does**
> 
> Displays the steps within the selected phase as a clickable stepper with connectors showing progress styling.
> 
> **User flow**
> 
> 1. User clicks a step in the stepper.
> 2. Selected step is highlighted.
> 3. Connector lines reflect completed, in-progress, or not-started appearance.
> 
> **Rules**
> 
> - Step labels show step number and step name.
> - Selecting a step updates the address bar with phase and step parameters without a full page reload.
> 
> **States**
> 
> - **No step selected:** defaults to first step or URL-specified step.
> - **Deep-linked:** opening a shared link with phase and step parameters opens the matching selection.
> 
> ---
> 
> ### Start your journey action
> 
> **What it does**
> 
> Takes the user into the personal progress dashboard with the currently selected phase and step pre-selected.
> 
> **User flow**
> 
> 1. User clicks **Start Your Journey** (or equivalent primary action in the phase section).
> 2. User lands on the dashboard with the same phase and step context carried over.
> 
> **Rules**
> 
> - Destination is the progress dashboard, not a separate onboarding flow.
> - Phase and step from the landing page are passed forward.
> 
> **States**
> 
> - Always available regardless of sign-in state.
> 
> ---
> 
> ### Explore articles section
> 
> **What it does**
> 
> Highlights info portal content types—articles to listen to and up-to-date articles—and offers exploration actions tied to the active phase.
> 
> **User flow**
> 
> 1. User reads the Explore Articles section heading and subtitle.
> 2. Guest user sees encouragement to sign up for phase-relevant article recommendations.
> 3. Guest primary action leads to registration.
> 4. Signed-in user primary action leads to info articles for the active phase.
> 5. User may follow a secondary explore link to phase articles.
> 
> **Rules**
> 
> - Article exploration is phase-aware based on the currently selected journey phase.
> - Guests are steered toward account creation before personalized recommendations.
> 
> **States**
> 
> - **Guest:** sign-up messaging and register action.
> - **Signed-in:** direct explore action to info content.
> 
> ---
> 
> ### Job opportunities preview
> 
> **What it does**
> 
> Shows a preview of current job listings from the job portal with links to individual postings.
> 
> **User flow**
> 
> 1. User scrolls to the Find Jobs section.
> 2. User browses up to three live job cards with employer, title, location, and summary.
> 3. User opens a job posting from a card.
> 
> **Rules**
> 
> - Expired listings are excluded from the preview.
> - Empty state shown when no jobs are available.
> 
> **States**
> 
> - **Loading:** skeleton cards while listings load.
> - **Empty:** message when no jobs found.
> - **Populated:** up to three cards.
> 
> ---
> 
> ### Community growth section
> 
> **What it does**
> 
> Introduces community entry points aligned with the journey: exam chatrooms, discussion forum, language learning, study partners, and events.
> 
> **User flow**
> 
> 1. User reads the community section introduction.
> 2. User clicks an entry card such as **Join forum**, **Learn German**, **Find a study partner**, or **Plan an event**.
> 3. User is taken to the relevant community area.
> 
> **Rules**
> 
> - Each card summarizes one community use case.
> - Links target community portal destinations.
> 
> **States**
> 
> - Visible when included in page content configuration.
> 
> ---
> 
> ### Member testimonials
> 
> **What it does**
> 
> Displays member quotes about platform experience with attribution.
> 
> **User flow**
> 
> 1. User reads testimonials in the Voices section.
> 2. User may scroll through multiple quotes.
> 
> **Rules**
> 
> - Curated marketing content.
> 
> **States**
> 
> - Multiple testimonials may repeat in carousel layout.
> 
> ---
> 
> ### Mobile app and partners sections
> 
> **What it does**
> 
> Promotes the mobile app and displays trusted partner logos when configured in page content.
> 
> **User flow**
> 
> 1. User opens app store links or views partner logos.
> 
> **Rules**
> 
> - Optional CMS-managed sections at page bottom.
> 
> **States**
> 
> - Hidden when not configured.
> 
> ---
> 
> ### URL deep linking for phase and step
> 
> **What it does**
> 
> Allows sharing or bookmarking a specific phase and step on the landing page.
> 
> **User flow**
> 
> 1. User selects phase/step or follows a link with phase and step parameters.
> 2. Page opens with matching selection.
> 3. Browser back and forward restore prior selections.
> 
> **Rules**
> 
> - Address updates in place without full reload when browsing phases and steps.
> 
> **States**
> 
> - Invalid phase parameter: **Unknown / requires product clarification** for fallback behavior.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site navigation, language switching, login, footer links, newsletter, and cookie consent.
> 
> **User flow**
> 
> 1. User navigates to other portals or creates an account from the header.
> 
> **Rules**
> 
> - Same global chrome as other marketing pages.
> 
> **States**
> 
> - Guest vs signed-in header differences apply.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Homepage **Start Your Journey**
> - Header Dashboard or journey links
> - Marketing campaigns and direct links
> - Post-registration may route to dashboard instead of this landing
> 
> **Outbound**
> 
> - Progress dashboard (Start Your Journey, with phase/step context)
> - Registration and login
> - Info portal articles for active phase
> - Job posting detail pages
> - Community portal entry points
> - Mobile app stores
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Sees value overview, sign-up prompts, register CTAs in article section |
> | Signed-in member | Overview hidden; explore articles goes directly to info portal |
> 
> ---
> 
> ## Important Business Rules
> 
> - This page is a preview and marketing funnel, not the progress tracker itself.
> - Phase and step browsing syncs to the URL for shareable state.
> - Progress saving requires an account; the dashboard holds tracked progress.
> - Job and community sections are discovery shortcuts, not full portal experiences.
> - Page supports English, German, French, and Arabic with localized addresses.
> 
> ---
> 
> ## Related Features
> 
> - Personal progress dashboard
> - Info Portal phase articles
> - Job Portal listings
> - Community Portal channels and events
> - Account registration
> - Homepage journey overview

---

## Page: Dashboard — My Journey Progress
- URL: https://freiburger-bund.com/en/dashboard
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: authenticated
- Source: docs/product-knowledge/pages/dashboard.md
- Updated: 2026-09-21

### Purpose
Help users track progress through the four journey phases, complete step tasks, access contextual tips and reading, discover community channels, and launch quick planning tools—all centered on the user’s current phase and step.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Welcome card
> 
> **What it does**
> 
> Greets signed-in users with a personalized welcome, phase completion ring, next-step preview, and checklist shortcut—or prompts guests to sign in to unlock tracking.
> 
> **User flow**
> 
> 1. Signed-in user sees their first name, current phase progress percentage, and next step preview.
> 2. User clicks **Go to checklist** to open the full checklist modal.
> 3. Guest user sees locked-progress messaging with **Login** as primary action and **Explore journey phases** as secondary action.
> 
> **Rules**
> 
> - Progress ring and next step require a signed-in account with saved progress.
> - Guest card emphasizes account creation to unlock tracking.
> 
> **States**
> 
> - **Signed-in:** personalized welcome with live progress data.
> - **Guest:** lock illustration and login prompt.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → My Journey and supports navigation back to the journey landing page.
> 
> **User flow**
> 
> 1. User clicks **My Journey** in the breadcrumb to open the journey landing page.
> 
> **Rules**
> 
> - Breadcrumb label uses “My Journey” while the page title area may show “My Dashboard” for guests.
> 
> **States**
> 
> - Mobile and desktop breadcrumb variants with same destinations.
> 
> ---
> 
> ### Overall progress and phase tabs
> 
> **What it does**
> 
> Displays overall progress heading, lets users switch journey phases, and shows phase completion for signed-in users.
> 
> **User flow**
> 
> 1. User reads the overall progress section title.
> 2. User clicks a phase tab to switch context.
> 3. Signed-in user sees numeric completion percentage and a personalized progress message for the active phase.
> 4. Signed-in user may see an achievement badge with encouragement.
> 
> **Rules**
> 
> - Guest progress is always shown as 0%.
> - Phase switch updates stepper and all contextual cards below.
> 
> **States**
> 
> - **Guest:** “Track your progress” teaser with sparkle icon; 0% bar.
> - **Signed-in:** live percentage, message, and achievement badge.
> - **Error loading progress:** retry option shown.
> 
> ---
> 
> ### Progress bar
> 
> **What it does**
> 
> Visual horizontal bar reflecting completion percentage for the active phase.
> 
> **User flow**
> 
> 1. User sees bar fill animate to match current progress.
> 
> **Rules**
> 
> - Guests always see an empty bar (0%).
> - Bar direction respects right-to-left layout for Arabic.
> 
> **States**
> 
> - Animated fill on progress updates.
> 
> ---
> 
> ### Journey stepper
> 
> **What it does**
> 
> Interactive step list for the active phase; selecting a step updates all contextual cards below.
> 
> **User flow**
> 
> 1. User clicks a step in the stepper.
> 2. Upcoming tasks, tips, reading, and community cards refresh for that step.
> 3. Signed-in users auto-select their current in-progress step on first load unless URL specifies otherwise.
> 
> **Rules**
> 
> - Step selection syncs to URL phase and step parameters after user interaction.
> - Guests default to the first step of the selected phase.
> 
> **States**
> 
> - **Signed-in initial load:** current in-progress step selected from saved progress.
> - **Guest:** first step selected.
> - **Deep link:** URL phase and step parameters override defaults.
> 
> ---
> 
> ### Upcoming tasks card
> 
> **What it does**
> 
> Lists up to five checklist tasks for the selected step with actions to open the full checklist or launch linked resources.
> 
> **User flow**
> 
> 1. User reads numbered tasks for the current step.
> 2. User clicks a task row to open the checklist modal.
> 3. User clicks the arrow on a task to follow its linked action (article, tool, portal page, or external resource).
> 
> **Rules**
> 
> - Tasks are step-specific.
> - Guests see tasks but cannot mark them complete.
> 
> **States**
> 
> - **Guest:** helper text encouraging account creation.
> - **Signed-in:** tasks reflect saved completion state in checklist modal.
> - **Empty:** no tasks for step.
> 
> ---
> 
> ### Tips and tricks card
> 
> **What it does**
> 
> Shows up to five tips to avoid common mistakes for the selected step.
> 
> **User flow**
> 
> 1. User reads tip titles on the card.
> 2. User clicks **See all mistakes** to open a modal with full tip descriptions.
> 
> **Rules**
> 
> - Tips change when a different step is selected.
> 
> **States**
> 
> - **Guest:** extra helper text about creating an account.
> - **Modal:** expanded list of all tips for the step.
> 
> ---
> 
> ### Recommended reading card
> 
> **What it does**
> 
> Surfaces up to three recommended info articles for the selected step with read time.
> 
> **User flow**
> 
> 1. User browses article cards.
> 2. User opens an article from a card.
> 3. User clicks **View all** to open a modal with up to fifty recommended articles for the step.
> 
> **Rules**
> 
> - Articles link to full info portal article pages.
> - Recommendations are step-specific.
> 
> **States**
> 
> - **Guest:** helper text; articles may still be readable when linked.
> - **Empty:** “No recommended articles for this step yet.”
> 
> ---
> 
> ### Community card
> 
> **What it does**
> 
> Recommends discussion channels relevant to the selected step with discussion counts.
> 
> **User flow**
> 
> 1. User browses recommended channels.
> 2. User opens a channel link.
> 3. User clicks **Go to portal** to open a modal with the full channel list and a link to the community home.
> 
> **Rules**
> 
> - Channels are step- and phase-aware.
> 
> **States**
> 
> - **Empty:** “No community discussions for this step yet.”
> 
> ---
> 
> ### Help card
> 
> **What it does**
> 
> Provides phase-aware links to community forum help and contact support.
> 
> **User flow**
> 
> 1. User clicks community forum link for the active phase.
> 2. User clicks contact support link.
> 
> **Rules**
> 
> - Forum link targets the community area for the current journey phase.
> 
> **States**
> 
> - Always visible below the info cards.
> 
> ---
> 
> ### Quick tools grid
> 
> **What it does**
> 
> Offers one-click access to planning and application tools from the dashboard.
> 
> **User flow**
> 
> 1. User browses tool tiles: Cost Calculator, CV Generator, Federal State Compass, Visa Navigator, Motivation Letter Generator, and optionally Document Checker and Comparison Table.
> 2. User clicks a tile to open the tool.
> 
> **Rules**
> 
> - Active tools link to their dedicated pages.
> - Document Checker and Comparison Table may appear but link to coming-soon pages or inactive placeholders depending on configuration.
> 
> **States**
> 
> - Tool set may be CMS-configured; default includes six tools with two potentially inactive.
> 
> ---
> 
> ### Checklist modal
> 
> **What it does**
> 
> Full-screen checklist for the active phase with expandable step sections and task checkboxes.
> 
> **User flow**
> 
> 1. User opens checklist from welcome card, tasks card, or **View checklist** link.
> 2. User expands a step section.
> 3. Signed-in user toggles task completion; progress percentage updates.
> 4. User follows task action arrows to linked destinations.
> 
> **Rules**
> 
> - Task completion persists for signed-in users only.
> - Guests can view tasks but checkboxes are disabled with sign-in prompt.
> 
> **States**
> 
> - **Guest:** view-only with empty-state sign-in message.
> - **Signed-in:** interactive checkboxes and live progress updates.
> - **Error:** retry option.
> 
> ---
> 
> ### Recommended reading modal
> 
> **What it does**
> 
> Expanded list of recommended articles for the selected step (up to fifty items).
> 
> **User flow**
> 
> 1. User opens modal from reading card.
> 2. User browses and opens articles.
> 
> **Rules**
> 
> - Same article linking as the reading card.
> 
> **States**
> 
> - Scrollable list inside modal.
> 
> ---
> 
> ### Community channels modal
> 
> **What it does**
> 
> Shows the full list of recommended channels for the step with link to community portal home.
> 
> **User flow**
> 
> 1. User opens from community card **Go to portal** action.
> 2. User selects a channel or navigates to community home.
> 
> **Rules**
> 
> - Superset of channels shown on the card preview.
> 
> **States**
> 
> - Modal overlay.
> 
> ---
> 
> ### URL sync for phase and step
> 
> **What it does**
> 
> Keeps the dashboard address in sync with selected phase and step for sharing and return visits.
> 
> **User flow**
> 
> 1. User changes phase or step.
> 2. Address updates with phase and step parameters without full page reload.
> 
> **Rules**
> 
> - Sync occurs after user interaction, not on passive initial load without parameters.
> 
> **States**
> 
> - Browser history supports back/forward navigation of selections.
> 
> ---
> 
> ### Floating chat (signed-in)
> 
> **What it does**
> 
> Provides quick access to messaging while on the dashboard.
> 
> **User flow**
> 
> 1. Signed-in user opens floating chat widget.
> 
> **Rules**
> 
> - Hidden for guests.
> - Hidden on the map tool page but available on dashboard.
> 
> **States**
> 
> - **Signed-in:** widget visible.
> - **Guest:** not shown.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard navigation, language, account menu, footer, newsletter, and cookies.
> 
> **User flow**
> 
> 1. User navigates away to portals, settings, or support pages.
> 
> **Rules**
> 
> - Same global chrome as other pages.
> 
> **States**
> 
> - Guest vs signed-in header.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Journey landing **Start Your Journey**
> - Header Dashboard link
> - Post-registration onboarding completion
> - Homepage and portal quick-tool links
> - Checklist task action links from same page
> - Direct link with phase/step parameters
> 
> **Outbound**
> 
> - Journey landing page (breadcrumb)
> - Info portal articles
> - Community channels
> - Quick tools (cost calculator, map, visa navigator, CV builder, motivation letter)
> - Login and registration
> - Contact support
> - Job portal (via task actions)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Guest welcome card; 0% progress; view-only checklist; helper text on cards; login CTAs |
> | Signed-in member | Personalized welcome; saved progress; task completion; achievement badge; floating chat |
> 
> ---
> 
> ## Important Business Rules
> 
> - Progress tracking requires an authenticated account; guests can browse but not save completion.
> - All contextual content (tasks, tips, reading, community) is driven by the selected phase and step.
> - Phase tabs switch context without leaving the dashboard.
> - Quick tools are shortcuts; full tool experiences live on dedicated pages.
> - After registration, users are typically routed here as their home base for journey tracking.
> - Arabic layout mirrors progress bar direction and reading order appropriately.
> 
> ---
> 
> ## Related Features
> 
> - My Journey landing page
> - Journey checklist (modal)
> - Info Portal articles
> - Community Portal channels
> - Cost calculator, visa navigator, federal state compass (map)
> - CV builder and motivation letter generator
> - Account registration and login
> - Bookmarks (requires sign-in; separate area)

---

## Page: Federal State Compass (Interactive Map)
- URL: https://freiburger-bund.com/en/dashboard/map
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: public
- Source: docs/product-knowledge/pages/dashboard-map.md
- Updated: 2026-09-21

### Purpose
Let users explore opportunities and state-specific information across Germany through a full-screen interactive map embedded in the journey tools area.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Dashboard → Map and allows navigation back to the progress dashboard.
> 
> **User flow**
> 
> 1. User opens the map from dashboard quick tools, tools hub, or info/community quick tools.
> 2. User clicks **Dashboard** in the breadcrumb to return.
> 
> **Rules**
> 
> - Map is nested under the dashboard journey area in navigation hierarchy.
> 
> **States**
> 
> - Breadcrumb always visible above the map frame.
> 
> ---
> 
> ### Full-screen interactive map
> 
> **What it does**
> 
> Embeds a third-party interactive map of Germany that loads in the user’s selected site language.
> 
> **User flow**
> 
> 1. User waits for the map to load inside the page frame.
> 2. User explores regions, filters, and data visualizations inside the embedded map application.
> 3. User may enter full-screen mode within the embedded tool.
> 
> **Rules**
> 
> - All map interaction happens inside the embedded application.
> - Map language matches the user’s current site language selection.
> - No sign-in required to use the map.
> 
> **States**
> 
> - **Loading:** lazy-loaded frame until map is ready.
> - **Loaded:** interactive map fills available viewport height below breadcrumb.
> 
> ---
> 
> ### Accessible to all users
> 
> **What it does**
> 
> Provides the same map entry point for guests and signed-in members.
> 
> **User flow**
> 
> 1. Any visitor opens the page and uses the map equally.
> 
> **Rules**
> 
> - No authentication gate on this page.
> 
> **States**
> 
> - Guest and signed-in experience identical for map access.
> 
> ---
> 
> ### Floating chat suppression
> 
> **What it does**
> 
> Hides the floating messaging widget on this page so it does not overlap the map.
> 
> **User flow**
> 
> 1. Signed-in user notices chat widget is not shown while viewing the map.
> 
> **Rules**
> 
> - Floating chat available on dashboard but intentionally hidden here.
> 
> **States**
> 
> - **Signed-in on map:** no floating chat.
> - **Signed-in on dashboard:** chat available.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site navigation and footer remain available outside the map frame.
> 
> **User flow**
> 
> 1. User navigates to other site areas from the header.
> 
> **Rules**
> 
> - Same global chrome as other journey tool pages.
> 
> **States**
> 
> - Standard guest vs signed-in header.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Dashboard quick tools (Federal State Compass tile)
> - Application tools hub
> - Info or community portal quick tools sections
> - Journey checklist task actions linking to the map
> - Direct link or localized equivalent address
> 
> **Outbound**
> 
> - Progress dashboard (breadcrumb)
> - Other site areas via header/footer
> - External or internal destinations within the embedded map application
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full map access; no floating chat |
> | Signed-in member | Full map access; floating chat hidden on this page |
> 
> ---
> 
> ## Important Business Rules
> 
> - The host page provides navigation shell only; map data and interactions are owned by the embedded application.
> - Language follows the user’s active site locale.
> - Map uses full available viewport below breadcrumbs for usable exploration area.
> - This tool is also marketed as “Federal State Compass” or “Bundesland Compass” in quick-tool tiles.
> 
> ---
> 
> ## Related Features
> 
> - Progress dashboard quick tools
> - Application tools hub
> - Cost calculator and visa navigator (sibling journey tools)
> - Info and community portal quick tools sections

---

## Page: Visa Navigator
- URL: https://freiburger-bund.com/en/dashboard/visa-navigator
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: public
- Source: docs/product-knowledge/pages/dashboard-visa-navigator.md
- Updated: 2026-09-21

### Purpose
Guide international healthcare professionals to the appropriate German visa or residency pathway through a personalized embedded visa navigator tool.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Dashboard → Visa Navigator with a link back to the progress dashboard.
> 
> **User flow**
> 
> 1. User opens the visa navigator from dashboard quick tools, tools hub, portal quick tools, or checklist tasks.
> 2. User clicks **Dashboard** in the breadcrumb to return.
> 
> **Rules**
> 
> - Tool lives under the dashboard journey area in site hierarchy.
> 
> **States**
> 
> - Breadcrumb always shown above the tool frame.
> 
> ---
> 
> ### Embedded visa navigator
> 
> **What it does**
> 
> Loads a full-viewport third-party visa guidance application in the user’s selected site language.
> 
> **User flow**
> 
> 1. User waits for the navigator to load.
> 2. User answers pathway questions or browses guidance inside the embedded application.
> 3. User receives visa and residency recommendations within the tool.
> 4. User may use full-screen mode inside the embedded application.
> 
> **Rules**
> 
> - All questionnaire logic and recommendations occur inside the embedded tool.
> - Language matches the user’s current site locale.
> - No authentication required.
> 
> **States**
> 
> - **Loading:** lazy-loaded frame.
> - **Loaded:** interactive navigator fills viewport below breadcrumb.
> 
> ---
> 
> ### Open access
> 
> **What it does**
> 
> Provides identical entry for guests and signed-in users.
> 
> **User flow**
> 
> 1. Any visitor uses the navigator without signing in.
> 
> **Rules**
> 
> - No login gate.
> 
> **States**
> 
> - Same experience for all roles.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site chrome surrounding the embedded tool.
> 
> **User flow**
> 
> 1. User navigates elsewhere from the header or footer.
> 
> **Rules**
> 
> - Same as other dashboard tool pages.
> 
> **States**
> 
> - Standard header/footer states.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Dashboard quick tools (Visa Navigator tile)
> - Application tools hub (when enabled)
> - Info or community portal quick tools
> - Journey checklist task actions
> - Direct or localized link
> 
> **Outbound**
> 
> - Progress dashboard (breadcrumb)
> - Destinations linked from within the embedded navigator
> - Other site areas via header/footer
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full navigator access |
> | Signed-in member | Full navigator access |
> 
> No role-based differences on the host page.
> 
> ---
> 
> ## Important Business Rules
> 
> - The host page is a navigation shell; visa logic and legal guidance content live in the embedded application.
> - Tool language follows the active site locale.
> - Personalized pathway output is generated inside the embedded tool, not on the host page.
> - Commonly reached early in Phase 1 (travel preparation) tasks and quick tools.
> 
> ---
> 
> ## Related Features
> 
> - Progress dashboard and checklist tasks
> - Application tools hub
> - Federal state compass (map)
> - Cost calculator
> - Info Portal articles on visas and travel

---

## Page: Cost Calculator
- URL: https://freiburger-bund.com/en/dashboard/cost-calculator
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: public
- Source: docs/product-knowledge/pages/dashboard-cost-calculator.md
- Updated: 2026-09-21

### Purpose
Help users estimate relocation and living costs in Germany through an embedded cost calculator tailored to their situation and language.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Dashboard → Cost Calculator with navigation back to the progress dashboard.
> 
> **User flow**
> 
> 1. User opens the calculator from dashboard quick tools, tools hub, or portal quick tools.
> 2. User returns via breadcrumb **Dashboard** link.
> 
> **Rules**
> 
> - Nested under dashboard in site hierarchy.
> 
> **States**
> 
> - Always visible above calculator frame.
> 
> ---
> 
> ### Embedded cost calculator
> 
> **What it does**
> 
> Loads a full-viewport third-party cost estimation application in the user’s selected site language.
> 
> **User flow**
> 
> 1. User waits for the calculator to load.
> 2. User enters personal situation inputs inside the embedded tool.
> 3. User views calculated cost breakdowns, comparisons, or totals within the tool.
> 4. User may expand to full-screen inside the embedded application.
> 
> **Rules**
> 
> - All calculations and inputs occur inside the embedded application.
> - Internal scrolling is handled within the calculator frame.
> - Language follows active site locale.
> - No sign-in required.
> 
> **States**
> 
> - **Loading:** lazy-loaded frame.
> - **Loaded:** calculator interactive below breadcrumb.
> 
> ---
> 
> ### Open access
> 
> **What it does**
> 
> Allows guests and signed-in users equal access.
> 
> **User flow**
> 
> 1. Any visitor uses the calculator without an account.
> 
> **Rules**
> 
> - No authentication gate.
> 
> **States**
> 
> - Identical access for all users.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site navigation and footer outside the calculator frame.
> 
> **User flow**
> 
> 1. User leaves via header links or footer.
> 
> **Rules**
> 
> - Same global chrome as sibling journey tools.
> 
> **States**
> 
> - Standard states.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Dashboard quick tools (Cost Calculator tile)
> - Application tools hub (when enabled and not marked disabled)
> - Info or community portal quick tools
> - Journey checklist task actions
> - Direct or localized link
> 
> **Outbound**
> 
> - Progress dashboard (breadcrumb)
> - Other site areas via header/footer
> - **Unknown / requires product clarification:** whether calculator supports exporting or saving results
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full calculator access |
> | Signed-in member | Full calculator access |
> 
> ---
> 
> ## Important Business Rules
> 
> - Host page provides navigation shell only; calculation logic lives in the embedded application.
> - Language follows user’s selected site locale.
> - Frequently linked from Phase 1 planning content across info, community, and dashboard surfaces.
> - On the application tools hub, this tool may appear disabled until CMS configuration enables it—even though the dedicated calculator page itself is live.
> 
> ---
> 
> ## Related Features
> 
> - Progress dashboard quick tools
> - Application tools hub
> - Visa navigator and federal state compass
> - Info Portal travel planning articles

---

## Page: Document Checker
- URL: https://freiburger-bund.com/en/dashboard/document-checker
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: public
- Source: docs/product-knowledge/pages/dashboard-document-checker.md
- Updated: 2026-09-21

### Purpose
Reserve a place in the journey tools area for a future document verification feature that will help users check whether their application documents meet requirements.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Dashboard → Document Checker with a link back to the progress dashboard.
> 
> **User flow**
> 
> 1. User arrives from dashboard quick tools, tools hub, or direct link.
> 2. User clicks **Dashboard** in the breadcrumb to leave.
> 
> **Rules**
> 
> - Page exists in navigation hierarchy even though the tool is not yet available.
> 
> **States**
> 
> - Breadcrumb always shown.
> 
> ---
> 
> ### Coming soon message
> 
> **What it does**
> 
> Displays a centered coming-soon notice inside a bordered card instead of a working tool.
> 
> **User flow**
> 
> 1. User opens the page expecting a document checker.
> 2. User reads the coming-soon message.
> 3. User navigates away via breadcrumb or header.
> 
> **Rules**
> 
> - No upload form, checklist, or verification workflow is available yet.
> - No authentication required to view the placeholder.
> 
> **States**
> 
> - **Only state today:** coming soon placeholder.
> - **Future:** **Unknown / requires product clarification** for verification rules, supported document types, and guest vs member access.
> 
> ---
> 
> ### Quick tool tile reference
> 
> **What it does**
> 
> May appear on the dashboard quick tools grid but link to an inactive placeholder rather than this page in some configurations.
> 
> **User flow**
> 
> 1. User sees Document Checker named on dashboard but may not reach this page from every quick-tool entry point.
> 
> **Rules**
> 
> - Dashboard default quick tools may use a non-navigating placeholder link until the feature launches.
> 
> **States**
> 
> - Tile may be visible with inactive link on dashboard; dedicated page shows coming soon when visited directly.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site chrome on the placeholder page.
> 
> **User flow**
> 
> 1. User navigates to other tools or portals from the header.
> 
> **Rules**
> 
> - Same as other dashboard sub-pages.
> 
> **States**
> 
> - Standard.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Direct URL
> - Dashboard quick tools (when linked)
> - Application tools hub (when listed as disabled/non-clickable)
> - Journey checklist tasks **Unknown / requires product clarification**
> 
> **Outbound**
> 
> - Progress dashboard (breadcrumb)
> - Other site areas via header/footer
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Sees coming soon message |
> | Signed-in member | Sees coming soon message |
> 
> No functional differences today.
> 
> ---
> 
> ## Important Business Rules
> 
> - Feature is announced but not yet delivered; users must not expect document upload or validation.
> - Page should remain reachable so marketing and navigation references do not break.
> - When launched, business rules for acceptable file types, privacy, and pass/fail criteria will need a full spec update.
> 
> ---
> 
> ## Related Features
> 
> - Progress dashboard quick tools
> - Application tools hub (listed as coming soon)
> - Comparison table (also placeholder)
> - CV builder and documents folder (job application tools)

---

## Page: Comparison Table
- URL: https://freiburger-bund.com/en/dashboard/comparison-table
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: public
- Source: docs/product-knowledge/pages/dashboard-comparison-table.md
- Updated: 2026-09-21

### Purpose
Reserve a place in the journey tools area for a future side-by-side comparison feature—such as comparing federal states, employers, or opportunities—that is not yet available.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Shows Home → Dashboard → Comparison Table with a link back to the progress dashboard.
> 
> **User flow**
> 
> 1. User arrives from dashboard quick tools, tools hub, or direct link.
> 2. User returns via breadcrumb.
> 
> **Rules**
> 
> - Listed in journey tools navigation before feature launch.
> 
> **States**
> 
> - Breadcrumb always visible.
> 
> ---
> 
> ### Coming soon message
> 
> **What it does**
> 
> Shows a centered coming-soon notice in a bordered card with no comparison UI.
> 
> **User flow**
> 
> 1. User opens the page.
> 2. User reads that the comparison table is not yet available.
> 3. User navigates away.
> 
> **Rules**
> 
> - No tables, filters, or comparison datasets are presented yet.
> - No sign-in required to view the placeholder.
> 
> **States**
> 
> - **Only state today:** coming soon.
> 
> ---
> 
> ### Quick tool tile reference
> 
> **What it does**
> 
> May appear on the dashboard quick tools grid with an inactive placeholder link in default configuration.
> 
> **User flow**
> 
> 1. User sees Comparison Table named on dashboard tiles but may not reach this page from every entry point.
> 
> **Rules**
> 
> - Default dashboard quick tools may use a non-navigating placeholder until launch.
> 
> **States**
> 
> - Inactive tile on dashboard vs reachable coming-soon page when visited directly.
> 
> ---
> 
> ### Global site header and footer
> 
> **What it does**
> 
> Standard site chrome surrounding the placeholder.
> 
> **User flow**
> 
> 1. User navigates elsewhere from header or footer.
> 
> **Rules**
> 
> - Same as sibling dashboard tool pages.
> 
> **States**
> 
> - Standard.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Direct URL
> - Dashboard quick tools (when eventually linked)
> - Application tools hub (when listed as disabled)
> - **Unknown / requires product clarification** for checklist task links
> 
> **Outbound**
> 
> - Progress dashboard (breadcrumb)
> - Header/footer destinations
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Coming soon message only |
> | Signed-in member | Coming soon message only |
> 
> ---
> 
> ## Important Business Rules
> 
> - Feature is planned but not implemented; avoid promising comparison capability in user-facing copy beyond “coming soon.”
> - When launched, comparison dimensions (states, hospitals, jobs, etc.) require product definition and a spec revision.
> - Page exists to prevent broken navigation from tools marketing references.
> 
> ---
> 
> ## Related Features
> 
> - Progress dashboard quick tools
> - Application tools hub (Check & Compare section when enabled)
> - Federal state compass (map)—live alternative for regional exploration
> - Document checker (also placeholder)

---

## Page: Application Tools Hub
- URL: https://freiburger-bund.com/en/tools
- Type: product-spec
- Section: Journey & Dashboard Tools
- Access: public
- Source: docs/product-knowledge/pages/tools.md
- Updated: 2026-09-21

### Purpose
Centralize discovery of document-creation and planning tools—CV builder, motivation letter, regional compass, visa navigator, cost calculator, and future check/compare tools—so users can find the right tool from one marketing hub page.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Page hero
> 
> **What it does**
> 
> Introduces the Application Tools area with a badge, title, subtitle, and optional hero image on desktop.
> 
> **User flow**
> 
> 1. User arrives from homepage Practical Tools card, header Tools menu, or direct link.
> 2. User reads “Application Tools” positioning copy about preparing and managing applications with confidence.
> 
> **Rules**
> 
> - Hero content is editable without code changes.
> - Desktop layout may show a tilted card-style hero image; mobile stacks content.
> 
> **States**
> 
> - **Staging note:** hero visible; lower sections depend on published content configuration.
> 
> ---
> 
> ### Create and build section
> 
> **What it does**
> 
> Groups tools for creating application documents, typically CV Builder and Motivation Letter Generator.
> 
> **User flow**
> 
> 1. User scrolls to the Create & Build section.
> 2. User reads each tool card with icon, title, description, and call-to-action.
> 3. User clicks **Open Tool** (or equivalent) on an active card to launch the tool.
> 
> **Rules**
> 
> - Each card requires title, description, link, and call-to-action to appear.
> - Section hidden if no valid tools are configured.
> 
> **States**
> 
> - **Active tool:** clickable card with hover emphasis.
> - **Misconfigured tool:** omitted from section.
> 
> ---
> 
> ### Check and compare section
> 
> **What it does**
> 
> Groups planning and verification tools: Federal State Compass, Visa Navigator, Document Checker, Cost Calculator, and Comparison Table.
> 
> **User flow**
> 
> 1. User scrolls to Check & Compare.
> 2. User opens active tools such as map or visa navigator.
> 3. User sees disabled cards for tools not yet available.
> 
> **Rules**
> 
> - Tools can be marked disabled; disabled cards appear muted and are not clickable.
> - Active tools link to their dedicated pages (map, visa navigator, cost calculator, etc.).
> 
> **States**
> 
> - **Active:** clickable with hover shadow.
> - **Disabled:** visually muted, no navigation (typical for document checker, cost calculator, comparison table until CMS enables them).
> - **Empty section:** hidden if no tools configured.
> 
> ---
> 
> ### Tool card layout
> 
> **What it does**
> 
> Presents tools in a responsive grid with icon, title, description, and action button with arrow.
> 
> **User flow**
> 
> 1. User scans grid on mobile (stacked) or desktop (multi-column).
> 2. User selects a tool.
> 
> **Rules**
> 
> - Responsive grid adapts to screen size.
> 
> **States**
> 
> - Hover/active visual feedback on enabled cards only.
> 
> ---
> 
> ### CMS-managed content
> 
> **What it does**
> 
> Allows operators to change section titles, tool names, descriptions, links, disabled flags, and hero content per language.
> 
> **User flow**
> 
> 1. Content updates appear on next publish without redeploying the application.
> 
> **Rules**
> 
> - Page returns not-found if the tools page is not published in the CMS for a locale.
> 
> **States**
> 
> - **Unpublished:** page unavailable (404).
> - **Partial config:** only configured sections and tools render.
> 
> ---
> 
> ### No authentication gate
> 
> **What it does**
> 
> Shows the same tool catalog to guests and signed-in users.
> 
> **User flow**
> 
> 1. Guest or member browses and opens tools equally from this hub.
> 
> **Rules**
> 
> - Individual tools may have their own sign-in requirements downstream (e.g. saving a CV).
> 
> **States**
> 
> - Identical hub experience for all roles.
> 
> ---
> 
> ### Embedded page header (duplicate chrome)
> 
> **What it does**
> 
> On this page, a full marketing header block may appear within page content in addition to the global site header.
> 
> **User flow**
> 
> 1. User may see duplicated header navigation elements within the page body on some configurations.
> 
> **Rules**
> 
> - **Unknown / requires product clarification:** whether duplicate header is intentional for all locales.
> 
> **States**
> 
> - Observed on staging with nested header elements.
> 
> ---
> 
> ### Global site footer and cookie consent
> 
> **What it does**
> 
> Standard footer, newsletter, legal links, and cookie banner.
> 
> **User flow**
> 
> 1. User subscribes or navigates to support/legal pages.
> 
> **Rules**
> 
> - Same as other CMS marketing pages.
> 
> **States**
> 
> - Standard.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Homepage Practical Tools **Explore** card
> - Header Tools navigation
> - Footer or portal cross-links
> - Direct URL with localized equivalents (German, French, Arabic addresses)
> 
> **Outbound**
> 
> - CV builder
> - Motivation letter builder
> - Federal state compass (interactive map)
> - Visa navigator
> - Cost calculator (when enabled)
> - Document checker and comparison table (when enabled; otherwise disabled on hub)
> - Job portal document tools (separate job-area tools, not this hub)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full hub browsing; downstream tools may prompt sign-in when saving |
> | Signed-in member | Same hub; may have saved documents in job tools |
> 
> ---
> 
> ## Important Business Rules
> 
> - This hub (`/tools`) is distinct from the job portal’s application tools area under job navigation.
> - Disabled tools remain visible on the hub to communicate roadmap without broken links when configured that way.
> - Active vs disabled state is controlled per tool in content configuration, independent of whether a dedicated page exists (cost calculator page is live even if hub card is disabled).
> - All four site languages supported when CMS content is published per locale.
> - Section visibility depends on having at least one valid tool entry per section.
> 
> ---
> 
> ## Related Features
> 
> - Progress dashboard quick tools
> - Job portal application tools (CV, motivation letter, documents)
> - Federal state compass, visa navigator, cost calculator
> - Document checker and comparison table (planned)
> - Homepage Practical Tools entry card

---

## Page: Login
- URL: https://freiburger-bund.com/en/login
- Type: product-spec
- Section: Authentication & Onboarding
- Access: public
- Source: docs/product-knowledge/pages/login.md
- Updated: 2026-09-21

### Purpose
Let existing members sign in with email and password or social accounts, complete two-factor verification when required, and return to the page they intended to visit before authentication.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Welcome and sign-in form
> 
> **What it does**
> 
> Presents a welcome-back heading, explanatory subtitle, email field, password field, and primary log-in action.
> 
> **User flow**
> 
> 1. User opens the login page from header, protected actions, or direct link.
> 2. User enters email and password.
> 3. User clicks **Log In**.
> 
> **Rules**
> 
> - Email and password are both required.
> - Invalid email format shows an inline validation error.
> - Empty password shows an inline validation error.
> 
> **States**
> 
> - **Default:** empty form ready for input.
> - **Loading:** log-in button shows loading state during submission.
> - **Validation error:** inline field errors before submit.
> 
> ---
> 
> ### Show or hide password
> 
> **What it does**
> 
> Lets the user toggle password visibility in the password field.
> 
> **User flow**
> 
> 1. User clicks show/hide password control.
> 2. Password characters become visible or masked.
> 
> **Rules**
> 
> - Optional convenience control; does not affect validation.
> 
> **States**
> 
> - Masked (default) or visible.
> 
> ---
> 
> ### Forgot password link
> 
> **What it does**
> 
> Navigates to the password reset request flow while preserving the intended return destination after future sign-in.
> 
> **User flow**
> 
> 1. User clicks **Reset** (forgot password link).
> 2. User lands on forgot-password page.
> 
> **Rules**
> 
> - Return destination carried through the auth flow where supported.
> 
> **States**
> 
> - Always available on login form.
> 
> ---
> 
> ### Create account link
> 
> **What it does**
> 
> Navigates to registration while preserving the intended return destination.
> 
> **User flow**
> 
> 1. User clicks **Create Account**.
> 2. User lands on registration step 1.
> 
> **Rules**
> 
> - Return destination preserved for post-registration navigation.
> 
> **States**
> 
> - Always visible for guests.
> 
> ---
> 
> ### Social sign-in
> 
> **What it does**
> 
> Offers sign-in with Apple, Google, and LinkedIn through icon buttons below an “Or Sign Up With” divider.
> 
> **User flow**
> 
> 1. User clicks a social provider button.
> 2. User completes provider authentication externally.
> 3. User returns to the site with session established.
> 
> **Rules**
> 
> - Intended return destination is passed through the social sign-in flow.
> - Microsoft sign-in is not offered in the current product.
> 
> **States**
> 
> - **Loading:** provider redirect in progress.
> - **Failure:** error feedback via notification.
> 
> ---
> 
> ### Return destination handling
> 
> **What it does**
> 
> Remembers where the user wanted to go before login and sends them there after successful authentication when safe.
> 
> **User flow**
> 
> 1. User attempts a protected action and is sent to login with a return destination.
> 2. After successful login, user is redirected to that destination unless blocked by onboarding requirements.
> 
> **Rules**
> 
> - Return destinations that point to other auth pages (login, register, verify, forgot/reset password) are normalized to home to prevent redirect loops.
> - Invitation links may pre-fill email when return URL contains a valid invitation token.
> 
> **States**
> 
> - **With return destination:** post-login navigation respects it when allowed.
> - **Without return destination:** user lands on home or next required onboarding step.
> 
> ---
> 
> ### Two-factor authentication challenge
> 
> **What it does**
> 
> When the account has two-factor authentication enabled, replaces the password form inline with a six-digit code entry screen on the same page.
> 
> **User flow**
> 
> 1. User submits valid email and password.
> 2. System sends a verification code and shows OTP entry UI with the target email displayed.
> 3. User enters six numeric digits and submits.
> 4. User is signed in on success.
> 
> **Rules**
> 
> - Code must be exactly six numeric digits.
> - Resend is unavailable for 30 seconds, then becomes clickable.
> - Successful code send shows confirmation feedback.
> 
> **States**
> 
> - **Password step:** standard login form.
> - **OTP step:** inline code entry on same page.
> - **Resend countdown:** timer visible until resend allowed.
> - **OTP error:** server message shown via notification.
> 
> ---
> 
> ### Unverified account handling
> 
> **What it does**
> 
> Redirects users whose email is not yet verified to the email verification flow instead of completing login.
> 
> **User flow**
> 
> 1. User submits correct credentials for an unverified account.
> 2. User is redirected to email verification with credentials temporarily held for the verification step.
> 
> **Rules**
> 
> - Login cannot complete until email is verified.
> 
> **States**
> 
> - Redirect to verification flow.
> 
> ---
> 
> ### Post-login routing
> 
> **What it does**
> 
> After successful authentication, routes the user through any required setup steps before final destination.
> 
> **User flow**
> 
> 1. User signs in successfully.
> 2. If username is missing, user is sent to username setup first.
> 3. If onboarding questions are incomplete, user is sent to registration resume (onboarding step).
> 4. Otherwise user goes to preserved return destination or home.
> 
> **Rules**
> 
> - Username setup takes priority over return destination.
> - Incomplete onboarding overrides most destinations except community and embed routes at site level.
> 
> **States**
> 
> - **Needs username:** forced username setup.
> - **Needs onboarding:** registration resume mode.
> - **Complete:** return destination or home.
> 
> ---
> 
> ### Auth page layout
> 
> **What it does**
> 
> Provides a focused sign-in experience with site logo, language switcher, form column, and desktop hero illustration.
> 
> **User flow**
> 
> 1. User switches language from the corner control.
> 2. User clicks logo to return home, or to onboarding resume if onboarding is incomplete while signed in.
> 
> **Rules**
> 
> - Arabic uses right-to-left layout adjustments.
> - No main site header or footer on this page.
> 
> **States**
> 
> - Desktop shows side hero image; mobile form-focused layout.
> 
> ---
> 
> ### Error and success feedback
> 
> **What it does**
> 
> Communicates login outcomes through notifications and inline validation.
> 
> **User flow**
> 
> 1. User sees success notification on login or when 2FA code is sent.
> 2. User sees error notification for wrong credentials, server errors, or failed 2FA.
> 3. User sees generic retry message on unexpected network failure.
> 
> **Rules**
> 
> - Server-provided messages shown when available.
> 
> **States**
> 
> - Toast notifications for success and error.
> 
> ---
> 
> ### Cookie consent
> 
> **What it does**
> 
> Shows cookie notification banner on the auth page like other public pages.
> 
> **User flow**
> 
> 1. User accepts all or opens settings to manage cookie categories.
> 
> **Rules**
> 
> - Same cookie policy as rest of site.
> 
> **States**
> 
> - Visible until consent recorded.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header **Login** link
> - Protected actions across site (bookmark, join, create event, etc.)
> - Registration “Already have an account?” link
> - Forgot-password **Back to Login**
> - Reset-password success redirect
> - Direct URL
> 
> **Outbound**
> 
> - Registration
> - Forgot password
> - Email verification (unverified accounts)
> - Username setup (missing username)
> - Registration onboarding resume (incomplete onboarding)
> - Preserved return destination or home
> - Social provider authentication (external)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Primary audience; full login form and social sign-in |
> | Signed-in member (complete profile) | Can visit page but typically navigates elsewhere |
> | Signed-in member (incomplete onboarding) | Logo may route to onboarding resume instead of home |
> 
> ---
> 
> ## Important Business Rules
> 
> - Login is the primary entry for returning members.
> - Two-factor authentication happens inline without a separate page.
> - Email verification blocks login completion for unverified accounts.
> - Post-login flow enforces username and onboarding completion before general site use.
> - Social sign-in preserves return intent where technically supported.
> - Password reset is a separate flow starting from the forgot-password link.
> 
> ---
> 
> ## Related Features
> 
> - Registration
> - Forgot password and reset password
> - Email verification
> - Username setup
> - Onboarding questions (registration step 4)
> - Personal progress dashboard (common post-onboarding destination)
> - Protected actions site-wide

---

## Page: Registration
- URL: https://freiburger-bund.com/en/register
- Type: product-spec
- Section: Authentication & Onboarding
- Access: public
- Source: docs/product-knowledge/pages/register.md
- Updated: 2026-09-21

### Purpose
Let new international healthcare professionals create an account through a four-step flow: credentials, profile details, email verification, and journey onboarding questions—establishing identity and initial journey phase placement.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Four-step progress indicator
> 
> **What it does**
> 
> Shows the user their position in registration (Step 01 of 04 through Step 04 of 04) with visual step dots.
> 
> **User flow**
> 
> 1. User advances through steps and sees updated progress indicator.
> 
> **Rules**
> 
> - Four steps total; step 4 uses full-width layout without side hero image.
> 
> **States**
> 
> - Current step highlighted in indicator.
> 
> ---
> 
> ### Step 1 — Create credentials
> 
> **What it does**
> 
> Collects email, password, and confirm password before advancing locally to step 2.
> 
> **User flow**
> 
> 1. User enters email and password twice.
> 2. User clicks **Next** (no server registration yet).
> 
> **Rules**
> 
> - Email required with valid format.
> - Password minimum 8 characters with at least one uppercase letter and one number.
> - Confirm password must match password (minimum 8 characters).
> - **Already have an account? Log in** link preserves return destination.
> - Social sign-up (Apple, Google, LinkedIn) available with return destination preserved.
> - Invitation token in return URL may pre-fill email.
> 
> **States**
> 
> - **Validation error:** inline errors on fields.
> - **Loading:** on social sign-up redirect.
> 
> ---
> 
> ### Step 2 — Set up account
> 
> **What it does**
> 
> Collects profile and professional information and submits registration to create the account.
> 
> **User flow**
> 
> 1. User navigates back to step 1 if needed.
> 2. User completes profile fields and accepts terms.
> 3. User clicks **Sign up**.
> 
> **Rules**
> 
> - First and last name required (minimum 2 characters each).
> - Username required: 3–20 characters, letters, numbers, underscore only; invalid characters stripped while typing.
> - Live username availability check with success indicator or “unavailable” error.
> - Username suggestions generated from name; user can tap a suggestion.
> - Email shown disabled from step 1.
> - Phone optional with country code selector.
> - Date of birth required: valid date, not in future, minimum age 10 years.
> - Gender required: male, female, other, prefer not to say.
> - Profession required: dentist, medicine, nursing, pharmacist.
> - Headline/position required (minimum 2 characters).
> - Terms and conditions checkbox required with link to terms page.
> 
> **States**
> 
> - **Username checking:** availability feedback in progress.
> - **Submit loading:** sign-up button loading.
> - **Error:** server message or generic retry notification.
> - **Success:** advance to step 3.
> 
> ---
> 
> ### Step 3 — Email verification
> 
> **What it does**
> 
> Verifies email ownership with a six-digit code sent after registration.
> 
> **User flow**
> 
> 1. User enters six-digit code.
> 2. User submits verification.
> 3. On success, session is established and user advances to step 4.
> 
> **Rules**
> 
> - Exactly six numeric digits required.
> - Target email displayed; if phone provided, last four digits of phone shown in prompt.
> - Resend available after 30-second countdown.
> - Invalid or expired code shows specific error; other failures show generic error.
> - User can navigate back to step 2.
> 
> **States**
> 
> - **Countdown:** resend disabled with timer.
> - **Success:** notification and advance to onboarding questions.
> 
> ---
> 
> ### Step 4 — Onboarding questions
> 
> **What it does**
> 
> Asks three yes/no journey questions to determine onboarding phase placement.
> 
> **User flow**
> 
> 1. User sees three-question timeline (visa, professional license, job offer).
> 2. User selects Yes or No for the current question.
> 3. User clicks **Continue** (disabled until an answer is selected).
> 4. After all questions or early exit rules, user is redirected to dashboard.
> 
> **Rules**
> 
> - Info note explains answers determine next onboarding phase.
> - Back from question 1 returns to step 3; back from questions 2–3 goes to previous question.
> - **Early exit:** answering **No** on question 1 or 2 marks onboarding complete and redirects to dashboard with success message.
> - **Question 3 completion:** onboarding complete, redirect to dashboard.
> - Save failure reverts answer and shows error.
> 
> **States**
> 
> - **Resume mode:** signed-in users with incomplete onboarding land directly on step 4 with prior answers restored.
> - **Loading:** selected answer shows loading during save.
> - **Continue disabled:** until Yes or No chosen.
> 
> ---
> 
> ### Registration layout
> 
> **What it does**
> 
> Provides auth-focused layout with logo, language switcher, form column, and hero image on steps 1–3.
> 
> **User flow**
> 
> 1. User switches language.
> 2. User clicks logo (home or onboarding resume if applicable).
> 
> **Rules**
> 
> - Step 4 drops side hero for full-width question card.
> - RTL support for Arabic.
> 
> **States**
> 
> - Steps 1–3: split layout with illustration.
> - Step 4: full-width onboarding card.
> 
> ---
> 
> ### Resume incomplete onboarding
> 
> **What it does**
> 
> Lets signed-in users who have not finished onboarding questions return directly to step 4.
> 
> **User flow**
> 
> 1. User is redirected from protected site areas or opens register with resume mode.
> 2. User completes remaining onboarding questions.
> 
> **Rules**
> 
> - Site-wide redirect to registration resume for incomplete onboarding on most routes.
> - Community and embed routes may be exempt from forced redirect.
> 
> **States**
> 
> - Resume mode skips steps 1–3.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header **Sign Up**
> - Login **Create Account** link
> - Homepage and journey CTAs
> - Forced redirect when onboarding incomplete
> - Direct URL with optional return destination
> 
> **Outbound**
> 
> - Login (step 1 link)
> - Terms and conditions page
> - Email verification (step 3, same page flow)
> - Progress dashboard (onboarding complete or early exit)
> - Social provider registration (external)
> - Home (logo, when allowed)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full steps 1–4 available |
> | Signed-in (incomplete onboarding) | Resume at step 4 with hydrated answers |
> | Signed-in (complete onboarding) | **Unknown / requires product clarification** whether register remains accessible |
> 
> ---
> 
> ## Important Business Rules
> 
> - Account creation requires email verification before onboarding questions finalize the session.
> - Username must be unique and meet character rules.
> - Minimum age 10 years for date of birth.
> - Profession selection is required and limited to healthcare categories offered in the dropdown.
> - Terms acceptance is mandatory.
> - Onboarding answers affect journey phase placement; early “No” answers can complete onboarding immediately.
> - Post-registration default destination is the personal progress dashboard.
> 
> ---
> 
> ## Related Features
> 
> - Login
> - Email verification (standalone flow if needed)
> - Username setup (separate step if username blank after social sign-up)
> - Personal progress dashboard
> - My Journey landing
> - Invitation-based registration pre-fill

---

## Page: Forgot Password
- URL: https://freiburger-bund.com/en/forgot-password
- Type: product-spec
- Section: Authentication & Onboarding
- Access: public
- Source: docs/product-knowledge/pages/forgot-password.md
- Updated: 2026-09-21

### Purpose
Let users request a password reset link by email and confirm that the request was sent, with option to resend if the message does not arrive.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Step 1 — Enter email
> 
> **What it does**
> 
> Collects the account email address and submits a password reset request.
> 
> **User flow**
> 
> 1. User opens forgot password from login **Reset** link or direct URL.
> 2. User reads instructions to enter email for a reset link.
> 3. User enters email and clicks **Next**.
> 
> **Rules**
> 
> - Email field uses standard format validation.
> - Success notification shown on submit even when server handling fails silently from user perspective on initial request (**Unknown / requires product clarification** for exact anti-enumeration behavior).
> - Advances to step 2 on successful submit.
> 
> **States**
> 
> - **Default:** email entry form.
> - **Loading:** Next button loading during submit.
> - **Step 2:** advances after submit.
> 
> ---
> 
> ### Back to login
> 
> **What it does**
> 
> Returns user to the login page from either step.
> 
> **User flow**
> 
> 1. User clicks **Back to Login** at top of page.
> 
> **Rules**
> 
> - Available on both steps.
> 
> **States**
> 
> - Always visible.
> 
> ---
> 
> ### Social sign-in options
> 
> **What it does**
> 
> Offers Apple, Google, and LinkedIn sign-in below the email form on step 1 as an alternative to password reset.
> 
> **User flow**
> 
> 1. User clicks a social provider instead of email reset.
> 
> **Rules**
> 
> - Return destination defaults to home for social flow from this page.
> 
> **States**
> 
> - Same provider set as login (no Microsoft).
> 
> ---
> 
> ### Step 2 — Check your email
> 
> **What it does**
> 
> Confirms that a reset link was sent and displays the submitted email address.
> 
> **User flow**
> 
> 1. User sees “Check your email” heading and success illustration.
> 2. User reads confirmation message naming their email.
> 3. User checks inbox for reset link.
> 
> **Rules**
> 
> - Reset mechanism is an email **link**, not an OTP on this page.
> - Link leads to reset-password page with token and email parameters.
> 
> **States**
> 
> - **Confirmation view:** step 2 static content.
> - Hero illustration changes from step 1 to step 2 imagery.
> 
> ---
> 
> ### Resend reset email
> 
> **What it does**
> 
> Lets user request another reset email from step 2.
> 
> **User flow**
> 
> 1. User clicks **Resend email** under “Didn’t receive email?”
> 2. System resends if stored email is available.
> 
> **Rules**
> 
> - Missing stored email shows error notification.
> - Success shows server confirmation message.
> - Failure shows generic error notification.
> 
> **States**
> 
> - **Resend available:** after step 1 completed.
> - **Error:** no email on record in session.
> 
> ---
> 
> ### Auth page layout
> 
> **What it does**
> 
> Focused auth shell with logo, language switcher, form area, and step-specific hero illustrations.
> 
> **User flow**
> 
> 1. User switches language.
> 2. User uses logo navigation.
> 
> **Rules**
> 
> - Step 1 hero: thinking illustration.
> - Step 2 hero: mobile phone illustration.
> - No main site header/footer.
> 
> **States**
> 
> - Two-step internal flow on one route.
> 
> ---
> 
> ### Cookie consent
> 
> **What it does**
> 
> Standard cookie banner on auth page.
> 
> **User flow**
> 
> 1. User manages cookie preferences or accepts all.
> 
> **Rules**
> 
> - Same as other auth pages.
> 
> **States**
> 
> - Until consent given.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Login **Reset** / forgot password link
> - Reset-password invalid link **Resend email** path
> - Direct URL
> 
> **Outbound**
> 
> - Login (back link)
> - Reset password (via email link, not from this page UI)
> - Social provider authentication (external)
> - Home (logo)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Primary audience |
> | Signed-in member | Can access page; password reset still email-based |
> 
> No role gate on this page.
> 
> ---
> 
> ## Important Business Rules
> 
> - Password recovery uses email link, not SMS OTP on this screen.
> - Two-step flow stays on the same route with internal step state.
> - User must use the emailed link within that link’s validity period (**Unknown / requires product clarification** for exact expiry duration).
> - Resend requires prior successful step 1 submission with email stored for the session.
> 
> ---
> 
> ## Related Features
> 
> - Login
> - Reset password (link destination)
> - Social sign-in (alternative to password recovery)

---

## Page: Reset Password
- URL: https://freiburger-bund.com/en/reset-password
- Type: product-spec
- Section: Authentication & Onboarding
- Access: public
- Source: docs/product-knowledge/pages/reset-password.md
- Updated: 2026-09-21

### Purpose
Let users who received a password reset email link set a new password after the system validates their reset token.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Reset link validation
> 
> **What it does**
> 
> On page load, validates the token and email from the reset link before showing the password form.
> 
> **User flow**
> 
> 1. User clicks reset link in email.
> 2. User sees loading state while link is verified.
> 3. Valid link shows password form; invalid link shows error state.
> 
> **Rules**
> 
> - Link must include token and email query parameters.
> - Valid verification cached for the browser session to avoid re-check on refresh.
> - Expired or invalid token shows error notification and invalid-link screen.
> 
> **States**
> 
> - **Loading:** verifying link.
> - **Valid:** password form shown.
> - **Invalid:** error message with recovery action.
> 
> ---
> 
> ### Invalid link recovery
> 
> **What it does**
> 
> When the reset link is missing or invalid, shows an error and offers path back to forgot-password.
> 
> **User flow**
> 
> 1. User sees red error message on invalid link.
> 2. User clicks **Resend email** or equivalent action to return to forgot-password flow.
> 
> **Rules**
> 
> - User cannot set password without valid token.
> 
> **States**
> 
> - **Invalid/missing link:** error card only, no password fields.
> 
> ---
> 
> ### Create new password form
> 
> **What it does**
> 
> Collects new password and confirmation, then submits the reset.
> 
> **User flow**
> 
> 1. User reads “Create password” heading and instructions.
> 2. User enters new password and confirmation.
> 3. User clicks **Reset password**.
> 
> **Rules**
> 
> - New password minimum 8 characters with uppercase letter, number, and special character.
> - Confirm password minimum 8 characters and must match new password.
> - Inline validation errors on fields before/at submit.
> 
> **States**
> 
> - **Default:** empty fields.
> - **Validation error:** inline messages.
> - **Submit loading:** button loading during request.
> 
> ---
> 
> ### Successful password reset
> 
> **What it does**
> 
> Confirms success and sends user to login to sign in with the new password.
> 
> **User flow**
> 
> 1. User submits valid matching passwords.
> 2. Success notification appears.
> 3. Session verification cache cleared.
> 4. User redirected to login page.
> 
> **Rules**
> 
> - User must log in again with new password; not auto-signed-in.
> 
> **States**
> 
> - Success toast then redirect to login.
> 
> ---
> 
> ### Failed password reset
> 
> **What it does**
> 
> Shows server error message and allows retry when reset submission fails.
> 
> **User flow**
> 
> 1. User sees error notification with server message when available.
> 2. User can edit passwords and resubmit.
> 
> **Rules**
> 
> - Submit re-enabled after failure.
> 
> **States**
> 
> - Error notification; form remains editable.
> 
> ---
> 
> ### Auth page layout
> 
> **What it does**
> 
> Standard auth shell with logo, language switcher, form column, and laptop hero illustration.
> 
> **User flow**
> 
> 1. User switches language.
> 2. User uses logo to navigate home.
> 
> **Rules**
> 
> - RTL spacing adjustments for Arabic.
> - No main site header/footer.
> 
> **States**
> 
> - Fixed hero image for this page.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Password reset email link (primary entry)
> - Direct URL with token and email parameters (must be valid)
> 
> **Outbound**
> 
> - Login (after successful reset)
> - Forgot password (from invalid link recovery)
> - Home (logo)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Primary audience |
> | Signed-in member | Can use reset link while logged in; still redirected to login after success |
> 
> ---
> 
> ## Important Business Rules
> 
> - Reset links are single-purpose and validated before password entry.
> - New password policy is stricter than registration (includes special character requirement).
> - Successful reset does not automatically establish a signed-in session.
> - Token validity is time-limited (**Unknown / requires product clarification** for exact duration).
> 
> ---
> 
> ## Related Features
> 
> - Forgot password (request link)
> - Login (post-reset destination)
> - Registration password rules (similar but not identical requirements)

---

## Page: Course Journey Entry
- URL: https://freiburger-bund.com/en/course
- Type: cms
- Section: Authentication & Onboarding
- Access: public
- Source: docs/product-knowledge/pages/course.md
- Updated: 2026-09-21

### Purpose
Direct authenticated members who need to complete FIA language course registration to the external Freiburg International Academy website, where course enrollment is handled.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Authentication requirement
> 
> **What it does**
> 
> Restricts the page to signed-in users; guests are redirected to login with return destination pointing back here.
> 
> **User flow**
> 
> 1. Guest attempts to open the page.
> 2. Guest is sent to login.
> 3. After login, guest returns to this page if onboarding is complete.
> 
> **Rules**
> 
> - Guests cannot view course journey content without signing in.
> - Incomplete onboarding redirects to registration resume before this page renders.
> 
> **States**
> 
> - **Guest:** redirect to login.
> - **Incomplete onboarding:** redirect to registration resume.
> - **Authenticated and onboarded:** page content shown.
> 
> ---
> 
> ### Course journey heading
> 
> **What it does**
> 
> Displays the course journey title and subtitle prompting the user to complete registration.
> 
> **User flow**
> 
> 1. Signed-in user reads heading and supporting line about completing registration.
> 
> **Rules**
> 
> - Informational content only on this page.
> 
> **States**
> 
> - Static text.
> 
> ---
> 
> ### External registration action
> 
> **What it does**
> 
> Opens the FIA Academy website in a new browser tab for course registration.
> 
> **User flow**
> 
> 1. User clicks **Register** button.
> 2. External FIA Academy site opens in a new tab with locale-appropriate URL.
> 
> **Rules**
> 
> - German locale opens academy root URL; other locales use localized path on external site.
> - Does not open the internal multi-step course registration form on this page.
> - External site handles actual course enrollment.
> 
> **States**
> 
> - Button always visible for qualified users.
> 
> ---
> 
> ### Minimal auth layout
> 
> **What it does**
> 
> Shows logo and language switcher without main site header, footer, or portal navigation.
> 
> **User flow**
> 
> 1. User switches language.
> 2. User clicks logo for standard auth logo behavior.
> 
> **Rules**
> 
> - Intentionally stripped-down chrome compared to main site pages.
> 
> **States**
> 
> - Auth-only shell.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Footer **FIA Course Registration** link
> - Header or support links referencing course journey
> - Direct URL (authenticated)
> - Post-login return destination
> 
> **Outbound**
> 
> - Login (guests)
> - Registration resume (incomplete onboarding)
> - External FIA Academy website (primary action, new tab)
> - Home (logo)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in (incomplete onboarding) | Redirected to registration resume |
> | Signed-in (onboarding complete) | Sees page and external register action |
> 
> ---
> 
> ## Important Business Rules
> 
> - Course enrollment primary path is external FIA Academy, not the internal registration wizard.
> - Internal `/course/registration` form exists separately for a legacy or alternate in-app flow documented in its own spec.
> - Page is a bridge, not the enrollment form itself.
> - Authentication and completed onboarding are prerequisites.
> 
> ---
> 
> ## Related Features
> 
> - Course registration form (internal multi-step flow)
> - Registration and onboarding
> - Footer FIA Course Registration link
> - Login

---

## Page: Course Registration Form
- URL: https://freiburger-bund.com/en/course/registration
- Type: product-spec
- Section: Authentication & Onboarding
- Access: public
- Source: docs/product-knowledge/pages/course-registration.md
- Updated: 2026-09-21

### Purpose
Guide signed-in members through a six-step in-app course registration wizard to select course type, profession, situation, visa status, package, and required documents—then submit an enrollment request.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Access and prerequisites
> 
> **What it does**
> 
> Requires signed-in session and completed onboarding before the wizard is shown.
> 
> **User flow**
> 
> 1. Guest opens page → redirected to login with return URL.
> 2. Signed-in user with incomplete onboarding → redirected to registration resume.
> 3. Eligible user sees full registration wizard.
> 
> **Rules**
> 
> - Same gating as course journey entry page.
> 
> **States**
> 
> - **Unauthorized:** login redirect.
> - **Incomplete onboarding:** registration resume redirect.
> - **Eligible:** wizard visible.
> 
> ---
> 
> ### Page chrome and progress
> 
> **What it does**
> 
> Shows full site header, footer, breadcrumb (Registration), section header, page header, and a labeled progress bar.
> 
> **User flow**
> 
> 1. User orients via breadcrumb and headers.
> 2. User tracks progress percentage as steps advance.
> 
> **Rules**
> 
> - Progress approximates: step 1 ~12%, 2 ~25%, 3 ~48%, 4 ~60%, 5 ~84%, 6 ~100%.
> - Form progress saved in browser storage and restored on return visit until successful submission.
> 
> **States**
> 
> - Progress bar updates each step.
> - Restored session shows last saved step and selections.
> 
> ---
> 
> ### Step 1 — Course type and B2 certificate
> 
> **What it does**
> 
> User selects funded or self-payer course type and optionally indicates B2 German certificate possession.
> 
> **User flow**
> 
> 1. User selects one course type card (required).
> 2. User optionally selects Yes/No for B2 certificate.
> 3. User clicks **Next** when course type selected.
> 
> **Rules**
> 
> - **Next** disabled until course type chosen.
> - B2 selection optional for enabling Next.
> 
> **States**
> 
> - **Next disabled:** no course type.
> - **Next enabled:** course type selected.
> 
> ---
> 
> ### Step 2 — Profession
> 
> **What it does**
> 
> User selects healthcare profession or “other.”
> 
> **User flow**
> 
> 1. User picks medicine, dentistry, pharmacy, nursing, or other (with disclaimer on other).
> 2. User clicks **Next** when profession selected.
> 
> **Rules**
> 
> - **Next** disabled until profession chosen.
> - Choosing **other** skips steps 3 and 4 later in the flow.
> 
> **States**
> 
> - Profession required to proceed.
> 
> ---
> 
> ### Step 3 — Living and degree situation
> 
> **What it does**
> 
> User selects one of four situational cards describing residence and degree origin.
> 
> **User flow**
> 
> 1. User selects situation matching their case (e.g. live outside Germany with EU degree).
> 2. User clicks **Next**.
> 
> **Rules**
> 
> - Skipped entirely when profession is **other**.
> - **Next** disabled until one card selected.
> 
> **States**
> 
> - Omitted for “other” profession path.
> 
> ---
> 
> ### Step 4 — Visa or residence permit
> 
> **What it does**
> 
> User answers Yes/No whether they hold a German visa or residence permit.
> 
> **User flow**
> 
> 1. User reads contextual descriptions (wording differs for funded vs self-payer).
> 2. User selects Yes or No.
> 3. User clicks **Next** (always enabled on this step).
> 
> **Rules**
> 
> - Skipped when profession is **other**.
> - No required-selection gate blocking Next on this step.
> 
> **States**
> 
> - Omitted for “other” profession path.
> 
> ---
> 
> ### Step 5 — Package selection
> 
> **What it does**
> 
> Loads matching course packages based on prior answers and lets user choose one to register.
> 
> **User flow**
> 
> 1. User waits while packages load.
> 2. User compares packages in a table showing language/module columns (A1, A2, B1, B2, FSP, KP) with inclusion checkmarks.
> 3. User clicks **Register** on a package row to select and advance.
> 
> **Rules**
> 
> - Packages filtered by course type, profession, and situation answers.
> - Selecting a package auto-advances to step 6.
> - **Previous** returns to prior step.
> 
> **States**
> 
> - **Loading:** spinner and loading message.
> - **Error:** failure message with reload retry.
> - **Empty:** no packages match; message and back action.
> - **Populated:** comparison table with register buttons.
> 
> ---
> 
> ### Step 6 — Document submission
> 
> **What it does**
> 
> Collects required uploads and privacy acceptance before final submit.
> 
> **User flow**
> 
> 1. User reads submission instructions.
> 2. User uploads required documents via file picker cards.
> 3. User accepts privacy policy checkbox.
> 4. User submits enrollment.
> 
> **Rules**
> 
> - **Standard profession path required uploads:** visa/residence copy, qualifications copy, completed German language test results.
> - **Optional:** CV upload.
> - **Other profession path:** only language test upload required; visa, qualifications, and CV sections hidden.
> - Each upload shows max file size hint and “Uploaded” status after selection.
> - Privacy checkbox required; policy link present.
> - Submit disabled until required uploads and privacy acceptance satisfied.
> - Submit shows “Submitting…” during processing.
> 
> **States**
> 
> - **Incomplete:** submit disabled.
> - **Submitting:** in progress.
> - **Upload failure:** notification if cloud upload fails.
> - **Validation failure:** notification if required items missing at submit.
> - **Submission failure:** server error notification.
> - **Success:** success notification, cleared saved progress, redirect to homepage.
> 
> ---
> 
> ### Navigation shortcuts for “other” profession
> 
> **What it does**
> 
> Skips situational and visa steps when profession is “other.”
> 
> **User flow**
> 
> 1. User selects **other** on step 2 and continues.
> 2. Wizard jumps from step 2 to step 5.
> 3. Going back from step 5 returns to step 2 (not steps 3–4).
> 
> **Rules**
> 
> - Steps 3–4 hidden on this path.
> 
> **States**
> 
> - Abbreviated five-step effective path (2 → 5 → 6 with renumbered progress).
> 
> ---
> 
> ### Form persistence
> 
> **What it does**
> 
> Saves step number and selections locally so users can leave and return.
> 
> **User flow**
> 
> 1. User partially completes wizard and leaves.
> 2. User returns later and continues from saved step.
> 
> **Rules**
> 
> - Cleared after successful submission only.
> 
> **States**
> 
> - Restored wizard state on return.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Direct URL (authenticated)
> - **Unknown / requires product clarification** for live site links; footer FIA registration currently points to external academy via `/course` entry rather than this wizard
> 
> **Outbound**
> 
> - Homepage (successful submission)
> - Login (guests)
> - Registration resume (incomplete onboarding)
> - Previous steps within wizard
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Cannot access; login redirect |
> | Signed-in (incomplete onboarding) | Registration resume redirect |
> | Signed-in (onboarding complete) | Full wizard access |
> 
> ---
> 
> ## Important Business Rules
> 
> - Wizard is authenticated-only and requires completed member onboarding.
> - Package availability depends on cumulative answers from earlier steps.
> - Document requirements differ materially for “other” profession vs standard healthcare professions.
> - Successful submission ends on homepage, not dashboard.
> - Progress persists locally until submit succeeds.
> - Privacy acceptance mandatory before submit.
> 
> ---
> 
> ## Related Features
> 
> - Course journey entry (external FIA Academy path)
> - Registration and onboarding
> - Login
> - Homepage

---

## Page: User Profile — Public Profile
- URL: https://freiburger-bund.com/en/user/example-user
- Type: product-spec
- Section: Account & Social
- Access: public
- Source: docs/product-knowledge/pages/user-profile.md
- Updated: 2026-09-21

### Purpose
Let members present a professional identity to the community, let others discover credentials and skills, and support connection, messaging, and endorsement actions subject to privacy settings.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Profile header
> 
> **What it does**
> 
> Displays cover photo, profile photo, display name, professional title, verification badge, headline, language skills, location, connection count, and mutual connections summary.
> 
> **User flow**
> 
> 1. User opens a profile by username.
> 2. User reads identity information at top of page.
> 3. Signed-in viewer may see mutual connection avatars and count when permitted.
> 
> **Rules**
> 
> - Cover and profile photos show gradient or initials fallback when unset.
> - Connection count and language badges shown only when profile content is fully visible.
> - Profile owner sees edit controls for photo, cover, and basic info.
> 
> **States**
> 
> - **Full visibility:** all header fields populated per data and privacy.
> - **Partial visibility:** private profile restrictions apply (see below).
> 
> ---
> 
> ### Privacy and account states
> 
> **What it does**
> 
> Controls how much profile content visitors see based on public/private setting, connection status, and account hibernation.
> 
> **User flow**
> 
> 1. Visitor opens a private profile without connection → sees header plus privacy banner; detailed sections hidden.
> 2. Connected user or owner on private profile → full content shown.
> 3. Public profile → full content for everyone including guests.
> 4. Hibernated account (visitor) → unavailable message with no details.
> 5. Hibernated account (owner) → normal owner experience.
> 
> **Rules**
> 
> - Private profile requires accepted connection (or ownership) for section content.
> - Public profiles emit discoverable metadata for search engines.
> 
> **States**
> 
> - Private blocked, private full, public, hibernated visitor, hibernated owner.
> 
> ---
> 
> ### Connection actions
> 
> **What it does**
> 
> Lets signed-in users send, approve, reject, or remove connection requests and message connected users.
> 
> **User flow**
> 
> 1. Guest clicks connect or message → sign-in prompt.
> 2. No relationship → Connect sends request with feedback.
> 3. Pending (sent) → disabled pending state.
> 4. Pending (received) → Approve and Reject with loading states.
> 5. Connected → Message and Remove connection available.
> 
> **Rules**
> 
> - One connection relationship per pair of users.
> - Loading skeleton while connection status resolves.
> 
> **States**
> 
> - Connect, pending, approve/reject, connected, guest prompt.
> 
> ---
> 
> ### Profile verification (owner)
> 
> **What it does**
> 
> Shows verification status and entry to start or retry identity verification.
> 
> **User flow**
> 
> 1. Owner sees start verification, in-progress, approved badge, or rejected with retry.
> 
> **Rules**
> 
> - Verification status visible on owner profile header.
> 
> **States**
> 
> - Not started, in progress, approved, rejected.
> 
> ---
> 
> ### About section
> 
> **What it does**
> 
> Displays free-text professional summary; owner can edit in dialog with character limit.
> 
> **User flow**
> 
> 1. User reads about text when present.
> 2. Owner opens edit dialog, updates text (up to ~2,600 characters with live counter), saves.
> 
> **Rules**
> 
> - Hidden entirely for visitors when empty.
> - Owner always sees section with edit option.
> 
> **States**
> 
> - Populated, empty (owner only), hidden (visitor + empty).
> 
> ---
> 
> ### Education and experience sections
> 
> **What it does**
> 
> Lists university education, internships, dissertation/thesis, medical training, teaching, other activities, memberships, and publications with dates and locations.
> 
> **User flow**
> 
> 1. User browses structured CV-style sections when visible.
> 2. Owner adds, edits, or deletes entries per section.
> 
> **Rules**
> 
> - Sections hidden when private profile blocked for viewer.
> - Empty sections may show placeholder or hide for visitors.
> 
> **States**
> 
> - Populated list, empty, hidden (privacy).
> 
> ---
> 
> ### Skills and endorsements
> 
> **What it does**
> 
> Shows language and digital skills with proficiency; visitors can endorse skills; owner can edit skill lists inline.
> 
> **User flow**
> 
> 1. User reads skill lists with proficiency levels.
> 2. Signed-in visitor endorses a skill (sign-in required for guests).
> 3. Owner sees endorser names on hover and endorsement counts.
> 4. Owner enters inline edit mode for skills.
> 
> **Rules**
> 
> - Endorsements require signed-in account.
> - Endorsement counts displayed per skill.
> 
> **States**
> 
> - With endorsements, without endorsements, owner edit mode.
> 
> ---
> 
> ### Owner analytics teaser
> 
> **What it does**
> 
> Shows profile view count for last 90 days with link to full analytics (owner only).
> 
> **User flow**
> 
> 1. Owner reads private view count summary.
> 2. Owner follows link to analytics page.
> 
> **Rules**
> 
> - Visible only to profile owner.
> 
> **States**
> 
> - Count displayed when analytics available.
> 
> ---
> 
> ### Edit profile shortcuts
> 
> **What it does**
> 
> Routes owner to account settings for full profile editor and in-page edits for photos and sections.
> 
> **User flow**
> 
> 1. Owner clicks edit profile → account settings profile editor.
> 2. Owner uses inline section edits or photo/cover edit buttons.
> 
> **Rules**
> 
> - Basic profile redirect goes to account settings, not inline-only fields.
> 
> **States**
> 
> - Edit controls visible only to owner.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Global search user results
> - Connection lists, chat, community mentions
> - Direct URL with username
> - Notification links to profiles
> 
> **Outbound**
> 
> - Account settings (owner edit)
> - Profile analytics (owner)
> - Direct chat (connected users)
> - Sign-in (guest actions)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | View public profiles; connect/endorse/message prompt sign-in |
> | Signed-in member | Connection actions, endorsements, mutual connections |
> | Profile owner | Full edit access, verification, analytics |
> | Viewer of private profile | Header only until connected |
> 
> ---
> 
> ## Important Business Rules
> 
> - Invalid or unknown username shows not-found page.
> - Private profiles protect detailed sections until connection accepted.
> - Hibernated accounts appear unavailable to others but remain manageable by owner.
> - Profile view recorded when signed-in user views another person’s profile.
> - Incomplete onboarding does not block viewing profiles.
> 
> ---
> 
> ## Related Features
> 
> - [Connections](connections.md)
> - [Chat](chat.md)
> - [Settings — Account](settings-account.md)
> - [Settings — Visibility](settings-visibility.md)
> - [Global Search](search.md)

---

## Page: Settings — Account
- URL: https://freiburger-bund.com/en/settings/account
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/settings-account.md
- Updated: 2026-09-21

### Purpose
Let signed-in members manage profile information, app preferences, and account lifecycle actions (hibernate or close account) from a structured settings hub.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Protected access and settings layout
> 
> **What it does**
> 
> Restricts settings to signed-in users with completed onboarding and provides sidebar navigation on desktop and collapsible section picker on mobile.
> 
> **User flow**
> 
> 1. Guest is redirected to login with return URL.
> 2. Incomplete onboarding redirects to registration with resume flag.
> 3. User navigates account, security, notifications, and visibility sections from sidebar.
> 
> **Rules**
> 
> - Shared settings shell across all settings routes.
> - Return URL preserved through login redirect.
> 
> **States**
> 
> - **Authorized:** hub visible.
> - **Guest:** login redirect.
> - **Incomplete onboarding:** registration redirect.
> 
> ---
> 
> ### Account overview hub
> 
> **What it does**
> 
> Groups settings into Profile Information, Preferences, and Account Management with current values shown on rows where applicable.
> 
> **User flow**
> 
> 1. User lands on account settings hub.
> 2. User taps a row to open detail sub-page.
> 3. User uses back to return to hub.
> 
> **Rules**
> 
> - In-page navigation without full page reload for sub-pages.
> 
> **States**
> 
> - Hub with three grouped lists.
> 
> ---
> 
> ### Full name and profession editor
> 
> **What it does**
> 
> Multi-section CV-style editor for name, profession, and related profile fields used across job applications and public profile.
> 
> **User flow**
> 
> 1. User opens profile information → full name and profession.
> 2. User edits fields and saves.
> 
> **Rules**
> 
> - Same field groups as job application profile data.
> 
> **States**
> 
> - Loading, populated form, save success/error toast.
> 
> ---
> 
> ### Public profile URL and username
> 
> **What it does**
> 
> Lets user choose a unique public username with live availability checking and copy link for current profile URL.
> 
> **User flow**
> 
> 1. User edits username.
> 2. System shows checking, available, or unavailable state.
> 3. User saves valid username or copies unchanged URL.
> 
> **Rules**
> 
> - Empty, invalid, or reserved usernames rejected.
> - Availability checked as user types.
> 
> **States**
> 
> - Checking, available, unavailable, saved.
> 
> ---
> 
> ### Personal information
> 
> **What it does**
> 
> Captures disability status preference (yes, no, prefer not to say).
> 
> **User flow**
> 
> 1. User selects option and saves.
> 
> **Rules**
> 
> - Save shows success or error toast.
> 
> **States**
> 
> - Dropdown with three options.
> 
> ---
> 
> ### Language preference
> 
> **What it does**
> 
> Sets interface language among English, Arabic, French, and German.
> 
> **User flow**
> 
> 1. User selects language and saves.
> 2. User returns to hub.
> 
> **Rules**
> 
> - Language change applies to app UI after save.
> 
> **States**
> 
> - Four language options.
> 
> ---
> 
> ### Profile photo visibility
> 
> **What it does**
> 
> Controls who can see profile photo: only me, connections only, or everyone.
> 
> **User flow**
> 
> 1. User selects audience and saves.
> 
> **Rules**
> 
> - Independent from overall profile public/private mode.
> 
> **States**
> 
> - Three visibility levels.
> 
> ---
> 
> ### Community feed view preference
> 
> **What it does**
> 
> Chooses community feed ordering: most relevant (recommended) or most recent.
> 
> **User flow**
> 
> 1. User selects preference and saves.
> 
> **Rules**
> 
> - Affects community channel feed ordering for the user.
> 
> **States**
> 
> - Recommended vs recent.
> 
> ---
> 
> ### Hibernate account
> 
> **What it does**
> 
> Two-step flow to temporarily deactivate account with optional reason, feedback, and password confirmation.
> 
> **User flow**
> 
> 1. User reads intro, proceeds to details.
> 2. User enters optional reason and feedback.
> 3. User confirms with password.
> 4. On success, user is logged out to login page.
> 
> **Rules**
> 
> - Incorrect password blocks hibernation.
> - Hibernated accounts appear unavailable to others on profile.
> 
> **States**
> 
> - Intro step, details step, success logout.
> 
> ---
> 
> ### Close account
> 
> **What it does**
> 
> Two-step permanent account closure with reason selection, optional feedback, password, and optional unsubscribe from communications.
> 
> **User flow**
> 
> 1. User selects closure reason (duplicate account, too many emails, privacy, other).
> 2. User confirms with password and optional feedback.
> 3. Account closed on success.
> 
> **Rules**
> 
> - Incorrect password blocks closure.
> - Closure reasons required from predefined list.
> 
> **States**
> 
> - Intro, details, confirmation, success.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header account menu
> - Profile owner edit shortcuts
> - Direct URL
> 
> **Outbound**
> 
> - Other settings sections (security, notifications, visibility)
> - Login (after hibernate)
> - Registration (incomplete onboarding)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Full hub access |
> | Incomplete onboarding | Redirected to registration |
> 
> ---
> 
> ## Important Business Rules
> 
> - Account settings require authenticated session.
> - Username changes affect public profile URL immediately on save.
> - Hibernate is reversible by owner login; closure is permanent.
> - All saves provide toast feedback on success or failure.
> - Failed settings load navigates back to hub with error handling.
> 
> ---
> 
> ## Related Features
> 
> - [User Profile](user-profile.md)
> - [Settings — Security](settings-security.md)
> - [Settings — Visibility](settings-visibility.md)
> - [Register](register.md)

---

## Page: Settings — Security
- URL: https://freiburger-bund.com/en/settings/security
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/settings-security.md
- Updated: 2026-09-21

### Purpose
Let signed-in members manage sign-in credentials, email address, password, and two-step verification to keep their account secure.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Protected access
> 
> **What it does**
> 
> Same authentication and onboarding gates as other settings pages.
> 
> **User flow**
> 
> 1. Guest redirected to login with return URL.
> 2. Incomplete onboarding redirected to registration.
> 
> **Rules**
> 
> - Shared settings sidebar navigation.
> 
> **States**
> 
> - Authorized vs redirected.
> 
> ---
> 
> ### Security overview hub
> 
> **What it does**
> 
> Lists account access items under a single security heading.
> 
> **User flow**
> 
> 1. User opens security settings hub.
> 2. User selects email, password, or two-step verification row.
> 
> **Rules**
> 
> - Phone number management exists but is **not exposed** in current menu.
> 
> **States**
> 
> - Hub list visible.
> 
> ---
> 
> ### Email address change
> 
> **What it does**
> 
> Lets user view current email, enter new email, verify via one-time code, and resend code.
> 
> **User flow**
> 
> 1. User enters new email address.
> 2. User receives and enters verification code.
> 3. User completes change; success returns to email step with confirmation.
> 
> **Rules**
> 
> - Submitting same email as current is blocked.
> - Resend OTP available during verification step.
> 
> **States**
> 
> - Enter email, verify OTP, success confirmation.
> 
> ---
> 
> ### Change password
> 
> **What it does**
> 
> Updates password with current password verification (when password exists) and strength rules on new password.
> 
> **User flow**
> 
> 1. User enters current password if account has one.
> 2. User enters new password and confirmation.
> 3. User submits; success screen offers link back to login.
> 
> **Rules**
> 
> - New password minimum eight characters with uppercase and number.
> - Confirm must match new password.
> - Social-only accounts may omit current password when none set.
> 
> **States**
> 
> - Form, validation errors, success screen.
> 
> ---
> 
> ### Two-step verification toggle
> 
> **What it does**
> 
> Enables or disables two-factor authentication with immediate save.
> 
> **User flow**
> 
> 1. User toggles two-step verification on or off.
> 2. Success or error feedback shown.
> 
> **Rules**
> 
> - Toggle disabled while save in progress.
> - When enabled, login flow requires second factor (see login spec).
> 
> **States**
> 
> - On, off, toggling.
> 
> ---
> 
> ### Sub-page navigation and errors
> 
> **What it does**
> 
> Provides back navigation to security hub and handles load failures.
> 
> **User flow**
> 
> 1. User taps back from sub-page to hub.
> 2. On settings load failure, user returned to hub automatically.
> 
> **Rules**
> 
> - RTL-aware back buttons.
> 
> **States**
> 
> - Loading spinner on fetch; auto-back on failure.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Settings sidebar
> - Direct URL
> 
> **Outbound**
> 
> - Settings account, notifications, visibility
> - Login (after password change success option)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Full security management |
> | Social-login account | May change password without current password field |
> 
> ---
> 
> ## Important Business Rules
> 
> - Email change requires OTP verification before taking effect.
> - Password strength rules enforced before save.
> - Two-step verification state persists immediately on toggle.
> - Phone management not user-facing in current release.
> 
> ---
> 
> ## Related Features
> 
> - [Login](login.md)
> - [Settings — Account](settings-account.md)
> - [Forgot Password](forgot-password.md)
> - [Reset Password](reset-password.md)

---

## Page: Settings — Notifications
- URL: https://freiburger-bund.com/en/settings/notifications
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/settings-notifications.md
- Updated: 2026-09-21

### Purpose
Let signed-in members control which activity types generate notifications and how frequently job alert emails are delivered.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Protected access and loading
> 
> **What it does**
> 
> Requires signed-in completed onboarding user; shows loading while preferences fetch.
> 
> **User flow**
> 
> 1. User opens notification settings.
> 2. Loading spinner shown until preferences load.
> 
> **Rules**
> 
> - Failed load returns user to settings hub.
> 
> **States**
> 
> - Loading, loaded, error redirect.
> 
> ---
> 
> ### Job alert frequency
> 
> **What it does**
> 
> Sets email cadence for job alerts: Immediate, Daily, or Weekly.
> 
> **User flow**
> 
> 1. User sees current frequency on hub row.
> 2. User opens sub-page, selects radio option, saves.
> 
> **Rules**
> 
> - Dedicated sub-page with save action.
> - Current value displayed on hub summary row.
> 
> **States**
> 
> - Three frequency options.
> 
> ---
> 
> ### Connection invitation notifications
> 
> **What it does**
> 
> Toggle for notifications when others send connection invitations.
> 
> **User flow**
> 
> 1. User flips switch; saves immediately.
> 
> **Rules**
> 
> - Auto-save on toggle change.
> 
> **States**
> 
> - On/off with title and description (description on desktop).
> 
> ---
> 
> ### Thread and community activity
> 
> **What it does**
> 
> Toggle for thread replies and related community activity notifications.
> 
> **User flow**
> 
> 1. User enables or disables via switch.
> 
> **Rules**
> 
> - Immediate save on change.
> 
> **States**
> 
> - On/off.
> 
> ---
> 
> ### Messaging notifications
> 
> **What it does**
> 
> Toggle for new message notifications.
> 
> **User flow**
> 
> 1. User flips switch.
> 
> **Rules**
> 
> - Immediate save.
> 
> **States**
> 
> - On/off.
> 
> ---
> 
> ### Groups activity notifications
> 
> **What it does**
> 
> Toggle for group-related activity alerts.
> 
> **User flow**
> 
> 1. User flips switch.
> 
> **Rules**
> 
> - Immediate save.
> 
> **States**
> 
> - On/off.
> 
> ---
> 
> ### Events and invites notifications
> 
> **What it does**
> 
> Toggle for event and invitation notifications.
> 
> **User flow**
> 
> 1. User flips switch.
> 
> **Rules**
> 
> - Immediate save.
> 
> **States**
> 
> - On/off.
> 
> ---
> 
> ### Profile update notifications
> 
> **What it does**
> 
> Toggle for notifications about profile-related updates.
> 
> **User flow**
> 
> 1. User flips switch.
> 
> **Rules**
> 
> - Immediate save.
> 
> **States**
> 
> - On/off.
> 
> ---
> 
> ### Gamification and achievements
> 
> **What it does**
> 
> Toggle for gamification and achievement notifications.
> 
> **User flow**
> 
> 1. User flips switch.
> 
> **Rules**
> 
> - Immediate save.
> 
> **States**
> 
> - On/off.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Settings sidebar
> - Direct URL
> 
> **Outbound**
> 
> - Other settings sections
> - [Notifications center](notifications.md) (in-app feed separate from these preferences)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Full preference control |
> 
> ---
> 
> ## Important Business Rules
> 
> - Toggle switches save immediately without separate submit button (except job alert frequency sub-page).
> - Job alert frequency affects email delivery, not necessarily in-app notification center filtering.
> - Each toggle has descriptive copy explaining the notification type.
> - Preferences are per-user and private.
> 
> ---
> 
> ## Related Features
> 
> - [Notifications](notifications.md)
> - [Job Portal — Job Alerts](job-portal-alerts.md)
> - [Settings — Account](settings-account.md)

---

## Page: Settings — Visibility
- URL: https://freiburger-bund.com/en/settings/visibility
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/settings-visibility.md
- Updated: 2026-09-21

### Purpose
Let signed-in members control who can view their profile, discover them by contact information, and see their connection list.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Protected access and hub summary
> 
> **What it does**
> 
> Shows current values for all visibility settings on hub rows before opening detail sub-pages.
> 
> **User flow**
> 
> 1. User opens visibility settings.
> 2. User reads summary: profile mode, email visibility, phone discoverability, connection list visibility.
> 
> **Rules**
> 
> - Blocked-members management exists in product but is **not linked** from current hub menu.
> 
> **States**
> 
> - Hub with four summary rows.
> 
> ---
> 
> ### Profile viewing mode
> 
> **What it does**
> 
> Chooses public profile (visible to everyone) vs private profile (detailed content for connections only).
> 
> **User flow**
> 
> 1. User selects public or private radio option.
> 2. User saves with toast feedback.
> 
> **Rules**
> 
> - Private mode shows header to non-connections but hides detailed sections (see user profile spec).
> 
> **States**
> 
> - Public, private.
> 
> ---
> 
> ### Email visibility
> 
> **What it does**
> 
> Sets who can see email address: only me, connections only, or everyone.
> 
> **User flow**
> 
> 1. User selects one of three audience options.
> 2. User reads explanatory note and saves.
> 
> **Rules**
> 
> - Three mutually exclusive audience levels.
> 
> **States**
> 
> - Only me, connections, everyone.
> 
> ---
> 
> ### Phone discoverability
> 
> **What it does**
> 
> Controls who can find the user by phone number: connections, mutual connections, or everyone.
> 
> **User flow**
> 
> 1. User selects audience option with explanatory note.
> 2. User saves.
> 
> **Rules**
> 
> - Discoverability is not the same as displaying phone on profile.
> 
> **States**
> 
> - Three audience levels.
> 
> ---
> 
> ### Connection list visibility
> 
> **What it does**
> 
> On/off switch for whether others can view the user’s connections list on their profile.
> 
> **User flow**
> 
> 1. User toggles visibility with live on/off label.
> 2. User saves.
> 
> **Rules**
> 
> - Explicit save button on this sub-page (unlike notification toggles).
> 
> **States**
> 
> - Visibility on, visibility off.
> 
> ---
> 
> ### Error handling
> 
> **What it does**
> 
> Returns to hub if settings fail to load.
> 
> **User flow**
> 
> 1. Loader shown during fetch.
> 2. Auto-navigate back on failure.
> 
> **Rules**
> 
> - Consistent with other settings pages.
> 
> **States**
> 
> - Loading, loaded, error redirect.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Settings sidebar
> - Direct URL
> 
> **Outbound**
> 
> - Other settings sections
> - [User Profile](user-profile.md) (effect of visibility changes)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Full visibility control |
> 
> ---
> 
> ## Important Business Rules
> 
> - Public vs private profile is the primary gate for profile section visibility.
> - Email and phone settings are independent granular controls.
> - Connection list visibility does not hide individual connection actions elsewhere.
> - Blocked members feature not exposed in current visibility hub.
> 
> ---
> 
> ## Related Features
> 
> - [User Profile](user-profile.md)
> - [Settings — Account](settings-account.md)
> - [Connections](connections.md)

---

## Page: Connections — My Connections
- URL: https://freiburger-bund.com/en/connections
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/connections.md
- Updated: 2026-09-21

### Purpose
Give signed-in members a list of accepted professional connections with quick actions to message or remove connections, and navigation to grow network, invitations, and groups.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Connections layout and sidebar
> 
> **What it does**
> 
> Shared layout with sidebar (desktop) or dropdown (mobile) for Connections, Grow Network, Invitations (with badge count), and Groups.
> 
> **User flow**
> 
> 1. User navigates between connection areas via sidebar.
> 2. Invitations tab shows badge when received invitations pending.
> 
> **Rules**
> 
> - Signed-in only; guests redirect to login with return URL.
> - Incomplete onboarding redirects to registration.
> 
> **States**
> 
> - Active Connections tab highlighted.
> 
> ---
> 
> ### Connection list
> 
> **What it does**
> 
> Shows accepted connections only (pending excluded) with avatar, name, verified badge, headline, location, and connected-since timestamp.
> 
> **User flow**
> 
> 1. User scans connection list.
> 2. User clicks name to open public profile.
> 
> **Rules**
> 
> - Title shows total count or generic “Connections” when empty.
> - Only accepted relationships displayed.
> 
> **States**
> 
> - Populated list, empty state, error with retry.
> 
> ---
> 
> ### Remove connection
> 
> **What it does**
> 
> Lets user disconnect from another member with loading state and confirmation feedback.
> 
> **User flow**
> 
> 1. User initiates remove on a connection row.
> 2. Connection removed with toast confirmation; list refreshes.
> 
> **Rules**
> 
> - Does not block re-connecting later via Grow Network.
> 
> **States**
> 
> - Loading on action, success removal.
> 
> ---
> 
> ### Send message
> 
> **What it does**
> 
> Opens direct chat with the selected connection.
> 
> **User flow**
> 
> 1. User clicks message on connection row.
> 2. Chat opens with that person.
> 
> **Rules**
> 
> - Requires existing accepted connection.
> 
> **States**
> 
> - Navigates to chat with conversation selected.
> 
> ---
> 
> ### Preview and expand list
> 
> **What it does**
> 
> Shows first six connections with **See all connections** to expand full list.
> 
> **User flow**
> 
> 1. User sees truncated list by default.
> 2. User expands to view all connections.
> 
> **Rules**
> 
> - Expansion reveals full paginated or scrollable list.
> 
> **States**
> 
> - Collapsed (6), expanded (all).
> 
> ---
> 
> ### Responsive layouts
> 
> **What it does**
> 
> Card grid on mobile and tablet; row list on desktop.
> 
> **User flow**
> 
> 1. User views connections in layout suited to screen size.
> 
> **Rules**
> 
> - Same data in both layouts.
> 
> **States**
> 
> - Grid vs list by breakpoint.
> 
> ---
> 
> ### Loading and empty states
> 
> **What it does**
> 
> Skeleton placeholders during fetch and standard empty component when no connections.
> 
> **User flow**
> 
> 1. User waits on skeletons.
> 2. New user sees empty guidance.
> 
> **Rules**
> 
> - Error state offers retry.
> 
> **States**
> 
> - Loading (3 skeletons), empty, error, populated.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header navigation
> - Profile connection count links
> - Direct URL
> 
> **Outbound**
> 
> - [User Profile](user-profile.md)
> - [Chat](chat.md)
> - [Grow Network](connections-network.md)
> - [Invitations](connections-invitation.md)
> - [Groups](connections-groups.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Full connection list and actions |
> 
> ---
> 
> ## Important Business Rules
> 
> - Pending invitations never appear in this list.
> - Remove connection is immediate from viewer’s list; other user’s list updates accordingly.
> - Connection count on profile reflects accepted connections only.
> 
> ---
> 
> ## Related Features
> 
> - [Connections — Grow Network](connections-network.md)
> - [Connections — Invitations](connections-invitation.md)
> - [Connections — Groups](connections-groups.md)
> - [User Profile](user-profile.md)

---

## Page: Connections — Grow Network
- URL: https://freiburger-bund.com/en/connections/network
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/connections-network.md
- Updated: 2026-09-21

### Purpose
Suggest people the member may know and let them send connection requests to expand their professional network.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### People you may know
> 
> **What it does**
> 
> Displays suggested members excluding already-accepted connections.
> 
> **User flow**
> 
> 1. User browses suggestion cards with avatar, name, headline, and location.
> 2. User sends connect request or sees pending state.
> 
> **Rules**
> 
> - Suggestions algorithm **Unknown / requires product clarification** for exact matching criteria.
> - Already-connected users excluded.
> 
> **States**
> 
> - Populated suggestions, empty, loading skeletons, error.
> 
> ---
> 
> ### Connect action
> 
> **What it does**
> 
> Sends connection invitation with loading, success, and error feedback; refreshes list on success.
> 
> **User flow**
> 
> 1. User clicks Connect on a suggestion.
> 2. Button shows loading; success toast; card updates to pending or removes.
> 
> **Rules**
> 
> - Duplicate requests show disabled Pending state.
> 
> **States**
> 
> - Connect, pending (disabled), loading.
> 
> ---
> 
> ### Preview and expand
> 
> **What it does**
> 
> Shows first six suggestions with **See all** to expand.
> 
> **User flow**
> 
> 1. User expands to view full suggestion list.
> 
> **Rules**
> 
> - Same expand pattern as connections list.
> 
> **States**
> 
> - Collapsed (6), expanded.
> 
> ---
> 
> ### Responsive layout
> 
> **What it does**
> 
> Card grid on mobile/tablet; row list on desktop matching connections page patterns.
> 
> **User flow**
> 
> 1. User interacts with suggestions in responsive layout.
> 
> **Rules**
> 
> - Consistent with main connections list styling.
> 
> **States**
> 
> - Grid vs list by breakpoint.
> 
> ---
> 
> ### Sidebar navigation
> 
> **What it does**
> 
> Grow Network tab active within shared connections layout.
> 
> **User flow**
> 
> 1. User switches to Connections, Invitations, or Groups via sidebar.
> 
> **Rules**
> 
> - Signed-in only.
> 
> **States**
> 
> - Grow Network tab highlighted.
> 
> ---
> 
> ### Empty state
> 
> **What it does**
> 
> Shown when no suggestions available.
> 
> **User flow**
> 
> 1. User sees empty guidance when algorithm returns no matches.
> 
> **Rules**
> 
> - Distinct from error state.
> 
> **States**
> 
> - Standard no-results empty component.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Connections sidebar Grow Network tab
> - Direct URL
> 
> **Outbound**
> 
> - [User Profile](user-profile.md) (from suggestion name links)
> - [Connections](connections.md)
> - [Invitations](connections-invitation.md) (after send)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Send connection requests |
> 
> ---
> 
> ## Important Business Rules
> 
> - Pending outgoing requests show disabled state on suggestion card.
> - Successful connect moves request to sent invitations list.
> - Suggestions refresh after connect actions.
> 
> ---
> 
> ## Related Features
> 
> - [Connections](connections.md)
> - [Connections — Invitations](connections-invitation.md)
> - [User Profile](user-profile.md)

---

## Page: Connections — Groups
- URL: https://freiburger-bund.com/en/connections/groups
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/connections-groups.md
- Updated: 2026-09-21

### Purpose
Let signed-in members view group conversations with more than two participants, create new groups from connections, inspect members, and open group chat.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Group list
> 
> **What it does**
> 
> Lists group chats with initial-letter avatar, title, optional subtitle, member avatar stack (first three plus overflow count).
> 
> **User flow**
> 
> 1. User browses groups they belong to.
> 2. User taps member area to open members dialog or message to open chat.
> 
> **Rules**
> 
> - Only groups with more than two members appear.
> - Empty state when user belongs to no groups.
> 
> **States**
> 
> - Populated, empty, loading.
> 
> ---
> 
> ### Members dialog
> 
> **What it does**
> 
> Shows group members; creators may see add-member placeholder for future actions.
> 
> **User flow**
> 
> 1. User opens members from group row.
> 2. User views member list.
> 
> **Rules**
> 
> - Creator detection enables future add-member UI.
> - Add-member may be placeholder in current release.
> 
> **States**
> 
> - Dialog open with member list.
> 
> ---
> 
> ### Message group
> 
> **What it does**
> 
> Opens the group conversation in chat experience.
> 
> **User flow**
> 
> 1. User clicks message on group row.
> 2. Chat opens with group thread selected.
> 
> **Rules**
> 
> - Same group accessible from chat conversation list.
> 
> **States**
> 
> - Navigates to chat.
> 
> ---
> 
> ### Create group — desktop
> 
> **What it does**
> 
> Modal dialog to name group and pick members from connections.
> 
> **User flow**
> 
> 1. User clicks Create on desktop.
> 2. User enters title (required) and selects at least two additional members.
> 3. User submits or cancels.
> 
> **Rules**
> 
> - Title required; error toast if empty.
> - Minimum two members beyond self required.
> - Success clears form, closes dialog, refreshes list.
> 
> **States**
> 
> - Dialog open, submitting, success, validation error.
> 
> ---
> 
> ### Create group — mobile
> 
> **What it does**
> 
> Full-screen inline create flow with dismiss/back instead of modal.
> 
> **User flow**
> 
> 1. User taps Create on mobile.
> 2. Same validation as desktop in inline form.
> 
> **Rules**
> 
> - Identical validation rules as desktop dialog.
> 
> **States**
> 
> - Inline form, submitting, success.
> 
> ---
> 
> ### Member picker
> 
> **What it does**
> 
> Multi-select search to choose connections for new group.
> 
> **User flow**
> 
> 1. User searches and selects connections.
> 2. Selected members shown before submit.
> 
> **Rules**
> 
> - Only connections eligible for group membership.
> 
> **States**
> 
> - Search results, selected chips.
> 
> ---
> 
> ### Informational note
> 
> **What it does**
> 
> Displays guidance about group creation expectations below create action.
> 
> **User flow**
> 
> 1. User reads note before creating group.
> 
> **Rules**
> 
> - Static informational copy.
> 
> **States**
> 
> - Always visible near create entry.
> 
> ---
> 
> ### Sidebar navigation
> 
> **What it does**
> 
> Groups tab active within shared connections layout.
> 
> **User flow**
> 
> 1. User navigates to other connection areas via sidebar.
> 
> **Rules**
> 
> - Signed-in only.
> 
> **States**
> 
> - Groups tab highlighted.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Connections sidebar Groups tab
> - Chat deep links to group management
> - Direct URL
> 
> **Outbound**
> 
> - [Chat](chat.md) (group thread)
> - [Connections](connections.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | View and create groups from connections |
> | Group creator | Members dialog may show add-member placeholder |
> 
> ---
> 
> ## Important Business Rules
> 
> - Minimum three participants total (creator plus two others) to create group.
> - Group title required before submit.
> - Groups appear in chat with group filter pill.
> - Create success immediately opens group in list.
> 
> ---
> 
> ## Related Features
> 
> - [Chat](chat.md)
> - [Connections](connections.md)
> - [Connections — Invitations](connections-invitation.md)

---

## Page: Connections — Invitations
- URL: https://freiburger-bund.com/en/connections/invitation
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/connections-invitation.md
- Updated: 2026-09-21

### Purpose
Let signed-in members review incoming connection requests, approve or reject them, and manage outgoing pending invitations including withdrawal.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Received invitations section
> 
> **What it does**
> 
> Lists connection requests others sent to the user with approve and reject actions.
> 
> **User flow**
> 
> 1. User opens Invitations tab (badge on sidebar when unread received).
> 2. User approves or rejects each invitation with loading and feedback.
> 
> **Rules**
> 
> - First four shown with **See all invitations** expansion.
> - Approve creates accepted connection; reject dismisses request.
> 
> **States**
> 
> - Populated, empty per section, loading skeletons.
> 
> ---
> 
> ### Sent invitations section
> 
> **What it does**
> 
> Lists outgoing pending requests the user has sent.
> 
> **User flow**
> 
> 1. User reviews sent pending list.
> 2. User withdraws invitation with loading and feedback.
> 
> **Rules**
> 
> - First three shown with **See all sent invitations** expansion.
> - Withdraw cancels pending request.
> 
> **States**
> 
> - Populated, empty, loading.
> 
> ---
> 
> ### Approve connection
> 
> **What it does**
> 
> Accepts received invitation; both users become connected.
> 
> **User flow**
> 
> 1. User clicks approve.
> 2. Success toast; entry removed from received list; appears in connections.
> 
> **Rules**
> 
> - Loading state on button during action.
> 
> **States**
> 
> - Loading, success, error toast.
> 
> ---
> 
> ### Reject connection
> 
> **What it does**
> 
> Declines received invitation without creating connection.
> 
> **User flow**
> 
> 1. User clicks reject.
> 2. Request removed from received list.
> 
> **Rules**
> 
> - Sender may send new request later unless blocked **Unknown / requires product clarification**.
> 
> **States**
> 
> - Loading, success, error.
> 
> ---
> 
> ### Withdraw sent invitation
> 
> **What it does**
> 
> Cancels outgoing pending request before acceptance.
> 
> **User flow**
> 
> 1. User clicks withdraw on sent item.
> 2. Request removed from sent list.
> 
> **Rules**
> 
> - Recipient no longer sees pending request.
> 
> **States**
> 
> - Loading, success, error.
> 
> ---
> 
> ### Sidebar badge
> 
> **What it does**
> 
> Shows count of unread or pending received invitations on Invitations nav item.
> 
> **User flow**
> 
> 1. User sees badge on sidebar until invitations handled.
> 
> **Rules**
> 
> - Badge reflects received count, not sent.
> 
> **States**
> 
> - Badge visible when count > 0.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Connections sidebar Invitations tab
> - Notification links to invitations
> - Direct URL
> 
> **Outbound**
> 
> - [Connections](connections.md) (after approve)
> - [User Profile](user-profile.md)
> - [Grow Network](connections-network.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Manage received and sent invitations |
> 
> ---
> 
> ## Important Business Rules
> 
> - Received and sent lists are separate sections on one page.
> - Approve immediately adds to connections list.
> - Sidebar badge encourages reviewing received invitations.
> - Expand links reveal full lists beyond preview limits.
> 
> ---
> 
> ## Related Features
> 
> - [Connections](connections.md)
> - [Connections — Grow Network](connections-network.md)
> - [Notifications](notifications.md)
> - [User Profile](user-profile.md)

---

## Page: Notifications — Activity Center
- URL: https://freiburger-bund.com/en/notifications
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/notifications.md
- Updated: 2026-09-21

### Purpose
Give signed-in members a unified feed of activity updates across info, community, and job portals with filtering, read state, and navigation to relevant content.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Page header
> 
> **What it does**
> 
> Shows title and subtitle about latest updates.
> 
> **User flow**
> 
> 1. User opens notification center from header bell or direct link.
> 
> **Rules**
> 
> - Signed-in only; guests redirect to login.
> 
> **States**
> 
> - Header always visible.
> 
> ---
> 
> ### Portal filter tabs
> 
> **What it does**
> 
> Filters feed by All, Info portal, Community, or Job portal.
> 
> **User flow**
> 
> 1. User selects tab.
> 2. Feed refetches for selected portal; pagination resets.
> 
> **Rules**
> 
> - Tab change clears prior list and reloads.
> 
> **States**
> 
> - All, Info, Community, Job active tabs.
> 
> ---
> 
> ### Notification list items
> 
> **What it does**
> 
> Each item shows portal icon, title, description, and relative timestamp; unread items have distinct background.
> 
> **User flow**
> 
> 1. User scans feed.
> 2. User taps item to navigate to destination (article, thread, event, job, profile, application, etc.).
> 
> **Rules**
> 
> - Destination depends on notification type.
> - Unread visually highlighted.
> 
> **States**
> 
> - Read vs unread styling.
> 
> ---
> 
> ### Mark all as read
> 
> **What it does**
> 
> Marks all visible notifications as read in current tab.
> 
> **User flow**
> 
> 1. User clicks mark all as read.
> 2. Unread styling clears for visible items.
> 
> **Rules**
> 
> - Applies to filtered tab context.
> 
> **States**
> 
> - Action available when unread items exist.
> 
> ---
> 
> ### Infinite scroll
> 
> **What it does**
> 
> Loads additional notifications as user scrolls toward bottom.
> 
> **User flow**
> 
> 1. User scrolls down.
> 2. More items append with loading indicator.
> 
> **Rules**
> 
> - Initial load plus load-more batches.
> 
> **States**
> 
> - Initial loading skeletons, loading more, end of feed.
> 
> ---
> 
> ### Empty state
> 
> **What it does**
> 
> Shown when no notifications exist for active tab.
> 
> **User flow**
> 
> 1. User sees empty guidance when feed has no items.
> 
> **Rules**
> 
> - Per-tab empty possible.
> 
> **States**
> 
> - Standard empty component.
> 
> ---
> 
> ### Error state
> 
> **What it does**
> 
> Retryable error when feed fails to load.
> 
> **User flow**
> 
> 1. User sees error message and retry action.
> 
> **Rules**
> 
> - Retry refetches current tab.
> 
> **States**
> 
> - Error banner with retry.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header notification bell
> - Direct URL
> 
> **Outbound**
> 
> - Info articles, community threads/events, job postings, profiles, applications (by notification type)
> - [Settings — Notifications](settings-notifications.md) (preference control separate)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Full feed with mark read and navigation |
> 
> ---
> 
> ## Important Business Rules
> 
> - In-app feed is separate from email notification preferences in settings.
> - Mark all as read affects in-app read state, not necessarily email subscriptions.
> - Tab filter scopes both list and mark-all action.
> - Notification types span all three portals plus account/social events.
> 
> ---
> 
> ## Related Features
> 
> - [Settings — Notifications](settings-notifications.md)
> - [Info Portal — Article](info-portal-article.md)
> - [Community Portal — Thread](community-portal-thread.md)
> - [Job Portal — Job Posting Detail](job-portal-detail.md)

---

## Page: Chat — Messaging
- URL: https://freiburger-bund.com/en/chat
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/chat.md
- Updated: 2026-09-21

### Purpose
Let signed-in members exchange direct and group messages, manage conversations (archive, mute, block), and support recruiter company chat mode for users with employer access.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Protected access and layout
> 
> **What it does**
> 
> Two-pane desktop layout (list + thread) and mobile single-pane with back navigation; signed-in only.
> 
> **User flow**
> 
> 1. Guest redirected to login with return URL.
> 2. Desktop: list left, active thread right.
> 3. Mobile: list OR thread full screen with back button.
> 
> **Rules**
> 
> - Deep link via conversation id parameter opens that thread on desktop.
> - Create-group parameter opens new-chat dialog on load.
> 
> **States**
> 
> - List view, thread view (mobile), split view (desktop).
> 
> ---
> 
> ### Conversation list search
> 
> **What it does**
> 
> Filters conversations by participant or content with minimum two characters and debounce.
> 
> **User flow**
> 
> 1. User types in conversation search.
> 2. List narrows to matching chats.
> 
> **Rules**
> 
> - Minimum two characters before search activates.
> 
> **States**
> 
> - Unfiltered list, filtered list, no matches.
> 
> ---
> 
> ### Conversation type filters
> 
> **What it does**
> 
> Pill filters: All, Direct, Colleague-to-colleague (C2C), Groups, Events; hidden while viewing archived chats.
> 
> **User flow**
> 
> 1. User selects filter pill.
> 2. List shows matching conversation types, optionally grouped by type.
> 
> **Rules**
> 
> - Archived view uses separate toggle instead of type pills.
> 
> **States**
> 
> - Active pill highlighted; grouped sections when filtered.
> 
> ---
> 
> ### Conversation rows
> 
> **What it does**
> 
> Each row shows avatar, name, last message preview, timestamp, unread badge or dot, typing indicator, and draft indicator.
> 
> **User flow**
> 
> 1. User selects row to open thread.
> 2. Unread conversations marked visually.
> 
> **Rules**
> 
> - Sorted by latest activity.
> 
> **States**
> 
> - Unread vs read, typing, draft present.
> 
> ---
> 
> ### New chat dialog
> 
> **What it does**
> 
> Creates direct message (one connection) or named group (two or more members); personal vs company/recruiter mode when eligible.
> 
> **User flow**
> 
> 1. User clicks new chat.
> 2. User picks personal or company mode (company only if recruiter access and employer features enabled).
> 3. User selects participants; group requires name and minimum members.
> 4. Preview shown before create; new thread opens on success.
> 
> **Rules**
> 
> - Direct: exactly one connected user.
> - Group: title required, two or more additional members from connections.
> - Company mode uses separate messaging endpoints.
> 
> **States**
> 
> - Personal vs company mode, direct vs group creation.
> 
> ---
> 
> ### Archived chats
> 
> **What it does**
> 
> Toggle to view archived conversations with separate unread counts for personal vs company mode.
> 
> **User flow**
> 
> 1. User opens archived view.
> 2. User restores or reads archived threads.
> 
> **Rules**
> 
> - Type filter pills hidden in archived view.
> - Personal and company archive counts tracked separately.
> 
> **States**
> 
> - Active vs archived list modes.
> 
> ---
> 
> ### Active thread header
> 
> **What it does**
> 
> Shows participant name/avatar, online member count for groups, back (mobile), in-chat search, video call (personal only), and more actions menu.
> 
> **User flow**
> 
> 1. User uses header actions during conversation.
> 
> **Rules**
> 
> - Video call not supported in company/recruiter mode (error toast if attempted).
> 
> **States**
> 
> - Personal vs group vs company header variants.
> 
> ---
> 
> ### Message list and compose
> 
> **What it does**
> 
> Infinite scroll upward for history; compose with rich text, emoji, attachments, voice recording, reply-to, edit, undo send.
> 
> **User flow**
> 
> 1. User scrolls up to load older messages.
> 2. User composes and sends messages with optional attachments.
> 3. User replies to or edits own messages where supported.
> 
> **Rules**
> 
> - Mark as read automatically when opening unread thread.
> - Typing indicators in thread and list.
> 
> **States**
> 
> - Loading history, composing, sending, failed send.
> 
> ---
> 
> ### Reactions and read receipts
> 
> **What it does**
> 
> Message reactions and seen-by indicators for group and direct chats.
> 
> **User flow**
> 
> 1. User adds reaction to message.
> 2. User sees who has read message when available.
> 
> **Rules**
> 
> - Seen-by may vary by conversation type.
> 
> **States**
> 
> - Reactions displayed; seen list on hover or inline.
> 
> ---
> 
> ### Special conversation types
> 
> **What it does**
> 
> Supports pinned messages, event cards, official channel headers, C2C offer context, and learning partner request threads.
> 
> **User flow**
> 
> 1. User sees contextual headers or cards within specialized threads.
> 
> **Rules**
> 
> - Official groups may include extra tabs (threads, materials, etc.).
> - Inactive event channels may show inactive banner.
> 
> **States**
> 
> - Standard DM vs specialized thread chrome.
> 
> ---
> 
> ### Block, mute, archive, delete
> 
> **What it does**
> 
> Block or unblock user with confirmation; mute, archive, or delete chat via info dialog; report message option.
> 
> **User flow**
> 
> 1. User opens more actions or info dialog.
> 2. User blocks user → blocked conversation banner shown.
> 3. User mutes, archives, or deletes as needed.
> 
> **Rules**
> 
> - Block requires confirmation.
> - Company mode may use separate block/archive endpoints.
> 
> **States**
> 
> - Blocked banner, muted icon, archived in archive list.
> 
> ---
> 
> ### Recruiter company chat mode
> 
> **What it does**
> 
> Recruiters with employer access operate company chat mode with separate message, archive, and block behavior from personal chat.
> 
> **User flow**
> 
> 1. User switches to company mode in new chat or archived counts.
> 2. Company conversations isolated from personal list filters where applicable.
> 
> **Rules**
> 
> - Company option visible only when recruiter access and employer features enabled.
> 
> **States**
> 
> - Personal vs company mode throughout chat UI.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header messages link
> - Connection list message action
> - Groups message action
> - Deep link with conversation id or create-group flag
> - Job/colleague C2C interest flows
> 
> **Outbound**
> 
> - [User Profile](user-profile.md)
> - [Connections — Groups](connections-groups.md)
> - Employer company area (recruiter mode)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Personal direct and group chat |
> | Recruiter with employer access | Additional company chat mode |
> 
> ---
> 
> ## Important Business Rules
> 
> - Messaging requires signed-in account with completed onboarding.
> - Group creation requires named group and minimum member count from connections.
> - Archived and company chats tracked separately from active personal list.
> - Video calls personal mode only.
> - Block prevents messaging until unblocked.
> 
> ---
> 
> ## Related Features
> 
> - [Connections](connections.md)
> - [Connections — Groups](connections-groups.md)
> - [Job Portal — Colleague-to-Colleague](job-portal-c2c.md)
> - [Settings — Notifications](settings-notifications.md)

---

## Page: Bookmarks — All
- URL: https://freiburger-bund.com/en/bookmarks/all
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/bookmarks-all.md
- Updated: 2026-09-21

### Purpose
Give signed-in members a unified view of saved content across info articles, community threads, and job postings with search, tab navigation, and per-section pagination.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Protected access and redirect
> 
> **What it does**
> 
> Requires signed-in user; bare bookmarks root redirects to All tab.
> 
> **User flow**
> 
> 1. Guest redirected to login with return URL.
> 2. User opening bookmarks root lands on All tab.
> 
> **Rules**
> 
> - Login required for all bookmark routes.
> 
> **States**
> 
> - Redirect to All tab from root.
> 
> ---
> 
> ### Shared bookmarks layout
> 
> **What it does**
> 
> Page title, subtitle, and tabs: All, Info, Community, Job; shared across all bookmark routes.
> 
> **User flow**
> 
> 1. User switches tabs to filter bookmark type.
> 2. Active tab reflected in navigation.
> 
> **Rules**
> 
> - Same shell on all four bookmark URLs.
> 
> **States**
> 
> - All tab active on this page.
> 
> ---
> 
> ### Bookmarks search
> 
> **What it does**
> 
> Search bar filters bookmarks via URL query parameter; clears on empty submit; resets pagination when query changes.
> 
> **User flow**
> 
> 1. User types search terms.
> 2. All three sections filter simultaneously on All tab.
> 
> **Rules**
> 
> - Query synced to address bar for shareable filtered views.
> 
> **States**
> 
> - Unfiltered, active search query.
> 
> ---
> 
> ### Info articles section
> 
> **What it does**
> 
> Paginated grid of bookmarked info articles with title, description, topic tag; smaller page size than Info-only tab.
> 
> **User flow**
> 
> 1. User browses info bookmarks section.
> 2. User opens article from card.
> 3. User removes bookmark from card toggle.
> 
> **Rules**
> 
> - Independent pagination per section on All tab.
> - Load failure message for info section.
> 
> **States**
> 
> - Loading skeletons, populated, empty, error.
> 
> ---
> 
> ### Community threads section
> 
> **What it does**
> 
> Paginated grid of bookmarked community posts with content-type label (thread, poll, event, protocol, material, etc.) and text preview.
> 
> **User flow**
> 
> 1. User browses community bookmarks.
> 2. User opens thread in community portal.
> 3. User removes bookmark with toast and list refresh.
> 
> **Rules**
> 
> - Optimistic update on remove.
> 
> **States**
> 
> - Loading, populated, empty, error.
> 
> ---
> 
> ### Job postings section
> 
> **What it does**
> 
> Paginated grid of saved jobs with title, company, location, type, snippet; expired jobs excluded.
> 
> **User flow**
> 
> 1. User browses job bookmarks.
> 2. User opens job detail (error toast if URL unavailable).
> 3. User removes bookmark toggle.
> 
> **Rules**
> 
> - Retryable error state for jobs section.
> - Expired postings excluded.
> 
> **States**
> 
> - Loading, populated, empty, retryable error.
> 
> ---
> 
> ### Remove bookmark on cards
> 
> **What it does**
> 
> Toggle on each card removes bookmark with toast feedback and list refresh.
> 
> **User flow**
> 
> 1. User clicks remove bookmark on any card type.
> 2. Item disappears from section.
> 
> **Rules**
> 
> - Consistent across info, community, and job cards.
> 
> **States**
> 
> - Bookmark active → removed on toggle.
> 
> ---
> 
> ### Responsive card grids
> 
> **What it does**
> 
> One, two, or three column responsive grids per section.
> 
> **User flow**
> 
> 1. User views bookmarks across screen sizes.
> 
> **Rules**
> 
> - Same grid pattern across portal types.
> 
> **States**
> 
> - Column count by breakpoint.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header bookmarks menu
> - Community portal bookmark redirect
> - Direct URL to All tab or bookmarks root
> 
> **Outbound**
> 
> - [Bookmarks — Info](bookmarks-info.md), [Community](bookmarks-community.md), [Job](bookmarks-job.md) tabs
> - Info articles, community threads, job detail
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Full bookmark collections with search |
> 
> ---
> 
> ## Important Business Rules
> 
> - All tab uses smaller per-section page sizes than single-portal tabs.
> - Empty sections on All tab still show section heading with empty state when no matches.
> - Search applies across all sections simultaneously.
> - Removing bookmark is immediate with list refresh.
> 
> ---
> 
> ## Related Features
> 
> - [Bookmarks — Info](bookmarks-info.md)
> - [Bookmarks — Community](bookmarks-community.md)
> - [Bookmarks — Job](bookmarks-job.md)
> - [Info Portal — Bookmarked](info-portal-bookmarked.md)
> - [Community Portal — Bookmarks](community-portal-bookmarks.md)
> - [Job Portal — Saved Jobs](job-portal-bookmarked.md)

---

## Page: Bookmarks — Info
- URL: https://freiburger-bund.com/en/bookmarks/info
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/bookmarks-info.md
- Updated: 2026-09-21

### Purpose
Let signed-in members view, search, and manage bookmarked info portal articles in a focused list separate from community and job bookmarks.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Info-only bookmark list
> 
> **What it does**
> 
> Shows only info article bookmarks with larger page size than combined All tab.
> 
> **User flow**
> 
> 1. User selects Info tab in bookmarks layout.
> 2. User browses article cards with title, description, and topic tag chip.
> 
> **Rules**
> 
> - Signed-in only; shared search bar and tabs from bookmarks shell.
> 
> **States**
> 
> - Populated grid, empty, loading skeletons.
> 
> ---
> 
> ### Article cards
> 
> **What it does**
> 
> Each card links to canonical article; displays topic tag and remove bookmark control.
> 
> **User flow**
> 
> 1. User opens article from card.
> 2. User toggles bookmark off to remove from list.
> 
> **Rules**
> 
> - Remove shows toast and refreshes list.
> 
> **States**
> 
> - Bookmarked card → removed on toggle.
> 
> ---
> 
> ### Search filtering
> 
> **What it does**
> 
> Shared bookmarks search filters info articles by keyword via URL query.
> 
> **User flow**
> 
> 1. User enters search terms.
> 2. List narrows; pagination resets.
> 
> **Rules**
> 
> - Same search parameter as other bookmark tabs.
> 
> **States**
> 
> - Filtered vs full list.
> 
> ---
> 
> ### Pagination with prefetch
> 
> **What it does**
> 
> Pages through info bookmarks with adjacent page prefetch for smoother navigation.
> 
> **User flow**
> 
> 1. User moves between pages when bookmarks exceed page size.
> 
> **Rules**
> 
> - Larger page size than All tab info section.
> 
> **States**
> 
> - Single vs multi-page.
> 
> ---
> 
> ### Loading, empty, and error
> 
> **What it does**
> 
> Skeleton grid while loading; empty state when no info bookmarks match; load error message on failure.
> 
> **User flow**
> 
> 1. User sees appropriate state feedback.
> 
> **Rules**
> 
> - Error distinct from empty search results.
> 
> **States**
> 
> - Loading, empty, error, populated.
> 
> ---
> 
> ### Shared bookmarks tabs
> 
> **What it does**
> 
> Info tab active; user can switch to All, Community, or Job tabs.
> 
> **User flow**
> 
> 1. User navigates to other bookmark collections via tabs.
> 
> **Rules**
> 
> - Search query may persist across tab switch **Unknown / requires product clarification**.
> 
> **States**
> 
> - Info tab highlighted.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Bookmarks All tab
> - Info article bookmark action
> - Direct URL
> 
> **Outbound**
> 
> - [Info Portal — Article](info-portal-article.md)
> - Other bookmark tabs
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Manage info bookmarks |
> 
> ---
> 
> ## Important Business Rules
> 
> - Info bookmarks are independent from info portal phase bookmark filter view (different entry, same underlying saves **Unknown / requires product clarification** for deduplication).
> - Removing bookmark here removes from All tab info section too.
> - Search filters within info bookmarks only on this tab.
> 
> ---
> 
> ## Related Features
> 
> - [Bookmarks — All](bookmarks-all.md)
> - [Info Portal — Bookmarked](info-portal-bookmarked.md)
> - [Info Portal — Article](info-portal-article.md)

---

## Page: Bookmarks — Community
- URL: https://freiburger-bund.com/en/bookmarks/community
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/bookmarks-community.md
- Updated: 2026-09-21

### Purpose
Let signed-in members view, search, and manage bookmarked community threads and posts across content types in one focused list.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Community-only bookmark list
> 
> **What it does**
> 
> Shows bookmarked community threads and posts with larger page size than All tab community section.
> 
> **User flow**
> 
> 1. User selects Community tab in bookmarks layout.
> 2. User browses cards with content-type labels and preview text.
> 
> **Rules**
> 
> - Signed-in only.
> 
> **States**
> 
> - Populated, empty, loading, error.
> 
> ---
> 
> ### Content-type labels
> 
> **What it does**
> 
> Identifies bookmark type: thread, poll, event, protocol, material, or default thread icon/label.
> 
> **User flow**
> 
> 1. User recognizes content type before opening.
> 
> **Rules**
> 
> - Label derived from post type in community portal.
> 
> **States**
> 
> - Per-card type indicator.
> 
> ---
> 
> ### Smart text preview
> 
> **What it does**
> 
> Shows excerpt from post body on bookmark card.
> 
> **User flow**
> 
> 1. User reads preview to choose which thread to reopen.
> 
> **Rules**
> 
> - Preview truncated for card layout.
> 
> **States**
> 
> - Text preview on each card.
> 
> ---
> 
> ### Open thread
> 
> **What it does**
> 
> Links card to thread detail in community portal.
> 
> **User flow**
> 
> 1. User clicks card → community thread page.
> 
> **Rules**
> 
> - Canonical thread URL in community area.
> 
> **States**
> 
> - Navigation to thread detail.
> 
> ---
> 
> ### Remove bookmark
> 
> **What it does**
> 
> Toggle removes bookmark with optimistic update, toast, and list refresh.
> 
> **User flow**
> 
> 1. User removes bookmark from card.
> 2. Card disappears from list.
> 
> **Rules**
> 
> - Same bookmark state as community portal thread bookmark control.
> 
> **States**
> 
> - Removed immediately from view.
> 
> ---
> 
> ### Search and pagination
> 
> **What it does**
> 
> Shared search bar filters community bookmarks; pagination with prefetch across pages.
> 
> **User flow**
> 
> 1. User searches and paginates long bookmark collections.
> 
> **Rules**
> 
> - Query in URL; pagination resets on search change.
> 
> **States**
> 
> - Filtered paginated list.
> 
> ---
> 
> ### Loading, empty, and error
> 
> **What it does**
> 
> Standard skeleton, empty, and error states for community bookmark fetch.
> 
> **User flow**
> 
> 1. User receives feedback when list loading fails or is empty.
> 
> **Rules**
> 
> - Retry may be available on error.
> 
> **States**
> 
> - Loading, empty, error, populated.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - [Community Portal — Bookmarks](community-portal-bookmarks.md) redirect
> - Community thread bookmark actions
> - Bookmarks All tab
> 
> **Outbound**
> 
> - [Community Portal — Thread](community-portal-thread.md)
> - Other bookmark tabs
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Manage community bookmarks |
> 
> ---
> 
> ## Important Business Rules
> 
> - Community bookmarks include multiple content types beyond plain threads.
> - Removing bookmark here syncs with thread page bookmark state.
> - `/community/bookmark` redirects to this global bookmarks view.
> 
> ---
> 
> ## Related Features
> 
> - [Bookmarks — All](bookmarks-all.md)
> - [Community Portal — Bookmarks](community-portal-bookmarks.md)
> - [Community Portal — Thread](community-portal-thread.md)

---

## Page: Bookmarks — Job
- URL: https://freiburger-bund.com/en/bookmarks/job
- Type: product-spec
- Section: Account & Social
- Access: authenticated
- Source: docs/product-knowledge/pages/bookmarks-job.md
- Updated: 2026-09-21

### Purpose
Let signed-in members view, search, and manage bookmarked employer job postings separately from job portal Saved Jobs tab and colleague-to-colleague offers.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Job-only bookmark list
> 
> **What it does**
> 
> Shows saved employer job postings with larger page size than All tab job section.
> 
> **User flow**
> 
> 1. User selects Job tab in bookmarks layout.
> 2. User browses job cards with title, company, location, employment type, and description snippet.
> 
> **Rules**
> 
> - Expired jobs excluded by default.
> - Signed-in only.
> 
> **States**
> 
> - Populated, empty, loading, retryable error.
> 
> ---
> 
> ### Open job detail
> 
> **What it does**
> 
> Opens job posting detail when user taps job title on card.
> 
> **User flow**
> 
> 1. User clicks title → job detail page.
> 2. If URL unavailable, error toast shown instead.
> 
> **Rules**
> 
> - Same posting detail as job portal catalog.
> 
> **States**
> 
> - Successful navigation vs unavailable toast.
> 
> ---
> 
> ### Remove bookmark
> 
> **What it does**
> 
> Toggle removes job from bookmarks with list refresh.
> 
> **User flow**
> 
> 1. User removes bookmark from card.
> 2. Job disappears from list; also removed from Saved Jobs tab if synced.
> 
> **Rules**
> 
> - Bookmark state shared with job offers card bookmarks **Unknown / requires product clarification** for exact sync with `/job/open/bookmarked`.
> 
> **States**
> 
> - Removed on toggle.
> 
> ---
> 
> ### Search filtering
> 
> **What it does**
> 
> Shared bookmarks search filters job bookmarks by keyword.
> 
> **User flow**
> 
> 1. User searches saved jobs by title or company keywords.
> 
> **Rules**
> 
> - URL query parameter; pagination resets on change.
> 
> **States**
> 
> - Filtered vs full list.
> 
> ---
> 
> ### Pagination with prefetch
> 
> **What it does**
> 
> Pages through job bookmarks with adjacent page prefetch.
> 
> **User flow**
> 
> 1. User navigates pages for long bookmark lists.
> 
> **Rules**
> 
> - Larger page size than All tab job section.
> 
> **States**
> 
> - Multi-page when needed.
> 
> ---
> 
> ### Loading, empty, and error
> 
> **What it does**
> 
> Skeleton cards while loading; empty when no saved jobs; retryable error on fetch failure.
> 
> **User flow**
> 
> 1. User sees appropriate feedback.
> 
> **Rules**
> 
> - Retry action on error state.
> 
> **States**
> 
> - Loading, empty, error with retry, populated.
> 
> ---
> 
> ### Shared bookmarks tabs
> 
> **What it does**
> 
> Job tab active within bookmarks shell with All, Info, Community siblings.
> 
> **User flow**
> 
> 1. User switches to other bookmark collections.
> 
> **Rules**
> 
> - Consistent layout across bookmark routes.
> 
> **States**
> 
> - Job tab highlighted.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Header bookmarks menu Job tab
> - Job offers bookmark toggle
> - Bookmarks All tab
> 
> **Outbound**
> 
> - [Job Portal — Job Posting Detail](job-portal-detail.md)
> - [Job Portal — Saved Jobs](job-portal-bookmarked.md) (related in-portal view)
> - Other bookmark tabs
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Redirected to login |
> | Signed-in member | Manage job bookmarks |
> 
> ---
> 
> ## Important Business Rules
> 
> - Expired postings automatically drop from bookmark list.
> - Global job bookmarks may overlap with job portal Saved Jobs tab for employer listings; C2C offers appear on Saved Jobs tab but not necessarily here **Unknown / requires product clarification**.
> - Removing bookmark does not withdraw job applications.
> 
> ---
> 
> ## Related Features
> 
> - [Bookmarks — All](bookmarks-all.md)
> - [Job Portal — Saved Jobs](job-portal-bookmarked.md)
> - [Job Portal — Job Offers Listings](job-portal-offers.md)
> - [Job Portal — Job Posting Detail](job-portal-detail.md)

---

## Page: FAQs — General
- URL: https://freiburger-bund.com/en/faqs/general
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/faqs-general.md
- Updated: 2026-09-21

### Purpose
Answer common questions about the Freiburger Bund platform as a whole, organized in a searchable-by-category accordion with portal-specific tabs for deeper help areas.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> Also serves as the landing destination when users visit the FAQ hub (`/faqs` redirects here).
> 
> ## Features
> 
> ### FAQ hub redirect
> 
> **What it does**
> 
> Visiting the bare FAQ hub URL immediately redirects to the General tab with locale preserved.
> 
> **User flow**
> 
> 1. User opens FAQ hub from footer or navigation.
> 2. User lands on General FAQs without seeing empty hub content.
> 
> **Rules**
> 
> - Server-side redirect before render.
> - Deep links should target `/faqs/general` or a specific tab for stable bookmarks.
> 
> **States**
> 
> - Redirect always; no standalone hub content.
> 
> ---
> 
> ### CMS header slot
> 
> **What it does**
> 
> Editable rich-text area above tabs for titles, introductions, or banners managed in content administration.
> 
> **User flow**
> 
> 1. User reads optional CMS intro before FAQ tabs.
> 
> **Rules**
> 
> - Content shared across FAQ tab routes via same page content entry.
> - Renders in initial slot only.
> 
> **States**
> 
> - Populated CMS blocks or empty slot.
> 
> ---
> 
> ### Four-tab navigation
> 
> **What it does**
> 
> Horizontal tab bar: General · Info · Community · Job with active tab underline indicator.
> 
> **User flow**
> 
> 1. User clicks tab to switch FAQ section.
> 2. Active tab highlighted; labels translated per site language.
> 
> **Rules**
> 
> - Scrollable on small screens.
> - No sign-in required to switch tabs.
> 
> **States**
> 
> - General active on this page.
> 
> ---
> 
> ### Section heading
> 
> **What it does**
> 
> Displays portal-specific section title above accordion (General on this tab).
> 
> **User flow**
> 
> 1. User confirms which FAQ collection they are viewing.
> 
> **Rules**
> 
> - Heading translated per locale.
> 
> **States**
> 
> - “General” label (localized).
> 
> ---
> 
> ### Category-grouped accordion
> 
> **What it does**
> 
> Two-level accordion: category headers collapse/expand; questions within open category also collapse/expand with formatted markdown answers.
> 
> **User flow**
> 
> 1. User opens a category (chevron indicator).
> 2. User opens a question (plus/minus indicator).
> 3. User reads answer with links, lists, and emphasis.
> 
> **Rules**
> 
> - Only one category open at a time; opening another closes previous.
> - Only one question open at a time in interaction model.
> - All categories start collapsed on first load.
> - Category order reversed from source order; items within category also reversed.
> - No in-page search or filter.
> 
> **States**
> 
> - All collapsed initially; expanded category/question pairs.
> 
> ---
> 
> ### FAQ data filtering
> 
> **What it does**
> 
> Loads questions filtered to general portal type from FAQ content source.
> 
> **User flow**
> 
> 1. User sees only general-platform FAQs, not other portal types.
> 
> **Rules**
> 
> - Categories from content taxonomy; uncategorized items under default General label.
> - Featured FAQ highlighting not used on these pages.
> 
> **States**
> 
> - Populated accordion or silent empty (no accordion, no empty message).
> 
> ---
> 
> ### Accessibility and animation
> 
> **What it does**
> 
> Expand/collapse with spring animation; accessibility expanded/collapsed states on question buttons.
> 
> **User flow**
> 
> 1. User interacts with keyboard or screen reader friendly controls.
> 
> **Rules**
> 
> - Bidirectional text support on question text for mixed-language content.
> 
> **States**
> 
> - Animated open/close.
> 
> ---
> 
> ### Search engine structured data
> 
> **What it does**
> 
> Exposes FAQ structured markup for search engines on page and each Q&A.
> 
> **User flow**
> 
> 1. Invisible to user; improves discoverability in search results.
> 
> **Rules**
> 
> - Applied to FAQ tab pages.
> 
> **States**
> 
> - Background SEO behavior.
> 
> ---
> 
> ### Analytics tracking
> 
> **What it does**
> 
> Records category and question click events for usage analytics.
> 
> **User flow**
> 
> 1. Invisible to user on interaction.
> 
> **Rules**
> 
> - Fires on category header and question row clicks.
> 
> **States**
> 
> - Background analytics.
> 
> ---
> 
> ### Page shell
> 
> **What it does**
> 
> Standard site header (login/profile, language switcher, navigation) and footer; desktop full footer with newsletter; mobile newsletter strip.
> 
> **User flow**
> 
> 1. Guest and signed-in user see identical FAQ content; header differs only by auth menu.
> 
> **Rules**
> 
> - Public page; no authentication gate.
> 
> **States**
> 
> - Standard site chrome.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - FAQ hub redirect
> - Footer FAQ links, header navigation
> - Direct URL (localized equivalents per language)
> 
> **Outbound**
> 
> - [FAQs — Info](faqs-info.md), [Community](faqs-community.md), [Job](faqs-job.md) tabs
> - Links within markdown answers to portals or external resources
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full FAQ read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - FAQ hub never shows content; always redirects to General.
> - Empty FAQ data yields no accordion without explicit empty-state message.
> - Users cannot submit new questions from FAQ pages.
> - Content is static FAQ entries, not live portal data.
> 
> ---
> 
> ## Related Features
> 
> - [FAQs — Info](faqs-info.md)
> - [FAQs — Community](faqs-community.md)
> - [FAQs — Job](faqs-job.md)
> - [Contact Us](contact-us.md)

---

## Page: FAQs — Info Portal
- URL: https://freiburger-bund.com/en/faqs/info
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/faqs-info.md
- Updated: 2026-09-21

### Purpose
Provide self-service answers about the Info portal—articles, journey phases, and guidance topics—using the shared FAQ accordion with Info-filtered content.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Shared FAQ shell
> 
> **What it does**
> 
> Same CMS header slot, four-tab navigation, section heading, accordion interaction, accessibility, SEO structured data, analytics, and page shell as General FAQs.
> 
> **User flow**
> 
> 1. User switches to Info tab or lands via direct link.
> 2. User experiences identical accordion UX with Info-specific content.
> 
> **Rules**
> 
> - See [FAQs — General](faqs-general.md) for full cross-tab behavior.
> - Info tab active on this page.
> 
> **States**
> 
> - Info tab highlighted.
> 
> ---
> 
> ### Info portal FAQ content
> 
> **What it does**
> 
> Loads questions filtered to info portal type covering articles, phases, bookmarks, and guidance themes.
> 
> **User flow**
> 
> 1. User browses categories such as visa, recognition, relocation when configured in content administration.
> 2. User reads answers that may link to info articles or external resources.
> 
> **Rules**
> 
> - Categories reflect info-specific themes when authored.
> - Does not show live article lists or journey progress.
> 
> **States**
> 
> - Populated accordion or silent empty.
> 
> ---
> 
> ### Localized tab URL
> 
> **What it does**
> 
> Info tab reachable under locale-specific FAQ paths (e.g. localized “info” segment per language).
> 
> **User flow**
> 
> 1. User accesses in chosen site language with canonical slug correction if needed.
> 
> **Rules**
> 
> - Language switcher uses per-locale alternates.
> 
> **States**
> 
> - Locale-appropriate URL and labels.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - FAQ tab navigation from other FAQ sections
> - Info portal help links, footer
> - Direct URL
> 
> **Outbound**
> 
> - Other FAQ tabs
> - [Info Portal — Phase](info-portal-phase.md) (via answer links)
> - [Contact Us](contact-us.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - Static FAQ content only; not a substitute for browsing the info portal.
> - Same accordion rules: one open category, one open question, all collapsed initially.
> - No authentication required.
> 
> ---
> 
> ## Related Features
> 
> - [FAQs — General](faqs-general.md)
> - [Info Portal — Phase](info-portal-phase.md)
> - [Info Portal — Article](info-portal-article.md)

---

## Page: FAQs — Community Portal
- URL: https://freiburger-bund.com/en/faqs/community
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/faqs-community.md
- Updated: 2026-09-21

### Purpose
Provide self-service answers about community features—channels, threads, events, moderation, and participation—using the shared FAQ accordion with community-filtered content.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Shared FAQ shell
> 
> **What it does**
> 
> Same CMS header, tab bar, accordion UX, SEO, analytics, and public access as other FAQ tabs with Community tab active.
> 
> **User flow**
> 
> 1. User opens Community FAQ tab from navigation or direct link.
> 
> **Rules**
> 
> - See [FAQs — General](faqs-general.md) for full accordion and shell behavior.
> 
> **States**
> 
> - Community tab highlighted.
> 
> ---
> 
> ### Community portal FAQ content
> 
> **What it does**
> 
> Loads questions filtered to community portal type covering channels, threads, events, bookmarks, and guidelines.
> 
> **User flow**
> 
> 1. User browses community-themed categories when configured.
> 2. User reads step-by-step answers with markdown formatting.
> 
> **Rules**
> 
> - Does not surface live threads, channels, or events.
> - Guest-readable without community membership.
> 
> **States**
> 
> - Populated accordion or silent empty.
> 
> ---
> 
> ### Entry from community context
> 
> **What it does**
> 
> Serves as help destination linked from community footer and support paths.
> 
> **User flow**
> 
> 1. User seeks guidance while using community portal.
> 
> **Rules**
> 
> - Cross-linked from community-related navigation.
> 
> **States**
> 
> - Static help content.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - FAQ tabs, community help links, footer
> - Direct URL (localized)
> 
> **Outbound**
> 
> - Other FAQ tabs
> - [Community Portal — Phase](community-portal-phase.md) (via answer links)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - No live community data on FAQ page.
> - Same single-open accordion interaction model.
> - No ability to submit questions from this page.
> 
> ---
> 
> ## Related Features
> 
> - [FAQs — General](faqs-general.md)
> - [Community Portal — Phase](community-portal-phase.md)
> - [Contact Us](contact-us.md)

---

## Page: FAQs — Job Portal
- URL: https://freiburger-bund.com/en/faqs/job
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/faqs-job.md
- Updated: 2026-09-21

### Purpose
Provide self-service answers about job search, applications, CV tools, alerts, and employer features using the shared FAQ accordion with job-filtered content.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### Shared FAQ shell
> 
> **What it does**
> 
> Same CMS header, tab bar, accordion UX, SEO, analytics, and public access as other FAQ tabs with Job tab active.
> 
> **User flow**
> 
> 1. User opens Job FAQ tab from navigation or direct link.
> 
> **Rules**
> 
> - See [FAQs — General](faqs-general.md) for full accordion and shell behavior.
> 
> **States**
> 
> - Job tab highlighted.
> 
> ---
> 
> ### Job portal FAQ content
> 
> **What it does**
> 
> Loads questions filtered to job portal type covering listings, applications, documents, alerts, and colleague offers.
> 
> **User flow**
> 
> 1. User browses job-themed categories when configured.
> 2. User reads answers that may link to job tools or employer resources.
> 
> **Rules**
> 
> - Does not show live job listings or application status.
> - No employer-only FAQ segregation on page (filter is portal type, not user role).
> 
> **States**
> 
> - Populated accordion or silent empty.
> 
> ---
> 
> ### Entry from job context
> 
> **What it does**
> 
> Reachable from job portal help links and site footer for job seekers and employers.
> 
> **User flow**
> 
> 1. User seeks help while using job portal.
> 
> **Rules**
> 
> - Guest-readable without job seeker account.
> 
> **States**
> 
> - Static help content.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - FAQ tabs, job portal help links, footer
> - Direct URL (localized)
> 
> **Outbound**
> 
> - Other FAQ tabs
> - [Job Portal — Home](job-portal.md), [Application Tools](job-portal-tools.md) (via answer links)
> - [Company — Entry](company-entry.md) (employer topics in answers)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> | Employer | Same FAQ content; employer-specific tasks live in company area |
> 
> ---
> 
> ## Important Business Rules
> 
> - Static FAQ only; not a substitute for job portal tools.
> - Markdown answers may include application checklists as lists.
> - Same accordion interaction rules as all FAQ tabs.
> 
> ---
> 
> ## Related Features
> 
> - [FAQs — General](faqs-general.md)
> - [Job Portal — Home](job-portal.md)
> - [Company — Entry](company-entry.md)

---

## Page: Contact Us
- URL: https://freiburger-bund.com/en/contact-us
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/contact-us.md
- Updated: 2026-09-21

### Purpose
Let visitors reach the organization through a CMS-composed contact page with optional introductory content blocks and a validated contact form for inquiries across general, community, job, and IT support topics.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### CMS page composition
> 
> **What it does**
> 
> Assembles page from configurable blocks: page header, breadcrumb, rich content, text-and-image hero, section banner, image banner, call-to-action, media, and reusable content snippets—in any order editors choose.
> 
> **User flow**
> 
> 1. User reads introductory sections above the form.
> 2. User follows optional CTA buttons to internal or external destinations.
> 
> **Rules**
> 
> - Fully CMS-managed without code changes for layout updates.
> - Unpublished page shows not-found; empty layout shows header and footer only.
> 
> **States**
> 
> - Populated blocks, blank body, not-found.
> 
> ---
> 
> ### Breadcrumb navigation
> 
> **What it does**
> 
> Home → Contact trail with clickable earlier segments and structured breadcrumb data for search engines.
> 
> **User flow**
> 
> 1. User clicks Home to return to homepage.
> 
> **Rules**
> 
> - Current page shown as active non-clickable segment.
> 
> **States**
> 
> - Breadcrumb visible when block configured.
> 
> ---
> 
> ### Contact form — personal fields
> 
> **What it does**
> 
> Collects salutation (Mr, Ms, Prefer not to say, Other), first name, last name, and email address.
> 
> **User flow**
> 
> 1. User completes required personal fields.
> 
> **Rules**
> 
> - Salutation defaults to Mr.
> - First name, last name, and email required.
> - Email format validated.
> - No profile prefill for signed-in users; defaults only.
> 
> **States**
> 
> - Empty form, validation errors, populated fields.
> 
> ---
> 
> ### Contact form — subject and message
> 
> **What it does**
> 
> Subject dropdown (General info, Community, Job, IT support, Other) and required multiline message.
> 
> **User flow**
> 
> 1. User selects subject category.
> 2. User writes message (approximately five visible rows).
> 
> **Rules**
> 
> - Subject defaults to General info.
> - Message required.
> 
> **States**
> 
> - Validation on empty message.
> 
> ---
> 
> ### Privacy consent
> 
> **What it does**
> 
> Required checkbox with link to Privacy Policy opening in new tab.
> 
> **User flow**
> 
> 1. User must check consent before submit.
> 
> **Rules**
> 
> - Submit blocked without consent.
> 
> **States**
> 
> - Unchecked blocks submit.
> 
> ---
> 
> ### Form submission
> 
> **What it does**
> 
> Submit button with sending state, success toast with full form reset, or error toast with message.
> 
> **User flow**
> 
> 1. User clicks submit.
> 2. Button shows sending label and disables during submission.
> 3. Success resets all fields to defaults; failure shows retry guidance.
> 
> **Rules**
> 
> - No login required; guests and members use identical form.
> 
> **States**
> 
> - Default, sending, success, error.
> 
> ---
> 
> ### Page shell and SEO
> 
> **What it does**
> 
> Standard header, footer, newsletter areas; SEO title, description, and social preview image from CMS; localized URL with canonical slug correction.
> 
> **User flow**
> 
> 1. User switches language via header switcher.
> 
> **Rules**
> 
> - Content cached and refreshed periodically for performance.
> - Draft preview for editors only until published.
> 
> **States**
> 
> - Public live content vs editor preview.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Footer contact links, header navigation, CTAs on other pages
> - Direct URL (localized: e.g. contact, kontakt)
> 
> **Outbound**
> 
> - [Privacy Policy](privacy-policy.md) (consent link, new tab)
> - [Home](home.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full form access |
> | Signed-in member | Same form; no auto-fill from profile |
> 
> ---
> 
> ## Important Business Rules
> 
> - All form fields except salutation/subject defaults are user-entered each time.
> - Privacy consent mandatory with link to privacy policy.
> - Subject routing helps internal triage (Community, Job, IT support, Other).
> - CMS blocks optional; form appears only when contact form block configured.
> 
> ---
> 
> ## Related Features
> 
> - [Privacy Policy](privacy-policy.md)
> - [FAQs — General](faqs-general.md)
> - [Partnership](partnership.md)

---

## Page: Terms of Use
- URL: https://freiburger-bund.com/en/terms-conditions
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/terms-conditions.md
- Updated: 2026-09-21

### Purpose
Publish the legally binding terms and conditions governing use of the Freiburger Bund platform as a read-only CMS document referenced during registration and footer legal navigation.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### CMS legal document
> 
> **What it does**
> 
> Renders full terms text from rich content blocks with headings, lists, links, and emphasis editable in content administration.
> 
> **User flow**
> 
> 1. User reads long-form legal prose on desktop or mobile.
> 2. User follows cross-links to related policies where referenced in copy.
> 
> **Rules**
> 
> - Read-only for visitors; no forms or interactive elements required.
> - Unpublished page shows not-found.
> 
> **States**
> 
> - Populated document, blank body if no blocks, not-found.
> 
> ---
> 
> ### Page header and breadcrumb
> 
> **What it does**
> 
> Document title (e.g. Terms and Conditions) and Home → Terms breadcrumb with search-engine structured trail.
> 
> **User flow**
> 
> 1. User orients via breadcrumb back to Home.
> 
> **Rules**
> 
> - Labels configurable per language in CMS.
> 
> **States**
> 
> - Header and breadcrumb when blocks configured.
> 
> ---
> 
> ### Optional CMS blocks
> 
> **What it does**
> 
> Editors may add section header banner, media blocks, CTAs to registration or contact, or reusable legal boilerplate snippets.
> 
> **User flow**
> 
> 1. User may see visual banner or supplementary CTAs above/below main text.
> 
> **Rules**
> 
> - Block combination entirely editorial.
> 
> **States**
> 
> - Optional blocks present or omitted.
> 
> ---
> 
> ### Localized URLs and canonical slugs
> 
> **What it does**
> 
> Per-language URLs (e.g. German terms path, French conditions path) with silent correction to canonical slug when visitor uses outdated localized path.
> 
> **User flow**
> 
> 1. User accesses terms in chosen language via language switcher alternates.
> 
> **Rules**
> 
> - No full page reload on canonical slug correction.
> 
> **States**
> 
> - Locale-appropriate URL and content.
> 
> ---
> 
> ### SEO metadata
> 
> **What it does**
> 
> Configurable page title, description, and social preview image from CMS meta fields.
> 
> **User flow**
> 
> 1. Invisible to on-page user; affects search and link previews.
> 
> **Rules**
> 
> - Included in sitemap with language alternates.
> 
> **States**
> 
> - CMS-configured meta.
> 
> ---
> 
> ### Registration and footer references
> 
> **What it does**
> 
> Linked from account registration acknowledgment and site footer legal column.
> 
> **User flow**
> 
> 1. User opens terms from registration flow or footer to read full document.
> 
> **Rules**
> 
> - Registration requires acknowledging terms elsewhere; this page is reference document.
> 
> **States**
> 
> - Public access; no sign-in gate.
> 
> ---
> 
> ### Page shell
> 
> **What it does**
> 
> Standard global header, footer, newsletter, and cookie banner (references privacy/legal pages separately).
> 
> **User flow**
> 
> 1. Guest and signed-in user see identical terms content.
> 
> **Rules**
> 
> - Printable long-form styling.
> 
> **States**
> 
> - Standard site chrome.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - [Register](register.md) terms acknowledgment link
> - Footer legal links
> - Direct URL (localized)
> 
> **Outbound**
> 
> - [Home](home.md)
> - [Privacy Policy](privacy-policy.md), [Legal Notice](legal-notice.md) (via in-document links)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - Terms content version controlled in CMS; version history for editors not exposed to end users.
> - Scheduled publishing supported for future effective dates.
> - Cookie banner references privacy/legal pages, not terms directly.
> 
> ---
> 
> ## Related Features
> 
> - [Privacy Policy](privacy-policy.md)
> - [Legal Notice](legal-notice.md)
> - [Register](register.md)

---

## Page: Privacy Policy
- URL: https://freiburger-bund.com/en/privacy-policy
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/privacy-policy.md
- Updated: 2026-09-21

### Purpose
Explain how personal data is collected, used, stored, and protected—including cookies and user rights—as a CMS-managed policy linked from forms, cookie consent, and footer legal navigation.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### CMS privacy document
> 
> **What it does**
> 
> Rich content blocks for policy sections: data collected, purposes, cookies, retention, user rights, international transfers, contact for data requests, etc.
> 
> **User flow**
> 
> 1. User reads policy sections in editorial order.
> 
> **Rules**
> 
> - Read-only public document.
> - Unpublished → not-found.
> 
> **States**
> 
> - Populated, blank, not-found.
> 
> ---
> 
> ### Page header and breadcrumb
> 
> **What it does**
> 
> Policy title and Home → Privacy breadcrumb with structured data for search engines.
> 
> **User flow**
> 
> 1. User navigates back to Home via breadcrumb.
> 
> **Rules**
> 
> - Per-language breadcrumb labels from CMS.
> 
> **States**
> 
> - Standard legal page header pattern.
> 
> ---
> 
> ### Cross-site references
> 
> **What it does**
> 
> Linked from contact form consent checkbox (new tab), cookie banner, cookie settings modal, consultation forms, registration flows, and footer legal links.
> 
> **User flow**
> 
> 1. User opens privacy policy from consent or settings contexts.
> 
> **Rules**
> 
> - Primary reference document for data processing transparency.
> 
> **States**
> 
> - Public access from multiple entry points.
> 
> ---
> 
> ### Optional CMS blocks
> 
> **What it does**
> 
> Banner, media infographic, CTA to contact or cookie settings, reusable shared policy snippets.
> 
> **User flow**
> 
> 1. User may see introductory banner or visual summary before full text.
> 
> **Rules**
> 
> - Editorial configuration only.
> 
> **States**
> 
> - Optional blocks.
> 
> ---
> 
> ### Localized URLs and SEO
> 
> **What it does**
> 
> Per-locale slugs with canonical correction; configurable meta title, description, Open Graph image; sitemap with alternates.
> 
> **User flow**
> 
> 1. User reads policy in selected site language.
> 
> **Rules**
> 
> - Per-language content versions in CMS.
> 
> **States**
> 
> - Locale-specific URL and body.
> 
> ---
> 
> ### In-document cross-links
> 
> **What it does**
> 
> Policy copy may link to Legal Notice and Terms where cross-referenced.
> 
> **User flow**
> 
> 1. User follows links to related legal pages.
> 
> **Rules**
> 
> - Markdown-style rich links in content blocks.
> 
> **States**
> 
> - Inline navigation to related legal docs.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - [Contact Us](contact-us.md) form consent
> - Cookie banner and settings
> - [Register](register.md) and other form consents
> - Footer legal links
> 
> **Outbound**
> 
> - [Legal Notice](legal-notice.md)
> - [Terms of Use](terms-conditions.md)
> - [Contact Us](contact-us.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - Privacy policy is authoritative reference for contact form and cookie consent links.
> - No user input on page itself.
> - Content editable without deployment; scheduled publishing supported.
> 
> ---
> 
> ## Related Features
> 
> - [Legal Notice](legal-notice.md)
> - [Terms of Use](terms-conditions.md)
> - [Contact Us](contact-us.md)

---

## Page: Legal Notice
- URL: https://freiburger-bund.com/en/legal-notice
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/legal-notice.md
- Updated: 2026-09-21

### Purpose
Fulfill statutory transparency requirements (Impressum / legal notice) by publishing organization identity, contact, registration, and responsible-party information as a CMS-managed public page.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### CMS statutory content
> 
> **What it does**
> 
> Rich content blocks for company name, address, registration numbers, VAT, responsible persons, and other legally required disclosures.
> 
> **User flow**
> 
> 1. User reads legal notice information for regulatory compliance context.
> 
> **Rules**
> 
> - Read-only public page.
> - Unpublished → not-found.
> 
> **States**
> 
> - Populated, blank, not-found.
> 
> ---
> 
> ### Page header and breadcrumb
> 
> **What it does**
> 
> Legal Notice title and Home → Legal Notice breadcrumb with SEO structured trail.
> 
> **User flow**
> 
> 1. User returns to Home via breadcrumb.
> 
> **Rules**
> 
> - German locale commonly uses Impressum labeling.
> 
> **States**
> 
> - Standard legal page pattern.
> 
> ---
> 
> ### Cookie and footer integration
> 
> **What it does**
> 
> Linked from cookie banner alongside Privacy Policy and from cookie settings modal footer; included in site footer legal column.
> 
> **User flow**
> 
> 1. User opens from cookie consent or footer legal links.
> 
> **Rules**
> 
> - Required legal transparency page in EU/German context.
> 
> **States**
> 
> - Public access.
> 
> ---
> 
> ### Optional CMS blocks
> 
> **What it does**
> 
> Section banner, contact details block, CTA to Contact page, reusable organization boilerplate.
> 
> **User flow**
> 
> 1. User may see visual header or contact shortcut above statutory text.
> 
> **Rules**
> 
> - May duplicate organization details also in global footer.
> 
> **States**
> 
> - Optional editorial blocks.
> 
> ---
> 
> ### Localized URLs and SEO
> 
> **What it does**
> 
> Per-locale paths (e.g. Impressum, mentions légales) with canonical slug sync; CMS meta and sitemap alternates.
> 
> **User flow**
> 
> 1. User accesses in selected language.
> 
> **Rules**
> 
> - Typically shorter document than Terms/Privacy but same block toolkit available.
> 
> **States**
> 
> - Locale-specific URL and content.
> 
> ---
> 
> ### Page shell
> 
> **What it does**
> 
> Standard header with language switcher; desktop and mobile footer variants.
> 
> **User flow**
> 
> 1. Guest and member see identical legal notice.
> 
> **Rules**
> 
> - No authentication or forms on page.
> 
> **States**
> 
> - Standard site chrome.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Cookie banner and settings
> - Footer legal links
> - Direct URL (localized)
> 
> **Outbound**
> 
> - [Home](home.md)
> - [Contact Us](contact-us.md)
> - [Privacy Policy](privacy-policy.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - Legal notice satisfies statutory disclosure obligations; content is editor-maintained.
> - Scheduled publishing and version history for editors not shown to public.
> - Cross-referenced from cookie UX as mandatory legal link.
> 
> ---
> 
> ## Related Features
> 
> - [Privacy Policy](privacy-policy.md)
> - [Terms of Use](terms-conditions.md)
> - [Contact Us](contact-us.md)

---

## Page: Press
- URL: https://freiburger-bund.com/en/press
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/press.md
- Updated: 2026-09-21

### Purpose
Provide journalists and visitors with press room content—releases, media guidelines, assets, and partner logos—through a CMS-composed public page.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### CMS press room layout
> 
> **What it does**
> 
> Combines page header, breadcrumb, rich content, text-and-image hero, image card grids, logo cloud, media blocks, testimonial carousel, banner, and CTA blocks per editorial configuration.
> 
> **User flow**
> 
> 1. User browses press releases, boilerplate about text, and media resources.
> 2. User follows CTAs to contact press team or download media kit.
> 
> **Rules**
> 
> - Unpublished → not-found; empty layout → header/footer only.
> 
> **States**
> 
> - Populated press content, blank, not-found.
> 
> ---
> 
> ### Image cards section
> 
> **What it does**
> 
> Desktop grid of press items; mobile accordion cards expanding image and description on tap.
> 
> **User flow**
> 
> 1. User expands mobile accordion or scans desktop grid for press stories.
> 
> **Rules**
> 
> - Responsive presentation of same content.
> 
> **States**
> 
> - Grid vs accordion by breakpoint.
> 
> ---
> 
> ### Logo cloud
> 
> **What it does**
> 
> Partner or media logo strip with title and subtitle in centered responsive wrap.
> 
> **User flow**
> 
> 1. User scans affiliated media or partner logos.
> 
> **Rules**
> 
> - Empty logo list may render section shell without logos.
> 
> **States**
> 
> - Populated logos or empty shell.
> 
> ---
> 
> ### Testimonial carousel
> 
> **What it does**
> 
> Member or partner quotes in carousel when testimonials configured in content source.
> 
> **User flow**
> 
> 1. User reads quotes when present.
> 
> **Rules**
> 
> - Section hidden entirely when no testimonials available.
> 
> **States**
> 
> - Visible carousel vs hidden section.
> 
> ---
> 
> ### Media and banner blocks
> 
> **What it does**
> 
> Standalone images with captions, downloadable asset previews, full-width promotional banners with optional app store badges.
> 
> **User flow**
> 
> 1. User views or downloads press assets where linked.
> 
> **Rules**
> 
> - Analytics may track CTA and banner link clicks.
> 
> **States**
> 
> - Optional blocks per CMS config.
> 
> ---
> 
> ### Optional contact form
> 
> **What it does**
> 
> Editors may embed contact or consultation form block for press inquiries.
> 
> **User flow**
> 
> 1. User submits inquiry if form block present.
> 
> **Rules**
> 
> - Press page does not require form; editorial choice.
> 
> **States**
> 
> - With or without embedded form.
> 
> ---
> 
> ### Localized URLs and SEO
> 
> **What it does**
> 
> Per-locale press paths; canonical slug correction; CMS meta and sitemap alternates.
> 
> **User flow**
> 
> 1. User accesses press room in selected language.
> 
> **Rules**
> 
> - Public; no journalist authentication gate.
> 
> **States**
> 
> - Locale-specific content.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Footer Press link, external PR campaigns
> - Direct URL (localized)
> 
> **Outbound**
> 
> - [Contact Us](contact-us.md)
> - [Partnership](partnership.md)
> - [Home](home.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - Press content is marketing/informational unless form block added for inquiries.
> - Testimonials and logo sections empty-safe (hidden or shell-only).
> - Does not expose member-only or employer-only data.
> 
> ---
> 
> ## Related Features
> 
> - [Contact Us](contact-us.md)
> - [Partnership](partnership.md)
> - [About Us](about-us.md)

---

## Page: Sponsors
- URL: https://freiburger-bund.com/en/sponsor
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/sponsor.md
- Updated: 2026-09-21

### Purpose
Showcase organizations and supporters who sponsor the Freiburger Bund through a CMS-managed page centered on logo displays, acknowledgements, and optional calls to become a sponsor.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### CMS sponsors showcase
> 
> **What it does**
> 
> Combines page header, breadcrumb, logo cloud (primary feature), rich content for tiers and criteria, text-and-image hero, image cards, purpose section, testimonials, banner, media blocks, CTA, and reusable snippets.
> 
> **User flow**
> 
> 1. User views sponsor logos and acknowledgement copy.
> 2. User follows “Become a sponsor” CTA to contact or external form when configured.
> 
> **Rules**
> 
> - Read-only showcase unless form block added.
> - Unpublished → not-found.
> 
> **States**
> 
> - Populated showcase, blank, not-found.
> 
> ---
> 
> ### Logo cloud block
> 
> **What it does**
> 
> Centered responsive grid of sponsor logos with optional title and subtitle.
> 
> **User flow**
> 
> 1. User scans sponsor organizations visually.
> 
> **Rules**
> 
> - Empty logo list still renders section shell without logos.
> 
> **States**
> 
> - Logos present or empty shell.
> 
> ---
> 
> ### Image cards and purpose section
> 
> **What it does**
> 
> Sponsor spotlights as desktop grid with mobile accordion; values or impact statements as icon cards.
> 
> **User flow**
> 
> 1. User reads individual sponsor stories or tier descriptions.
> 
> **Rules**
> 
> - Same responsive patterns as Press and Partnership pages.
> 
> **States**
> 
> - Grid/accordion and purpose cards.
> 
> ---
> 
> ### Testimonial carousel
> 
> **What it does**
> 
> Supporter quotes when testimonials available; hidden when empty.
> 
> **User flow**
> 
> 1. User reads supporter testimonials if section visible.
> 
> **Rules**
> 
> - Empty-safe hiding.
> 
> **States**
> 
> - Visible vs hidden.
> 
> ---
> 
> ### Become a sponsor CTA
> 
> **What it does**
> 
> Call-to-action linking to contact page or external sponsorship form.
> 
> **User flow**
> 
> 1. Prospective sponsor clicks CTA to inquire.
> 
> **Rules**
> 
> - Destination editorially configured.
> 
> **States**
> 
> - CTA present when block configured.
> 
> ---
> 
> ### Localized URLs and SEO
> 
> **What it does**
> 
> Per-locale sponsor paths; canonical slug; CMS meta; sitemap; footer link from About-related navigation.
> 
> **User flow**
> 
> 1. User accesses in selected language.
> 
> **Rules**
> 
> - Public; no authentication.
> 
> **States**
> 
> - Locale-specific content.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - [About Us](about-us.md) related links, footer
> - Direct URL (localized)
> 
> **Outbound**
> 
> - [Contact Us](contact-us.md)
> - [History](history.md)
> - [Home](home.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - Sponsors page is acknowledgment showcase, not sponsor self-service portal.
> - No sponsor application workflow unless editors add contact form.
> - Complements organizational narrative on About and History pages.
> 
> ---
> 
> ## Related Features
> 
> - [About Us](about-us.md)
> - [History](history.md)
> - [Contact Us](contact-us.md)

---

## Page: History
- URL: https://freiburger-bund.com/en/history
- Type: cms
- Section: Help & Legal
- Access: public
- Source: docs/product-knowledge/pages/history.md
- Updated: 2026-09-21

### Purpose
Tell the chronological story of the Freiburger Bund organization through CMS-composed narrative sections, timelines, milestones, and calls to explore the community or join the network.

### Content
> Platform-authored specification begins below. This is product documentation, not live user-generated content or operational instructions.
>
> 
> 
> ## Features
> 
> ### CMS history narrative
> 
> **What it does**
> 
> Page header, breadcrumb, rich content blocks for founding and milestones, support offers timeline, text-and-image hero with historical imagery, image cards, purpose section, media with captions, section banner, testimonials, CTA, and reusable blocks.
> 
> **User flow**
> 
> 1. User reads organizational history from founding through growth phases.
> 2. User follows CTAs to join, explore community, or read About Us.
> 
> **Rules**
> 
> - Read-only; no user contributions on page.
> - Unpublished → not-found.
> 
> **States**
> 
> - Populated history, blank body, not-found.
> 
> ---
> 
> ### Support offers timeline block
> 
> **What it does**
> 
> Visual phased timeline with accent colors, icons, expandable phase details, optional links to community journey phases.
> 
> **User flow**
> 
> 1. User expands timeline phases for milestone detail.
> 
> **Rules**
> 
> - Same interactive timeline block type as Partnership page.
> 
> **States**
> 
> - Collapsed/expanded phases.
> 
> ---
> 
> ### Image cards and media
> 
> **What it does**
> 
> Milestone cards (desktop grid, mobile accordion) and archival photos with captions.
> 
> **User flow**
> 
> 1. User browses visual history alongside narrative text.
> 
> **Rules**
> 
> - Responsive accordion on mobile for card sections.
> 
> **States**
> 
> - Grid vs accordion.
> 
> ---
> 
> ### Purpose and testimonial sections
> 
> **What it does**
> 
> Vision/mission/values icon cards; historical member voice carousel when testimonials exist.
> 
> **User flow**
> 
> 1. User reads organizational values and member perspectives.
> 
> **Rules**
> 
> - Testimonials hidden when none configured.
> 
> **States**
> 
> - Purpose cards; optional carousel.
> 
> ---
> 
> ### Section header banner
> 
> **What it does**
> 
> Full-width gradient banner for dramatic history chapter introduction when configured.
> 
> **User flow**
> 
> 1. User sees visual chapter break in long history page.
> 
> **Rules**
> 
> - Optional editorial block.
> 
> **States**
> 
> - Banner present or omitted.
> 
> ---
> 
> ### Localized URLs and SEO
> 
> **What it does**
> 
> Per-locale history paths; canonical slug sync; CMS meta; sitemap; footer link when configured.
> 
> **User flow**
> 
> 1. User reads history in selected language.
> 
> **Rules**
> 
> - Complements [About Us](about-us.md) with deeper chronological detail.
> 
> **States**
> 
> - Locale-specific URL and body.
> 
> ---
> 
> ### Page shell
> 
> **What it does**
> 
> Standard header, footer, newsletter; public access for all visitors.
> 
> **User flow**
> 
> 1. Guest and member see identical history content.
> 
> **Rules**
> 
> - No authentication required.
> 
> **States**
> 
> - Standard site chrome.
> 
> ---
> 
> ## Page Navigation
> 
> **Inbound**
> 
> - Footer History link, About Us cross-links
> - Direct URL (localized: e.g. geschichte, histoire)
> 
> **Outbound**
> 
> - [About Us](about-us.md)
> - [Community Portal — Phase](community-portal-phase.md) (timeline links)
> - [Home](home.md)
> 
> ---
> 
> ## User Roles
> 
> | Role | Differences on this page |
> |------|---------------------------|
> | Guest | Full read access |
> | Signed-in member | Identical content |
> 
> ---
> 
> ## Important Business Rules
> 
> - History is editorial CMS content, not a user-generated timeline.
> - Scheduled publishing supported for content editors.
> - Interactive timeline links may connect narrative history to live community journey phases.
> 
> ---
> 
> ## Related Features
> 
> - [About Us](about-us.md)
> - [Sponsors](sponsor.md)
> - [Community Portal — Phase](community-portal-phase.md)

---