Navigation Rules

Per-screen overrides for the navigation schema the CLI uploaded. The CLI scans your code and gets the structural picture (screen names, routes, basic params); navigation rules are where you add the editorial layer the AI needs to suggest screens well — auth requirements, descriptions, deeplinks.

The Editorial Layer

The CLI can name screens and infer some structure, but it can’t know whether a screen is “the login screen” or “the cart” without context. Without that, the AI either suggests irrelevant screens or refuses to suggest them at all. Navigation rules close that gap:

• Description is the most-impactful field. The AI reads it to decide whether to suggest the screen for a given user message. Vague descriptions cause vague matching.
• Access type (public / authenticated / unauthenticated / restricted) controls auth-gating. See Filtering by Auth State for what each value does at runtime.
• Deeplink is the URL the SDK navigates to (or your onNavigationAction callback receives). Override here when the CLI’s auto-detected route is wrong.

Re-uploading After Edits

When you re-upload the schema with qafka upload, your overrides are preserved — the merge logic detects user-edited fields and keeps them, refreshing only the AI-inferred or auto-detected portions. This means you can keep iterating on your code’s navigation structure without losing the editorial layer you’ve built up.

When AI Suggests vs You Decide

If you ran qafka analyze --deep, the AI populates an inferred description and access type per screen. Those are visible alongside your overrides — the AI’s suggestion stays as a “draft” the user can accept, modify, or ignore. Your override always wins at runtime.